From nobody Wed Aug 1 05:38:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112B7130DFC for ; Wed, 1 Aug 2018 05:38:14 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTArCBULFtpu for ; Wed, 1 Aug 2018 05:38:08 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C50127332 for ; Wed, 1 Aug 2018 05:38:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41gXsB45vZz15K6G; Wed, 1 Aug 2018 14:38:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D9KnTa5pKiw; Wed, 1 Aug 2018 14:38:04 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.24] (i577BCE12.versanet.de [87.123.206.18]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 1 Aug 2018 14:38:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Proposal to replace ACK block count with ACK length From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 1 Aug 2018 14:38:01 +0200 Cc: Subodh Iyengar , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , Ian Swett , Marten Seemann , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson , Kazuho Oku Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B86D457@ORSMSX111.amr.corp.intel.com> To: "Deval, Manasi" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-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 Aug 2018 12:38:14 -0000 Hi Manasi, this idea sounds really interesting, however, I believe that in most = cases the segmenting would still be needed to be done by the higher = layer because the data frames need to be =E2=80=9Esmall=E2=80=9C enough = to fit in a segment and I believe that in many cases the frame size = would be chosen to exactly fill the segment size, thus there are not = much options to segment differently in the kernel. Or do you have = another scenario in mind? Mirja > Am 15.07.2018 um 21:14 schrieb Deval, Manasi : >=20 > I think if ACKs are sent every 20 to 40 packets, they require the = segmentation code to care about them.=20 >=20 > Also from talking to various folks I heard different things. Some = implementations like to piggyback the ack with data while others keep = ACK separate. In my understanding, the piggybacked ask is used for = bandwidth restricted cases where they avoid padding.=20 >=20 > This is also an excellent question for the implementers and deployers = on this list. >=20 > Thanks, > Manasi >=20 >=20 > On Jul 15, 2018, at 1:15 PM, Subodh Iyengar wrote: >=20 >> Hi Manasi, >> Doesn't the segmentation make more sense for stream frames than ACK = frames? ACK frames are not sent very often and at least in production = what we've seen is that most of the time ACKs naturally end up getting = sent in their own pure ACK packets.=20 >>=20 >> Not arguing for or against the length prefix design, but trying to = understand why having a length prefix in the ACK frame helps = segmentation for stream frames even on the recv side. >>=20 >> Subodh >> From: QUIC on behalf of Deval, Manasi = >> Sent: Saturday, July 14, 2018 8:35:14 PM >> To: 'Mikkel Fahn=C3=B8e J=C3=B8rgensen'; Eric Rescorla; Kazuho Oku >> Cc: Jana Iyengar; Praveen Balasubramanian; Ian Swett; Marten Seemann; = IETF QUIC WG; Martin Thomson >> Subject: RE: Proposal to replace ACK block count with ACK length >> =20 >> Hi All, >> =20 >> I would like to revisit this discussion in the context of distributed = processing. The distributed processing doesn=E2=80=99t only apply to = multi-threading but also to layered processing. >> =20 >> One example of layered processing is segmentation. The current = Chromium implementation currently creates the segments and passes them = as a bunch into the Linux kernel. There is a GSO patch that would chop = at the segment boundary and encapsulate in UDP headers. We can further = improve performance by plugging in a smarter segmentation algorithm such = that the segment processing can account for type of frame, its size and = make intelligent boundary and padding decisions at a lower layer or in = an offload. To this end, the algorithm needs to identify the size of = each of the frames. Having an ACK length that can be determined in a = single read is much more efficient than having to do a series of reads.=20= >> =20 >> Thanks, >> Manasi >> =20 >> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]=20= >> Sent: Friday, June 22, 2018 9:15 AM >> To: Eric Rescorla ; Kazuho Oku >> Cc: Jana Iyengar ; IETF QUIC WG ; = Deval, Manasi ; Marten Seemann = ; Martin Thomson ; = Ian Swett ; Praveen Balasubramanian = >> Subject: Re: Proposal to replace ACK block count with ACK length >> =20 >> Another option is to write out frames as is without length except as = needed for varints. When a packet is nearly done, a run-length encoded = frame index is placed in the packet tail. It could also include the = frame types. A reader can now directly find or skip ACK frames and the = writer does not have to compute lengths before writing. Of course, the = reader needs to be able to locate the index at the tail which can be = tricky with coalesced packets, but not impossible. Isn=E2=80=99t this = largely how zip-files work? >> =20 >> Mikkel >> =20 >> On 22 June 2018 at 17.00.52, Mikkel Fahn=C3=B8e J=C3=B8rgensen = (mikkelfj@gmail..com) wrote: >>=20 >> As I said earlier, I also favour a length prefix. But, Ian does have = a point: >> =20 >> Writing data is generally more expensive than reading data. = Especially if you have to traverse long data structures to find the = length before you can start writing and/or you may have to = conservatively reserve extra space for a length field. >> =20 >> So before deciding one way or the other, the cost of writing needs to = be well understood, also in scenarios with large MTU=E2=80=99s. >> =20 >> In the flatbuffers space that I=E2=80=99m involved with, streaming = has turned to be an issue because data cannot be transmitted in parts = without index data on a separate channel to recombined fragments. A = simple, but non-standard, change in the format would fix this. JSON and = CoAP allows streaming, but many other formats do not, including later = versions of protocol buffers, as I understand. >> =20 >> An odd consequence of making both read and write efficient is that = length better work better if stored at the end and packets read = backwards. This requires a single total length prefix but this is stored = in the datagram header. This is probably too odd-ball, but still a = consideration worth noting. >> =20 >> The second best alternative may therefore be to allow writes to be = fast and reads to be decent. >> =20 >> Yet, I still like length prefixes if they could be made write = efficient because high performance low-latency processes care zero about = ACK and can consume a packet directly while a background process handles = all the latency insensitive ACK and retransmission logic. >> =20 >> The question is also, where is the pressure: an IoT aggregator might = be massively read intensive while a web cache would be very write = intensive. >> =20 >> =20 >> Kind Regards, >> Mikkel Fahn=C3=B8e J=C3=B8rgensen >>=20 >> =20 >> On 22 June 2018 at 15.12.09, Eric Rescorla (ekr@rtfm.com) wrote: >>=20 >> It seems like there are two questions at hand here: >> =20 >> 1. Would it be architecturally better to have frames have a = consistent self-contained >> representation? >> 2. Is it enough better that we should do so now. >> =20 >> I agree with Kazuho that (a) we don't have that representation now = and (b) it would >> be a better design to do so. I'm perhaps somewhat more positive on = (2) than he >> is. I don't think it's critically important that we make the change, = but if we were >> to hold a consensus call, I think I would be in favor. I'd certainly = be interested >> in looking at a proposal if someone else were to make one. >> =20 >> -Ekr >> =20 >> =20 >> =20 >> On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku = wrote: >> 2018-06-22 8:08 GMT+09:00 Deval, Manasi : >> > I feel that the requirement to have every value valid is somewhat = academic. >>=20 >> I think that Marten is correct in pointing out that making the ACK >> frame self-containing (by having a field that represents the number = of >> octets being consumed by the frame) would be an exception from the >> design pattern we have. >>=20 >> Look at STREAM frame. The field is not self-contained. Instead, it = has >> a Length field for the Stream Data, which is a leaf. The same goes = for >> NEW_CONNECTION_ID frame (that has the length field for Connection ID >> field (which is also a leaf)), CONNECTION_CLOSE (length field for >> Reason Phase). >>=20 >> I agree with Marten, Mikkel (and possibly others as well) that having >> consistency is important. >>=20 >> Therefore, I agree with Mikkel that we should consider making every >> frame self-contained or keeping every frame as-is (i.e. not >> self-contained). >>=20 >> FWIW, as described in the latter half of >> https://www.ietf.org/mail-archive/web/quic/current/msg04287.html, it >> is possible to make every frame self-contained *and* also make ACK >> frames smaller than the current draft. Making every frame >> self-contained gives us the possibility to send new extension frames >> without negotiation. >>=20 >> I do not think that I would push for making every frame = self-contained >> by myself (because I do not think it meets the high bar to have a >> change at such a late moment of standardization), but as stated, my >> preference goes to seeing every frame made self-contained or none of >> them made as such. >>=20 >> > The length value provides much more value than the block count and = the fact >> > that certain values can never be achieved is an inherent property = of the >> > length. >> > >> > >> > >> > One interesting observation is that this property is not limited to = length. >> > One can even make a similar argument about ACK block count. The = maximum >> > number of ACK blocks that can be defined will not always have a = meaningful >> > value. In out examples, 0,1,2,3 are all valid. If I set the value = of ACK >> > block count to have lower two bits to be 11, the maximum value is = of ACK >> > blocks is =E2=80=93 4611686018427387903. This is the same value of = largest >> > acknowledged so if the ACK block count was set to this value, it = would still >> > be meaningless. >> > >> > >> > >> > Thanks, >> > >> > Manasi >> > >> > >> > >> > >> > >> > >> > >> > From: Marten Seemann [mailto:martenseemann@gmail.com] >> > Sent: Tuesday, June 19, 2018 6:44 PM >> > To: Deval, Manasi >> > Cc: Ian Swett ; Kazuho Oku = ; Eric >> > Rescorla ; Jana Iyengar ; Praveen >> > Balasubramanian ; IETF QUIC WG = ; Martin >> > Thomson >> > >> > >> > Subject: Re: Proposal to replace ACK block count with ACK length >> > >> > >> > >> > Hi Manasi, >> > >> > >> > >> >> The risk of disagreement between ack blocks and ack block count is = same as >> >> the risk of disagreement between ack blocks and ack length. Either = way this >> >> needs to be counted up while creating the ACK and counted down = while parsing >> >> it. The possibility of error is the same. Getting the ack block = count wrong >> >> is as problematic as getting the ack length wrong. Do you agree? >> > >> > >> > >> > I disagree. Let's take an example of an ACK frame with one ACK = range, that >> > needs a 2 byte varint to represent the First ACK Block and another = 2 byte >> > varint to represent the Gap. >> > >> > With your proposal: >> > >> > The values 0 and 1 are invalid, since the length fields itself is = included >> > in the length. >> > The values 2, 3, ..., (2 + len(LargestAcknowledged) + = len(AckDelay)) - 1 are >> > invalid, since the length needs to include the Largest Acknowledged = and the >> > Ack Delay. >> > The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the = first >> > valid value, and correspond to an ACK frame with no blocks. >> > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is = invalid, since >> > it would cut the varint for the First ACK Block >> > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is = invalid, since >> > it would cut the frame after the First ACK Block (but every block = must be >> > followed by a gap length) >> > The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is = invalid, since >> > it would cut the varint for the Gap >> > Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 = is valid >> > >> > There are *a lot* of invalid values that you can encode into the = ACK length >> > field. More importantly, *none* of these error cases exists with = the current >> > frame format. >> > >> > The *only* error case that can occur with our current format is = that the >> > packet is too short for the number of ACK blocks that are supposed = to >> > contained in the frame. This can occur with your proposal as well = (in >> > addition to the error cases listed above). >> > >> > >> > >> > My concern is not that it's impossible or even particularly hard to = catch >> > these errors, but I dislike the property that some (in fact, most) = encodable >> > values are invalid. >> > >> > >> > >> > Best, >> > >> > Marten >> > >> > >> > >> > >> > >> > On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi = >> > wrote: >> > >> > Hi Ian, >> > >> > >> > >> > Here is another attempt to solve the objections you raised: >> > >> > >> > >> >>I'm not a fan of this proposal, because I think it is impractical = to drop >> >> the number of ack blocks, because with the ECN proposal it becomes >> >> impractically complex to parse. >> > >> > Is there a reason the proposal from Christian does not solve this = problem? >> > >> > >> > >> >>If we don't remove the number of ack blocks, then the ack frame is = larger, >> >> but I don't think the extra size field is useful for most = implementations. >> >> Also, it means the length can disagree with the actual length, = which add >> >> complexity and the possibility of writing error-prone code. The = idea of >> >> someone offloading ack processing and then proceeding to trust the = length >> >> seems like someone could get wrong and cause some concerning = issues. >> > >> > The risk of disagreement between ack blocks and ack block count is = same as >> > the risk of disagreement between ack blocks and ack length. Either = way this >> > needs to be counted up while creating the ACK and counted down = while parsing >> > it. The possibility of error is the same. Getting the ack block = count wrong >> > is as problematic as getting the ack length wrong. Do you agree? >> > >> > >> > >> >>My experience is multithreaded packet processing is more cost and = work than >> >> it's worth. Sure you can't fill a 100G NIC with one connection, = but that >> >> seems like an academic problem, not one for workloads I've seen. = Typically >> >> the extra cost of multithreading outweighs its value. >> > >> > The value is two fold =E2=80=93 pre-processing and multi-threading. = If we >> > pre-process the received packets such that ACKs and streams can be >> > coalesced, the receive side can indicate a large chunk of = information though >> > the kernel, reducing the cost of system call and protocol overhead. = This is >> > the same concept as UDP segmentation taken a step further on = receive side. >> > After this chunk is indicated into the QUIC protocol, the protocol = may >> > process stream and ACK in parallel. While folks may or may not = utilize this, >> > there is an advantage here. >> > >> > >> > >> > Thanks, >> > >> > Manasi >> > >> > >> > >> > >> > >> > From: Ian Swett [mailto:ianswett@google.com] >> > Sent: Tuesday, June 19, 2018 11:26 AM >> > To: Deval, Manasi >> > Cc: Marten Seemann ; Kazuho Oku >> > ; Eric Rescorla ; Jana Iyengar >> > ; Praveen Balasubramanian = ; IETF >> > QUIC WG ; Martin Thomson >> > >> > >> > Subject: Re: Proposal to replace ACK block count with ACK length >> > >> > >> > >> > I'm still not interested in this change, for the reasons I stated = above. >> > >> > >> > >> > On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi = >> > wrote: >> > >> > Hi All, >> > >> > >> > >> > Do we have agreement here to create a new PR? >> > >> > >> > >> > Thanks, >> > >> > Manasi >> > >> > >> > >> > From: Deval, Manasi >> > Sent: Sunday, June 17, 2018 2:25 PM >> > To: Marten Seemann ; Kazuho Oku >> > >> > Cc: Ian Swett ; Eric = Rescorla >> > ; Jana Iyengar ; Praveen = Balasubramanian >> > ; IETF QUIC WG ; Martin Thomson >> > >> > Subject: RE: Proposal to replace ACK block count with ACK length >> > >> > >> > >> > Hi All, >> > >> > >> > >> > I have made a list of objections to the proposal and the solutions = to those >> > objections discussed on this thread. >> > >> > >> > >> > a. Co-existence of length field with ECN field and ACK blocks. >> > >> > >> > >> > Christian suggested to move the ECN fields to precede the ACK = blocks. This >> > is an elegant solution. Parsing entire list of ACK blocks to review = ECN bits >> > would have been annoying, even though it can work. >> > >> > >> > >> > b. There are two cases to be parsed =E2=80=93 entire ACK and = parse ACK to >> > identify length. There are some reservations when ACK parsing gets = harder >> > for the case where the entire header needs to be parsed. >> > >> > >> > >> > Agreement from several folks here. In the original ACK defined in = draft 12 >> > of the slide, one would count down number of ACK blocks to get to = the end of >> > the packet. In the proposal I made, one would count down the length = to >> > identify the end of the packet. The logic is very similar in cycle = count and >> > complexity. Several folks also commented to this effect. >> > >> > >> > >> > c. Multi-threaded packet processing >> > >> > >> > >> > I would expect that there are 10s of 1000s of connections in use at = any time >> > for a server with a high speed link. Multi-threading to handle each = of these >> > flows / connections in parallel is necessity to be able to support = large >> > number of connections on a high speed link. Tx segmentation, Rx = coalescing >> > are well known strategies to reduce the processing cost. In initial = stages, >> > code is often written as a single-threaded and then re-factored to >> > parallelize cycle intensive operations. In order to allow this = protocol to >> > scale in future, I would suggest we do not preclude this case. >> > >> > >> > >> > d. Increase in ACK size by 1 byte. >> > >> > >> > >> > I do not see this as a serious issue but if folks but we can = consider making >> > this a varint, if others have strong feelings about it. It=E2=80=99s = a trade-off : 2 >> > reads to save 1 byte. >> > >> > >> > >> > e. Every encodable value should be valid >> > >> > Not every length will be valid. This is inherent to lengths. This = same issue >> > ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only = does the issue exist for >> > small values, it also applies to large values since data stream = will be sent >> > after crypto negotiation. E.g. - how does one craft a payload = with 62 bit >> > payload length in a large header? >> > >> > >> > >> > >> > >> > Thanks, >> > >> > Manasi >> > >> > >> > >> > >> > >> > From: Marten Seemann [mailto:martenseemann@gmail.com] >> > Sent: Sunday, June 17, 2018 6:59 AM >> > To: Kazuho Oku >> > Cc: Ian Swett ; Eric = Rescorla >> > ; Jana Iyengar ; Praveen = Balasubramanian >> > ; IETF QUIC WG ; Martin Thomson >> > ; Deval, Manasi >> > Subject: Re: Proposal to replace ACK block count with ACK length >> > >> > >> > >> > Maybe it's specific to Go, but I'm using a single io.Reader for the = whole >> > packet, so as long as the packet payload is long enough, the varint = parsing >> > will not fail. >> > >> > I don't think that specifics of programming languages matter here = though, >> > and I'm sure both frame formats can be reasonably implemented in C = as well >> > as in Go. The reasons I'm opposed to Manasi's proposal are that it = moves us >> > away from the principle that only reasonable values should be = encodable, and >> > that it increases the size of the ACK frame, for the questionable = benefit of >> > being able to parallelise the frame parser. >> > >> > >> > >> > On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku = wrote: >> > >> > 2018-06-17 22:36 GMT+09:00 Marten Seemann = : >> >> At least for my implementation, parsing doesn't become easier, it = becomes >> >> more complex with this proposal. My varint-parser always consumes = as many >> >> bytes as the varint requires, so after parsing a varint, I'd have = to >> >> introduce an additional check that this didn't overflow the ACK = length >> >> (e.g. >> >> consider that I parsed the ACK frame so far that only 2 bytes are >> >> remaining >> >> according to ACK length field, but the next varint is 4 bytes = long). >> > >> > Isn't your varint parser checking that it has not (or will not) run >> > across the end of the packet payload for every ACK block it parses? >> > I'd assume that you would be doing that, because I think that is >> > necessary to avoid buffer overrun. >> > >> > What I am saying that that check could be converted to a overrun = check >> > against the end of the "frame payload", and that checking the >> > remaining block count becomes unnecessary, in case we replace ACK >> > Block Count with ACK Frame Length. >> > >> >> >> >> In general, we've been moving the wire image towards making every >> >> encodable >> >> value valid. This proposal moves us away from that principle: >> >> * some small values are always invalid (the length can never be = between 0 >> >> and 3) >> >> * a lot of intermediate values are invalid (if the boundary falls = inside a >> >> varint, as described above) >> >> Both these cases can't occur with the current ACK frame format.. >> >> >> >> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku = wrote: >> >>> >> >>> 2018-06-17 8:34 GMT+09:00 Ian Swett >> >>> : >> >>> > I'm not a fan of this proposal, because I think it is = impractical to >> >>> > drop >> >>> > the number of ack blocks, because with the ECN proposal it = becomes >> >>> > impractically complex to parse. >> >>> >> >>> For the ECN proposal, as Christian has suggested, we can move the = ECN >> >>> counters before the ACK blocks. Then, it would not be complex to >> >>> parse. >> >>> >> >>> And my view is that parsing becomes easier if we replace ACK = Block >> >>> Count with ACK Frame Length. >> >>> >> >>> Now, with ACK Block Count, we need to check the remaining number = of >> >>> blocks and the remaining space in the packet payload for every = block >> >>> that we parse. Failing to check either leads to a bug or a = security >> >>> issue. >> >>> >> >>> If we switch to ACK Frame Length, we need to only check the = remaining >> >>> space in the frame. >> >>> >> >>> I think that this is the biggest benefit of replacing ACK Block = Count >> >>> with ACK Frame Length. OTOH the downside is that you need extra = one to >> >>> two bits (one if the size of block / gap is expected to be below = 65, >> >>> two if they are expected to be above that) for encoding ACK Frame >> >>> Length compared to ACK Block Count. >> >>> >> >>> >> >>> >> >>> Having said that, I honestly wonder if all the frames could have = it's >> >>> length being encoded (either explicitly or either as a signal = that >> >>> says "to the end of the packet"). Consider something like below: >> >>> >> >>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) = | >> >>> or >> >>> |1| frame-type (7) | frame-payload (*) | >> >>> >> >>> When MSB of the first octet set to zero, the length of the frame >> >>> payload is designated by the varint that immediately follows the = frame >> >>> type. >> >>> When MSB of the first octet set to one, the length of the frame >> >>> payload spans to the end of the packet. >> >>> >> >>> In this encoding, we can always omit the Length field of a STREAM >> >>> frame. So the overhead for carrying stream data will be = indifferent in >> >>> practice. >> >>> >> >>> For the ACK frame, we can omit the ACK Block Count field. And the >> >>> overhead will be one to two bits if the ACK frame is sent in the >> >>> middle of the packet (thereby using the encoding with explicit = frame >> >>> payload length), or one octet or more shorter if ACK is the last = frame >> >>> of the packet. >> >>> >> >>> We are likely to see increase of overhead for most of the other = types >> >>> of frames, but I do not think that would be an issue considering = that >> >>> they will be far seldom seen compared to STREAMs and ACKs. >> >>> >> >>> To summarize, my anticipation is that we can make all the frames >> >>> self-contained (i.e. the length can be determined without the >> >>> knowledge of how each frame is encoded) without any overhead, if = we >> >>> agree on making the frame type space 1 bit smaller. >> >>> >> >>> Finally, the biggest benefit of using a self-contained encoding = of >> >>> frames is that we would have the ability to introduce new = optional >> >>> frames without negotiation. By making the frames self-contained, = QUIC >> >>> endpoints will have the freedom of ignoring the frames that they = do >> >>> not understand. >> >>> >> >>> Being able to send QUIC frames defined in extensions without >> >>> negotiating using Transport Parameters will be a win in both = terms of >> >>> security (because clients' TP is sent in clear) and flexibility >> >>> (because we will be possible to send the extensions before we = figure >> >>> out whether the peer supports that extension). >> >>> >> >>> > If we don't remove the number of ack blocks, then the ack frame = is >> >>> > larger, >> >>> > but I don't think the extra size field is useful for most >> >>> > implementations. >> >>> > Also, it means the length can disagree with the actual length, = which >> >>> > add >> >>> > complexity and the possibility of writing error-prone code. = The idea >> >>> > of >> >>> > someone offloading ack processing and then proceeding to trust = the >> >>> > length >> >>> > seems like someone could get wrong and cause some concerning = issues. >> >>> > >> >>> > My experience is multithreaded packet processing is more cost = and work >> >>> > than >> >>> > it's worth. Sure you can't fill a 100G NIC with one = connection, but >> >>> > that >> >>> > seems like an academic problem, not one for workloads I've = seen. >> >>> > Typically >> >>> > the extra cost of multithreading outweighs its value. >> >>> > >> >>> > To be clear, I don't think this is an awful idea, but I also = don't see >> >>> > the >> >>> > value and it adds complexity. I read Manasi's email, but I = don't think >> >>> > I >> >>> > understand why any of those matter in practice. >> >>> > >> >>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla = wrote: >> >>> >> >> >>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann >> >>> >> >> >>> >> wrote: >> >>> >>> >> >>> >>> This proposal increases the size of the ACK frame by 1 byte = in the >> >>> >>> common >> >>> >>> case (less than 63 ACK ranges), since the ACK length field = here >> >>> >>> always >> >>> >>> consumes 2 bytes, whereas the ACK Block Count is a = variable-length >> >>> >>> integer. >> >>> >>> Considering how much work we put into minimising the size of = the >> >>> >>> frames, >> >>> >>> this feels like a step in the wrong direction.. >> >>> >>> >> >>> >>> Regarding the processing cost, I agree with Dmitri. Handling = an ACK >> >>> >>> frame >> >>> >>> requires looping over and making changes to a data structure = that >> >>> >>> keeps >> >>> >>> track of sent packets. This is much more expensive than = simply >> >>> >>> parsing >> >>> >>> a >> >>> >>> bunch of varints in the ACK frame. It seems unlikely that a >> >>> >>> multi-threaded >> >>> >>> packet parser would offer any real-world performance = benefits. >> >>> >> >> >>> >> >> >>> >> I don't want to overstate the benefit here, but my point isn't = that >> >>> >> parsing is expensive but that if you want to have a = multithreaded >> >>> >> packet >> >>> >> processing system, then it's nice to have a simpler data = structure >> >>> >> (the >> >>> >> unparsed ACK block) to hand to the ACK processing thread. >> >>> >> >> >>> >> -Ekr >> >>> >> >> >>> >> >> >>> >>> >> >>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson >> >>> >>> >> >>> >>> wrote: >> >>> >>>> >> >>> >>>> When we discussed this before, some people observed that = this >> >>> >>>> creates >> >>> >>>> a need to encode in two passes. That's the trade-off here. = (Not >> >>> >>>> expressing an opinion.) >> >>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar = >> >>> >>>> wrote: >> >>> >>>> > >> >>> >>>> > I don't have a strong opinion on this. I'm certainly not = opposed >> >>> >>>> > to >> >>> >>>> > it. >> >>> >>>> > Does anyone have a strong opposition? >> >>> >>>> > >> >>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian >> >>> >>>> > wrote: >> >>> >>>> >> >> >>> >>>> >> I agree as well since this can help reduce per packet = processing >> >>> >>>> >> overhead. ACKs are going to be the second most common = frame type >> >>> >>>> >> so no >> >>> >>>> >> objections to special casing. >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of = Eric >> >>> >>>> >> Rescorla >> >>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM >> >>> >>>> >> To: Deval, Manasi >> >>> >>>> >> Cc: Jana Iyengar ; QUIC WG = >> >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK = length >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> I agree with Manasi here. This change would allow ack = frame >> >>> >>>> >> parsing >> >>> >>>> >> to be more self-contained, which is an advantage for the = parser >> >>> >>>> >> and also >> >>> >>>> >> potentially for parallelism (because you can quickly find = the >> >>> >>>> >> frame and then >> >>> >>>> >> process it in parallel). >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> -Ekr >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi >> >>> >>>> >> wrote: >> >>> >>>> >> >> >>> >>>> >> In general, varints require some specific logic for = parsing. To >> >>> >>>> >> skip >> >>> >>>> >> over any header, I have to read every single varint. As = the code >> >>> >>>> >> sees Stream >> >>> >>>> >> and ACK headers most frequently, that is my focus. The = Stream >> >>> >>>> >> frame has a >> >>> >>>> >> length in its third field. >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to = identify >> >>> >>>> >> length. There are two reads each for =E2=80=98largest = acknowledged=E2=80=99, =E2=80=98ACK >> >>> >>>> >> delay=E2=80=99 and >> >>> >>>> >> =E2=80=98ACK block count=E2=80=99. The pain point is the = total number of cycles >> >>> >>>> >> parse an >> >>> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the = packets >> >>> >>>> >> have a >> >>> >>>> >> piggybacked ACK, these cycles becomes a significant = bottleneck. >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> Thanks, >> >>> >>>> >> >> >>> >>>> >> Manasi >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of = Jana >> >>> >>>> >> Iyengar >> >>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM >> >>> >>>> >> To: Deval, Manasi ; QUIC WG >> >>> >>>> >> >> >>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK = length >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> You're right that we no longer have the ability to skip = an ACK >> >>> >>>> >> frame, >> >>> >>>> >> and this crept in when we moved to varints. >> >>> >>>> >> >> >>> >>>> >> I believe your problem though is generally true of most = frames >> >>> >>>> >> not >> >>> >>>> >> just ACKs, since ids, packet numbers, and numbers in all = frames >> >>> >>>> >> are now all >> >>> >>>> >> varints. To skip any frame, you'll need to parse the = varint >> >>> >>>> >> fields >> >>> >>>> >> in those >> >>> >>>> >> frames. If you have logic to process and skip varints, = then >> >>> >>>> >> skipping the ack >> >>> >>>> >> block section is merely repeating this operation = (2*num_block+1) >> >>> >>>> >> times. Do >> >>> >>>> >> you see specific value in skipping ACK frames over the = other >> >>> >>>> >> control frames? >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >> >>> >>>> >> wrote: >> >>> >>>> >> >> >>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi = wrote: >> >>> >>>> >> > - Moving the ACK length to the front of the ACK = allows >> >>> >>>> >> > the >> >>> >>>> >> > flexibility of either reading the entire ACK = or >> >>> >>>> >> > reading >> >>> >>>> >> > the >> >>> >>>> >> > first 16 bits and skipping over the length. = This is a >> >>> >>>> >> > useful >> >>> >>>> >> > feature for the case where ACK processing is = split >> >>> >>>> >> > into >> >>> >>>> >> > multiple layers. Depending on the processor = this is >> >>> >>>> >> > run >> >>> >>>> >> > on, >> >>> >>>> >> > there are different advantages - >> >>> >>>> >> >> >>> >>>> >> Just a note. In my experience, the cost of parsing an = ACK frame >> >>> >>>> >> is >> >>> >>>> >> negligible compared to the cost of processing an ACK = frame: that >> >>> >>>> >> is, >> >>> >>>> >> poking at various memory locations to discard newly ACKed >> >>> >>>> >> packets. >> >>> >>>> >> >> >>> >>>> >> - Dmitri. >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >>> >> >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> Kazuho Oku >> > >> > >> > >> > -- >> > Kazuho Oku >>=20 >>=20 >>=20 >> -- >> Kazuho Oku From nobody Wed Aug 1 05:54:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC43127332 for ; Wed, 1 Aug 2018 05:54:26 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8OfNsdEtZtQ for ; Wed, 1 Aug 2018 05:54:23 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183AA130DFC for ; Wed, 1 Aug 2018 05:54:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41gYCx4hJxz15K3S; Wed, 1 Aug 2018 14:54:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH2eZA-58OTK; Wed, 1 Aug 2018 14:54:20 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.24] (i577BCE12.versanet.de [87.123.206.18]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 1 Aug 2018 14:54:20 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: On the relation between QUIC documents From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <1f54ada2-c0e2-2664-1137-b3382fa7a605@nccgroup.trust> Date: Wed, 1 Aug 2018 14:54:19 +0200 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2C8536C6-5581-453A-8371-7DA1A82BF7B1@tik.ee.ethz.ch> References: <1f54ada2-c0e2-2664-1137-b3382fa7a605@nccgroup.trust> To: Mathias Hall-Andersen X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-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 Aug 2018 12:54:26 -0000 Hi Mathias, the group concluded a while ago that version 1 (or whatever this first = IETF version will be called) of QUIC will use TLS and using a different = encryption scheme will require to specify a new QUIC version. However, = the TLS part is still in an separate document to make the specification = on a new version with just a different crypto as easy as possible. However, I do agree that there are some cases where the separation could = be even more clear (e.g. the key phase bit is an example) and maybe = requirements should be spelled out separately in order to make is easier = to evolve to a new crypto scheme when needed. The PNE, however, is in my = opinion separate enough from the payload encryption that is should stay = in the transport draft itself. Mirja > Am 12.07.2018 um 20:56 schrieb Mathias Hall-Andersen = : >=20 > Hi QUIC WG. >=20 > I wish to discuss the relation between QUIC design documents,=20 > as well as the relation between QUIC and TLS more generally. >=20 > Currently the draft-ietf-quic-transport and draft-ietf-quic-tls = documents both depend on each other, > the remainder of this text details my rationale for desiring a more > clear delegation of responsibilities between these two documents: >=20 > I suggest that draft-ietf-quic-transport should describe a (semi = formal) > interface between the transport component and the cryptographic = component,=20 > by listing a series of criteria for the handshake and the packet = protection.. > The draft-ietf-quic-tls would be an implementation meeting these = criteria and > the draft-ietf-quic-transport should reference draft-ietf-quic-tls as = an example. >=20 > Essentially the standard would become a version of quic-transport = instantiated with a version of quic-tls. >=20 > The advantages of having a more clear relation between the two = documents include: >=20 > 1. Allowing the documents to evolve independently, > by having changes to the internals of the TLS document not affect = the transport document. >=20 > 2. Encourage people to create implementations which better separate = the two, > which might make it easier to swap in different / future = implementations of the handshake & packet protection. >=20 > 3. Clearly stating what properties we expect the handshake and packet = protection to satisfy. > This might also make formal analysis easier, by showing that the = TLS instantiation satisfies these properties. > We might even be able to state what a handshake should satisfy = formally in a proof assistant. >=20 > 4. Permitting the construction of alternate handshakes satisfying the = criteria. >=20 > I have compiled a list of some sections which currently violate this = relation: >=20 > ------ >=20 > The "Key Phase Bit" is mentioned in the draft-ietf-quic-transport = document, > but not described herein, instead the document refers to = draft-ietf-quic-tls. >=20 > It is unclear if this bit has any definition outside a QUIC + TLS = context, > instead it could be a "PACKET_PROTECTION_FLAG" bit in the transport = document, > which is used as the "KEY_PHASE" bit in the QUIC-TLS instantiation of > the handshake & packet protection. >=20 > ------ >=20 > "The packet number has confidentiality protection separate from > packet protection, as described in Section 5.6 of [QUIC-TLS]." >=20 > Could be replaced with something like: >=20 > "The protector MAY provide confidentiality for packet numbers. > This protection is separate from the packet protection and SHOULD = achieve the following: XYZ. >=20 > Example: > The TLS based handshake [QUIC-TLS], section is one example which = satisfies the aforementioned properties." >=20 > ------ >=20 > "The payload is protected using authenticated encryption. > [QUIC-TLS] describes packet protection in detail. After decryption, = the > plaintext consists of a sequence of frames, as described in > Section 5." >=20 > Might become: >=20 > "The payload is protected using authenticated encryption > offering at least 128-bits of security, using the packet header as AD = and ... >=20 > Example: > [QUIC-TLS], section A.B.C, describes in detail an implementation = satisfying these criteria" >=20 > ------ >=20 > "For the most part, the cryptographic handshake protocol [QUIC-TLS] is > responsible for detecting tampering during the handshake, though > additional validation is required for version negotiation (see = Section 6.6.4)." >=20 > QUIC-TLS is referred to as THE cryptographic handshake,instead we = should > aim to have a section more in the vain of: >=20 > "The cryptographic handshake MUST ensure that XYZ > Additional validation is required for version negotiation (see = Section 6.6.4)." >=20 > Examples of XYZ, might include the authenticity of all data sent in = CRYPTO frames. >=20 > ------ >=20 > "The Initial packet is protected by Initial keys as described in > [QUIC-TLS]." >=20 > This should be part of the description of the packet protect > requirements, something like: >=20 > "The packet protector MAY make an effort to obfuscate the contents of = initial packets, > to help prevent version aware middleboxes from parsing...." >=20 > - Mathias >=20 From nobody Wed Aug 1 10:17:34 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7544B130DF2 for ; Wed, 1 Aug 2018 10:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 nFMcuI2gWo9q for ; Wed, 1 Aug 2018 10:17:30 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04on070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4d::70e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18345129C6B for ; Wed, 1 Aug 2018 10:17:30 -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:X-MS-Exchange-SenderADCheck; bh=VWs/mC8p8q6uVNDzSWaE99PvA8A4ZO6z+UCMk2scjso=; b=JWMiEzaFM5lox7xSXOivsF26GIN/EzoT8MLG9n6TreRMD4K0Jlc0pf/XuF1kCH6o9FsmhE5vUvBy8o+Nmgy3Kf+GJtcrZWA2KSHb6NklCgg4MBSVRzIZeDewkLmv7OHiQJoIj1s3w43dwX/YC8U0uq1Kx7U0p4mezB63ONmfoXw= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1013.namprd21.prod.outlook.com (52.132.133.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.7; Wed, 1 Aug 2018 17:17:28 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::60b8:4702:aa5f:f00]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::60b8:4702:aa5f:f00%3]) with mapi id 15.20.1038.003; Wed, 1 Aug 2018 17:17:28 +0000 From: Nick Banks To: Tommy Pauly , "quic@ietf.org" , Eric Rescorla , Kazuho Oku CC: Dmitri Tikhonov , Martin Thomson , Patrick McManus Subject: RE: Go Back to Single Packet Number Space Thread-Topic: Go Back to Single Packet Number Space Thread-Index: AdQkTBwat6Uz522HTCmlcfdQS0RX0wANbUcAAALJdwAAAvnmgAAAQ0HqABhGVQABLz4MnA== Date: Wed, 1 Aug 2018 17:17:28 +0000 Message-ID: References: <20180726030135.GA19322@ubuntu-dmitri> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.235.10.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1013; 6:ELA4TSAaUcRt0OYIDIK4n82YBZqBjHu1TI3VzGYVh0srBq8awvpWYWMncsPcDmBhNIDmphvduvewk2mAPUsC3lzxUmirkwMx2TmgVC07VZwy7ogQia0ZTGgxY0PV3yC/2nFGRHlbI+9glF9+5lJJTjfnQ37OLHfgCYvvU7f8245LdDJmHS7TbsONSvL/y4pNdoP5ZaezgzGWSBJjdk7QgLFoq+bwZHZP1AL6HxqOrTHHoFs/SC9o54hZaH+LSKOTXCAp/axxbi4kpwRE4UnBp6vearzeRlh/JziRnXQk7rU5FFLCmnLUigw2SwNPb9Q/Qh0dnw5fkD7bdY1eFf5ULoQDEdB7ov/lBoph7KsCxw+43g3Pd7PTDH3T+v6gEpTWgjHuYa8mx915r8ydss38IrlRRD/AgG3cbr4xrjJximhZ5KyXZDqquIOyU6pGmcz9PW2uFweGONJDNBt02j7S9g==; 5:dD3YlM/NzJTtNux0aQd17QqLImnUssMUYCaUcHBzfbs0gtJYbv8H5vZnSllDqhKGs0vtysr9McYNJKFY/0Qxr684i1npSkVgENBHsg0QioBihsR0TH7U1zkXyoR+kbFJQ5kwCj3sTGBqlkcbfLsaMGALa4KI6mXQaxYgqNo81w8=; 7:ziQqCrhvUNttQLGlRwcQK2KBbyB+3+WbFWX9Oa6/tHer9PCElNMFe+xOOdjR+b5UxP5BfAhlqaftFdt71KWdqs18Il39yoRF1a6les27QZFz01fo1d3FSPte/YVk1nG6beGmf6s+QHYSktkh+fj7xvUoKK4zmr8OLdIYR6wYgS8JRHnqlgh22tYayAM3lZ092IXNXhxxTv5Eue9jmw6thcdrPqS9UxNNX6hnS9/JEOQE5l+aDIxDL1cTM9MiGzFG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a4d3c5ed-2474-4613-1fdc-08d5f7d2a86c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:DM5PR2101MB1013; x-ms-traffictypediagnostic: DM5PR2101MB1013: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(80524489315369)(158342451672863)(156600954879566)(166708455590820)(192374486261705)(189930954265078)(219752817060721)(31960201722614); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(2018427008)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB1013; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1013; x-forefront-prvs: 0751474A44 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(396003)(39860400002)(346002)(189003)(199004)(33656002)(11346002)(2501003)(186003)(66066001)(486006)(476003)(8936002)(446003)(105586002)(2906002)(5660300001)(86362001)(86612001)(14444005)(575784001)(8676002)(106356001)(256004)(561944003)(6116002)(5250100002)(54906003)(3846002)(68736007)(74316002)(7736002)(2900100001)(478600001)(93886005)(10290500003)(81166006)(966005)(81156014)(53936002)(6436002)(14454004)(8990500004)(110136005)(229853002)(55016002)(54896002)(236005)(9686003)(6306002)(39060400002)(97736004)(25786009)(99286004)(7696005)(102836004)(316002)(10090500001)(22452003)(4326008)(606006)(6246003)(53546011)(76176011)(26005)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1013; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: mUWVp9pydcYYym7yEQj1FnWh2p86ysNXJw4RK6z20V2faLfSbKrhM3mqsJJKU/MmhWhzdKy4z/VJ/1UQUujOidQVmqm1Nm8SYblAPnBk0S3EDafUNv99BAIcbBEoXOqVHWeNAMV/WSDSqYGxwQve4yIGNrEbSvWp7N1mJVbvJwGkoPxhQEqspRj6FhAR6W/PBUCQcpVHValNFrZL4y70/aw8YM+LQc6V15t5GtzANsKh7eAexJvp14p7/eMBn8np/SsY5Lv5zcKjSESOXbtbnq9ebxfCz5LzCAsrk65he4K4w4cY0ZFT4F//5aF1ANRucy1U1od6O7VmnvJH1tlmiQyRgnvBKw5SO5tFo6/Q9wo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901DF38B51EA5450B6D5F6FB32D0DM5PR2101MB0901_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4d3c5ed-2474-4613-1fdc-08d5f7d2a86c X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2018 17:17:28.2394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1013 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-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 Aug 2018 17:17:33 -0000 --_000_DM5PR2101MB0901DF38B51EA5450B6D5F6FB32D0DM5PR2101MB0901_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry for the lack of immediate follow up here. I was on vacation. I=92d li= ke to summarize what I see as the current arguments against my proposal wit= h my counters: 1. Multiple packet number spaces make it easier, theoretically, to reaso= n about the security properties for the packets. * I=92d argue that the security properties should be reasoned in ter= ms of the packet=92s encryption level/epoch and leave packet number spaces = out of it completely. In those terms, the only difference my design has is = that an acknowledgement can also be sent in a higher encryption level. 2. Folks have an uneasiness (and see it as a hack) about allowing for AC= K frames to be sent in greater than or equal encryption level. * Personally, I don=92t see this as a hack at all. To me, it seems r= easonable and intuitive to always use the more secure mechanism to acknowle= dge the information you have received so far. 3. A single packet number space may pose problems with the client=92s se= cond flight (if the Handshake packet is lost). * In the multiple packet space, if the client coalesces the Initial = packet with the ACK frame with their Handshake packet with the CRYPTO frame= , you have exactly the same issue. The server ends up with an RTO and retra= nsmits. 4. There are issues related to the security analysis if Handshake packet= s are allowed to acknowledge 1-RTT packets. * I=92d like more explanation on exactly what the issue is here. Did= previous analysis explicitly show that something like this would be a prob= lem, or has there just not been any analysis for something like this? My un= derstanding is that the Handshake keys give you trust enough to know you ar= e talking with whoever you started the conversation with, but they aren=92t= authenticated to be who they claim they are yet. Why would that level of t= rust not be acceptable to acknowledge a received packet? To summarize my claimed pros for a single packet number space: 1. There is less state (memory) to manage on both the sender and receive= r side. 2. There is less logic required for building packets to acknowledge all = the currently received packets. * I don=92t believe an implementation would need to support sending = coalesced packets to have an efficient handshake. 3. Cross encryption level loss recovery is easier to reason about and im= plement. 4. A single set of packet numbers is easier to reason about and debug. 5. Saves bytes on the wire. * 1 ACK frame for the server=92s first flight. * 1 long header packet and ACK frame for the client=92s second fligh= t. In general, I still believe the single packet number space far superior to = the multiple packet space design. I feel it has a lot of tangible benefits = over the multiple packet space design. - Nick Sent from Mail for Window= s 10 ________________________________ From: tpauly@apple.com on behalf of Tommy Pauly Sent: Thursday, July 26, 2018 9:09:24 AM To: Nick Banks Cc: Dmitri Tikhonov; quic@ietf.org; Martin Thomson Subject: Re: Go Back to Single Packet Number Space First off, I'd like to +1 to the points Kazuho made, as I think he did a ve= ry good job of expressing the concern I have. To elaborate on the point about separation of spaces making things easier t= o reason about: While the table below does indicate that there are 4 different encryption l= evels/sets of keys, there can and should be a connection between the 0-RTT = and 1-RTT spaces. | Packet Type | Encryption Level | PN Space | |:----------------|:-----------------|:----------| | Initial | Initial secrets | Initial | | 0-RTT Protected | 0-RTT | 0/1-RTT | | Handshake | Handshake | Handshake | | Retry | N/A | N/A | | Short Header | 1-RTT | 0/1-RTT | Effectively, there are three different levels of trust at play, which deter= mine the type of frame content that may be sent: - For Initial packets, there is no established trust at all - For Handshake packets, there is only the established trust that the peers= are the same ones that performed the Initial exchange; at this point it is= safe to perform authentication - For both 0-RTT and 1-RTT packets, there is the trust that the peers have = completed an authenticated handshake; only here is it safe to send applicat= ion data These three levels of trust are not specific to TLS, but a common feature o= f security handshakes. Separated packet number spaces allows an implementation to very discretely = separate its handling of frames and retransmissions between the three level= s of trust. The architecture that this promotes is one that (I hope) is les= s likely to have bugs in which frames that must only be sent in higher leve= ls of trust are sent in lower levels. Thanks, Tommy On Jul 25, 2018, at 9:37 PM, Nick Banks > wrote: Since there are four encryption levels, the fact that there are only three = packet spaces only makes things more confusing IMO.. If your argument is th= at matching them together makes things easier, then I=92d think there shoul= d be four packet spaces. I think having all this duplication and separation= just adds unnecessary complexity. Sent from my Windows 10 device [HxS - 15254 - 16.0.10325.20083] ________________________________ From: tpauly@apple.com > on behalf of Tommy Pauly > Sent: Wednesday, July 25, 2018 9:26:49 PM To: Dmitri Tikhonov Cc: Martin Thomson; Nick Banks; QUIC WG Subject: Re: Go Back to Single Packet Number Space As another implementer, I also prefer having the split packet spaces. The p= oint isn't necessarily that it's good to have the triple spaces, but rather= that it's nice to have the packet number spaces correspond tightly with th= e packet types and protection. The logic for handling a space can be treate= d more uniformly in that way, although it does involve potentially more mem= ory to store the state. Thanks, Tommy > On Jul 25, 2018, at 8:01 PM, Dmitri Tikhonov > wrote: > > On Thu, Jul 26, 2018 at 11:41:48AM +1000, Martin Thomson wrote: >> The feedback I've heard is that the simplification is subjective. >> Others have said that a single space would complicate their >> implementation considerably more. > > EKR is one of the "others" [1] -- are there other implementers who > prefer the triple packet space? > > - Dmitri. > > 1. https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgit= hub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&= ;data=3D02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b0068= 4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636681760204180396&sdata= =3DfstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&reserved=3D0 > --_000_DM5PR2101MB0901DF38B51EA5450B6D5F6FB32D0DM5PR2101MB0901_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Sorry for the lack of immediate follow up here. I wa= s on vacation. I=92d like to summarize what I see as the current arguments = against my proposal with my counters:

 

  1. Multiple packet number spaces make it easier, theoretically, to reaso= n about the security properties for the packets.
    1. I=92d argue that the security properties should be reasoned in terms = of the packet=92s encryption level/epoch and leave packet number spaces out= of it completely. In those terms, the only difference my design has is that an acknowledgement can also be sent in a = higher encryption level.
  2. Folks have an uneasiness (and see it as a hack) about allowing f= or ACK frames to be sent in greater than or equal encryption level.
    1. Personally, I don=92t see this as a hack at all. To me, it seems reas= onable and intuitive to always use the more secure mechanism to acknowledge= the information you have received so far.
  3. A single packet number space may pose problems with the client= =92s second flight (if the Handshake packet is lost).
    1. In the multiple packet space, if the client coalesces the Initial pac= ket with the ACK frame with their Handshake packet with the CRYPTO frame, y= ou have exactly the same issue. The server ends up with an RTO and retransmits.
  4. There are issues related to the security analysis if Handshake p= ackets are allowed to acknowledge 1-RTT packets.
    1. I=92d like more explanation on exactly what the issue is here. Did pr= evious analysis explicitly show that something like this would be a problem= , or has there just not been any analysis for something like this? My understanding is that the Handshake keys give = you trust enough to know you are talking with whoever you started the conve= rsation with, but they aren=92t authenticated to be who they claim they are= yet. Why would that level of trust not be acceptable to acknowledge a received packet?

 

To summarize my claimed pros for a single packet num= ber space:

 

  1. There is less state (memory) to manage on both the sender and receive= r side.
  2. There is less logic required for building packets to ackn= owledge all the currently received packets.
    1. I don=92t believe an implementation would need to support sending coa= lesced packets to have an efficient handshake.
  3. Cross encryption level loss recovery is easier to reason about a= nd implement.
  4. A single set of packet numbers is easier to reason = about and debug.
  5. Saves bytes on the wire.
    1. 1 ACK frame for the server=92s first flight.
    2. 1 long header = packet and ACK frame for the client=92s second flight.

 

In general, I still believe the single packet number= space far superior to the multiple packet space design. I feel it has a lo= t of tangible benefits over the multiple packet space design.

 

- Nick

 

Sent from Mail for Windows 10

 

From: tpauly@apple.com <= tpauly@apple.com> on behalf of Tommy Pauly <tpauly@apple.com>
Sent: Thursday, July 26, 2018 9:09:24 AM
To: Nick Banks
Cc: Dmitri Tikhonov; quic@ietf.org; Martin Thomson
Subject: Re: Go Back to Single Packet Number Space
 
First off, I'd like to +1 to the points Kazuho made, as I think he= did a very good job of expressing the concern I have.

To elaborate on the point about separation of spaces making= things easier to reason about:

While the table below does indicate that there are 4 differ= ent encryption levels/sets of keys, there can and should be a connection be= tween the 0-RTT and 1-RTT spaces. 

| Packet Type     | Encryption Level | PN Space  |
|:----------------|:-----------------|:----------|
| Initial         | Initial secrets  | Initia= l   |
| 0-RTT Protected | 0-RTT            | 0= /1-RTT   |
| Handshake       | Handshake        |&n= bsp;Handshake |
| Retry           | N/A        = ;      | N/A       |
| Short Header    | 1-RTT           &nbs= p;| 0/1-RTT   |

Effectively, there are three different levels of trust at p= lay, which determine the type of frame content that may be sent:
- For Initial packets, there is no established trust at all=
- For Handshake packets, there is only the established trus= t that the peers are the same ones that performed the Initial exchange; at = this point it is safe to perform authentication
- For both 0-RTT and 1-RTT packets, there is the trust that= the peers have completed an authenticated handshake; only here is it safe = to send application data

These three levels of trust are not specific to TLS, but a = common feature of security handshakes.

Separated packet number spaces allows an implementation to = very discretely separate its handling of frames and retransmissions between= the three levels of trust. The architecture that this promotes is one that= (I hope) is less likely to have bugs in which frames that must only be sent in higher levels of trust are sent = in lower levels.

Thanks,
Tommy

On Jul 25, 2018, at 9:37 PM, Nick Banks <nibanks=3D40microso= ft.com@dmarc.ietf.org> wrote:

Since there are four encryption levels, the fact that there are only three = packet spaces only makes things more confusing IMO.. If your argument is th= at matching them together makes things easier, then I=92d think there shoul= d be four packet spaces. I think having all this duplication and separation just adds unnecessary complexity.

 

Sent from my Windows 10 device
[HxS - 15254 - 16.0.10325.20083]

 

From: tpauly@apple.com <tpauly@a= pple.com> on behalf of Tommy Pauly <tpauly@apple.com>
Sent: W= ednesday, July 25, 2018 9:26:49 PM
To: Dmi= tri Tikhonov
Cc: Mar= tin Thomson; Nick Banks; QUIC WG
Subject: Re: Go Back to Single Packet Number Space
 
As another implementer, I also prefer having the s= plit packet spaces. The point isn't necessarily that it's good to have the = triple spaces, but rather that it's nice to have the packet number spaces c= orrespond tightly with the packet types and protection. The logic for handling a space can be treated more u= niformly in that way, although it does involve potentially more memory to s= tore the state.

Thanks,
Tommy

> On Jul 25, 2018, at 8:01 PM, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wr= ote:
> 
> On Thu, Jul 26, 2018 at 11:41:48AM +1000, Martin Thomson wrote: >> The feedback I've heard is that the simplification is subjective.<= br class=3D""> >> Others have said that a single space would complicate their
>> implementation considerably more.
> 
> EKR is one of the "others" [1] -- are there other implemente= rs who
> prefer the triple packet space?
> 
>  - Dmitri.
> 
> 1. https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-dr= afts%2Fissues%2F1579%23issuecomment-405720217&amp;data=3D02%7C01%7Cniba= nks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b00684%7C72f988bf86f141af91= ab2d7cd011db47%7C1%7C1%7C636681760204180396&amp;sdata=3DfstGdvwnKKfApVK= VQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&amp;reserved=3D0
> 


--_000_DM5PR2101MB0901DF38B51EA5450B6D5F6FB32D0DM5PR2101MB0901_-- From nobody Sat Aug 4 17:45:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD2A130E76 for ; Sat, 4 Aug 2018 17:45:27 -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=mnot.net header.b=EPsg7TRC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OwBd5TEm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzCXLLT3Nh9M for ; Sat, 4 Aug 2018 17:45:24 -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 F2432130E72 for ; Sat, 4 Aug 2018 17:45:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5F1B421F31 for ; Sat, 4 Aug 2018 20:45:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 04 Aug 2018 20:45:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=+vng4A0BE9OQfY6ra 3+04+VlOQCsO+IRCvTd4drn01I=; b=EPsg7TRCqvrtfp8TT6IzgSQO/YzAH3M9N hfvtwkzvH4H3Nm060wKlp7QXPob6C34IYufgXHrImfrXhttV8bEQISb8mEv3gbJo cwgXk4CSlMOzmyqJ4zVMSYMVwbKtGQiM8ShwLnvNeZ3F+npwufT+OE/dSG3sVPdm +9CTHjBIU1uBZxep4zn8RCMyFpL1AmqrDX5giT8zKgThs1daK9JNBjDgpBPsVIPz rPNeUpb1H/EZ7cSWVrKwfbVhenis7EBG050ZVUCR0HRl3Ez8osbPx+LzEY/6KZr3 GhTkMb3s0VCD/VAkULNvy2Cdxyj7nu8I+vWiBL6o1P2jnj1vYhrww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=+vng4A0BE9OQfY6ra3+04+VlOQCsO+IRCvTd4drn01I=; b=OwBd5TEm KgFuFsXxRd0I1XUt+QRxZdH8tI9onsDQ8n4aI4s/YB/5OzrxNgy0EBYkYzgo9uK6 XI3nVpocol8hIlnSb0sCiwgLLB/JHWF3KDZ83VSNzCE36SSbtFntZulS21Tr51gj B4aMDNDL/Cfv3eR6n/Pc1oUIn2z2Uzuc/yUtHuNkZ7pQ/ua340pnY+bK8ljgWFka nLKEX1Na0/pMihlNQgNqR/46nuNCLHKfLN/iWVFWEuiQUrFbx5sW39hWCMxXfSFL 6oMi0GYqgK+m1wGdpTEp9AFJHs7hBmIF40kSPZ1PZMYYLOPc3XFtKIjRAypuWOj8 dPUKzU/Fr+BTWg== X-ME-Proxy: X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id F2010E4511 for ; Sat, 4 Aug 2018 20:45:21 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id D5AEBC78CD for ; Sun, 5 Aug 2018 00:45:18 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============8502166173478808975==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180805004518.D5AEBC78CD@cloud.mnot.net> Date: Sun, 5 Aug 2018 00:45:18 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 00:45:27 -0000 --===============8502166173478808975== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+4/-9/=F0=9F=92=AC34) 4 issues created: - CANCEL_PUSH, MAX_PUSH_ID and GOAWAY specify the length of the ID twice = (by afrind) https://github.com/quicwg/base-drafts/issues/1620 = - Discuss application-limited congestion control in Recovery (by ianswett) https://github.com/quicwg/base-drafts/issues/1619 [-recovery] = - quic-transport: dangling reference to quic-recovery (by reschke) https://github.com/quicwg/base-drafts/issues/1618 = - quic-tls: dangling references to quic-transport (by reschke) https://github.com/quicwg/base-drafts/issues/1617 = 7 issues received 34 new comments: - #1612 are flow control frames really idempotent? (25 by kazuho, marten-= seemann, mikkelfj, siyengar, ekr, martinthomson, huitema, ianswett, MartinT= hompson, dtikhonov) https://github.com/quicwg/base-drafts/issues/1612 [-transport] [design] = - #1439 Improve ACK_ECN frame encoding (e.g., use bit-vector) (3 by kazuh= o, martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/issues/1439 [-transport] [design] = - #1620 CANCEL_PUSH, MAX_PUSH_ID and GOAWAY specify the length of the ID = twice (2 by martinthomson, afrind) https://github.com/quicwg/base-drafts/issues/1620 [-http] [design] = - #1603 qpack: acking headers that do not reference the dynamic table is = wasteful (1 by afrind) https://github.com/quicwg/base-drafts/issues/1603 [-qpack] [design] = - #1451 Looping with multiple Retry packets (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1451 [-transport] [design] = - #1486 Client's initial destination CID is unauthenticated (1 by mikkelf= j) https://github.com/quicwg/base-drafts/issues/1486 [-transport] [design] = - #1556 HTTP SETTINGS: define setting content encoding (1 by afrind) https://github.com/quicwg/base-drafts/issues/1556 [-http] = 9 issues closed: - Idle timeout interaction with RTO https://github.com/quicwg/base-drafts= /issues/1429 [-transport] [design] = - qpack: acking headers that do not reference the dynamic table is wastef= ul https://github.com/quicwg/base-drafts/issues/1603 [-qpack] [design] = - are flow control frames really idempotent? https://github.com/quicwg/ba= se-drafts/issues/1612 [-transport] [design] = - What if the packet number of a retry packet is not zero? https://github= .com/quicwg/base-drafts/issues/1448 [-transport] [design] = - Looping with multiple Retry packets https://github.com/quicwg/base-draf= ts/issues/1451 [-transport] [design] = - Retry in response to 0-RTT https://github.com/quicwg/base-drafts/issues= /1547 [-transport] [design] = - Can a client send 0-RTT data when receiving Retry? https://github.com/q= uicwg/base-drafts/issues/1507 [-transport] [design] = - Long header + token and PNE https://github.com/quicwg/base-drafts/issue= s/1535 [-transport] [design] = - Packet Number Must Be Decrypted to Read Initial Token Field https://git= hub.com/quicwg/base-drafts/issues/1492 [-transport] [design] = Pull requests ------------- * quicwg/base-drafts (+13/-11/=F0=9F=92=AC23) 13 pull requests submitted: - Other congestion controllers (by ianswett) https://github.com/quicwg/base-drafts/pull/1633 = - Fix: a connection is not identified by a *collection* (by dtikhonov) https://github.com/quicwg/base-drafts/pull/1632 = - Clarify use of the term "supports ECN" (by mirjak) https://github.com/quicwg/base-drafts/pull/1631 = - Fix typos in HTTP draft and use the more common "incautious" (by dtikho= nov) https://github.com/quicwg/base-drafts/pull/1630 = - Fix several orthographical errors in the transport draft (by dtikhonov) https://github.com/quicwg/base-drafts/pull/1629 = - add code points for 1, 2 and 3 byte connection IDs (by marten-seemann) https://github.com/quicwg/base-drafts/pull/1628 = - Defend against endless Stateless Reset ping-pong (by martinthomson) https://github.com/quicwg/base-drafts/pull/1627 [-transport] = - Consequences of bad ECN markings (by martinthomson) https://github.com/quicwg/base-drafts/pull/1626 [-recovery] = - Duplicates are dropped (by martinthomson) https://github.com/quicwg/base-drafts/pull/1624 [-transport] = - Fix dangling references (by martinthomson) https://github.com/quicwg/base-drafts/pull/1623 = - An endpoint cannot renege on advertised limits (by martinthomson) https://github.com/quicwg/base-drafts/pull/1622 [-transport] = - Explicitly permit starting over (by martinthomson) https://github.com/quicwg/base-drafts/pull/1621 [-transport] = - Define idle timeout more precisely (by martinthomson) https://github.com/quicwg/base-drafts/pull/1614 [-transport] [design] = 7 pull requests received 23 new comments: - #1624 Duplicates are dropped (13 by marten-seemann, kazuho, mikkelfj, m= artinthomson, ekr) https://github.com/quicwg/base-drafts/pull/1624 [-transport] = - #1605 Only ack headers that have non-zero declared Largest Reference (4= by martinthomson, dtikhonov, afrind) https://github.com/quicwg/base-drafts/pull/1605 [-qpack] = - #1633 Other congestion controllers (2 by martinthomson, ianswett) https://github.com/quicwg/base-drafts/pull/1633 = - #1611 Use largest_acked consistently (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1611 = - #1591 Single Packet Number Space (1 by nibanks) https://github.com/quicwg/base-drafts/pull/1591 = - #1628 add code points for 1, 2 and 3 byte connection IDs (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/1628 = - #1629 Fix several orthographical errors in the transport draft (1 by ma= rtinthomson) https://github.com/quicwg/base-drafts/pull/1629 = 11 pull requests merged: - Other congestion controllers https://github.com/quicwg/base-drafts/pull/1633 = - make the initial_max_data transport parameter optional https://github.com/quicwg/base-drafts/pull/1610 [-transport] = - Define idle timeout more precisely https://github.com/quicwg/base-drafts/pull/1614 [-transport] [design] = - Only ack headers that have non-zero declared Largest Reference https://github.com/quicwg/base-drafts/pull/1605 [-qpack] = - Explicitly permit starting over https://github.com/quicwg/base-drafts/pull/1621 [-transport] = - Fix several orthographical errors in the transport draft https://github.com/quicwg/base-drafts/pull/1629 = - Fix dangling references https://github.com/quicwg/base-drafts/pull/1623 = - An endpoint cannot renege on advertised limits https://github.com/quicwg/base-drafts/pull/1622 [-transport] = - Allow Retry in response to 0-RTT packets https://github.com/quicwg/base-drafts/pull/1552 [-transport] [design] = - Permit 0-RTT after Retry and VN https://github.com/quicwg/base-drafts/pull/1514 [-transport] = - Rework Retry packet https://github.com/quicwg/base-drafts/pull/1498 [-transport] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============8502166173478808975== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday August 05, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+4/-9/=F0=9F=92=AC34)

4 issues created:

7 issues received 34 new comments:

9 issues closed:

Pull requests

quicwg/base-drafts (+13/-11/=F0=9F=92=AC23)

13 pull requests submitted:

7 pull requests received 23 new comments:

11 pull requests merged:

Repositories tracked by this digest:

--===============8502166173478808975==-- From nobody Sun Aug 5 08:47:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81C5130E66 for ; Sun, 5 Aug 2018 08:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.09 X-Spam-Level: *** X-Spam-Status: No, score=3.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 wkmxzwB9u3k5 for ; Sun, 5 Aug 2018 08:47:00 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6B91277BB for ; Sun, 5 Aug 2018 08:46:59 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id m13-v6so11262438qth.1 for ; Sun, 05 Aug 2018 08:46:59 -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:mime-version :content-disposition:user-agent; bh=7QFFcPRr17+C0zvGqTjpOEQve6b1gvQMJO64Em0YSyQ=; b=sfqs9lz30i+3MAxcpv/Q5GSQk05RWkM4Ml7SXK76XjtKNucfi19CROHRoz5ghl6AIX 1I5ZE/hRLO+8GngtLq2/e9Tb0mcWd8uG5m+j9r4aDh9MtrABtIUsfFS+4rzCDMOlCdSq HRD1aqb0TykSHucRUn49J4hiIPS/oAXC1f1iy5Fn/rQx+Ez5qWkU62R1tmyoY4SeCiWV afNPZxq0GKITnzFyzr9KxtmN78YejheW+r4LLpKB/dBgguUYVc26vGIbMwurgMsmJxWd rqHPd03EfNOnQWFxDhW93GEFmlQoybcue2NiIiY9OYfVMOIexaM9aezeKfzjuL3AXVD6 OtFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=7QFFcPRr17+C0zvGqTjpOEQve6b1gvQMJO64Em0YSyQ=; b=ll7UxYrM0JAazZMAIOjhcWW3yXdj8+v1L2oJvmxCFBJXZbDuFmq+arH5joySr8Gskl VJ5VWxQoNUDwgxFVomH3VlBkoXJ4d8O33gJ7n5piyGiuBFjFvdowieCS+GYUnOa/wehM QkOI0papiTsf+ZzVgxJikvSTIx494FyF2kuXD6SqLiT9S/UNksTR3rOZ424vtuRzU5BF z7V06uH3OhDD2OFKBb6q9aPgFqixR0qLSoPZZk4do+43q3NTz8trsiaMLYaKpIFgfO9W /h0ROxoi9TYnVAnU0lIcCQ+b3OKbbD7AJHCv+Ooe7ksseee2gNGwZXNXS5loUb76U52N h68Q== X-Gm-Message-State: AOUpUlFSu8opbOHphPUFcsea9fMIprP0R9ddAoHAXrB+A2ze6dmKzRN4 GEl6xAOHg/JniJc5ClyVy3lslAkAKsk= X-Google-Smtp-Source: AAOMgpdo8JBhRgy/kpFlJLukfCZVCHgfgJ1aiuCtog5EShAvqYBDtqMukMi0YiJFqPPjZRmi5DhXGg== X-Received: by 2002:a0c:8d8e:: with SMTP id t14-v6mr10286614qvb.32.1533484018843; Sun, 05 Aug 2018 08:46:58 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id a187-v6sm6727017qkd.47.2018.08.05.08.46.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Aug 2018 08:46:58 -0700 (PDT) Date: Sun, 5 Aug 2018 11:46:50 -0400 From: Dmitri Tikhonov To: IETF QUIC WG Subject: QPACK proposal: wrap absolute index values Message-ID: <20180805154649.GA14245@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2018 15:47:02 -0000 Abstract -------- The practical and theoretical problems caused by the unbounded absolute index values in the current QPACK Internet Draft are discussed. The proposal to impose a limit on the range of absolute index values by wrapping them is presented. Background ---------- The current QPACK draft states that [the] first entry inserted has an absolute index of "1"; indices increase sequentially with each insertion. No upper limit is specified. This is reasonable, as it is impossible to run out of numbers. Nevertheless, an absolute index whose value is ever-increasing creates significant problems. Problem 1: Compression Impact ----------------------------- A large absolute index value has a negative effect on compression. There are two places in QPACK that use the unadjusted value of the absolute index: - the Largest Reference field in the Header Data Prefix; and - the Table State Synchronize instruction. Larger values mean that more bytes are necessary to encode them. For example, using 8-bit prefix integer encoding, values larger than 254 encode to 2 bytes, larger than 382 to 3 bytes, and larger than 16638 to 4 bytes. Relatively quickly, the overhead associated with communicating the absolute index doubles and then triples. Problem 2: Theoretical Concerns ------------------------------- Why should compression at t(1) be worse than at t(0)? An ability to operate at the optimum level in perpetuity is a good property for a protocol to have. Problem 3: Implementation Efficiency ------------------------------------ A QPACK implementation has to place some limits on the value of the absolute index -- simply because it has to pick an integral type to store it. For example, uint64_t is likely large enough for all uses of the protocol, but it is wider than uint32_t and may be more expensive to process. On other platforms, uint16_t may be the fastest integer; the unbounded nature of the absolute index would rule out its use. Such limit also requires an extra check [1] to cease inserting entries into the dynamic table once the maximum value for the integer is reached. (One can run out of numbers in practice...) Solution: Have the Absolute Index Wrap Around --------------------------------------------- The main insight of the proposal is that the dynamic table has a bounded number of entries, that both encoder and decoder know what this number is, and that both can use this information to place an absolute index value communicated to it by its peer at the correct place in the sequence. The dynamic table has a maximum size which is specified at the beginning of the connection and which never changes afterwards. The current size of the table is the sum of all its entry sizes. The entry size is the sum of the fixed overhead plus the lengths of the name and the value strings. It is this fixed entry overhead that places a hard limit on the number of entries in the dynamic table: MaxEntries = MaxTableSize / FixedEntryOverhead For example, using the current QPACK defaults, this number is MaxEntries = 4096 / 32 = 128 Imagine an encoder or decoder whose largest absolute index value (referred to as the total number of insertions in the QPACK draft) is X. The smallest valid absolute index value its peer could possibly communicate to it is X - MaxEntries + 1. The largest value is X + MaxEntries. (All other values would indicate a bug at one or both sides.) The maximum size of the valid absolute index values window, then, is MaxEntries * 2. Therefore, we can wrap the absolute index value without loss of information. The proposal is to limit the absolute index values to the range [ 1, MaxEntries * 2 ] Continuing with the QPACK defaults example above, the sequence would go 1, 2, 3, ... 254, 255, 256, 1, 2, ... (and so on). The compression overhead cost is now a function of the maximum table size (and not a function of time as before). To continue with our example, out of 256 possible values, 254 encode to 1 byte and 2 to two bytes. A 64 KB table results in a maximum encoding of 3 bytes, while a 1 MB table has a maximum encoding of 4 bytes. Changes to the Draft -------------------- The changes to the draft are small. Only the definition of the absolute index has to change; all instructions and encodings stay the same. Conclusion ---------- Limiting the range of values the absolute index can have improves compression and implementation efficiency and removes the time penalty from the QPACK protocol. A mechanism to do just that using existing QPACK parameters and with minimal changes to the draft has been proposed. I suggest that it be examined for flaws. If none be found, I say let's include it in the next version of the QPACK Internet Draft. - Dmitri. 1. https://github.com/litespeedtech/ls-qpack/blob/122d1163eaca359f5d79cd608722b1b19acad15f/src/lsqpack.c#L1110 From nobody Sun Aug 5 17:30:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E321130DC6 for ; Sun, 5 Aug 2018 17:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 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, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRXOagXN4C1d for ; Sun, 5 Aug 2018 17:30:02 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F950130DC2 for ; Sun, 5 Aug 2018 17:30:02 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id n21-v6so19242500oig.3 for ; Sun, 05 Aug 2018 17:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pmvUGyWHBzCWLskHjSCvhNvdIZ/Hbak3KaNV9eo4fUY=; b=TfdXoNh6QQh+laBXL0Z77wTj4OXOewv1ucYamWR5SMSLQzTXWwZYQBC6PO5FGWX9by kEkgGpMul05tfUeBB1Gak+1Vl/sqU0x72o3lVUbHCGUIwhDbeUYSbiVXwQPqjioKZLyZ beNyJFzDBLOt+66t/1J3dB7xXnwrFclS8z5sssL3waauQuMFD16Sa2ULYqPzf0pxt9NN zDtVMkUNJyuJa9n/atuQxx/A1Lwpy/YHOR9hT4NbqtB1kYAcgYQVoH3uygmi9FOJ4Cfd 8Lc6SizOH6tHoVEQTq7jyz1Bcbh4v4GW2q4d95679mh7JoFh1RTgnS6Ka9QCKfBKXmIx pOrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pmvUGyWHBzCWLskHjSCvhNvdIZ/Hbak3KaNV9eo4fUY=; b=Tx+3pp33ENoZc71p0QOYQDnWJbMLVcmarHmMWSIuskqL0NhDi/OOuHTiCJEJakeo+e UtZBF1Ev88zQThTQm9UL9ZSWN0yx1ZG/qziee838s5ATQRCDw4/gQtlOoJIWEw5OjsfG saxm7q9HKbQHZSuACuqQX1yh5bQDXQCpSuocZ1FS8tD7z+IpR+vGhPznB9zKcEv8sblR FYWKeAzbEuS06HH2xzUW9dEsvrkd2KJoNbIyt4/fapDsrv4rlIZup19xgewfQiiQEsoy bIm8nc1v43dbXaPEeaYqfKYuDUWzwyN9gWu76+pkIjzOTGdLiFfHB666UFX0OWfBTtUy 7Ypg== X-Gm-Message-State: AOUpUlEYzW73eYvg2wlEefQEnPdy8s0h3tDhQvc+wK+FevwLUbq1xpjx VVUnzq/EDsw4flWpbDSvGfNjfcoWjZa5yIyf0+t+dwXy X-Google-Smtp-Source: AA+uWPzKCzZERROzyv6sDxR5UfKHkiUxSp/tBcCqxneoDCVZ087QMZjPGb8k03d/FzWj5Ftg2RRV+/zqisQz+Mnccs8= X-Received: by 2002:aca:b208:: with SMTP id b8-v6mr11798471oif.144.1533515401370; Sun, 05 Aug 2018 17:30:01 -0700 (PDT) MIME-Version: 1.0 References: <20180805154649.GA14245@ubuntu-dmitri> In-Reply-To: <20180805154649.GA14245@ubuntu-dmitri> From: Martin Thomson Date: Mon, 6 Aug 2018 10:29:50 +1000 Message-ID: Subject: Re: QPACK proposal: wrap absolute index values To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 00:30:04 -0000 Table State Synchronize is relative, so it wouldn't benefit from a change here. That's something I missed initially, so it's probably a candidate for clearer text. I've no real opinion on the wrapping proposal. It seems like it might work for the Largest Reference. The math is a tiny bit annoying to decode in the same way the packet number encoding is, but it is doable. I imagine that you reconstruct the Largest Reference based on the smallest index in the table. That is: rotation = floor(table_size / 32) base = minimum - (minimum % rotation) # equivalently: base = floor(minimum / rotation) * rotation largest = encoded + base if largest < minimum: largest += rotation On Mon, Aug 6, 2018 at 1:47 AM Dmitri Tikhonov wrote: > > Abstract > -------- > > The practical and theoretical problems caused by the unbounded absolute > index values in the current QPACK Internet Draft are discussed. The > proposal to impose a limit on the range of absolute index values by > wrapping them is presented. > > Background > ---------- > > The current QPACK draft states that > > [the] first entry inserted has an absolute index of "1"; indices > increase sequentially with each insertion. > > No upper limit is specified. This is reasonable, as it is impossible > to run out of numbers. > > Nevertheless, an absolute index whose value is ever-increasing creates > significant problems. > > Problem 1: Compression Impact > ----------------------------- > > A large absolute index value has a negative effect on compression. > There are two places in QPACK that use the unadjusted value of the > absolute index: > > - the Largest Reference field in the Header Data Prefix; and > - the Table State Synchronize instruction. > > Larger values mean that more bytes are necessary to encode them. > For example, using 8-bit prefix integer encoding, values larger than > 254 encode to 2 bytes, larger than 382 to 3 bytes, and larger than > 16638 to 4 bytes. > > Relatively quickly, the overhead associated with communicating the > absolute index doubles and then triples. > > Problem 2: Theoretical Concerns > ------------------------------- > > Why should compression at t(1) be worse than at t(0)? An ability > to operate at the optimum level in perpetuity is a good property > for a protocol to have. > > Problem 3: Implementation Efficiency > ------------------------------------ > > A QPACK implementation has to place some limits on the value of the > absolute index -- simply because it has to pick an integral type to > store it. For example, uint64_t is likely large enough for all uses of > the protocol, but it is wider than uint32_t and may be more expensive > to process. On other platforms, uint16_t may be the fastest integer; > the unbounded nature of the absolute index would rule out its use. > > Such limit also requires an extra check [1] to cease inserting entries > into the dynamic table once the maximum value for the integer is > reached. (One can run out of numbers in practice...) > > Solution: Have the Absolute Index Wrap Around > --------------------------------------------- > > The main insight of the proposal is that the dynamic table has a bounded > number of entries, that both encoder and decoder know what this number is, > and that both can use this information to place an absolute index value > communicated to it by its peer at the correct place in the sequence. > > The dynamic table has a maximum size which is specified at the beginning > of the connection and which never changes afterwards. The current size > of the table is the sum of all its entry sizes. The entry size is the sum > of the fixed overhead plus the lengths of the name and the value strings. > It is this fixed entry overhead that places a hard limit on the number > of entries in the dynamic table: > > MaxEntries = MaxTableSize / FixedEntryOverhead > > For example, using the current QPACK defaults, this number is > > MaxEntries = 4096 / 32 = 128 > > Imagine an encoder or decoder whose largest absolute index value (referred > to as the total number of insertions in the QPACK draft) is X. The > smallest valid absolute index value its peer could possibly communicate > to it is X - MaxEntries + 1. The largest value is X + MaxEntries. (All > other values would indicate a bug at one or both sides.) The maximum > size of the valid absolute index values window, then, is MaxEntries * 2. > > Therefore, we can wrap the absolute index value without loss of > information. The proposal is to limit the absolute index values to > the range > > [ 1, MaxEntries * 2 ] > > Continuing with the QPACK defaults example above, the sequence would > go > > 1, 2, 3, ... 254, 255, 256, 1, 2, ... (and so on). > > The compression overhead cost is now a function of the maximum table > size (and not a function of time as before). > > To continue with our example, out of 256 possible values, 254 encode > to 1 byte and 2 to two bytes. A 64 KB table results in a maximum > encoding of 3 bytes, while a 1 MB table has a maximum encoding of 4 > bytes. > > Changes to the Draft > -------------------- > > The changes to the draft are small. Only the definition of the > absolute index has to change; all instructions and encodings stay > the same. > > Conclusion > ---------- > > Limiting the range of values the absolute index can have improves > compression and implementation efficiency and removes the time penalty > from the QPACK protocol. A mechanism to do just that using existing > QPACK parameters and with minimal changes to the draft has been proposed. > I suggest that it be examined for flaws. If none be found, I say let's > include it in the next version of the QPACK Internet Draft. > > > - Dmitri. > > 1. https://github.com/litespeedtech/ls-qpack/blob/122d1163eaca359f5d79cd608722b1b19acad15f/src/lsqpack.c#L1110 > From nobody Sun Aug 5 20:15:01 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5610130E50 for ; Sun, 5 Aug 2018 20:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.51 X-Spam-Level: X-Spam-Status: No, score=-12.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3r5z-dUYi6E for ; Sun, 5 Aug 2018 20:14:57 -0700 (PDT) Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE74130E41 for ; Sun, 5 Aug 2018 20:14:57 -0700 (PDT) Received: by mail-yw1-xc2b.google.com with SMTP id 139-v6so3102150ywg.12 for ; Sun, 05 Aug 2018 20:14: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=v6TR+YwSgS5EqVb/eueD5tjTbxPt+29x3tP8Ym6aI2g=; b=BMg/7nh1U2EaY7RuHE6Rszgh078x6GfvOOKUxprEr4K4b5eHzIHQYxRiM5/PeHfz5a VN1hf7F3qOZNUjLnpk7eFuKYchDPaSFCN48D2/RPzrwi0AITfHUuSK4yqb8y6dxiLp/2 P2avpC7pdW9zd+zsCH2D5GavScfuRVtzxzzTMvXiAapo6ru7KwniQCyewuN9DhX16Q4Y PKUMrbIukqSvd6NNtxaO9/ELcsnNc//z6mgZBuoEPyD6px74nJDBgX+5tQ9GxugoAtsm zOhc1hlXG5Gm9pkSIIK4Rod0BURDqYRvBFYAAVaT+7vzvuGT4nvyhCx7MZdU3IEcqvBL xR9g== 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=v6TR+YwSgS5EqVb/eueD5tjTbxPt+29x3tP8Ym6aI2g=; b=H5KWbZb8JSx72kuzzpTnT/lZWCebMyrCjLJsU7A1CXkWkayeb69jOpNnlSJ2gWnNXu 5hzAg8zQCkK9HEVvPS5Kb42sJbsL+mUfwWAGDmawpniycI0Wy0+qnf3zlzSFYna4q5hp CHGfYz1VKhiEOJA3TkLunktlEVLTrYqiZoXTpwsrvtW9BCsJbLsKPggv78BzjEP5FVyL 2JPE1xwfedi29s+AvUa9Wdr0RBDaWvLZB/Ooi45ujPz/DrOxI1ZjWE34GByRJraP81Pu 1QAmJJoekP1kNS1ItUI1JBf+vg0gmwaTvaXZgZVsmUasHcZ2NUAJIqEqOBwGYKkFpH43 fHTg== X-Gm-Message-State: AOUpUlHn59xZegj9w7/6Yqzfki/tp0BnGMtfAOnK22kKwhVz4YYMU7OG pWVOqsWjo/hdZARUE0FT5HS8MsSMba43R6RdExj7PQ== X-Google-Smtp-Source: AAOMgpd4nufdtkCg+zQns8DJOltu1+tnSnOPpUDUlPKBsFa68KRPCY7yFKuyVC94a6PHBCdrDrYr4AZ1SoPwAmP7k9A= X-Received: by 2002:a81:d8b:: with SMTP id 133-v6mr6914531ywn.179.1533525296282; Sun, 05 Aug 2018 20:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:8b11:0:0:0:0:0 with HTTP; Sun, 5 Aug 2018 20:14:55 -0700 (PDT) In-Reply-To: References: <20180805154649.GA14245@ubuntu-dmitri> From: Ryan Hamilton Date: Sun, 5 Aug 2018 20:14:55 -0700 Message-ID: Subject: Re: QPACK proposal: wrap absolute index values To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="0000000000008ab59e0572bbae1c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 03:15:00 -0000 --0000000000008ab59e0572bbae1c Content-Type: text/plain; charset="UTF-8" Do we have any sense on the overall impact on compression efficiency base on typical HTTP workloads? On Sun, Aug 5, 2018 at 5:29 PM, Martin Thomson wrote: > Table State Synchronize is relative, so it wouldn't benefit from a > change here. That's something I missed initially, so it's probably a > candidate for clearer text. > > I've no real opinion on the wrapping proposal. It seems like it might > work for the Largest Reference. The math is a tiny bit annoying to > decode in the same way the packet number encoding is, but it is > doable. I imagine that you reconstruct the Largest Reference based on > the smallest index in the table. That is: > > rotation = floor(table_size / 32) > base = minimum - (minimum % rotation) > # equivalently: base = floor(minimum / rotation) * rotation > largest = encoded + base > if largest < minimum: > largest += rotation > On Mon, Aug 6, 2018 at 1:47 AM Dmitri Tikhonov > wrote: > > > > Abstract > > -------- > > > > The practical and theoretical problems caused by the unbounded absolute > > index values in the current QPACK Internet Draft are discussed. The > > proposal to impose a limit on the range of absolute index values by > > wrapping them is presented. > > > > Background > > ---------- > > > > The current QPACK draft states that > > > > [the] first entry inserted has an absolute index of "1"; indices > > increase sequentially with each insertion. > > > > No upper limit is specified. This is reasonable, as it is impossible > > to run out of numbers. > > > > Nevertheless, an absolute index whose value is ever-increasing creates > > significant problems. > > > > Problem 1: Compression Impact > > ----------------------------- > > > > A large absolute index value has a negative effect on compression. > > There are two places in QPACK that use the unadjusted value of the > > absolute index: > > > > - the Largest Reference field in the Header Data Prefix; and > > - the Table State Synchronize instruction. > > > > Larger values mean that more bytes are necessary to encode them. > > For example, using 8-bit prefix integer encoding, values larger than > > 254 encode to 2 bytes, larger than 382 to 3 bytes, and larger than > > 16638 to 4 bytes. > > > > Relatively quickly, the overhead associated with communicating the > > absolute index doubles and then triples. > > > > Problem 2: Theoretical Concerns > > ------------------------------- > > > > Why should compression at t(1) be worse than at t(0)? An ability > > to operate at the optimum level in perpetuity is a good property > > for a protocol to have. > > > > Problem 3: Implementation Efficiency > > ------------------------------------ > > > > A QPACK implementation has to place some limits on the value of the > > absolute index -- simply because it has to pick an integral type to > > store it. For example, uint64_t is likely large enough for all uses of > > the protocol, but it is wider than uint32_t and may be more expensive > > to process. On other platforms, uint16_t may be the fastest integer; > > the unbounded nature of the absolute index would rule out its use. > > > > Such limit also requires an extra check [1] to cease inserting entries > > into the dynamic table once the maximum value for the integer is > > reached. (One can run out of numbers in practice...) > > > > Solution: Have the Absolute Index Wrap Around > > --------------------------------------------- > > > > The main insight of the proposal is that the dynamic table has a bounded > > number of entries, that both encoder and decoder know what this number > is, > > and that both can use this information to place an absolute index value > > communicated to it by its peer at the correct place in the sequence. > > > > The dynamic table has a maximum size which is specified at the beginning > > of the connection and which never changes afterwards. The current size > > of the table is the sum of all its entry sizes. The entry size is the > sum > > of the fixed overhead plus the lengths of the name and the value strings. > > It is this fixed entry overhead that places a hard limit on the number > > of entries in the dynamic table: > > > > MaxEntries = MaxTableSize / FixedEntryOverhead > > > > For example, using the current QPACK defaults, this number is > > > > MaxEntries = 4096 / 32 = 128 > > > > Imagine an encoder or decoder whose largest absolute index value > (referred > > to as the total number of insertions in the QPACK draft) is X. The > > smallest valid absolute index value its peer could possibly communicate > > to it is X - MaxEntries + 1. The largest value is X + MaxEntries. (All > > other values would indicate a bug at one or both sides.) The maximum > > size of the valid absolute index values window, then, is MaxEntries * 2. > > > > Therefore, we can wrap the absolute index value without loss of > > information. The proposal is to limit the absolute index values to > > the range > > > > [ 1, MaxEntries * 2 ] > > > > Continuing with the QPACK defaults example above, the sequence would > > go > > > > 1, 2, 3, ... 254, 255, 256, 1, 2, ... (and so on). > > > > The compression overhead cost is now a function of the maximum table > > size (and not a function of time as before). > > > > To continue with our example, out of 256 possible values, 254 encode > > to 1 byte and 2 to two bytes. A 64 KB table results in a maximum > > encoding of 3 bytes, while a 1 MB table has a maximum encoding of 4 > > bytes. > > > > Changes to the Draft > > -------------------- > > > > The changes to the draft are small. Only the definition of the > > absolute index has to change; all instructions and encodings stay > > the same. > > > > Conclusion > > ---------- > > > > Limiting the range of values the absolute index can have improves > > compression and implementation efficiency and removes the time penalty > > from the QPACK protocol. A mechanism to do just that using existing > > QPACK parameters and with minimal changes to the draft has been proposed. > > I suggest that it be examined for flaws. If none be found, I say let's > > include it in the next version of the QPACK Internet Draft. > > > > > > - Dmitri. > > > > 1. https://github.com/litespeedtech/ls-qpack/blob/ > 122d1163eaca359f5d79cd608722b1b19acad15f/src/lsqpack.c#L1110 > > > > --0000000000008ab59e0572bbae1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do we have any sense on the overall impact on compression = efficiency base on typical HTTP workloads?

On Sun, Aug 5, 2018 at 5:29 PM, Martin= Thomson <martin.thomson@gmail.com> wrote:
Table State Synchronize is relative, so it wouldn&#= 39;t benefit from a
change here.=C2=A0 That's something I missed initially, so it's pro= bably a
candidate for clearer text.

I've no real opinion on the wrapping proposal.=C2=A0 It seems like it m= ight
work for the Largest Reference.=C2=A0 The math is a tiny bit annoying to decode in the same way the packet number encoding is, but it is
doable.=C2=A0 I imagine that you reconstruct the Largest Reference based on=
the smallest index in the table.=C2=A0 That is:

rotation =3D floor(table_size / 32)
base =3D minimum - (minimum % rotation)
# equivalently: base =3D floor(minimum / rotation) * rotation
largest =3D encoded + base
if largest < minimum:
=C2=A0 largest +=3D rotation
On Mon, Aug 6, 2018 at 1:47 AM Dmit= ri Tikhonov
<dtikhonov@litespeedtech.= com> wrote:
>
> Abstract
> --------
>
> The practical and theoretical problems caused by the unbounded absolut= e
> index values in the current QPACK Internet Draft are discussed.=C2=A0 = The
> proposal to impose a limit on the range of absolute index values by > wrapping them is presented.
>
> Background
> ----------
>
> The current QPACK draft states that
>
>=C2=A0 =C2=A0 [the] first entry inserted has an absolute index of "= ;1"; indices
>=C2=A0 =C2=A0 increase sequentially with each insertion.
>
> No upper limit is specified.=C2=A0 This is reasonable, as it is imposs= ible
> to run out of numbers.
>
> Nevertheless, an absolute index whose value is ever-increasing creates=
> significant problems.
>
> Problem 1: Compression Impact
> -----------------------------
>
> A large absolute index value has a negative effect on compression.
> There are two places in QPACK that use the unadjusted value of the
> absolute index:
>
>=C2=A0 =C2=A0 =C2=A0- the Largest Reference field in the Header Data Pr= efix; and
>=C2=A0 =C2=A0 =C2=A0- the Table State Synchronize instruction.
>
> Larger values mean that more bytes are necessary to encode them.
> For example, using 8-bit prefix integer encoding, values larger than > 254 encode to 2 bytes, larger than 382 to 3 bytes, and larger than
> 16638 to 4 bytes.
>
> Relatively quickly, the overhead associated with communicating the
> absolute index doubles and then triples.
>
> Problem 2: Theoretical Concerns
> -------------------------------
>
> Why should compression at t(1) be worse than at t(0)?=C2=A0 An ability=
> to operate at the optimum level in perpetuity is a good property
> for a protocol to have.
>
> Problem 3: Implementation Efficiency
> ------------------------------------
>
> A QPACK implementation has to place some limits on the value of the > absolute index -- simply because it has to pick an integral type to > store it.=C2=A0 For example, uint64_t is likely large enough for all u= ses of
> the protocol, but it is wider than uint32_t and may be more expensive<= br> > to process.=C2=A0 On other platforms, uint16_t may be the fastest inte= ger;
> the unbounded nature of the absolute index would rule out its use.
>
> Such limit also requires an extra check [1] to cease inserting entries=
> into the dynamic table once the maximum value for the integer is
> reached.=C2=A0 (One can run out of numbers in practice...)
>
> Solution: Have the Absolute Index Wrap Around
> ---------------------------------------------
>
> The main insight of the proposal is that the dynamic table has a bound= ed
> number of entries, that both encoder and decoder know what this number= is,
> and that both can use this information to place an absolute index valu= e
> communicated to it by its peer at the correct place in the sequence. >
> The dynamic table has a maximum size which is specified at the beginni= ng
> of the connection and which never changes afterwards.=C2=A0 The curren= t size
> of the table is the sum of all its entry sizes.=C2=A0 The entry size i= s the sum
> of the fixed overhead plus the lengths of the name and the value strin= gs.
> It is this fixed entry overhead that places a hard limit on the number=
> of entries in the dynamic table:
>
>=C2=A0 =C2=A0 =C2=A0MaxEntries =3D MaxTableSize / FixedEntryOverhead >
> For example, using the current QPACK defaults, this number is
>
>=C2=A0 =C2=A0 =C2=A0MaxEntries =3D 4096 / 32 =3D 128
>
> Imagine an encoder or decoder whose largest absolute index value (refe= rred
> to as the total number of insertions in the QPACK draft) is X.=C2=A0 T= he
> smallest valid absolute index value its peer could possibly communicat= e
> to it is X - MaxEntries + 1.=C2=A0 The largest value is X + MaxEntries= .=C2=A0 (All
> other values would indicate a bug at one or both sides.)=C2=A0 The max= imum
> size of the valid absolute index values window, then, is MaxEntries * = 2.
>
> Therefore, we can wrap the absolute index value without loss of
> information.=C2=A0 The proposal is to limit the absolute index values = to
> the range
>
>=C2=A0 =C2=A0 =C2=A0[ 1, MaxEntries * 2 ]
>
> Continuing with the QPACK defaults example above, the sequence would > go
>
>=C2=A0 =C2=A0 =C2=A01, 2, 3, ... 254, 255, 256, 1, 2, ... (and so on).<= br> >
> The compression overhead cost is now a function of the maximum table > size (and not a function of time as before).
>
> To continue with our example, out of 256 possible values, 254 encode > to 1 byte and 2 to two bytes.=C2=A0 A 64 KB table results in a maximum=
> encoding of 3 bytes, while a 1 MB table has a maximum encoding of 4 > bytes.
>
> Changes to the Draft
> --------------------
>
> The changes to the draft are small.=C2=A0 Only the definition of the > absolute index has to change; all instructions and encodings stay
> the same.
>
> Conclusion
> ----------
>
> Limiting the range of values the absolute index can have improves
> compression and implementation efficiency and removes the time penalty=
> from the QPACK protocol.=C2=A0 A mechanism to do just that using exist= ing
> QPACK parameters and with minimal changes to the draft has been propos= ed.
> I suggest that it be examined for flaws.=C2=A0 If none be found, I say= let's
> include it in the next version of the QPACK Internet Draft.
>
>
>=C2=A0 =C2=A0- Dmitri.
>
> 1. https://github.com/litespeedtech/ls-qpack/blob/122= d1163eaca359f5d79cd608722b1b19acad15f/src/lsqpack.c#L1110
>


--0000000000008ab59e0572bbae1c-- From nobody Sun Aug 5 20:33:39 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103FC130E72 for ; Sun, 5 Aug 2018 20:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 TuLUBngJutQ6 for ; Sun, 5 Aug 2018 20:33:36 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66AEC130E55 for ; Sun, 5 Aug 2018 20:33:36 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id c126-v6so7965623qkd.7 for ; Sun, 05 Aug 2018 20:33:36 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=mKIRJCpBaBuCQxext45JSfM+wjly3/8wJ/7A94BME8I=; b=DgGSFTbfpHdUOFLg9/Wjv0WZx9vU92CKLEX5VXirihbCiwY/0FAhu4z+B93pW6zWN1 A7TL/oKsbuYNJTO1cyZQsPjwO/3cABNce9f745bvdEQSC74gDr61thNhJ3LiB2qacgSL Rfk6RQLmrZQCkKYk6Fc5rnl2H7Cf76gV6S817nmF5CzxzCqEStUr6TtLYg05FmN3GIvO /yCX77UGsr2x+Sqxo50j/VFXSVNQjmiM7E0/fSzN7rXFPURfhDceNzeIUiG9oPVBXXL7 9jfr0sQ9XckayHb4TkVvjQPUPYxXYqBvS3HK8BO31ZXRqDUo+AGhgKoLq3skPProByB4 TbVA== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=mKIRJCpBaBuCQxext45JSfM+wjly3/8wJ/7A94BME8I=; b=ko/7wlMS+jgEs4tzTJCYMNMf1WvMt/OWDV7otxlTLZ50rp5r+dojUjRKfW0Yx0qk+F MRJr9HjWQSMFbnkhlcNvj/IOj1CEyY90gjocsWvVprlR4rL42Nn5l2SydV14RNwiQZVG SfRkqN9L+udp1n4k2b5UEvzHm+shMTtgWwtZT4AZQ35EAHZaSEobrBelcM4mXkVodzEX b93o9CinG1n2ACLVr5BptOlTP4TyQIS/3QsC7Bs7KT5vsD9m1zsyTgZRFqQRnI4UxMhF e/W7C/SHOZBq+0X3xSGJ1/Rn8QHmWNSawQHB+3LXskP8rAIZoEJkt8K/TXb9Ul5yyzJw x58w== X-Gm-Message-State: AOUpUlHgzmf/VSq8WheEXeVFLs2xL13DOniqBsgcpk57ePmFH173rMvO bCJQuEPvJqNQwkXW15573qoc9w== X-Google-Smtp-Source: AAOMgpeLfGa+QXUnEdNpzDT7Mwm49JYEcNw1g8lUgW49C9VmBI/CFGuJmwYKh2hmvEOjwSFSRZVLSQ== X-Received: by 2002:a37:9007:: with SMTP id s7-v6mr11820623qkd.243.1533526415495; Sun, 05 Aug 2018 20:33:35 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id v4-v6sm8138408qth.23.2018.08.05.20.33.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Aug 2018 20:33:35 -0700 (PDT) Date: Sun, 5 Aug 2018 23:33:30 -0400 From: Dmitri Tikhonov To: Ryan Hamilton Cc: Martin Thomson , QUIC WG Subject: Re: QPACK proposal: wrap absolute index values Message-ID: <20180806033330.GA25402@ubuntu-dmitri> Mail-Followup-To: Ryan Hamilton , Martin Thomson , QUIC WG References: <20180805154649.GA14245@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 03:33:38 -0000 On Sun, Aug 05, 2018 at 08:14:55PM -0700, Ryan Hamilton wrote: > Do we have any sense on the overall impact on compression efficiency base > on typical HTTP workloads? The "typical" part is somewhat subjective. The impact is on compression would be more pronounced in scenarios where the header blocks are smaller (meaning that the dynamic table has slower churn). For example, a small HAR I've been working with as example to our QPACK implementation contains 18 requests. The header blocks and the encoder stream compress to about 1 KB. An overhead of 2 bytes per header block would translate to 18 * 2 / 1024 = ~4% The penalty is not dramatic, but it's not insignificant, either. - Dmitri. From nobody Sun Aug 5 20:40:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED439130E72 for ; Sun, 5 Aug 2018 20:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 Oklub_GEYRxF for ; Sun, 5 Aug 2018 20:40:40 -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 61217130DCF for ; Sun, 5 Aug 2018 20:40:40 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id n6-v6so12366115qtl.4 for ; Sun, 05 Aug 2018 20:40:40 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=QzS3NGSbWEHXJ7G0CpKpyKmRlHO9RcN38N6CKgur+RI=; b=W4GYEugInrtqTsW6SF6qnSYN//yFBf3e3U0T4kL0LlFEE9a/lVqLdNendQx1GRg1Bz pqddig/a1gs7QtnucGoAiI/ok89GXq/j52A6n6uFFArEDoDY6o+aHqtuqmuItGOZZ24Q 3OLNDYNdU4LxPKQf/uZmzAQ3DQOTbTQr3FY+htoh1cQOlNIb7nD2nP0C/HbX+/SMqiot Z3bC9q0SfUVZr2yCHzMc/+JYwJARiGYyuFwJCftRIahdAQcIo+Y/03a3QH8rUvR3ZZdR K2w0rAXIXkJoLxkCwZv0uHFJ202creWtNtL/qEcbrMekcVlExS3DTc4dB3WdTMMi2JGB FtBA== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=QzS3NGSbWEHXJ7G0CpKpyKmRlHO9RcN38N6CKgur+RI=; b=nowFRy7OM2h7kBwDz5efTvTo1SMeT2zRzT6rWCTTs2n+hJ2eIQyKyFSZdWBj70F20Z SAgAbio40ZoWEVfUuIo9M/cNZZHwOs7IVA0uTCIcr7vx71Bl43YookT++lgaZYKgws9m uQeurA2LD+n9FFOTWPIPirjwzIm4MUHxQgc2dPtnrhA9JZKCaBBJRoi3zy0u9b/bv1Vy C/LiRlGT3Qu4BmO5MHdN9BdDpLI3Wlgk4W/sqMCa7hJS8ZpHXbAWXHRwvGJ1Qll+ecPq TCcv/z3Jzi4XkRFepYgBhLS93/tan+nKd21RIPK1MkVtsi5qhKkGpvpPH1JX/YjqLqT+ 6KXQ== X-Gm-Message-State: AOUpUlFHIzKdxG5DvKtUH3EoDo2sytaHnAlT7HP8nVG9LXxhRhO9kC19 GnRmE/oherwR7gCxjv8XM0giDA== X-Google-Smtp-Source: AAOMgpdt3NVnMGoAc2XnSTUxY0SFI8sK3cnrbLTrs4/mLPRCthdTX893eJGsRoddtktp7MV2kBdk5g== X-Received: by 2002:a0c:98c1:: with SMTP id g1-v6mr11517532qvd.27.1533526839573; Sun, 05 Aug 2018 20:40:39 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id c184-v6sm5593645qkd.43.2018.08.05.20.40.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Aug 2018 20:40:39 -0700 (PDT) Date: Sun, 5 Aug 2018 23:40:37 -0400 From: Dmitri Tikhonov To: Martin Thomson Cc: QUIC WG Subject: Re: QPACK proposal: wrap absolute index values Message-ID: <20180806034037.GB25402@ubuntu-dmitri> Mail-Followup-To: Martin Thomson , QUIC WG References: <20180805154649.GA14245@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 03:40:42 -0000 On Mon, Aug 06, 2018 at 10:29:50AM +1000, Martin Thomson wrote: > Table State Synchronize is relative, so it wouldn't benefit from a > change here. That's something I missed initially, so it's probably a > candidate for clearer text. I think the text looks fine -- I simply was not reading it carefully enough. > I've no real opinion on the wrapping proposal. It seems like it might > work for the Largest Reference. The math is a tiny bit annoying to > decode in the same way the packet number encoding is, but it is > doable. Yes, it is similar to the packet number logic, except that unlike the packet number, the absolute index wraps around. - Dmitri. From nobody Sun Aug 5 21:36:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F07130E8C for ; Sun, 5 Aug 2018 21:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 LNAlR9U4hjEI for ; Sun, 5 Aug 2018 21:36:14 -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 8B48A130DC1 for ; Sun, 5 Aug 2018 21:36:14 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id h4-v6so12434064qtj.7 for ; Sun, 05 Aug 2018 21:36:14 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Z/fr9rVn3tT83UMyCndQL8h7qZwnQdtgZtAfM+zJvG0=; b=o5vmMgNUZSnLud7qXD0X9ZxgBNGNOhzkJmrjyOk0CnFPa1LV90AQobo1NbnC+Qsx+e vJ4uPrAWCS9x6WrzMemexYZAKTcuqw9w6c+Diu2DqPe9Ftke23BwyU4YjvOHpaKSYYEC R+/iIl+GcP8Tb2dbIQt2vRLtLQZ13YCM7mEGUqhWCcsbX+dFwM+Ki4FFhnF9aAmwUscV IRUnFmE/L/1K/xRESZv8ngHUHzwmqudiwi7mSMLvPg93+1PjqFYYjQ0NuXH6HqVF55vE 7d/IRI7oiatQj5V3KbzpHAgLpjtaAWkL2ezxvlUNAFGy5XJ4amIl0Q3YuUrrhM/SW4q+ YD1g== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=Z/fr9rVn3tT83UMyCndQL8h7qZwnQdtgZtAfM+zJvG0=; b=ZImSvmS9oPxRZQPLg5VU7xjY4ey8wGc0FKJFNdu3BMdm7gs3tgchf7yEP2XvojUlwt oDo0QIwpubglivqb1Hc4uMbD/O/8hiRfsRXClyQ37xgEpXHSXx+AcdtHtBOO4kQyhbjl U9qOGz/j7gsUHXvMpCIYmTHpBNfF8RiKY2rn659jrOci3rrLJeLKcGo9qsDrPqKtSVPI ZfHI+Jtu16k8No4Lc57LTt0GMsXKEdT4ER2yvgPhAXWbqcfmyryLvt72EER4EhGo6MYg XWKi1aAB8o17MTmpRMrEiYPID1iK0+5IpAq11ILVIktT4GGkZttXjQzyDopoa6ubq+Ax k7fg== X-Gm-Message-State: AOUpUlFT0IUHHyLi+3yhoxEBmJ/GzwIUCVgRWywrG38gx14kRFId5UJT nQSHEiweoaFmIPmteMl2U7qzXA== X-Google-Smtp-Source: AAOMgpdLpgQMZI0yESX6QR4pdTWrIasYUydM2sXaBrKe+MZ+/c1ezkzwQhd0B0Sjxk7CBUBmrFkUMA== X-Received: by 2002:aed:235a:: with SMTP id i26-v6mr12813136qtc.382.1533530173695; Sun, 05 Aug 2018 21:36:13 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id i1-v6sm5021488qtj.65.2018.08.05.21.36.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Aug 2018 21:36:13 -0700 (PDT) Date: Mon, 6 Aug 2018 00:36:11 -0400 From: Dmitri Tikhonov To: Martin Thomson Cc: QUIC WG Subject: Re: QPACK proposal: wrap absolute index values Message-ID: <20180806043610.GC25402@ubuntu-dmitri> Mail-Followup-To: Martin Thomson , QUIC WG References: <20180805154649.GA14245@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 04:36:17 -0000 On Mon, Aug 06, 2018 at 10:29:50AM +1000, Martin Thomson wrote: > I've no real opinion on the wrapping proposal. It seems like it might > work for the Largest Reference. The math is a tiny bit annoying to > decode in the same way the packet number encoding is, but it is > doable. I imagine that you reconstruct the Largest Reference based on > the smallest index in the table. That is: > > rotation = floor(table_size / 32) > base = minimum - (minimum % rotation) > # equivalently: base = floor(minimum / rotation) * rotation > largest = encoded + base > if largest < minimum: > largest += rotation My thinking is that there is no need to reconstruct the Largest Reference, as the encoded value represents the actual absolute index. It is its interpretation that requires some logic. One way to think about it is whether the absolute index is in the Past or the Future -- as it is always either one or the other. The window is 2 * MaxEntries wide 1 2 * MaxEntries |--------------------------------------------| If the current maximum absolute index has the value MaxEntries, all values to its left are in the Past, while all entries to the right are in the Future: <-- Past ---------\ /---- Future ---> |----------------- CurMax -------------------| If CurMax is larger than or equal to than MaxEntries, the Past region is contiguous. If CurMax is smaller than or equal to MaxEntries, the Future region is contiguous. The code is bool isHeaderBlocked (unsigned LargestRef) { if (CurMax <= MaxEntries) return LargestRef > CurMax && LargestRef <= CurMax + MaxEntries; else return !(LargestRef <= CurMax && LargestRef > CurMax - MaxEntries + 1); } - Dmitri. From nobody Sun Aug 5 21:46:34 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43417130E88 for ; Sun, 5 Aug 2018 21:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 dB__yQ3Fcf63 for ; Sun, 5 Aug 2018 21:46:31 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CBB130DBE for ; Sun, 5 Aug 2018 21:46:30 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id y5-v6so12414227qti.12 for ; Sun, 05 Aug 2018 21:46:30 -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=KSesSdln/aPfn/pgte34Y5grhcW4MCCsYmjDC3mkRUw=; b=OD6+lec4vp14gUkEmo31LBaBLm18yrM8HyASZZEo04uyYIZKlcjrloi4qLl92oJKd3 0bDOg3g11wrIfFvrmisbuJnuoDtDC4YhfNb/RJbKAWtl+KIu/8WblGS3fbl0ACIqxkvo kdLr8KkNKw6qvRs1RA3Sl9ODrD4VSR+nIcHT5gHEkf2uWr/T8Nzc/4amHGdBoUrxXAE1 iFkkdWZoPnIJ9dgA0CbgNIQbBEM57ABM7Np8If9KAmQmkHzD9qWmk7pohPvtJ6iJqJgW qnQ6QCyk91RmY77MejnCzMyAIhOwjIFFNeID9brqi5Ug3tyV3WMZQmIhNSUVzSeHxT9H sKxw== 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=KSesSdln/aPfn/pgte34Y5grhcW4MCCsYmjDC3mkRUw=; b=GrbvGtrNGOxokKcRXh+ilKOpFAUnHLlz7FzVvYEr/YQZ1ohzGFy1WJ4LWFMDRlejWX OVOUuvylUWVGMFMZFAim+YJmjClsHmc39qicUi/0OG9GLfkC8iDL6w/EnsNsBVxlxJaH H4Z+3xWtfU/iDibhBgqUQESmoUlT6x2HDjvqvzDmB+p8z2qi+36r+RSmt9SeoZYVkqFx IGTK9Pl11HK2rIw/R0LDCcsR9TNmTtNck6hfArJk31T5AAu5mzz/1Wdme86dU27hYXj0 WXC2ac1d6pWcDkxXckmkZVMYs5X4hhOGFS9fjio0v3FnyL/z+PsrfGRwdofxs89/kiVL BSjA== X-Gm-Message-State: AOUpUlHIJ0YWUGywqzE3ECwqbo7JYnGir/1K75afqAHV1U1VhXTet9h+ KjwnznA+wjLq6EDKHDobvEXrUjH9zqw= X-Google-Smtp-Source: AAOMgpcg4ylsbmsLkJ1O0RgtXE/Qjp3JweBg/GY0RjZFKeokxyWPZA9hZ1YS7Iz6fPubFUA58ON+OQ== X-Received: by 2002:ac8:26ee:: with SMTP id 43-v6mr13081597qtp.274.1533530790055; Sun, 05 Aug 2018 21:46:30 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id i24-v6sm10133665qti.28.2018.08.05.21.46.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Aug 2018 21:46:29 -0700 (PDT) Date: Mon, 6 Aug 2018 00:46:27 -0400 From: Dmitri Tikhonov To: Martin Thomson , QUIC WG Subject: Re: QPACK proposal: wrap absolute index values Message-ID: <20180806044626.GD25402@ubuntu-dmitri> Mail-Followup-To: Martin Thomson , QUIC WG References: <20180805154649.GA14245@ubuntu-dmitri> <20180806043610.GC25402@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180806043610.GC25402@ubuntu-dmitri> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 04:46:32 -0000 Bug fix: bool isHeaderBlocked (unsigned LargestRef) { if (CurMax <= MaxEntries) return LargestRef > CurMax && LargestRef <= CurMax + MaxEntries; else return !(LargestRef <= CurMax - && LargestRef > CurMax - MaxEntries + 1); + && LargestRef >= CurMax - MaxEntries + 1); } From nobody Sun Aug 5 22:55:51 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA8A130DFE for ; Sun, 5 Aug 2018 22:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C844oJUcASif for ; Sun, 5 Aug 2018 22:55:47 -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 3976A130DE6 for ; Sun, 5 Aug 2018 22:55:47 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id j205-v6so20124428oib.4 for ; Sun, 05 Aug 2018 22:55:47 -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=DQ8gmgZcZFfbffkfIV9HjPbr4eCOZqjxpwlVw5HNr1o=; b=AykLj0xzSVkarCGuqgXRtSjTUgYpP5QLXhOvHmd1LH2tCougKdrb7MvbZRfr2gWky8 3+hvXl0/YR29GGCZ+alObhZ4rk7vnPbFyPlfOvMJ23kZ71H90iNKwUE86D5oJG+ZPTQw VwdhLYoOd8GAxQ+xuuwkQqTbbtRwIFrpNXs5kbMpnIGn21ZbBc8RNLNH15lsTt4z/fXN UAFOpVtlt+cp2Fnfce6T9izdWCQbvoAgJtccP9Jo6FIw36BPwnI1/L/W+6NEaGW8oXf8 cSYDyi9Jnu+8Mt4RdwJ/xjaLrJC51evsv6tlGwspUSMcYfH66GTQU+7nqxtpCSW+qtJ1 dT3A== 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=DQ8gmgZcZFfbffkfIV9HjPbr4eCOZqjxpwlVw5HNr1o=; b=kEEeBSKF2A9/iTbvW5AAFoh3JhP6J1M4J3Xj8LOM9TPzBUgQG97tstChmso2C1LavF L+djgKVfthmaDzkyP1Yfp8nm3ltQvYnCgMTM8/nWCmu3Iak5uptVyBiO6dQnsaMnGck8 bd54bfxN1yzYrLW3Chy4hULJMuTfQUShSy2NuBLm1bIhzV6p9k+dynhyV/wt8s4D56YD 6iwX258MaYUL4eOg+tW4h99FQ9dlrTaz2WqMUlf54YNF2NVI9kFgiyERxvYr8pCeusbi nB/e8akfD9rvguQmhRMbRQWfYOFrrxl5Ely1VQNj6UzlDoq/IW1I/c0d/0k2XKAxd9Ml hdBw== X-Gm-Message-State: AOUpUlEGoNofcHI8cnLaT7ZUcpo6GY70il4HlhARPb+4qrOrJTVpxSPh yzbL37Ldiz90t4ACsgg735/pRebddGVaFnE65m07q3Nz X-Google-Smtp-Source: AAOMgpffFD8pektIHQu7rniJ094N3duFUeC5GRXxAATMN5oNTeee+NrRx9BxKA8Xo0VhDNkfmn+tNFcD1p8E3MxOscw= X-Received: by 2002:aca:3d56:: with SMTP id k83-v6mr12545162oia.166.1533534946297; Sun, 05 Aug 2018 22:55:46 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Mon, 6 Aug 2018 15:55:36 +1000 Message-ID: Subject: The first octet To: quic@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 05:55:49 -0000 It appears as though we're about to get some information about how deployable the QUIC invariants are. Ian tells me that Google are most of the way to deploying a protocol that uses QUIC invariants and should be able to confirm that this works by the interim. Well, either that or to be able to tell us what doesn't work, which I'm hoping isn't a problem we have to deal with. I'd like to spend some time at the interim on what we do with the type bits in the protocol. This email is an attempt to thoroughly cover the constraints that we have here and attempt to describe a process that I hope should get us to a conclusion shortly after Bangkok. Looking at open design issues, this cluster is the one that is the biggest threat to our schedule. Design Status and Constraints Long Header The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we have are currently allocated to the 4 types of long header packet, using only 252-255. All other values are currently unused. With respect to design constraints, there is only one that I'm aware of and that is a potential collision with RTP (and RTCP) on this octet (see RFC 7983), which use 0x10xxxxxx (128-191). The open question here is what we do with unused types. We might debate creating a registry for unused values. We might want to grease values. We could even decide to encrypt these values (though the design of Retry makes that more difficult, because the contents of that packet aren't encrypted at all). I'm not aware of any plans to use these bits, except perhaps what might be done to be consistent with the short header changes, so we might have some latitude here. Short Header The short header uses the 0b0xxxxxxx pattern (0-127). This is far more complex and we have a bunch of open questions that will make this difficult. Right now, we use the 0b0K110RRR as the pattern, with K being the key phase, and RRR being reserved for the spin bit experiment. Those fixed bits are (largely) temporary, and might be reclaimed once existing deployments of Google QUIC (pre-44) are phased out, so I think that we might want to reclaim some or all of them. There is a chance that the reserved bits will also become available (if not all, then maybe 2 of them). That will be decided in Bangkok, but we might want to have a plan for those bits. The constraints that I am then aware of are these: 1. RFC 7983 has the lower half of the first octet fairly densely populated for demux. Of the protocols there, my understanding of their relative importance puts STUN (0-4) as fairly critical, if not mandatory, then TLS (20-63) as optional. ZRTP (16-19) and TURN channels (64-79) are both apparently unimportant, though each might be opportunistically accommodated. 2. Passive RTT measurement (spin bit) will take 0, 1, or 3 bits. I suggest that we allow for this, not counting on having any more bits than N-3, or assuming that only that many bits will be available. 3. Kazuho points out that the key phase is a linkability vector. We might want to consider encrypting that. We could do that by fixing the packet number key and not updating it after key updates and using more output from that process to mask the bit (and maybe other bits in this field). 4. I realize that we don't have to put a key phase in every packet if we are less concerned about being able to update immediately. If we adopt a scheme to what was proposed in DTLS, then a longer encoding can be used during the preparation and signaling phase. I'll follow up with another email on this subject. One thing that we could use extra bits for is to move the packet number size back into this octet. We could even move packet number bits back, depending on available space. That might make some difference to the number of bytes we allocate for packet numbers. Process Given that we don't have answers to some questions we might conclude several ways. I proposed that we agree on principles, starting with: 0. (This should already be agreed, but I'm repeating it because it's important.) The low 7 bits of the first octet are version-specific and can change in the next version of the protocol. A. What do we want to do with unused bits? Do we want to ensure that they are always used? Or can they be reserved? If so, how would they be reserved (fixed values, random values, greasing, etc...)? B. Should things in the first octet be encrypted where possible (for example, using an extension of packet number encoding). C. Should packet number encodings should be consistent between long and short header forms? D. What should we do with key phase? This was an open issue from the stream 0 design team, which might alter the outcome here. I have another email that covers this in more detail. E. How should we accommodate multiplexing? For me, the big questions here are whether we allow for RTP to collide with the long header and which of the protocols we privilege by avoiding with the short header. My hope is that reaching conclusion on those principles should allow us to to agree on designs that allow for 0, 1, or 3 bits of spin bit. That way we know what to do with the outcome of the discussions we plan to have in Bangkok and can implement the changes relatively quickly. For those who read this far, if you have opinions on what principles should drive this design, please respond here. If you have a proposed design (or designs) and can explain the principles that are expressed, that's OK too. If this gets enough feedback, I might arrange a call for interested parties. I don't expect that we'll reach a conclusion before the interim, but I don't think that we can let this go unresolved much beyond that point. From nobody Sun Aug 5 22:56:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC977130EC1 for ; Sun, 5 Aug 2018 22:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sfy9T2cw1vyH for ; Sun, 5 Aug 2018 22:55:50 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0130130E8B for ; Sun, 5 Aug 2018 22:55:50 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id k12-v6so20072547oiw.8 for ; Sun, 05 Aug 2018 22:55: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=iBDfb+eyhQ6fHkMeNW0QFh7tynj+IAinl40i9Am6GKQ=; b=IcsHu266Uv0UKNRrWykT/mcsoNuTIqSdChbRwPjkLCrwpwCthQog0KhMTnRWvsdqmU mpx2TshohgI4+CYF9es09PH64SRIgHaVN5jEMPB2XDBkK03Wq/Y/Wl62z6/E60jGRHjV hr35Z0V4yaAsmdABTrSz/BjmP7M7FFFzHhhBunFrFsJr0UzAKTOViba51fk62FuPyuWC sSAcL7QKqdXGo6gtilUD/g5QYfGXrYX39c2g7w8si8rlyCME8v9PX8WSOFvOwBC2fziD wgjAw8/WzfQx5OZEJ1ibKH3OvhKBuAvXcu4P2/4Py73nXw34D2vsLvebfGu3siM7EzXI YKnA== 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=iBDfb+eyhQ6fHkMeNW0QFh7tynj+IAinl40i9Am6GKQ=; b=lYrITxAsVzmcHFwkIk4PgTyy5UA81NiQb89Kq55nuv0Ka5lJWxd5/KMTMnDBTJLS9D 54OKOpqqHdUtqxV7Ie7lXeXi38cbAk6NgwuptJE5eDu56aIn42vHau/XaE+WyWBGStSB pi/prfjpc6INwj4oOYbRFltPmzfJP17qFWEit4t/VMf+XXiRsRzQTY/hn535Vhc3GcsE u+RBQbrwgOYvw2bkRd8bW655XPsnpaMSI0DUdl/U9uUqxnrq3rSy22eL2WOHWqA32Vym e39W+F63vEZVb9X4vJfrjnPQ9hQqWz0usSVm89A5RTCq5NwyTU2jsQv/xVc0VeIp497I FFQQ== X-Gm-Message-State: AOUpUlFiBHZ+0f+hsiQqKskLRWZHIGa5oIZMjM9WW3fDMpHtsjB5+WpC I0/M2/OSLUkR1++lIQaJxe39DHtJPUaYeGr9EGx9ereu X-Google-Smtp-Source: AAOMgpccL9DVg1g408+m4bSdBs1UnPZQIMdnAHzC8Lm/Lnj0oc3rRbHNi1Z00Tq+oQaclyCA6FyoXXUw0VjiRP/TXt0= X-Received: by 2002:aca:df42:: with SMTP id w63-v6mr12411553oig.295.1533534949670; Sun, 05 Aug 2018 22:55:49 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Mon, 6 Aug 2018 15:55:39 +1000 Message-ID: Subject: Key updates To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 05:55:58 -0000 One of the open items out of the design team work was the interaction between TLS and key updates. As you might know, TLS key updates are synchronous, which works well in TCP, but less well in QUIC, where you need at least two active keys for reception around a key change. As it is, I think that there are two serious options: 1. Use KEY_PHASE to signal a change. This requires that both endpoints are loosely synchronized, which disadvantages asymmetric data exchanges. 2. Use a prepare-commit style. DTLS does this by having each peer send a KeyUpdate message, then requiring that to be acknowledged before they can switch to the new epoch. QUIC could do the same. The change is still signaled in the key phase bit, but only after this signaling exchange. The weakness of the first option is that packets marked with a change of key phase trigger trial decryption. And it requires synchronized changes, where if one endpoint moves to epoch N (epoch == encryption level with fewer characters to type), then the other has to follow before either can move to epoch N+1. The second has more moving parts, but avoids both of these problems. I tend to think that the second is a better design on balance, if only to dispense with the trial decryption, which we've managed to avoid in every other case thus far. The complication might also present some opportunities, which I will explain below, but that's a secondary concern. If we want to use this signaling method, we need to decide who drives key updating, TLS or QUIC: TLS: The DTLS design might work in QUIC, but with the KeyUpdate message hidden in an opaque CRYPTO frame, it could be a little tricky to manage properly. If we let TLS drive the key update, then it will send a KeyUpdate message in a CRYPTO frame and inform QUIC of the change in sending keys. From here, QUIC can keep using old keys until all CRYPTO frames from that epoch are acknowledged. The receiver will inform QUIC of new receive keys when it receives KeyUpdate, which can be installed. QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC sends when it wants to update keys. When this is acknowledged, new keys can be installed and used for sending. A new API is needed to TLS to support cranking the key schedule forward. Invoking that API would lead to TLS signaling the availability of new keys. The receive side isn't any different from the TLS option. If this was to have parity with TLS, this would probably need to be two frame types so that a unilateral update could be distinguished from an update that includes a request for a mutual update. In both cases, QUIC will install new receive keys, but retain old receive keys so that it can deal with reordering. A few round trips, an RTO, 2MSL, or whatever we decide for the handshake is probably fine. Sending keys can be discarded immediately. The advantage of having TLS drive is that it uses the same machinery we have for the handshake. And there is no disparity between what TLS and QUIC understand to be current: when TLS wants to send something (a NewSessionTicket message for example), then it asks for an epoch that matches what QUIC is using. The disadvantage of using TLS is that there are more moving parts involved. It fits the rules we have for the handshake neatly: for instance, the CRYPTO frame would be retransmitted using the strict encryption-level rules, reusing that code from the handshake. But those rules aren't really necessary given that the rules for a KEY_UPDATE easily have the same effect. My inclination here is to have TLS drive this. The additional complexity seems to be manageable in the sense that it uses mechanisms that should already exist for the handshake. I also don't think that a new API for this feature is a good way to ensure that it is used. Those who are implementing, I know that key updates are often a long way down the list of priorities, but has anyone spent time considering the options here? (I personally implemented key updates for TLS, but I still haven't managed to find time to do it for DTLS, which might say something...) -- Addendum: Optional Key Phase ? One of the nice things about either prepare-commit design is that it opens a new option for how we use bits in headers. If there is a concern about spending a bit on every packet for the key phase (a whole bit!), we could design an encoding that only included the key phase if a longer packet number encoding was in use. The idea would be that you could use the longer packet number encoding while you have a key update outstanding, so that the key phase was available for the entirety of the changeover. Once packets with the new epoch were acknowledged, you could switch back to a shorter encoding that didn't include a key phase. The receiver would switch to expecting the new epoch after receiving the first packet in the new epoch. That's a saving that might allow endpoints to use the shortest packet number encoding in more cases. Of course, the header design is already complex enough, so maybe we don't actually *want* more options to consider there :) From nobody Sun Aug 5 23:52:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D411292AD for ; Sun, 5 Aug 2018 23:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqQnsL77C8JG for ; Sun, 5 Aug 2018 23:52:45 -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 CB020128CE4 for ; Sun, 5 Aug 2018 23:52:45 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id s198-v6so20269936oih.11 for ; Sun, 05 Aug 2018 23:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9BcELXssg94K8jaEqlP7wYkdIrK9FbVv/d0G7Nx/SjQ=; b=pl4XHB9tKGow+nALvp8HN+t1eekxVJWFwLljmdZ244p5HNO3it5+5GfFN+AGY4Em7U zrw443ZPBNJGG73IjufJwHWcDsAxmoiLEvVU8ixUZ1e0FpUmXfBoSNQc7AnNMRGev33l 3STFJpKxpFvDf4FpyksJYVrqQ2mQF5GN2pnQGdTQCqs6XiO7wHIPGAK4P/RsMo0ATNob nliS9iqYimYnI/t4CZl7VOMxMfVXV52eUa/KaeAei0jD3xFeWRTb9PiaLvaGPAB53Cry txOWDXI/ReNFlyGfbHRIT5Kmv3PSwN972aXrt7FfgRiYEmeM3sY5K92i6psEvUZm33vh 2Ziw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9BcELXssg94K8jaEqlP7wYkdIrK9FbVv/d0G7Nx/SjQ=; b=DLQNwP/ITB632ZY5GFybHF8BUmt07vD8ab5i2XHfxaSsthpKWnv1DYUgx5kPtOUpKU hXWfr7Io2EJW5GUOBeqsUUmemaFKTzxlJdgLh9DmE0hZkOgjTbfEydwm1fUKyuwBYlpj fvjS+Txz5B3vPnB4y8vkQ03F1YkWsKlTxjiOrCzO1zqD3cjbzewNQSPEW283jOtjUIA7 4AmNRb/kM8tVwVj7+W7xVgCFjnufWVPitlrE2pTELFODU+cAaKJPFnfhkyH+MmSQKa7G 7N+3GnPqKaH6s55kmRPMwtGf+a1xDBVBzVjBCTiS8Gk6aDsOefzE86qowwr0Uh6czyKO dkyw== X-Gm-Message-State: AOUpUlEirzUmaxVFiqbIX18EiEwDFRlByAnGoDrihg8VegophlGFLuMN O7BLYdtFCn5vvFNXrC1QNBrLB5xS7ZaqOfGplpiLnsot X-Google-Smtp-Source: AAOMgpcU3U5MTPvw/TXU9tzLJ/ZnBONdcemaoVMUSkie5Mz5jUW6RICroWgiHl2ZcRDk/DI1f2mcH5WhHxgXkwJtTE8= X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr12266136oib.254.1533538364663; Sun, 05 Aug 2018 23:52:44 -0700 (PDT) MIME-Version: 1.0 References: <20180805154649.GA14245@ubuntu-dmitri> <20180806043610.GC25402@ubuntu-dmitri> <20180806044626.GD25402@ubuntu-dmitri> In-Reply-To: <20180806044626.GD25402@ubuntu-dmitri> From: Martin Thomson Date: Mon, 6 Aug 2018 16:52:34 +1000 Message-ID: Subject: Re: QPACK proposal: wrap absolute index values To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 06:52:47 -0000 On Mon, Aug 6, 2018 at 2:46 PM Dmitri Tikhonov wrote: > bool > isHeaderBlocked (unsigned LargestRef) Thanks for sharing code. Note that I'm not just interested in whether I'm blocked, but for how many table updates I should block for, but I can use this function (repeatedly if necessary) to make that determination, I guess. It took me ages to understand this code. Are you expecting all the arithmetic for CurMax to be modulo MaxEntries*2 ? Because if that is the case, then this makes sense. Without that stipulation, I really struggled. We should examine the assertion here then. That is, you make two claims: one true, and one maybe-true: 1. You can't receive a header block with a largest reference that is more than MaxEntries old from the current state. This holds trivially because that would mean that the entire header table was evicted. We don't allow entries to be referenced after eviction and there is no way to reach this state without evicting the largest reference. 2. You can't receive a header block with a largest reference that is more than MaxEntries new. This doesn't hold because we don't cap the amount that a header block can be blocked by. Now, it's arguably a reasonable restriction, because it takes multiple round trips to reach a state where that header block can be used, but we don't currently prevent someone from doing something like that. Now, it's reasonable to assume that you can't have more than MaxEntries worth of updates in flight, which means that in one round trip, this will never happen. But we don't say that you can't reference dynamic table entries that are far in the future. For this to work, we would have to prohibit that. Maybe we should, because referencing entries that can't be sent is a footgun, just as referencing entries that have not yet been sent is a footgun (it can deadlock flow control if you do that). From nobody Mon Aug 6 01:10:55 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B42B129619 for ; Mon, 6 Aug 2018 01:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 oARf3O1o7tim for ; Mon, 6 Aug 2018 01:10:52 -0700 (PDT) Received: from enrai.xavamedia.nl (enrai.xavamedia.nl [217.115.195.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2B0127598 for ; Mon, 6 Aug 2018 01:10:51 -0700 (PDT) Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by enrai.xavamedia.nl (Postfix) with ESMTPSA id E213090007D for ; Mon, 6 Aug 2018 10:10:49 +0200 (CEST) Received: by mail-wm0-f43.google.com with SMTP id o18-v6so13352357wmc.0 for ; Mon, 06 Aug 2018 01:10:49 -0700 (PDT) X-Gm-Message-State: AOUpUlH2WadmYw+jAjyhrqEx/dpOwzQoy8rcujv8jxZWFKtqsjLaW21M xe3CLdioXF7YU+w4ANQ/15XUHH+s4aiekAFVuGA= X-Google-Smtp-Source: AAOMgpcImNQJITwVhZn0t0MiWDfKfoVXaWm64uGMydMpAV2iXJXetpgUSOti8Zp8AmDa+kZSVus3DFV9+4+ITJ/kA7A= X-Received: by 2002:a1c:2d54:: with SMTP id t81-v6mr11860569wmt.31.1533543049737; Mon, 06 Aug 2018 01:10:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dirkjan Ochtman Date: Mon, 6 Aug 2018 10:10:37 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: The first octet To: martin.thomson@gmail.com Cc: quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba3fd00572bfd0ba" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 08:10:54 -0000 --000000000000ba3fd00572bfd0ba Content-Type: text/plain; charset="UTF-8" On Mon, Aug 6, 2018 at 7:56 AM Martin Thomson wrote: > For those who read this far, if you have opinions on what principles > should drive this design, please respond here. If you have a proposed > design (or designs) and can explain the principles that are expressed, > that's OK too. If this gets enough feedback, I might arrange a call > for interested parties. > I haven't dug deeply into this, but I have been wondering about enabling alternatives to TLS for integrity and confidentiality. Notably, I think the Noise protocol variants are looking very interesting into this space. Assuming that the current stream 0 design makes it possible to somewhat generically swap out TLS for something and that Noise provides the right primitives to fit that conceptual API, it seems reserving some bits in the long header packets might help enable this? Regards, Dirkjan --000000000000ba3fd00572bfd0ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 6, 2018 at 7:56 AM Martin Thomson <martin.thomson@gmail.com> wrote= :
For those wh= o read this far, if you have opinions on what principles
should drive this design, please respond here.=C2=A0 If you have a proposed=
design (or designs) and can explain the principles that are expressed,
that's OK too.=C2=A0 If this gets enough feedback, I might arrange a ca= ll
for interested parties.

I haven't d= ug deeply into this, but I have been wondering about enabling alternatives = to TLS for integrity and confidentiality. Notably, I think the Noise protoc= ol variants are looking very interesting into this space. Assuming that the= current stream 0 design makes it possible to somewhat generically swap out= TLS for something and that Noise provides the right primitives to fit that= conceptual API, it seems reserving some bits in the long header packets mi= ght help enable this?

Regards,

Dirkjan
--000000000000ba3fd00572bfd0ba-- From nobody Mon Aug 6 01:13:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFF4129619 for ; Mon, 6 Aug 2018 01:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=SyM/f1Xd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WZgX8HkT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUOfr_dcFSCC for ; Mon, 6 Aug 2018 01:13:22 -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 259E4127598 for ; Mon, 6 Aug 2018 01:13:22 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5569021BBE; Mon, 6 Aug 2018 04:13:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 06 Aug 2018 04:13:21 -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= fm3; bh=A5iUCooetbs3a9xJTZ+M7lcKoH6rItRI5YAN9ROTRqI=; b=SyM/f1Xd n4QbneXFb0EOJn+/5rpWWASXSbTIiySBb3GJNYBfQfc9qguPQzeX9VRRkWNDwI29 iiqjvr9j5jDSxX/jDDozmdfjI3Ra2x0cSZ9a56js57IrDv8glByE/NVtOYf1n97n DGQMgF+uog62jKqOHptSeaaLxdfuJpAuakr2mpWkycxNtjdTvuzX1Oxm5/p5zmcx fVgYX/JeqJdiJsryxO4d+l6M257u/AO/Y+iiDJSNfRxDyWR+frQ0jWrnaJVjskF+ UZHbyONr/sPZsQqvtIVuyoAvk8YguAslcBRLHG8f43qxtGLVW1XKH4KIzCRK9m0v DKenu3BMFp7I/w== 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=fm3; bh=A5iUCooetbs3a9xJTZ+M7lcKoH6rI tRI5YAN9ROTRqI=; b=WZgX8HkTSNvhjgWxb/PKEJ4zQtfDITKoBv/IUgy5RZYM5 tyWal731XZS22tTB7NTbmRFQdeQqKVNWeJgYx+a2cbMku9ep+Wr5Knqfmi7f5T1Q 4tB1cvBKhFfi5Yp0YCzDNUwnRpTk45l20Zmg068yFelHOHelZfE0je8/ZKQEDNLr hLiSIPuAU9XFXS9orfWOUHINa6Y3/t19GwK0Ljk8cRc60x4zExEl3Oof0j8+v05u u7/6xIsPTML90Vl0MF3QdNnnZiV8ea0B2613+GI4vokI86n11ULtwmHwaJPU3QJf UApadmoxJQ1kCfNzX2Q5W9pkV2rQ0k67EGtLzD1MQ== X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id E2F2110255; Mon, 6 Aug 2018 04:13:19 -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.5 \(3445.9.1\)) Subject: Reminder: Registration for the September Interim Message-Id: <1820B63B-D278-4E8A-95EC-5200664163FB@mnot.net> Date: Mon, 6 Aug 2018 18:13:17 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 08:13:24 -0000 ... closes in roughly one week.=20 Please see: = https://github.com/quicwg/wg-materials/blob/master/interim-18-09/arrangeme= nts.md There is still room left, but if a lot of people have left it to the = last minute, we may have to impose restrictions on multiple = registrations from a single company, registrations from non-active = observers, etc. Cheers, P.S. If you aren't sure if you've registered yet, please ask me and/or = lars on Slack or in e-mail; so far we haven't had *any* duplicate = registrations :) -- Mark Nottingham https://www.mnot.net/ From nobody Mon Aug 6 02:22:30 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A875130EB5 for ; Mon, 6 Aug 2018 02:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 aBYH1G6u2Kdj for ; Mon, 6 Aug 2018 02:22:27 -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 90AF3130DE9 for ; Mon, 6 Aug 2018 02:22:27 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id p81-v6so17180452itp.1 for ; Mon, 06 Aug 2018 02:22:27 -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=kGzrdD+3rAXitRbL+P5cdWtghAGdyfC5hlTBBdYtzgw=; b=ZVn1j3tZoTjP8SoWsTpb9eCZEol2r0XN+kQYmQLU3miFNtbDeGq+rQhdaoxQcfffGe aZgp1E1j45vst+LIqeXDqaqW253SVZNk+f3eDjBr7+S3XGew1kkUa5FGaXbhKTOhHuuw vrpawFOXm9TJgepDtlFiQdvLEKzU5EbuVeG35hp8ODIjMBNxZXNwEcdzT+dUSOLU5E/9 R21ejFHl4YakY9HUxzp6QM3Nh02tuyyRR9iBh1fMbOv9SGt3RdYvL1XQ7FwLJSAGhcoF VoAS/vBk1K3Fucz6zupLerG/lOIdUgFdpf4Tl191eps5su6DYkCRb4MkV/WBuK+wd9ZV v9dQ== 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=kGzrdD+3rAXitRbL+P5cdWtghAGdyfC5hlTBBdYtzgw=; b=fuzPRlf5V6xlBc50Bzyj38cPuqTWCxossSfMcmA12w3krxaM+M3znKQjSAuDxopruf Wtomz88qMCPVTcURRnwys2Goxvju2s3c+52f9xuj8BverRNSKgkw+9dcMuOzey7LUJQB 4Ar8xwfUGAQv76ipbij/7uQ8CqhZ57DePUvh7nzByrRuHCkRFXuBK142YGyRh4hDcuDn io+t04FbDiGdeFdsgaBe36i1B0d0NlKi2hW5p1HpgS5TDjyEjStw3p6kWemkOW8KL7dw 0QgyJYL8e74GU9ku5DPZ+nBtNlBUnHajFh/gL6mj5NHPWBHgqMMtEO9+v1hejsCLM+Mo xoUA== X-Gm-Message-State: AOUpUlGaYm3YKazM46sBI1eRZc94XyTMTvBn68o8ClFvy+GfkV4m0F0M ZhUKY4BZnkp8rqvFhV7XjUmSYsYmCdB3X31LZVE= X-Google-Smtp-Source: AAOMgpdXuQeVT/MWCjvAs3Uolh2189CSKEYJbAwoA+emeVknvXCkR9LrT1KKGld9oZMSxDP7jOLtIoD39H0xyCUeb/M= X-Received: by 2002:a02:9833:: with SMTP id t48-v6mr12175468jaj.111.1533547346873; Mon, 06 Aug 2018 02:22:26 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 6 Aug 2018 02:22:26 -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: Mon, 6 Aug 2018 02:22:26 -0700 Message-ID: Subject: Re: Key updates To: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="000000000000db52ae0572c0d096" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 09:22:29 -0000 --000000000000db52ae0572c0d096 Content-Type: text/plain; charset="UTF-8" On the last part: using a longer packet number - that would create an observable signal similar to an unencrypted key-phase bit because many packets would tend to have similar sizes, then suddenly spike a few bytes in length. Key phase could also be tied to connection id, and perhaps some consideration should be given to a possible multi-path design before opting for the more complex solution. As I understand it, the commit option still requires synchronised key updates in both directions. How about one-sided key updates? On 6 August 2018 at 07.56.18, Martin Thomson (martin.thomson@gmail.com) wrote: One of the open items out of the design team work was the interaction between TLS and key updates. As you might know, TLS key updates are synchronous, which works well in TCP, but less well in QUIC, where you need at least two active keys for reception around a key change. As it is, I think that there are two serious options: 1. Use KEY_PHASE to signal a change. This requires that both endpoints are loosely synchronized, which disadvantages asymmetric data exchanges. 2. Use a prepare-commit style. DTLS does this by having each peer send a KeyUpdate message, then requiring that to be acknowledged before they can switch to the new epoch. QUIC could do the same. The change is still signaled in the key phase bit, but only after this signaling exchange. The weakness of the first option is that packets marked with a change of key phase trigger trial decryption. And it requires synchronized changes, where if one endpoint moves to epoch N (epoch == encryption level with fewer characters to type), then the other has to follow before either can move to epoch N+1. The second has more moving parts, but avoids both of these problems. I tend to think that the second is a better design on balance, if only to dispense with the trial decryption, which we've managed to avoid in every other case thus far. The complication might also present some opportunities, which I will explain below, but that's a secondary concern. If we want to use this signaling method, we need to decide who drives key updating, TLS or QUIC: TLS: The DTLS design might work in QUIC, but with the KeyUpdate message hidden in an opaque CRYPTO frame, it could be a little tricky to manage properly. If we let TLS drive the key update, then it will send a KeyUpdate message in a CRYPTO frame and inform QUIC of the change in sending keys. From here, QUIC can keep using old keys until all CRYPTO frames from that epoch are acknowledged. The receiver will inform QUIC of new receive keys when it receives KeyUpdate, which can be installed. QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC sends when it wants to update keys. When this is acknowledged, new keys can be installed and used for sending. A new API is needed to TLS to support cranking the key schedule forward. Invoking that API would lead to TLS signaling the availability of new keys. The receive side isn't any different from the TLS option. If this was to have parity with TLS, this would probably need to be two frame types so that a unilateral update could be distinguished from an update that includes a request for a mutual update. In both cases, QUIC will install new receive keys, but retain old receive keys so that it can deal with reordering. A few round trips, an RTO, 2MSL, or whatever we decide for the handshake is probably fine. Sending keys can be discarded immediately. The advantage of having TLS drive is that it uses the same machinery we have for the handshake. And there is no disparity between what TLS and QUIC understand to be current: when TLS wants to send something (a NewSessionTicket message for example), then it asks for an epoch that matches what QUIC is using. The disadvantage of using TLS is that there are more moving parts involved. It fits the rules we have for the handshake neatly: for instance, the CRYPTO frame would be retransmitted using the strict encryption-level rules, reusing that code from the handshake. But those rules aren't really necessary given that the rules for a KEY_UPDATE easily have the same effect. My inclination here is to have TLS drive this. The additional complexity seems to be manageable in the sense that it uses mechanisms that should already exist for the handshake. I also don't think that a new API for this feature is a good way to ensure that it is used. Those who are implementing, I know that key updates are often a long way down the list of priorities, but has anyone spent time considering the options here? (I personally implemented key updates for TLS, but I still haven't managed to find time to do it for DTLS, which might say something...) -- Addendum: Optional Key Phase ? One of the nice things about either prepare-commit design is that it opens a new option for how we use bits in headers. If there is a concern about spending a bit on every packet for the key phase (a whole bit!), we could design an encoding that only included the key phase if a longer packet number encoding was in use. The idea would be that you could use the longer packet number encoding while you have a key update outstanding, so that the key phase was available for the entirety of the changeover. Once packets with the new epoch were acknowledged, you could switch back to a shorter encoding that didn't include a key phase. The receiver would switch to expecting the new epoch after receiving the first packet in the new epoch. That's a saving that might allow endpoints to use the shortest packet number encoding in more cases. Of course, the header design is already complex enough, so maybe we don't actually *want* more options to consider there :) --000000000000db52ae0572c0d096 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On the last part: us= ing a longer packet number - that would create an observable signal similar= to an unencrypted key-phase bit because many packets would tend to have si= milar sizes, then suddenly spike a few bytes in length.

K= ey phase could also be tied to connection id, and perhaps some consideratio= n should be given to a possible multi-path design before opting for the mor= e complex solution.

As I understand it, the commit option still requires sy= nchronised key updates in both directions. How about one-sided key updates?=

On 6 August 2018 at 07.56.18, Mart= in Thomson (martin.thomson@gmai= l.com) wrote:

One of the open items out of the design team work was th= e interaction
between TLS and key updates. As you might know, TLS key updates are
synchronous, which works well in TCP, but less well in QUIC, where you
need at least two active keys for reception around a key change.

As it is, I think that there are two serious options:

1. Use KEY_PHASE to signal a change. This requires that both
endpoints are loosely synchronized, which disadvantages asymmetric
data exchanges.

2. Use a prepare-commit style. DTLS does this by having each peer
send a KeyUpdate message, then requiring that to be acknowledged
before they can switch to the new epoch. QUIC could do the same. The
change is still signaled in the key phase bit, but only after this
signaling exchange.

The weakness of the first option is that packets marked with a change
of key phase trigger trial decryption. And it requires synchronized
changes, where if one endpoint moves to epoch N (epoch =3D=3D encryptio= n
level with fewer characters to type), then the other has to follow
before either can move to epoch N+1. The second has more moving
parts, but avoids both of these problems.

I tend to think that the second is a better design on balance, if only
to dispense with the trial decryption, which we've managed to avoid= in
every other case thus far. The complication might also present some
opportunities, which I will explain below, but that's a secondary
concern.

If we want to use this signaling method, we need to decide who drives
key updating, TLS or QUIC:

TLS: The DTLS design might work in QUIC, but with the KeyUpdate
message hidden in an opaque CRYPTO frame, it could be a little tricky
to manage properly. If we let TLS drive the key update, then it will
send a KeyUpdate message in a CRYPTO frame and inform QUIC of the
change in sending keys. From here, QUIC can keep using old keys until
all CRYPTO frames from that epoch are acknowledged. The receiver will
inform QUIC of new receive keys when it receives KeyUpdate, which can
be installed.

QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC
sends when it wants to update keys. When this is acknowledged, new
keys can be installed and used for sending. A new API is needed to
TLS to support cranking the key schedule forward. Invoking that API
would lead to TLS signaling the availability of new keys. The receive
side isn't any different from the TLS option. If this was to have
parity with TLS, this would probably need to be two frame types so
that a unilateral update could be distinguished from an update that
includes a request for a mutual update.

In both cases, QUIC will install new receive keys, but retain old
receive keys so that it can deal with reordering. A few round trips,
an RTO, 2MSL, or whatever we decide for the handshake is probably
fine. Sending keys can be discarded immediately.

The advantage of having TLS drive is that it uses the same machinery
we have for the handshake. And there is no disparity between what TLS
and QUIC understand to be current: when TLS wants to send something (a
NewSessionTicket message for example), then it asks for an epoch that
matches what QUIC is using.

The disadvantage of using TLS is that there are more moving parts
involved. It fits the rules we have for the handshake neatly: for
instance, the CRYPTO frame would be retransmitted using the strict
encryption-level rules, reusing that code from the handshake. But
those rules aren't really necessary given that the rules for a
KEY_UPDATE easily have the same effect.

My inclination here is to have TLS drive this. The additional
complexity seems to be manageable in the sense that it uses mechanisms
that should already exist for the handshake. I also don't think th= at
a new API for this feature is a good way to ensure that it is used.

Those who are implementing, I know that key updates are often a long
way down the list of priorities, but has anyone spent time considering
the options here? (I personally implemented key updates for TLS, but
I still haven't managed to find time to do it for DTLS, which might
say something...)

--
Addendum: Optional Key Phase ?

One of the nice things about either prepare-commit design is that it
opens a new option for how we use bits in headers. If there is a
concern about spending a bit on every packet for the key phase (a
whole bit!), we could design an encoding that only included the key
phase if a longer packet number encoding was in use.

The idea would be that you could use the longer packet number encoding
while you have a key update outstanding, so that the key phase was
available for the entirety of the changeover. Once packets with the
new epoch were acknowledged, you could switch back to a shorter
encoding that didn't include a key phase. The receiver would switc= h
to expecting the new epoch after receiving the first packet in the new
epoch.

That's a saving that might allow endpoints to use the shortest pack= et
number encoding in more cases. Of course, the header design is
already complex enough, so maybe we don't actually *want* more opti= ons
to consider there :)

--000000000000db52ae0572c0d096-- From nobody Mon Aug 6 02:31:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BE3130E77 for ; Mon, 6 Aug 2018 02:31:31 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qW9eHTuWRxd for ; Mon, 6 Aug 2018 02:31:29 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538A9128C65 for ; Mon, 6 Aug 2018 02:31:29 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id j205-v6so21011936oib.4 for ; Mon, 06 Aug 2018 02:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i8szRashV7AyCBjzHEDCm8ylKChRB6yUc3QJQ5IXJLA=; b=iO3fjrRCAA9Nq4xSv7HnY/vGQ604dFvi/JX9GPb1+yCgVT2EjkNEUaphyyCFxBq55K SQf3vqUcMal7Ra+MtBDsJmjeQqJNXyHvpIjqnhpENdi/qHRH3sb8EpvkQa3f7ej2aiD/ VTV5nfxEcYMXLzHAPulx6Hbz/B7JDBsB06sHqylChB4KcsyAHq0BzKsTJ1HmbqCBj2OP gwzVHeIIBzkxhx0crPjkym4c/bJfYJlLGI9uUAqcrdvZjro8JbIIzMXL55qBa15GtCUx cLFskiVMPD80F/di1ZbPDIbPh5P1zdYVbFbsdDj/2bqwJcWWoPUoLtf4YXHYfI09Ic9l Ce5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i8szRashV7AyCBjzHEDCm8ylKChRB6yUc3QJQ5IXJLA=; b=dYrL52ZoAayWcqKhoYDgggP/HJP3rPxYo1Sj80YwwnxveFAXP6fpxtgM4BnzEHHvEo JvD1XaypOUbhDmXvppZnFkBiOTZ/pUB1SM/4+qxt/Fiy3uFMAUbJL/bHWbNCf+9JwgKd 7iEWtpwTPAi2lgDqi7DtJzRVg4oLIoBWso+0QBxYiU9JQTTVdLHju2TS8e48SHfRR36d sPKUhA4RF+XvksrXN/7hbkuigA5SBI7vM6BVtkVkmU8ZeCfwUBAEo0biAuNNWIarCy6h irWLGySNu+eDOYXeQ6GnerqS2n9EPNFUhc7WBRzpttoQLcKPL37Zw2CUlPFurUqZn2MS TrRg== X-Gm-Message-State: AOUpUlHSiA4xSexkZ2s0M/XRYAU+EBDSp0iRtiGQK5ObrY6BCntzTXNr 6rtpRQrpeOtDDFTl1Fno+gqueMKKRy3Mn+c2vNU= X-Google-Smtp-Source: AAOMgpdNkGku9Jj/XD15qq3WIaa0pPreAyZU/O8hmDHDDpsXLtWE7vq8hiHEwczRD0ZqjBPyBBWMag3mBbnOyBZGwLs= X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr12646562oib.254.1533547888398; Mon, 06 Aug 2018 02:31:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Mon, 6 Aug 2018 19:31:16 +1000 Message-ID: Subject: Re: Key updates To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: QUIC WG Content-Type: multipart/alternative; boundary="0000000000002257ae0572c0f1b0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 09:31:32 -0000 --0000000000002257ae0572c0f1b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 6 Aug. 2018, 19:22 Mikkel Fahn=C3=B8e J=C3=B8rgensen, wrote: > On the last part: using a longer packet number - that would create an > observable signal similar to an unencrypted key-phase bit because many > packets would tend to have similar sizes, then suddenly spike a few bytes > in length. > The size of a packet number is hidden. Given that most packets are full sized, the only effect on those would be less available space for payload. ACK packets would increase in size by a couple of octets, which could be masked easily and cheaply if necessary. Key phase could also be tied to connection id, and perhaps some > consideration should be given to a possible multi-path design before opti= ng > for the more complex solution. > This is definitely an option I have considered. If you have a workable design, I would be interested. I couldn't reconcile the desired rates of updates. Connection IDs are needed in spikes, where the rate for key updates is more measured. As I understand it, the commit option still requires synchronised key > updates in both directions. How about one-sided key updates? > The option I describe doesn't require that both sides update at the same time, not do endpoints need to update in lock-step (they can require reciprocal updates, but that is discretionary). > On 6 August 2018 at 07.56.18, Martin Thomson (martin.thomson@gmail.com) > wrote: > > One of the open items out of the design team work was the interaction > between TLS and key updates. As you might know, TLS key updates are > synchronous, which works well in TCP, but less well in QUIC, where you > need at least two active keys for reception around a key change. > > As it is, I think that there are two serious options: > > 1. Use KEY_PHASE to signal a change. This requires that both > endpoints are loosely synchronized, which disadvantages asymmetric > data exchanges. > > 2. Use a prepare-commit style. DTLS does this by having each peer > send a KeyUpdate message, then requiring that to be acknowledged > before they can switch to the new epoch. QUIC could do the same. The > change is still signaled in the key phase bit, but only after this > signaling exchange. > > The weakness of the first option is that packets marked with a change > of key phase trigger trial decryption. And it requires synchronized > changes, where if one endpoint moves to epoch N (epoch =3D=3D encryption > level with fewer characters to type), then the other has to follow > before either can move to epoch N+1. The second has more moving > parts, but avoids both of these problems. > > I tend to think that the second is a better design on balance, if only > to dispense with the trial decryption, which we've managed to avoid in > every other case thus far. The complication might also present some > opportunities, which I will explain below, but that's a secondary > concern. > > If we want to use this signaling method, we need to decide who drives > key updating, TLS or QUIC: > > TLS: The DTLS design might work in QUIC, but with the KeyUpdate > message hidden in an opaque CRYPTO frame, it could be a little tricky > to manage properly. If we let TLS drive the key update, then it will > send a KeyUpdate message in a CRYPTO frame and inform QUIC of the > change in sending keys. From here, QUIC can keep using old keys until > all CRYPTO frames from that epoch are acknowledged. The receiver will > inform QUIC of new receive keys when it receives KeyUpdate, which can > be installed. > > QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC > sends when it wants to update keys. When this is acknowledged, new > keys can be installed and used for sending. A new API is needed to > TLS to support cranking the key schedule forward. Invoking that API > would lead to TLS signaling the availability of new keys. The receive > side isn't any different from the TLS option. If this was to have > parity with TLS, this would probably need to be two frame types so > that a unilateral update could be distinguished from an update that > includes a request for a mutual update. > > In both cases, QUIC will install new receive keys, but retain old > receive keys so that it can deal with reordering. A few round trips, > an RTO, 2MSL, or whatever we decide for the handshake is probably > fine. Sending keys can be discarded immediately. > > The advantage of having TLS drive is that it uses the same machinery > we have for the handshake. And there is no disparity between what TLS > and QUIC understand to be current: when TLS wants to send something (a > NewSessionTicket message for example), then it asks for an epoch that > matches what QUIC is using. > > The disadvantage of using TLS is that there are more moving parts > involved. It fits the rules we have for the handshake neatly: for > instance, the CRYPTO frame would be retransmitted using the strict > encryption-level rules, reusing that code from the handshake. But > those rules aren't really necessary given that the rules for a > KEY_UPDATE easily have the same effect. > > My inclination here is to have TLS drive this. The additional > complexity seems to be manageable in the sense that it uses mechanisms > that should already exist for the handshake. I also don't think that > a new API for this feature is a good way to ensure that it is used. > > Those who are implementing, I know that key updates are often a long > way down the list of priorities, but has anyone spent time considering > the options here? (I personally implemented key updates for TLS, but > I still haven't managed to find time to do it for DTLS, which might > say something...) > > -- > Addendum: Optional Key Phase ? > > One of the nice things about either prepare-commit design is that it > opens a new option for how we use bits in headers. If there is a > concern about spending a bit on every packet for the key phase (a > whole bit!), we could design an encoding that only included the key > phase if a longer packet number encoding was in use. > > The idea would be that you could use the longer packet number encoding > while you have a key update outstanding, so that the key phase was > available for the entirety of the changeover. Once packets with the > new epoch were acknowledged, you could switch back to a shorter > encoding that didn't include a key phase. The receiver would switch > to expecting the new epoch after receiving the first packet in the new > epoch. > > That's a saving that might allow endpoints to use the shortest packet > number encoding in more cases. Of course, the header design is > already complex enough, so maybe we don't actually *want* more options > to consider there :) > > --0000000000002257ae0572c0f1b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Mon, 6 Aug. 2018, 19:22 Mikkel Fahn=C3=B8e J=C3=B8rgensen, <mikkelfj@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On the last part: using a longer packet number - th= at would create an observable signal similar to an unencrypted key-phase bi= t because many packets would tend to have similar sizes, then suddenly spik= e a few bytes in length.

The size of a packet number is hidden. Give= n that most packets are full sized, the only effect on those would be less = available space for payload. ACK packets would increase in size by a couple= of octets, which could be masked easily and cheaply if necessary.=C2=A0

Key phase could also be tied to connection id, and perhaps some c= onsideration should be given to a possible multi-path design before opting = for the more complex solution.

This is definitely an option I = have considered. If you have a workable design, I would be interested. I co= uldn't reconcile the desired rates of updates. Connection IDs are neede= d in spikes, where the rate for key updates is more measured.

A= s I understand it, the commit option still requires synchronised key update= s in both directions. How about one-sided key updates?

The opt= ion I describe doesn't require that both sides update at the same time,= not do endpoints need to update in lock-step (they can require reciprocal = updates, but that is discretionary).


On 6 August 2018 at 07.56.18, Martin = Thomson (martin.thomson@gmail.com) wrote:

One of the open items out of the design team work was the interaction
between TLS and key updates. As you might know, TLS key updates are
synchronous, which works well in TCP, but less well in QUIC, where you
need at least two active keys for reception around a key change.

As it is, I think that there are two serious options:

1. Use KEY_PHASE to signal a change. This requires that both
endpoints are loosely synchronized, which disadvantages asymmetric
data exchanges.

2. Use a prepare-commit style. DTLS does this by having each peer
send a KeyUpdate message, then requiring that to be acknowledged
before they can switch to the new epoch. QUIC could do the same. The
change is still signaled in the key phase bit, but only after this
signaling exchange.

The weakness of the first option is that packets marked with a change
of key phase trigger trial decryption. And it requires synchronized
changes, where if one endpoint moves to epoch N (epoch =3D=3D encryptio= n
level with fewer characters to type), then the other has to follow
before either can move to epoch N+1. The second has more moving
parts, but avoids both of these problems.

I tend to think that the second is a better design on balance, if only
to dispense with the trial decryption, which we've managed to avoid= in
every other case thus far. The complication might also present some
opportunities, which I will explain below, but that's a secondary
concern.

If we want to use this signaling method, we need to decide who drives
key updating, TLS or QUIC:

TLS: The DTLS design might work in QUIC, but with the KeyUpdate
message hidden in an opaque CRYPTO frame, it could be a little tricky
to manage properly. If we let TLS drive the key update, then it will
send a KeyUpdate message in a CRYPTO frame and inform QUIC of the
change in sending keys. From here, QUIC can keep using old keys until
all CRYPTO frames from that epoch are acknowledged. The receiver will
inform QUIC of new receive keys when it receives KeyUpdate, which can
be installed.

QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC
sends when it wants to update keys. When this is acknowledged, new
keys can be installed and used for sending. A new API is needed to
TLS to support cranking the key schedule forward. Invoking that API
would lead to TLS signaling the availability of new keys. The receive
side isn't any different from the TLS option. If this was to have
parity with TLS, this would probably need to be two frame types so
that a unilateral update could be distinguished from an update that
includes a request for a mutual update.

In both cases, QUIC will install new receive keys, but retain old
receive keys so that it can deal with reordering. A few round trips,
an RTO, 2MSL, or whatever we decide for the handshake is probably
fine. Sending keys can be discarded immediately.

The advantage of having TLS drive is that it uses the same machinery
we have for the handshake. And there is no disparity between what TLS
and QUIC understand to be current: when TLS wants to send something (a
NewSessionTicket message for example), then it asks for an epoch that
matches what QUIC is using.

The disadvantage of using TLS is that there are more moving parts
involved. It fits the rules we have for the handshake neatly: for
instance, the CRYPTO frame would be retransmitted using the strict
encryption-level rules, reusing that code from the handshake. But
those rules aren't really necessary given that the rules for a
KEY_UPDATE easily have the same effect.

My inclination here is to have TLS drive this. The additional
complexity seems to be manageable in the sense that it uses mechanisms
that should already exist for the handshake. I also don't think th= at
a new API for this feature is a good way to ensure that it is used.

Those who are implementing, I know that key updates are often a long
way down the list of priorities, but has anyone spent time considering
the options here? (I personally implemented key updates for TLS, but
I still haven't managed to find time to do it for DTLS, which might
say something...)

--
Addendum: Optional Key Phase ?

One of the nice things about either prepare-commit design is that it
opens a new option for how we use bits in headers. If there is a
concern about spending a bit on every packet for the key phase (a
whole bit!), we could design an encoding that only included the key
phase if a longer packet number encoding was in use.

The idea would be that you could use the longer packet number encoding
while you have a key update outstanding, so that the key phase was
available for the entirety of the changeover. Once packets with the
new epoch were acknowledged, you could switch back to a shorter
encoding that didn't include a key phase. The receiver would switc= h
to expecting the new epoch after receiving the first packet in the new
epoch.

That's a saving that might allow endpoints to use the shortest pack= et
number encoding in more cases. Of course, the header design is
already complex enough, so maybe we don't actually *want* more opti= ons
to consider there :)

--0000000000002257ae0572c0f1b0-- From nobody Mon Aug 6 02:37:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C59130E77 for ; Mon, 6 Aug 2018 02:37:57 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITTHloYTB4HB for ; Mon, 6 Aug 2018 02:37:55 -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 B097A128C65 for ; Mon, 6 Aug 2018 02:37:55 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id d189-v6so21004806oib.6 for ; Mon, 06 Aug 2018 02:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M5HLtTK5lQlkhZ40G/ZynoEza6hrWHOWufm9cbY4ytM=; b=U/bFs9JMokyYAXEFX4AArEF8gprIwhb9o8/2wS+57l+DFnUXb9gqn2TL8Hbew5tWMP YICl3N0GAZDbFDy8qpsojSj1b6j5qoHTHCWQwyKNcF2PQhB89ISWLeZlCjKDyaUTtKSO PmBoF4Sl5tYyIe5cebGByqMmtjYymryQLNp1xzpCAqX1GZ2ILuJnucCs46FoxnJnVKTI V+DLFS5TlOFnjEnMCXjw3lIs4VqTePGGChqpMKqE3trcYfi49/KIh5jKVGyNc6qvgBmm zZsR0AbT8TMSOFwoEM94qHU34Vm2ctFj6OIOt3LoHGb7M+KPa+FSYg4uDaDbavq8dFqx DS+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M5HLtTK5lQlkhZ40G/ZynoEza6hrWHOWufm9cbY4ytM=; b=IVtXHF0JJ8rCDH9j20/YDQtFSrq0JoRjJQ6utrENwHDrVaSgM54zLaIn7lde6alB6Y KLUspq8EbA+R6zXWP2xMNgSc9pFHOMoIU6UIVJuFTPRrXd7eqakjPXc1y57vEvvZc7Bz GQTeJuarEL0GYKmiSq2nDUAz6r+Rybz/UnRleeQ0mxcwaXOg279EUTRuL3+yrDtt+Lpl ZUWDlRZrtXfQrmid2VALFEx4lqKRGCfui47gdKCJicHaF3/TES3EbaLyGRJ7CEnCOifk WuOngE3hdXFAMWGscoiArh5ehUQgeXtc0Lr1x2MlLqzXoq+NYQN2UVpx9Dx89GllfAau R1fg== X-Gm-Message-State: AOUpUlGdny3DRoVd9YsYcwVf0eQR20hHUYA/BlDfODmnwBwaTBOAOg7w WURsU3QovagJyfYDnwmZU0Z578cdpAPqfOryR171IA== X-Google-Smtp-Source: AAOMgpfnv25wPcQ4x3MtwQbRKWjjO6dObh0vSatdQ2n8SHrlWHn3+k66SRI0DD4/jL3d8O+jM5dHY+AezHxZis1R2yw= X-Received: by 2002:aca:5841:: with SMTP id m62-v6mr14799283oib.346.1533548275016; Mon, 06 Aug 2018 02:37:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Mon, 6 Aug 2018 19:37:43 +1000 Message-ID: Subject: Re: The first octet To: Dirkjan Ochtman Cc: QUIC WG Content-Type: multipart/alternative; boundary="0000000000002dacea0572c10837" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 09:37:57 -0000 --0000000000002dacea0572c10837 Content-Type: text/plain; charset="UTF-8" On Mon, 6 Aug. 2018, 18:10 Dirkjan Ochtman, wrote: > On Mon, Aug 6, 2018 at 7:56 AM Martin Thomson > wrote: > >> For those who read this far, if you have opinions on what principles >> should drive this design, please respond here. If you have a proposed >> design (or designs) and can explain the principles that are expressed, >> that's OK too. If this gets enough feedback, I might arrange a call >> for interested parties. >> > > I haven't dug deeply into this, but I have been wondering about enabling > alternatives to TLS for integrity and confidentiality. Notably, I think the > Noise protocol variants are looking very interesting into this space. > Assuming that the current stream 0 design makes it possible to somewhat > generically swap out TLS for something and that Noise provides the right > primitives to fit that conceptual API, it seems reserving some bits in the > long header packets might help enable this? > QUIC v1 will use TLS. All the questions I am asking relate specifically to that version. I made it clear in my original email that these are version-specific bits. A protocol that uses a different cryptographic handle has to use a different version number. --0000000000002dacea0572c10837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, 6 Aug. 2018, 18:10 Dirkjan Ochtman, <dirkjan@ochtman.nl> wrote:
On Mon, Aug 6, 2018 at 7:56 AM Martin T= homson <martin.thomson@gmail.com> wrote:
For those who read this far, if = you have opinions on what principles
should drive this design, please respond here.=C2=A0 If you have a proposed=
design (or designs) and can explain the principles that are expressed,
that's OK too.=C2=A0 If this gets enough feedback, I might arrange a ca= ll
for interested parties.

I haven't d= ug deeply into this, but I have been wondering about enabling alternatives = to TLS for integrity and confidentiality. Notably, I think the Noise protoc= ol variants are looking very interesting into this space. Assuming that the= current stream 0 design makes it possible to somewhat generically swap out= TLS for something and that Noise provides the right primitives to fit that= conceptual API, it seems reserving some bits in the long header packets mi= ght help enable this?

QUIC v1 will use TLS. All the questions I am a= sking relate specifically to that version. I made it clear in my original e= mail that these are version-specific bits.

A protocol that uses a different cryptographic handle ha= s to use a different version number.
--0000000000002dacea0572c10837-- From nobody Mon Aug 6 02:39:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCF6130EB8 for ; Mon, 6 Aug 2018 02:39:27 -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, 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 d8Io_NvEeR9y for ; Mon, 6 Aug 2018 02:39:25 -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 8BB90130EB4 for ; Mon, 6 Aug 2018 02:39:24 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id h23-v6so17181199ita.5 for ; Mon, 06 Aug 2018 02:39:24 -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=am2o/0Aaomsi3znF6ZsM+0NFtysbarjLKpDIEOML60s=; b=FxXfcaZG83umIUb3TQUjwHbzHHdcZFHX93QDGM3dLN35KZrr9Z3EJwn1bVRHoa4VL8 VoNA5k5lohDk8Pv73yXCoLSny+n/J45jBnRWDyB9u/SSrvEXFYWIlZ2sHqeR6CeC/2C2 CGhUtcirSg+ANhFLqieLpLOwGtNuLvh6YZEvRgNxbfipko5+lFAvxKWxZrtcreK6gssI Teq4SDhUXHNUT9vUhfTjZSWqLWgh2yygyjDmR8UrJfX7ykHsMYga6xnHhPQN/Ez/6sOU XKb+Y5BEZa1wd4hHQ8c+wPW7KqkzIfoImpnlQOmGGYw8ICE19b83BJnSSMKGFkPKXRqD d2dA== 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=am2o/0Aaomsi3znF6ZsM+0NFtysbarjLKpDIEOML60s=; b=niOQR+jmUNVoFVM0O4GT7MICmGfVriooaFBhfsOJLTyXrYcQBDaeKYBoc4Hcxi8waA oZ0EG4Luw4JoivOQLDAt7e5hVur1htGFKjNRsmjLnLIXrvY8Er/FRr9pCTLxhAtlzJHI xvjLP7EdbTTjGFwgIsDOZkpum1v9eWsS5qC+YU32VSitm0GkIQttCmvdFOFpUb/Gl1tZ kFUGueht4pQ/aCE1uN4Xh1eVK+XZj5vlLaUEFPIyu95180KpcQ8AtiYjx+A/Rq0dL4UQ jq49AcMhAt1SrYj9mEf8Vtg/gxvTF8FZMbVoHTA51VUuxVKEODTsJxl3N2ac6nzJqGF6 1W1Q== X-Gm-Message-State: AOUpUlFPuPmS4kRFx8pCUKZhlrvRp1gQKWH9/wfOdceEPATJABTSGhbX T40cJM923rWF9m117ZTCek7tNjzoZ9g5jdtN8SgMGw== X-Google-Smtp-Source: AAOMgpf7WBrJXi0oVZt+2UDrZkCziVuwjltRVCNHsKnm5OsaqLKWKMM3SwfspOJYArCwcQhhfKX8uuzspXZc8/5orKQ= X-Received: by 2002:a24:5e0b:: with SMTP id h11-v6mr14598684itb.80.1533548363909; Mon, 06 Aug 2018 02:39:23 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 6 Aug 2018 02:39:23 -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: Mon, 6 Aug 2018 02:39:23 -0700 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="0000000000007a0e0d0572c10de3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 09:39:28 -0000 --0000000000007a0e0d0572c10de3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The size of a packet number is hidden. Given that most packets are full sized, the only effect on those would be less available space for payload. ACK packets would increase in size by a couple of octets, which could be masked easily and cheaply if necessary. I=E2=80=99d challenge that, especially in the cases where it matters most: = long running mobility applications. For example a car management system that uploads battery and other operational statistics, geofencing applications, or chat applications used by train commuters. --0000000000007a0e0d0572c10de3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

The size of a packet number is hidden. Give= n that most packets are full sized, the only effect on those would be less = available space for payload. ACK packets would increase in size by a couple= of octets, which could be masked easily and cheaply if necessary.=C2=A0

I=E2=80=99d challenge that, especial= ly in the cases where it matters most: long running mobility applications. = For example a car management system that uploads battery and other operatio= nal statistics, geofencing applications, or chat applications used by train= commuters.

--0000000000007a0e0d0572c10de3-- From nobody Mon Aug 6 02:44:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02784130EB5 for ; Mon, 6 Aug 2018 02:44:55 -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, 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 lVrXMZ-eroDl for ; Mon, 6 Aug 2018 02:44:53 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 AC385130EB2 for ; Mon, 6 Aug 2018 02:44:53 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id v71-v6so17228769itb.3 for ; Mon, 06 Aug 2018 02:44:53 -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=LKUfUmbTKFEPRANltQ6sfkno5KbZZLM5bLgGdCAFB5Y=; b=sbdfBDS76PNzf9Z+dQy+9M3EdFQua8ZFOwxCIZi9cc+BuWUt3gyP+rafTgGc6ZaaPV 4FqQD3u1FmRnqplOFomOo0Tsg0Z1Dt1eIYXMBP/TY5iM3YsTA0JGeuNSmPMjW1mpUmQe y1uwcgtHdVDfSmLmpUQYOuWHPsfW+Y5JofVKwvaw0BZqbf+iIbhaPJQh35NKc8KnvEe4 +Ardn/JSWBTrMjb8/2Wq4Cx54oLj/5ZYie17Nay2mrEPWOAVy1kWSLQsn0mskguOi+wA F3o2x9ObmGA3WpzxXOr2HDd4Tc5KHx+pjMjJ3SfuD+5bOfD+tjJODco764LeLuh931a1 PttA== 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=LKUfUmbTKFEPRANltQ6sfkno5KbZZLM5bLgGdCAFB5Y=; b=KY4eNy1QO4MUrA5PMbSXsnvH6TWQ02kCMOelmn0VUWq2IlKBySEDeNqRWLW8djACIN hNeE2INbywczHLbjRTK8Be/SkQBoQHYiuHlCounIbwyt4j0sxlGB/27FILgdCAH8CI22 RI8hjxTgX/+KIfcJk+aqMKEbnUa0Oor5y9awpebaJAfTxHZgK2AX/NuQ5f46I38neuVZ bKv1sfeP9FVQztbWxoAf25BgGgtOmGDwB/tEIhZoTrhdus4+VeVGSBFx+pbAb2vt/gWv gAqvv/0h1L8DIUB6iQxMmatjuW4Ib34DayB5axrgWbXP6fcjIbIiKLJJTbc2uXKAIsAA p2VQ== X-Gm-Message-State: AOUpUlFskjIUEqQpKOdJh/xX2tlDtg381bLx4hmRn6FfhL3kifIoNcO+ QOu95/lndFhkFtpxbKucsrNZyZz/AvCz+f+TOOU= X-Google-Smtp-Source: AAOMgpe7GIfYo10wBr5fUJOHh59M0+BBhcE9pdEWOHk95A3LGUA6NrUXLSZiZ8zHFVShoFJjHmF5+jqvee6bNIeOCvY= X-Received: by 2002:a02:8c75:: with SMTP id j50-v6mr12319836jal.76.1533548693100; Mon, 06 Aug 2018 02:44:53 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 6 Aug 2018 02:44:52 -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: Mon, 6 Aug 2018 02:44:52 -0700 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="000000000000191db20572c121be" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 09:44:55 -0000 --000000000000191db20572c121be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is definitely an option I have considered. If you have a workable design, I would be interested. I couldn't reconcile the desired rates of updates. Connection IDs are needed in spikes, where the rate for key updates is more measured. I believe the current consensus is to have an ordered set of connections ID=E2=80=99s. If that were not the case, or if there were two sets, then so= me connection ID=E2=80=99s could be associated with a key update. If running o= ut of key update ID=E2=80=99s, a new such ID would be requested. This is somewhat= similar to the commit based option. --000000000000191db20572c121be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
This is = definitely an option I have considered. If you have a workable design, I wo= uld be interested. I couldn't reconcile the desired rates of updates. C= onnection IDs are needed in spikes, where the rate for key updates is more = measured.

I believe the current co= nsensus is to have an ordered set of connections ID=E2=80=99s. If that were= not the case, or if there were two sets, then some connection ID=E2=80=99s= could be associated with a key update. If running out of key update ID=E2= =80=99s, a new such ID would be requested. This is somewhat similar to the = commit based option.

--000000000000191db20572c121be-- From nobody Mon Aug 6 02:52:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDF130EB9 for ; Mon, 6 Aug 2018 02:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeMjRVnEnaSE for ; Mon, 6 Aug 2018 02:52:35 -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 C637F130DE2 for ; Mon, 6 Aug 2018 02:52:34 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id k12-v6so21056694oiw.8 for ; Mon, 06 Aug 2018 02:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ug6YJpBePYU3s7oL0aCl3AFgD7e6sNpoCWfFQ7osE8Q=; b=TG6MliUHUSZ1OeDGdaspOx+2HYsCC1EQ6vyXjPpXvQOcZ3HBvc1bays+yjdMjTSjpW aMSgkH7pK1eHfiiXvolC9wgYPUEE3ZYcwsTtbAciuQKYAXK2HA7+zZhbwJJoyrRVFXqN PJXKQW2bUpNa6D4bMa5EiBLzlmQ8NXH0XR6pVljFFG8sp/GG9/eHr+C23uTKNR7SBnvj YbLw1Xk8nQYzdaAWZOO5TcZYhhvuC5dc0ZC/PkVCiWKKsUU6tEJiKQYlV1IGwaB355Qp ZXBdYchxLzqpm9P5WFwvbacdZg7m/Aa/1yVHhY99xxRlXE/PKEHTkWn+4XBzaKdRmFFT BVZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ug6YJpBePYU3s7oL0aCl3AFgD7e6sNpoCWfFQ7osE8Q=; b=YCIEdDmBJVgclP1AyHlZP7vSD7dEKBc/c+WsdA5i8z8sl1qe4RIgcYarIS7lS2rbQm FIwjP7bZdwi8+rY6eFotwBE3UU5uzflPI/UYboVPs2b2uouRljA8k4py8oH5QdClT/Vq 5MMzZNo50dA6oF7eK0UXfWF4KA0mIiGvQVZSFGd33oXEUupuoZMmePa/3YgMJ63+jF3d TCu/n99sjYXjzdAihOCcYUMG2Gg6aVNkoVRWrCImrTf6er7K/rhCXPN/R2BNeP30a9go Q7C8ubJW1GtykGp8yDdDbM0q2d6SwxYe2GHiDQzr2810zCWL0RNro88TxPYM2AtpUBfo iFtw== X-Gm-Message-State: AOUpUlFQSGbDOLRtALFxfw9bLP6D0adHfpzGsoumj5c9rq13esr4xYIq E2lP95ue+nP40fl7DZqDjdsFC7Cr7u8SCt6/da1tyBRY X-Google-Smtp-Source: AAOMgpeHp5w4aC4x2V2C0L8D4KYUoiYo+vCNxC/TJ5lhF/o/480NH5tSYU25vkVKNA9pOkD7vyKA0OjtWvkIbTfhUOQ= X-Received: by 2002:aca:5841:: with SMTP id m62-v6mr14842132oib.346.1533549154032; Mon, 06 Aug 2018 02:52:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Mon, 6 Aug 2018 19:52:24 +1000 Message-ID: Subject: Re: Key updates To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 09:52:36 -0000 On Mon, Aug 6, 2018 at 7:44 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > >> This is definitely an option I have considered. If you have a workable d= esign, I would be interested. I couldn't reconcile the desired rates of upd= ates. Connection IDs are needed in spikes, where the rate for key updates i= s more measured. > > I believe the current consensus is to have an ordered set of connections = ID=E2=80=99s. If that were not the case, or if there were two sets, then so= me connection ID=E2=80=99s could be associated with a key update. If runnin= g out of key update ID=E2=80=99s, a new such ID would be requested. This is= somewhat similar to the commit based option. The current direction seems to be toward a bag of connection IDs, without ordering. I considered attaching an epoch to NEW_CONNECTION_ID and having updates coupled to key changes, which could work if you were willing to couple changes in that way. The problem there is twofold: the provider of connection IDs is in entirely control over when updates happen (you can't ever update yourself unilaterally), and not all connections have a connection ID in the relevant direction. The former is annoying and probably manageable, the latter is a real deal breaker. >> ACK packets would increase in size by a couple of octets, which could be= masked easily and cheaply if necessary. > > I=E2=80=99d challenge that, especially in the cases where it matters most= : long running mobility applications. For example a car management system t= hat uploads battery and other operational statistics, geofencing applicatio= ns, or chat applications used by train commuters. Are you suggesting that these applications have fixed size payloads such that the change to a longer packet number would be noticeable. That's might be true, but sending a TLS KeyUpdate message or KEY_UPDATE frame would also change the size of packets in a fairly obvious fashion if that were the case (many of these applications have a predictable send rate) as well. If there is an occasional increase in rate, both in terms of number of packets and size, then yes, that could reveal that a key update happened. If that happens across a change of path, then yes, there is a linkability exposure. Given how packet rates are low on these applications, it might be that key updates could be disabled for those applications if this is a concern. As it is, this is far better than a cleartext KEY_PHASE bit, which is a great correlator. From nobody Mon Aug 6 05:19:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1101294D7 for ; Mon, 6 Aug 2018 05:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 FmlWkbD6fQ-u for ; Mon, 6 Aug 2018 05:19:54 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D6D130DC3 for ; Mon, 6 Aug 2018 05:19:54 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id y5-v6so13422855qti.12 for ; Mon, 06 Aug 2018 05:19:54 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=67eI+xGW0k3S2qV/lKvgZjLD2MekFLDphO0kbdk8rTU=; b=robdJMazzg2zXMTFc12QSHvEDECBDD7cjFzyav+aCppJi3O7a9LmtIhSqKCFsSgbiL s3THpyHQ5VUxsZmLCIIGD5pDk5ZDfnJwG4iSXZdzVqO/T2EsgsDVvy2DOKtL2K5nOMPk 8xbKKIdHF+YQaIVHFxP40PB9zuk10uTTAHqrvx5RWK//7wVVqm8jKYwOee9PdZYsmgg4 ypRyhaH1ohMFIMCD60R2iPUQYoA53PnaNMNrPSCRUYQ1viSVC/Bh5BQofOo2Wk25mWwm BE8QRLRU4gKpEH7AOBw8QoTvNsvm/Q/VerX+fY1xj2aat5Ynno3jSpE7XgDLOdbo555g MMqA== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=67eI+xGW0k3S2qV/lKvgZjLD2MekFLDphO0kbdk8rTU=; b=t06wwVqoROk8yEAYUMGRowsv4WgymfFtBqerHMgggQ1cT/Np36d7seOnVmatbksrjV 0rSIyd/387MmaCftxx3GCuvxaEwFuCe9C8vFEgCrbbTyZp3isCV2sFQsvCJyhOFfeyvh cL3n8d3yp0eX1xoC/prJU5uluCF/x5eQWyK89c8h/mWgU98masV01ZBWU/5vnLRlDT1Z AyX2clayndr8Br9v22u7lbdO4ZLsryoXOAdhr32lzhs6kYFQ+aCy0Q3dMVvAsBSzBtuh dBdESZg1PqL7MTdg2Zc06EmM+YAD14LerEYOeoWr+AppYPUXTGglOLyiN0mxnAwBtG5h dVPg== X-Gm-Message-State: AOUpUlGyIvaN0I5UoVgGBb0KdvJZi7W5MQgJlHQncDWuIWEMdFXpsa6e WGuPquTwGEz+frUqBlZgWxiO1A== X-Google-Smtp-Source: AAOMgpcxpOBUiJ45z4NxpgwI8nZStMaxhnqnt+phFH3rBB+oQ2Yp/ach1m0qhZjLGUrGfYN4tAwzlQ== X-Received: by 2002:a0c:bc8a:: with SMTP id l10-v6mr12809216qvg.130.1533557993800; Mon, 06 Aug 2018 05:19:53 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id w39-v6sm616942qtk.74.2018.08.06.05.19.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 05:19:53 -0700 (PDT) Date: Mon, 6 Aug 2018 08:19:48 -0400 From: Dmitri Tikhonov To: Martin Thomson Cc: QUIC WG Subject: Re: QPACK proposal: wrap absolute index values Message-ID: <20180806121947.GA31889@ubuntu-dmitri> Mail-Followup-To: Martin Thomson , QUIC WG References: <20180805154649.GA14245@ubuntu-dmitri> <20180806043610.GC25402@ubuntu-dmitri> <20180806044626.GD25402@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 12:19:56 -0000 On Mon, Aug 06, 2018 at 04:52:34PM +1000, Martin Thomson wrote: > On Mon, Aug 6, 2018 at 2:46 PM Dmitri Tikhonov > wrote: > > bool > > isHeaderBlocked (unsigned LargestRef) > > Thanks for sharing code. Note that I'm not just interested in whether > I'm blocked, but for how many table updates I should block for, but I > can use this function (repeatedly if necessary) to make that > determination, I guess. Well, that's just pseudo-code, you know. I'd never CamelCase real code! > It took me ages to understand this code. Are you expecting all the > arithmetic for CurMax to be modulo MaxEntries*2 ? Because if that is > the case, then this makes sense. Without that stipulation, I really > struggled. Yes, all the arithmetic for the absolute index is modulo MaxEntries * 2. > 2. You can't receive a header block with a largest reference that is > more than MaxEntries new. This doesn't hold because we don't cap the > amount that a header block can be blocked by. This is true -- my assertion about the future horizon is incorrect. Somehow I assumed that the mirror argument about the encoder worked, but it does not. For example, nothing prevents the encoder from pumping the table full of speculative updates, maybe even a few times over, before ever using it. > Now, it's arguably a > reasonable restriction, because it takes multiple round trips to reach > a state where that header block can be used, but we don't currently > prevent someone from doing something like that. > > Now, it's reasonable to assume that you can't have more than > MaxEntries worth of updates in flight, which means that in one round > trip, this will never happen. But we don't say that you can't > reference dynamic table entries that are far in the future. For this > to work, we would have to prohibit that. Maybe we should, because > referencing entries that can't be sent is a footgun, just as > referencing entries that have not yet been sent is a footgun (it can > deadlock flow control if you do that). Yes, for the proposed mechanism to work, we'd have to mandate that the encoder not create new entries past some limit, which is a function of the known decoder state (based on TSS or Header Acks) and MaxEntries. Thanks for identifying this flaw. The change is larger than I was hoping it would be. It's still worth it. - Dmitri. From nobody Mon Aug 6 05:43:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C866F130DC3 for ; Mon, 6 Aug 2018 05:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 YUFTNg-kGgRo for ; Mon, 6 Aug 2018 05:43:55 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC24E130934 for ; Mon, 6 Aug 2018 05:43:54 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id f10-v6so1652216ybk.13 for ; Mon, 06 Aug 2018 05:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V+8i+SP5FAA9bQ7xiZfP2WtCexHigwhC/ijrTUMojwk=; b=p/hzpYXQ/zIWta+iPMLBL4hHq3GmwC1PIMvRTOFa7fbWlQlhRlLDSQ4xA2YtQBTDGs ZYYS9sVY8dHBA19X8rONZ0EC4zbWbRHdumvUR7d/4VgA6YKITcFpSIaCPbVWdGfYj6lW rknqZqa/gjOzvW74C5PpUs6X4EpEUNu7JtqD30wLb0jgWsnezU7wZjfk7vgO250uGIzQ GTYDmCB3ev72OqvX61J8l51nn18JvHcu6Dj0brpzGKj5MIGa+DaijFKl1HqEbdt6Mq/4 f+gqUzwGnT0+Qz0W2mUajHzoJrgfe4fCsLeA87J8O678OAyhaunpQwGfP6UYciby0pPA 7L1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V+8i+SP5FAA9bQ7xiZfP2WtCexHigwhC/ijrTUMojwk=; b=kUV+ZndeFfwweQGjJZmhOOkSNRX3fJkRIy8+RYCMAiNH8rxtqtUhq56DzjO8ZBqQ5W AVEQP1z30tCu40mfLQNBuvnZAXLLfrrNk2V+cZT6+HjlqYmpV+uzSG3WZEzqZ91d+RrY k2kd8Wl6M4sOgUTshcVN6/dZNTR8/1J4OLKANEjvaEtNwR9AeqcJ9WFBSxYgbY+K/iEL 5SCphT5T91FKADfyr1wbsZEngUE4+Dy5HeVJfCUw/H7OWJXPoYQYYVG+Y331V/QoUKKZ 4AHnbgDA585DNF4PNm32i3WSbmc2g8rYL2HBu2mAuo48u5WfSbJky2TKGiXzYRggWoQq 7ctw== X-Gm-Message-State: AOUpUlEUKcmyBjlTt4v9IvxiubrAIDVRbUTc9GaSKmMvsBUVyelT8wVE oUNClA07UL/owC5hjBaeDBUFrD7FuVlM1yrvx8CaJw== X-Google-Smtp-Source: AAOMgpfNLYTpbUddgoo4+oNaRdP79jn0IjhPBcLv5sg56n3ELIq7NhTanH6MV9oXhz0u3R9JuKZE3rL/ZICrIiyNLCk= X-Received: by 2002:a25:c07:: with SMTP id 7-v6mr7591649ybm.178.1533559433714; Mon, 06 Aug 2018 05:43:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Mon, 6 Aug 2018 08:43:09 -0400 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004ab29f0572c3a1ee" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 12:43:58 -0000 --0000000000004ab29f0572c3a1ee Content-Type: text/plain; charset="UTF-8" On Mon, Aug 6, 2018 at 1:56 AM Martin Thomson wrote: > One of the open items out of the design team work was the interaction > between TLS and key updates. As you might know, TLS key updates are > synchronous, which works well in TCP, but less well in QUIC, where you > need at least two active keys for reception around a key change. > > As it is, I think that there are two serious options: > > 1. Use KEY_PHASE to signal a change. This requires that both > endpoints are loosely synchronized, which disadvantages asymmetric > data exchanges. > > 2. Use a prepare-commit style. DTLS does this by having each peer > send a KeyUpdate message, then requiring that to be acknowledged > before they can switch to the new epoch. QUIC could do the same. The > change is still signaled in the key phase bit, but only after this > signaling exchange. > > The weakness of the first option is that packets marked with a change > of key phase trigger trial decryption. And it requires synchronized > changes, where if one endpoint moves to epoch N (epoch == encryption > level with fewer characters to type), then the other has to follow > before either can move to epoch N+1. The second has more moving > parts, but avoids both of these problems. > > I tend to think that the second is a better design on balance, if only > to dispense with the trial decryption, which we've managed to avoid in > every other case thus far. The complication might also present some > opportunities, which I will explain below, but that's a secondary > concern. > > If we want to use this signaling method, we need to decide who drives > key updating, TLS or QUIC: > > TLS: The DTLS design might work in QUIC, but with the KeyUpdate > message hidden in an opaque CRYPTO frame, it could be a little tricky > to manage properly. If we let TLS drive the key update, then it will > send a KeyUpdate message in a CRYPTO frame and inform QUIC of the > change in sending keys. From here, QUIC can keep using old keys until > all CRYPTO frames from that epoch are acknowledged. The receiver will > inform QUIC of new receive keys when it receives KeyUpdate, which can > be installed. > > QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC > sends when it wants to update keys. When this is acknowledged, new > keys can be installed and used for sending. A new API is needed to > TLS to support cranking the key schedule forward. Invoking that API > would lead to TLS signaling the availability of new keys. The receive > side isn't any different from the TLS option. If this was to have > parity with TLS, this would probably need to be two frame types so > that a unilateral update could be distinguished from an update that > includes a request for a mutual update. > > In both cases, QUIC will install new receive keys, but retain old > receive keys so that it can deal with reordering. A few round trips, > an RTO, 2MSL, or whatever we decide for the handshake is probably > fine. Sending keys can be discarded immediately. > > The advantage of having TLS drive is that it uses the same machinery > we have for the handshake. And there is no disparity between what TLS > and QUIC understand to be current: when TLS wants to send something (a > NewSessionTicket message for example), then it asks for an epoch that > matches what QUIC is using. > > The disadvantage of using TLS is that there are more moving parts > involved. It fits the rules we have for the handshake neatly: for > instance, the CRYPTO frame would be retransmitted using the strict > encryption-level rules, reusing that code from the handshake. But > those rules aren't really necessary given that the rules for a > KEY_UPDATE easily have the same effect. > > My inclination here is to have TLS drive this. The additional > complexity seems to be manageable in the sense that it uses mechanisms > that should already exist for the handshake. I also don't think that > a new API for this feature is a good way to ensure that it is used. > > Those who are implementing, I know that key updates are often a long > way down the list of priorities, but has anyone spent time considering > the options here? (I personally implemented key updates for TLS, but > I still haven't managed to find time to do it for DTLS, which might > say something...) > I think we seriously considered the option of "Close the connection and 0RTT a new one". As a related point, I've seen a few use cases for QUIC where it was useful to have different keys for different connection IDs for a longish period of time. The first is pairing multicast + unicast, but I think there was another. That makes me attracted to the idea of punting on this for QUIC v1 and tackling this at the same time as multipath? > > -- > Addendum: Optional Key Phase ? > > One of the nice things about either prepare-commit design is that it > opens a new option for how we use bits in headers. If there is a > concern about spending a bit on every packet for the key phase (a > whole bit!), we could design an encoding that only included the key > phase if a longer packet number encoding was in use. > > The idea would be that you could use the longer packet number encoding > while you have a key update outstanding, so that the key phase was > available for the entirety of the changeover. Once packets with the > new epoch were acknowledged, you could switch back to a shorter > encoding that didn't include a key phase. The receiver would switch > to expecting the new epoch after receiving the first packet in the new > epoch. > > That's a saving that might allow endpoints to use the shortest packet > number encoding in more cases. Of course, the header design is > already complex enough, so maybe we don't actually *want* more options > to consider there :) > > --0000000000004ab29f0572c3a1ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Aug 6, 2018 at 1:56 AM Martin Thomson <martin.thomson@gmail.com> wrote:
One of the open items out of the design team work was the= interaction
between TLS and key updates.=C2=A0 As you might know, TLS key updates are synchronous, which works well in TCP, but less well in QUIC, where you
need at least two active keys for reception around a key change.

As it is, I think that there are two serious options:

1. Use KEY_PHASE to signal a change.=C2=A0 This requires that both
endpoints are loosely synchronized, which disadvantages asymmetric
data exchanges.

2. Use a prepare-commit style.=C2=A0 DTLS does this by having each peer
send a KeyUpdate message, then requiring that to be acknowledged
before they can switch to the new epoch. QUIC could do the same. The
change is still signaled in the key phase bit, but only after this
signaling exchange.

The weakness of the first option is that packets marked with a change
of key phase trigger trial decryption.=C2=A0 And it requires synchronized changes, where if one endpoint moves to epoch N (epoch =3D=3D encryption level with fewer characters to type), then the other has to follow
before either can move to epoch N+1.=C2=A0 The second has more moving
parts, but avoids both of these problems.

I tend to think that the second is a better design on balance, if only
to dispense with the trial decryption, which we've managed to avoid in<= br> every other case thus far.=C2=A0 The complication might also present some opportunities, which I will explain below, but that's a secondary
concern.

If we want to use this signaling method, we need to decide who drives
key updating, TLS or QUIC:

TLS: The DTLS design might work in QUIC, but with the KeyUpdate
message hidden in an opaque CRYPTO frame, it could be a little tricky
to manage properly.=C2=A0 If we let TLS drive the key update, then it will<= br> send a KeyUpdate message in a CRYPTO frame and inform QUIC of the
change in sending keys.=C2=A0 From here, QUIC can keep using old keys until=
all CRYPTO frames from that epoch are acknowledged.=C2=A0 The receiver will=
inform QUIC of new receive keys when it receives KeyUpdate, which can
be installed.

QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC
sends when it wants to update keys.=C2=A0 When this is acknowledged, new keys can be installed and used for sending.=C2=A0 A new API is needed to TLS to support cranking the key schedule forward.=C2=A0 Invoking that API would lead to TLS signaling the availability of new keys.=C2=A0 The receive=
side isn't any different from the TLS option.=C2=A0 If this was to have=
parity with TLS, this would probably need to be two frame types so
that a unilateral update could be distinguished from an update that
includes a request for a mutual update.

In both cases, QUIC will install new receive keys, but retain old
receive keys so that it can deal with reordering.=C2=A0 A few round trips,<= br> an RTO, 2MSL, or whatever we decide for the handshake is probably
fine.=C2=A0 Sending keys can be discarded immediately.

The advantage of having TLS drive is that it uses the same machinery
we have for the handshake.=C2=A0 And there is no disparity between what TLS=
and QUIC understand to be current: when TLS wants to send something (a
NewSessionTicket message for example), then it asks for an epoch that
matches what QUIC is using.

The disadvantage of using TLS is that there are more moving parts
involved.=C2=A0 It fits the rules we have for the handshake neatly: for
instance, the CRYPTO frame would be retransmitted using the strict
encryption-level rules, reusing that code from the handshake.=C2=A0 But
those rules aren't really necessary given that the rules for a
KEY_UPDATE easily have the same effect.

My inclination here is to have TLS drive this.=C2=A0 The additional
complexity seems to be manageable in the sense that it uses mechanisms
that should already exist for the handshake.=C2=A0 I also don't think t= hat
a new API for this feature is a good way to ensure that it is used.

Those who are implementing, I know that key updates are often a long
way down the list of priorities, but has anyone spent time considering
the options here?=C2=A0 (I personally implemented key updates for TLS, but<= br> I still haven't managed to find time to do it for DTLS, which might
say something...)

I think we seriousl= y considered the option of "Close the connection and 0RTT a new one&qu= ot;.

As a related point, I've seen a fe= w use cases for QUIC where it was useful to have different keys for differe= nt connection IDs for a longish period of time.=C2=A0 The first is pairing = multicast + unicast, but I think there was another.=C2=A0 That makes me att= racted to the idea of punting on this for QUIC v1 and tackling this at the = same time as multipath?

--
Addendum: Optional Key Phase ?

One of the nice things about either prepare-commit design is that it
opens a new option for how we use bits in headers.=C2=A0 If there is a
concern about spending a bit on every packet for the key phase (a
whole bit!), we could design an encoding that only included the key
phase if a longer packet number encoding was in use.

The idea would be that you could use the longer packet number encoding
while you have a key update outstanding, so that the key phase was
available for the entirety of the changeover.=C2=A0 Once packets with the new epoch were acknowledged, you could switch back to a shorter
encoding that didn't include a key phase.=C2=A0 The receiver would swit= ch
to expecting the new epoch after receiving the first packet in the new
epoch.

That's a saving that might allow endpoints to use the shortest packet number encoding in more cases.=C2=A0 Of course, the header design is
already complex enough, so maybe we don't actually *want* more options<= br> to consider there :)

--0000000000004ab29f0572c3a1ee-- From nobody Mon Aug 6 06:07:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D90A130F1A for ; Mon, 6 Aug 2018 06:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8DvIkzdTqC3 for ; Mon, 6 Aug 2018 06:06:56 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7900B130EFC for ; Mon, 6 Aug 2018 06:06:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 41kdG718hVzMlkR; Mon, 6 Aug 2018 15:06:55 +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 rSZcBiby8Zty; Mon, 6 Aug 2018 15:06:54 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.24] (mue-88-130-61-218.dsl.tropolys.de [88.130.61.218]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 6 Aug 2018 15:06:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Key updates From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 6 Aug 2018 15:06:52 +0200 Cc: Martin Thomson , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <193166ED-C8C3-4A6B-9483-5546C34B5BDA@tik.ee.ethz.ch> References: To: Ian Swett X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 13:07:06 -0000 > Am 06.08.2018 um 14:43 schrieb Ian Swett = : >=20 > Those who are implementing, I know that key updates are often a long > way down the list of priorities, but has anyone spent time considering > the options here? (I personally implemented key updates for TLS, but > I still haven't managed to find time to do it for DTLS, which might > say something...) >=20 > I think we seriously considered the option of "Close the connection = and 0RTT a new one". >=20 > As a related point, I've seen a few use cases for QUIC where it was = useful to have different keys for different connection IDs for a longish = period of time. The first is pairing multicast + unicast, but I think = there was another. That makes me attracted to the idea of punting on = this for QUIC v1 and tackling this at the same time as multipath? +1 However, this brings us back to Martin=E2=80=99s other question: does it = make sense to have a couple of reserved bits to make it easy to add a = bit for the next version with minimal changes to the protocol = machinery/wire image? From nobody Mon Aug 6 07:26:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F463130E43 for ; Mon, 6 Aug 2018 07:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 JaUyIM-QOIn5 for ; Mon, 6 Aug 2018 07:26:31 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0134.outbound.protection.outlook.com [104.47.38.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6D7130E3B for ; Mon, 6 Aug 2018 07:26: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:X-MS-Exchange-SenderADCheck; bh=hyOWSHkn0s5Dfr6YMXWw0iEGy/pOsgWwikLEaCV2ZSI=; b=iO50yzBEPAE2FSKSMYszbhO9836w8pZjwYXEYZPeqhIjp18Ob03vA/qnj1XxfgGgFyPTwjI9jOr6kROSGpC4gmdjsO5IIpQJJr+BJYsm1JeWGEIxx7FzivRDcbGm4jbTpJ8Pnx6T+L9HbjwP0TImECxTeVF1yqWLrkyY0KBlEL4= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0984.namprd21.prod.outlook.com (52.132.133.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.2; Mon, 6 Aug 2018 14:26:29 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::60b8:4702:aa5f:f00]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::60b8:4702:aa5f:f00%4]) with mapi id 15.20.1059.003; Mon, 6 Aug 2018 14:26:29 +0000 From: Nick Banks To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Ian Swett , Martin Thomson CC: IETF QUIC WG Subject: RE: Key updates Thread-Topic: Key updates Thread-Index: AQHULUoxGA6n/s8xp0e95A4jtAlbpqSyq3qAgAAGoACAABR4kA== Date: Mon, 6 Aug 2018 14:26:29 +0000 Message-ID: References: <193166ED-C8C3-4A6B-9483-5546C34B5BDA@tik.ee.ethz.ch> In-Reply-To: <193166ED-C8C3-4A6B-9483-5546C34B5BDA@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-08-06T14:26:26.1452004Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:9:1c1c:20b4:5d26:abec] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0984; 6:+uDKWriplhbvi5tU1t2r187czWpQBJRgbx4owoXXE61MV+WPpwPBBEXtY3gM4yxWudae2Apv9bRNg9udqFB149RbnCk4jeny2hlTFvw4K/uBQUSRUxnZ/3dBmkppaIcqrDRJH2GCaCGZlwRYGf+6kr7IH06+7HhI/wGGllzyi0yq1UOltAIGWdYkxXQ7KPD+9q5XmZg38r9Sm4uoLzrWGaB7NY1ihiq9jBIu2qXZRp83pXSZuq3M9p2tsNJZTDWCbhGerLaIa8bSiKXxz99Sh+Qyc7fVZ+YxJQGULelCEfo2M/y3LTlR45TcT8cFkjAlkxBjibz5WkKfULOQSjuMJFRfcJe5Tulq9tMW3yTUw5jIg3PemzA4zo1siQQMB+/gDaqyo/Fcy0gWAoyY7Kedg9NZ092KhzCtHelJ+IU2I1mDlTV3Xjw8mhGoaVxTkCObPmgzzDCY2UVAYhU5O/Nk1w==; 5:/nPgb0wrN6tPkIBCrtAf8jX/86blcb07AzN7KqPsrTIVyVcWR0F+D4GsKhKw2cgoKbjK5WuyZ/swmj8GXkAftvp9+B8cg0v6A2xPzLlD+R9X4SZjxZtDpnYznbdmzqwmjx4iG4dvJaj/VmQUAgPQN5npTcyeoN6RzUyJ7JQPOWM=; 7:holE3jOrGQVhK2DupPDXt6cD/NnKtAPf+9F3QTu82B4s7NEn3DpXwUMoaBwBzqroIaGhpY0C8SWodIdb1u3e4cHPxGmoY1oc/IuWXNngjbIJAIRfkALqQ0dNiHe3uDLIY1Mkhez+LMTnHA3kmRdCiCkOBi2rfwlfj4k6l8Se3bLihHxqulvQC0YDKyZnHXGk24TPffkmplEO4zIa9Cn7W0ygnNgmuqShXIw+V2rw4fde1GvU8Bv0pT6hkuFV5TQH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e01fe4e6-318f-4705-ffbd-08d5fba89987 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:DM5PR2101MB0984; x-ms-traffictypediagnostic: DM5PR2101MB0984: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231311)(944501410)(52105095)(2018427008)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB0984; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0984; x-forefront-prvs: 07562C22DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(136003)(376002)(396003)(199004)(189003)(486006)(10090500001)(10290500003)(105586002)(6116002)(86362001)(9686003)(2900100001)(33656002)(476003)(229853002)(5250100002)(55016002)(7736002)(46003)(81166006)(305945005)(22452003)(8936002)(8990500004)(11346002)(106356001)(3480700004)(446003)(53936002)(86612001)(8676002)(81156014)(74316002)(68736007)(316002)(110136005)(7696005)(186003)(99286004)(221733001)(14454004)(478600001)(76176011)(4326008)(97736004)(25786009)(5660300001)(39060400002)(7116003)(6436002)(15650500001)(256004)(6246003)(2906002)(102836004)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0984; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: MsB1RmJArGyeKG1/7S+tfXTIXdio5HSh+vAr2LlFpRTVLszn6mY98QiKgCs4RNsCaEPesxxn6rAuolD+Ya/hkB8xaWbgung/SDod6AM0Md2Va6zYJLOS1IViAP3WuXqd/GGjmDQD6VquGdrpp/+EgKHQX2OX8rc4EvT4T7ZGGa9m1lE7JDI4HwCbjFcfoaIW+4cU9EQtU6OZ3onF83kndEFqat6iOeBV3Mbm57Gxt/IoVzPGDOMt3YRwflobrKI37tKhl9qRe37bAUhihW8dLtWyIbVjkm3fiUpwe8wGR6x+Ja6LemlYlA/2R2GGjpvn1//0AMdQQGmG18G6RZk+piE2/nUIxh4iJ5SXRGAW/e0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e01fe4e6-318f-4705-ffbd-08d5fba89987 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2018 14:26:29.0786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0984 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 14:26:34 -0000 T24gdGhlIHRvcGljIG9mIHdobyBkcml2ZXMga2V5IHVwZGF0ZXMsIG15IHByZWZlcmVuY2Ugd291 bGQgYmUgdG93YXJkIFFVSUMuIEkgcHJlZmVyIFFVSUMgdG8gaGF2ZSBhcyBsaXR0bGUgZGVwZW5k ZW5jZSBvbiB0aGUgVExTIHN0YXRlIG9iamVjdCBwb3N0IGhhbmRzaGFrZSBhcyBwb3NzaWJsZS4g UHJlZmVyYWJseSwgSSdkIGxpa2UgdG8gIGJlIGFibGUgdG8gdGhyb3cgYXdheSB0aGUgZW50aXJl IFRMUyBzdGF0ZSBvYmplY3Qgc29tZSBzaG9ydCB0aW1lIGFmdGVyIHRoZSBoYW5kc2hha2UuIE9i dmlvdXNseSB0aGlzIHdvdWxkIG9ubHkgYmUgcG9zc2libGUgaWYgbm8gZnVydGhlciBOU1Qgd2ls bCBiZSBzaGFyZWQsIGJ1dCBJIGJlbGlldmUgdGhlcmUgYXJlIHNldmVyYWwgY2FzZXMgd2hlcmUg dGhpcyB3aWxsIGJlIHRydWUuIFRoaXMgd291bGQgYWxsb3cgYSBtb3JlIG1lbW9yeSBlZmZpY2ll bnQgZGVzaWduLCBlc3BlY2lhbGx5IG9uIHRoZSBzZXJ2ZXIgc2lkZS4NCg0KQXMgZmFyIGFzIHB1 bnRpbmcgdGhpcyB0byB0aGUgbmV4dCB2ZXJzaW9uLCBJIGFsc28gdGhpbmsgdGhhdCBtaWdodCBi ZSBhIGdvb2QgaWRlYS4gSSBmdXJ0aGVyIGFncmVlIHdpdGggTWlyamEncyBzdWdnZXN0aW9uIHRo YXQgd2Ugc2hvdWxkIHN0aWxsIGdpdmUgc29tZSBjb25zaWRlcmF0aW9uIG5vdywgc28gYXMgdG8g bWFrZSB0aGUgbW92ZSB0byB0aGUgbmV4dCB2ZXJzaW9uIGVhc2llcjsgaWYgd2UgZ28gdGhpcyBy b3V0ZS4NCg0KLSBOaWNrDQo= From nobody Mon Aug 6 10:27:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660A7130EE8 for ; Mon, 6 Aug 2018 10:27:02 -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 p3nctlQb7vqH for ; Mon, 6 Aug 2018 10:26:54 -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 76867130EE4 for ; Mon, 6 Aug 2018 10:26:54 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx114.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fmjGx-000lbt-VS for quic@ietf.org; Mon, 06 Aug 2018 19:26:51 +0200 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fmjFv-0003YX-Qn for quic@ietf.org; Mon, 06 Aug 2018 13:26:22 -0400 Received: (qmail 11050 invoked from network); 6 Aug 2018 17:05:56 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.107]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Aug 2018 17:05:55 -0000 To: Martin Thomson , quic@ietf.org References: From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <554b1dff-a839-24da-c95f-3370aa811fa6@huitema.net> Date: Mon, 6 Aug 2018 10:05:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: The first octet X-Originating-IP: 168.144.250.234 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.35) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5mXQNEi+wqr+5PBri0Gk2FR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVia+iMoztaKBa01OZvTScrmc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB81OoFFeyN79z+gPkYXfWpU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2Drvl3AsHuisl/RSyh5DLe 1OidX4Ts4xdG+C13IyWeZaLQFv21teFX4xX+heWMZvqWF8FcHzzV3acxBudgYcInb3YzWyKJcaJg isjiFj+QSl6Z4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZxaD1j8zstKyoNMHmOfd8LFwBl1z1+w2zS/h3e6UiVRePuofouKMePgHC OnvDWrETL004r80M5UVENe4iWC7t32eqA47D/juB1cx4exzYk7xEVhTEUT6xtIipPd5Oayzq647l NwN4qOsSZg+fYhVZGz1kOnf1peAVDGMbv2JVybbVwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 17:27:05 -0000 On 8/5/2018 10:55 PM, Martin Thomson wrote: > Long Header > > The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we > have are currently allocated to the 4 types of long header packet, > using only 252-255. All other values are currently unused. > > With respect to design constraints, there is only one that I'm aware > of and that is a potential collision with RTP (and RTCP) on this octet > (see RFC 7983), which use 0x10xxxxxx (128-191). > > The open question here is what we do with unused types. We might > debate creating a registry for unused values. We might want to grease > values. We could even decide to encrypt these values (though the > design of Retry makes that more difficult, because the contents of > that packet aren't encrypted at all). > > I'm not aware of any plans to use these bits, except perhaps what > might be done to be consistent with the short header changes, so we > might have some latitude here. We are actually greasing these bits with the version negotiation packets -- the 7 unused bits of the VN packets are supposedly set to random values. Of course, VN are special purpose packets and should not be used all that often in production, but it is something... -- Christian Huitema From nobody Mon Aug 6 11:12:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D320C130E42 for ; Mon, 6 Aug 2018 11:12:51 -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 8pof2Erg1xbH for ; Mon, 6 Aug 2018 11:12: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 4E578130EB8 for ; Mon, 6 Aug 2018 11:12:50 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fmjzZ-0004nh-2E for quic@ietf.org; Mon, 06 Aug 2018 20:12:48 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fmjzV-00073f-OW for quic@ietf.org; Mon, 06 Aug 2018 14:12:26 -0400 Received: (qmail 28595 invoked from network); 6 Aug 2018 17:25:00 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.107]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Aug 2018 17:25:00 -0000 To: Martin Thomson , quic@ietf.org References: From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <5440ceb8-681a-bdf7-b663-d6ffd0682247@huitema.net> Date: Mon, 6 Aug 2018 10:24:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: The first octet X-Originating-IP: 168.144.250.234 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.27) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5uyfotNHt/BrryPiuUX5Mv5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViE2LQHDW2S/FvytcsY8lMTs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuzDn5j2tUhjYPVPi3bwTCB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpX1dGJ7HPnOCWRaxVuHANylF8FcHzzV3acxBudgYcInb0CpyVROnVj/ w7sXHT79zGSZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZxaD1j8zstKyoNMHmOfd8LFwBl1z1+w2zS/h3e6UiVRfA8zSLq9v74ZMF adhPZSq1BhEDUCtUbohs3ncSqIdk5WeqA47D/juB1cx4exzYk7xEVhTEUT6xtIipPd5Oayzq647l NwN4qOsSZg+fYhVZGz1kOnf1peAVDGMbv2JVybbVwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 18:12:52 -0000 On 8/5/2018 10:55 PM, Martin Thomson wrote: > Process > > Given that we don't have answers to some questions we might conclude > several ways. I proposed that we agree on principles, starting with: > > 0. (This should already be agreed, but I'm repeating it because it's > important.) The low 7 bits of the first octet are version-specific > and can change in the next version of the protocol. Yes. > A. What do we want to do with unused bits? Do we want to ensure that > they are always used? Or can they be reserved? If so, how would they > be reserved (fixed values, random values, greasing, etc...)? My fast-brain response would be to use random values, 0b1RRRRRxx, and do T=3Doctet|0b01111100 when decoding the long header. But that's probably wrong, because of side channels, etc. The next alternative is to define several QUIC versions, with different codes for the four long header types. That would grease both the types and the version field, and would probably be a better way to teach middle-boxes not to make assumptions. > B. Should things in the first octet be encrypted where possible (for > example, using an extension of packet number encoding). That's tempting, but the decryption key is function of the packet type: epoch 0 for initial, epoch 1 for 0rtt, epoch 2 for handshake, clear text for retry. Encrypting the packet type means trial decryption. Do we really want to do that? > > C. Should packet number encodings should be consistent between long > and short header forms? Took me some time to parse what you wanted to say. I think you mean something like, "if we move the number length bits to first octet of the short header, should we also reserve the same two bits to encode the number length bits in the first octet of the long header?" Maybe. Or just say that packet numbers in the long header are always encoded on 32 bits, which might be even simpler. -- Christian Huitema From nobody Mon Aug 6 12:36:26 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9926130DEF for ; Mon, 6 Aug 2018 12:36:24 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8KT_TyWEJqE for ; Mon, 6 Aug 2018 12:36:22 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 97A4E12F1A2 for ; Mon, 6 Aug 2018 12:36:22 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id f8-v6so11549723ljk.1 for ; Mon, 06 Aug 2018 12:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S74jCGpPws1llwI8seL6JYqSqcyHDfYJbqENxEqZVyc=; b=mXjHPBxdk9MxKfC81ifXaLb1q/naYqlQOMgTG+tB5+IB/g+vGv53jrHsJRKcp39NHy HWf40Sc0m6MzQG5viY57KNLiVGc9Qg7vPfNhfLiONBH9x4UCzGztF6B7w1z/WIYZqJYj 5Pi84QE1L3lfHJNj6fwZNI/3EU8bbvG6bkNHUXOk0G3Tsnd7+Wqdos6ZvD3mXtC/LfqT 6Ph+FgUzgmacd5YNxQg0eD+9HN+AYCJZiGMkyj6Nv17VZr1muOUg4aPDaAxgB8tsm6Xn FWfKEIdD6y79iyYO5oi8yr/rRuhCds08OlTbpifkOs6rnruGPjhIkBu4c0EXeWqWXxLR kO2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S74jCGpPws1llwI8seL6JYqSqcyHDfYJbqENxEqZVyc=; b=pvCaHYZ80+afwTaybrXEfIbFcZpmAwBHKo2PGwhBnkuws2rpajt1lILM5IZ2Km+Z1V lPfh2P2IeK+i5m7M9tZn2xK62LW6SJYDIlXwlbNW0SLU3PkUKT0rU6hA/1PCfy28DHa9 UcNK+rK5Gg5Vvmx59SbuujOZNC6UazdV5e3/R8wtcBXBPzHdpBGvxCiZLStofzHFu3PH 4BZVUmAUGPd11OiK9Jz3WU6O/QD2VqdaEiUaj6N656DV1OYoGsfTPn/3s3229k4NVSkt bOsgXP4i/tRekUzJqNUq+WApY/tnQPeiTL4L9wq1BviPFUNeMFWaaPFXu51TYWSWEoME n6Sg== X-Gm-Message-State: AOUpUlG5LRKAuon/T+k4kTWGYfpYz5QYi3TUyq6987ALXzI2A4GHG7jM 6+D+Prno8zThm0DxVrv+sxnhfLtGPVSUOE5GCNs= X-Google-Smtp-Source: AAOMgpcpxYzE7E5rJ6OdMDqmpVwysVnesjdDdXhWIYXiLd4meUUWxoMv47BejoK6NwC/sNp2nZ16izUpmNz+Oy6cJMk= X-Received: by 2002:a2e:998e:: with SMTP id w14-v6mr1389707lji.7.1533584180686; Mon, 06 Aug 2018 12:36:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Mon, 6 Aug 2018 12:36:09 -0700 Message-ID: Subject: Re: The first octet To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="00000000000052b63d0572c9648a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 19:36:25 -0000 --00000000000052b63d0572c9648a Content-Type: text/plain; charset="UTF-8" Hi Martin, Thanks for raising these questions. I agree that we should at least agree as a group on the principles for resolving these questions, so I'll respond on the ones you've suggested. > 0. (This should already be agreed, but I'm repeating it because it's > important.) The low 7 bits of the first octet are version-specific > and can change in the next version of the protocol. > Agreed. > A. What do we want to do with unused bits? Do we want to ensure that > they are always used? Or can they be reserved? If so, how would they > be reserved (fixed values, random values, greasing, etc...)? > I would strongly encourage us to always use unused bits. I think what we so far is quite good, and for the rest of the unused bits, I'm starting to like Christian's idea of using different versions. B. Should things in the first octet be encrypted where possible (for > example, using an extension of packet number encoding). > Yes, but we need to do something where the first octet is not greased (Initial, for instance). And what we do there could also be done where encrypting is inconvenient. C. Should packet number encodings should be consistent between long > and short header forms? > I don't think I have a strong opinion on this yet, but I am leaning towards consistency. Let's not add another type of parsing if we don't need it. > D. What should we do with key phase? This was an open issue from the > stream 0 design team, which might alter the outcome here. I have > another email that covers this in more detail. > (I assume we'll discuss this in the other email thread then.) > E. How should we accommodate multiplexing? For me, the big questions > here are whether we allow for RTP to collide with the long header and > which of the protocols we privilege by avoiding with the short header. > So some thoughts, and I'll admit to still not fully being able to reason about this clearly. It seems to me that the connection ID in short header packets ought to be adequate for demux. For long header packets, again, after the Initial and 0RTT packets, the DCID ought to be enough. If that's true, then we want to avoid conflicting Initial and 0RTT types with RFC 7983 types, which at least reduces the problem. We can figure out where to go from here, but does this agree with your understanding of the world, or am I off in the weeds? - jana --00000000000052b63d0572c9648a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for raising these que= stions. I agree that we should at least agree as a group on the principles = for resolving these questions, so I'll respond on the ones you've s= uggested.
=C2=A0
0. (This should already be agreed, but I'm repeating it b= ecause it's
important.)=C2=A0 The low 7 bits of the first octet are version-specific and can change in the next version of the protocol.
Agreed.
=C2=A0
A. What do we want to do with unused bits?=C2=A0 Do we want to ensure that<= br> they are always used?=C2=A0 Or can they be reserved?=C2=A0 If so, how would= they
be reserved (fixed values, random values, greasing, etc...)?

I would strongly encourage us to always use unused bi= ts. I think what we so far is quite good, and for the rest of the unused bi= ts, I'm starting to like Christian's idea of using different versio= ns.

B. Should things in the first octet be encrypted where possible (for
example, using an extension of packet number encoding).

Yes, but we need to do something where the first octet is = not greased (Initial, for instance). And what we do there could also be don= e where encrypting is inconvenient.

C. Should packet number encodings should be consistent between long
and short header forms?

I don't thi= nk I have a strong opinion on this yet, but I am leaning towards consistenc= y. Let's not add another type of parsing if we don't need it.
=
=C2=A0
D. What should we do with key phase?=C2=A0 This was an open issue from the<= br> stream 0 design team, which might alter the outcome here.=C2=A0 I have
another email that covers this in more detail.

(I assume we'll discuss this in the other email thread then.)
=C2=A0
E. How should we accommodate multiplexing?=C2=A0 For me, the big questions<= br> here are whether we allow for RTP to collide with the long header and
which of the protocols we privilege by avoiding with the short header.
<= /blockquote>

So some thoughts, and I'll admit to sti= ll not fully being able to reason about this clearly. It seems to me that t= he connection ID in short header packets ought to be adequate for demux. Fo= r long header packets, again, after the Initial and 0RTT packets, the DCID = ought to be enough. If that's true, then we want to avoid conflicting I= nitial and 0RTT types with RFC 7983 types, which at least reduces the probl= em. We can figure out where to go from here, but does this agree with your = understanding of the world, or am I off in the weeds?

<= div>- jana
--00000000000052b63d0572c9648a-- From nobody Mon Aug 6 12:57:14 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE5B130EE1 for ; Mon, 6 Aug 2018 12:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQwIsCtWvtDa for ; Mon, 6 Aug 2018 12:57:09 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0124.outbound.protection.outlook.com [104.47.33.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942EC129AB8 for ; Mon, 6 Aug 2018 12:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wbskZvniExX911HR9SKEdvxJHvrIXQAz16qLbyCTqhs=; b=NTc1FAGJUnUM1McwTrbRmkkVdMW59Q62DHI0CkBWwm929A7qCZAlynuKjVBRwaIDsuwU9qi/cB8QQGXFVITSPL0mka1uLZf70aMOSMegLJRYwFqDgzv0aa0qdpcG36rhFQnCbQAmWmn/2VysgiBlFypzdct7IB9SX9Fb7HlVEqA= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4935.namprd08.prod.outlook.com (20.176.255.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.15; Mon, 6 Aug 2018 19:57:05 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::694e:1dd9:1406:b83d]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::694e:1dd9:1406:b83d%4]) with mapi id 15.20.1017.019; Mon, 6 Aug 2018 19:57:05 +0000 From: Mike Bishop To: Martin Thomson , Dirkjan Ochtman CC: QUIC WG Subject: RE: The first octet Thread-Topic: The first octet Thread-Index: AQHULUoqhgm5FMamw0+Lhym2pFmicKSyX1WAgAAYVoCAAKzBIA== Date: Mon, 6 Aug 2018 19:57:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4935; 6:SFPvjdYgKDT30vdG6nN6sIwWZLuq9eUhD5TbN0UI9iBYYA6abxuoYJcqgOnF1Qjlr/eldxg8aESygzF0IltiHKjLxo55tXGhTDzI1qazAbe+wumVMKL246Bp5dlwxUo5puOzapGB13+R5mFjEU5C7HCsZxbA5mlWht1WXOFjstNSuiRUfihpFiqRxwrBVZS1PUfkn+rVLYlobXEE3DWxzPkLSYkzrSplQTpKKiDNu4M3XM2mJAXcInGM0+NkqT23j8Ht7DYWc+tsoYaJPo22AO2kmTImL68VUZtGlpiocv4UKsCUUTvosOxhXRW+IuSZeaeEfpWNG0piN2c1uhvJvOMhF/tqjJ4ADlf88sqTpEl9PAdRG5VJtMS+3DdhKKkryXrKynpxbH43USSDY8E4kM5liLlBKmkxn/kZBVN5UD6w1BPPCQ19Kp/HilppUQ61l5M81Le++0zahhwD/HdL7Q==; 5:KLdbUtZOaysHrgmy31FsSIXQQHpxaCf1iwtmmJvM+9FAK9DRMAem9ZNPIjoqQdMIYshCsBwx/Kr7HQZeO0FpBkskBOLmbJddItExgznXq9M+G9TyvdGzQ+yNsJt6ArvlQpwDs+Z4sNsi1ZOkxsSQlLYpeeBKOPkqeM+zz7jczoU=; 7:ZAMVxadrW7q1gLl1lDeKZK2TCD9pOQM7JJdJFfVR+FNcvKeHx4lqho2GW4Y1DxG5vSFNP7SZnVsl7h13wsMGC6zj/hUoYWq8yMmmxVKO0x4zE+5JWIKPVJ/n2q1nipQ32B3KaMrvce62L1af3BzqpgXhphIFqcuNdt9LUTbcawjKvKa+pCR8vQAtFKszXlWWQ9KBON+ph/6W2ayWxZcd8SquOGxFX7m89WhQu2tA9pJF/i5sDBFF7wuO4w5Tk/OG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 58d3d0a9-76f0-45fd-1147-08d5fbd6c8c9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4935; x-ms-traffictypediagnostic: BYAPR08MB4935: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(2016111802025)(20161123560045)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB4935; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4935; x-forefront-prvs: 07562C22DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39830400003)(396003)(366004)(376002)(346002)(189003)(199004)(236005)(478600001)(9686003)(25786009)(5660300001)(3480700004)(2906002)(7116003)(5250100002)(86362001)(33656002)(53936002)(7736002)(6436002)(6116002)(790700001)(3846002)(81156014)(229853002)(8676002)(14454004)(55016002)(106356001)(4326008)(105586002)(39060400002)(8936002)(81166006)(54896002)(6306002)(6246003)(110136005)(74316002)(316002)(19609705001)(2900100001)(97736004)(66066001)(6506007)(256004)(26005)(186003)(11346002)(446003)(7696005)(102836004)(99286004)(74482002)(76176011)(476003)(486006)(53546011)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4935; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: SwbUeSjc5agAmCVP3gll5RTal/NLuOUEt9bunBO/rkUwc2UNOk5I7U6infRUpk0X0LGrReSkxzDaPC+n9lVcF3arr9KRq/3QpN+FcYaBdoMrGVmFo183bGKcoP1PFiV1xUdXeYg0St6qF+zVSOtfed84dNAXeGy9A6IJy5eokPUQO1dd/skXcDY9J0cn9p2GC/B7vSSK/FJqrtU4ajpsIlV1zToi4HQKrShgB3zwU2Vny6NEoycFYnFFrojgpQz02Rb7i1tGuTXfO0nJs6V1+T04S64Ofbe6C7ASoP/Y5CLSoQGGR/O6+ezX0z+s8juigt5Cx0mNG0H+BUHPQJVMqtGknn3WVbhwS9WafuvkzhU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB3944B68E350A800DE562FC0FDA200BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 58d3d0a9-76f0-45fd-1147-08d5fbd6c8c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2018 19:57:05.0214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4935 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 19:57:13 -0000 --_000_BYAPR08MB3944B68E350A800DE562FC0FDA200BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCmYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoYXQgdmVyc2lvbiBjb3VsZCBWZXJ5IENsb3NlbHkg UmVzZW1ibGUgUVVJQyB2MSAob3Igd2hhdGV2ZXIgdmVyc2lvbiB3ZSB3aW5kIHVwIGNhbGxpbmcg dGhpcykgd2l0aCBhIGRpZmZlcmVudCBwcm90b2NvbCBjYXJyaWVkIGluIENSWVBUTyBmcmFtZXMg LyBwcm92aWRpbmcga2V5cy4NCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6IE1vbmRheSwgQXVndXN0IDYsIDIwMTgg MjozOCBBTQ0KVG86IERpcmtqYW4gT2NodG1hbiA8ZGlya2phbkBvY2h0bWFuLm5sPg0KQ2M6IFFV SUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogVGhlIGZpcnN0IG9jdGV0DQoNCg0K T24gTW9uLCA2IEF1Zy4gMjAxOCwgMTg6MTAgRGlya2phbiBPY2h0bWFuLCA8ZGlya2phbkBvY2h0 bWFuLm5sPG1haWx0bzpkaXJramFuQG9jaHRtYW4ubmw+PiB3cm90ZToNCk9uIE1vbiwgQXVnIDYs IDIwMTggYXQgNzo1NiBBTSBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29t PG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCkZvciB0aG9zZSB3aG8g cmVhZCB0aGlzIGZhciwgaWYgeW91IGhhdmUgb3BpbmlvbnMgb24gd2hhdCBwcmluY2lwbGVzDQpz aG91bGQgZHJpdmUgdGhpcyBkZXNpZ24sIHBsZWFzZSByZXNwb25kIGhlcmUuICBJZiB5b3UgaGF2 ZSBhIHByb3Bvc2VkDQpkZXNpZ24gKG9yIGRlc2lnbnMpIGFuZCBjYW4gZXhwbGFpbiB0aGUgcHJp bmNpcGxlcyB0aGF0IGFyZSBleHByZXNzZWQsDQp0aGF0J3MgT0sgdG9vLiAgSWYgdGhpcyBnZXRz IGVub3VnaCBmZWVkYmFjaywgSSBtaWdodCBhcnJhbmdlIGEgY2FsbA0KZm9yIGludGVyZXN0ZWQg cGFydGllcy4NCg0KSSBoYXZlbid0IGR1ZyBkZWVwbHkgaW50byB0aGlzLCBidXQgSSBoYXZlIGJl ZW4gd29uZGVyaW5nIGFib3V0IGVuYWJsaW5nIGFsdGVybmF0aXZlcyB0byBUTFMgZm9yIGludGVn cml0eSBhbmQgY29uZmlkZW50aWFsaXR5LiBOb3RhYmx5LCBJIHRoaW5rIHRoZSBOb2lzZSBwcm90 b2NvbCB2YXJpYW50cyBhcmUgbG9va2luZyB2ZXJ5IGludGVyZXN0aW5nIGludG8gdGhpcyBzcGFj ZS4gQXNzdW1pbmcgdGhhdCB0aGUgY3VycmVudCBzdHJlYW0gMCBkZXNpZ24gbWFrZXMgaXQgcG9z c2libGUgdG8gc29tZXdoYXQgZ2VuZXJpY2FsbHkgc3dhcCBvdXQgVExTIGZvciBzb21ldGhpbmcg YW5kIHRoYXQgTm9pc2UgcHJvdmlkZXMgdGhlIHJpZ2h0IHByaW1pdGl2ZXMgdG8gZml0IHRoYXQg Y29uY2VwdHVhbCBBUEksIGl0IHNlZW1zIHJlc2VydmluZyBzb21lIGJpdHMgaW4gdGhlIGxvbmcg aGVhZGVyIHBhY2tldHMgbWlnaHQgaGVscCBlbmFibGUgdGhpcz8NCg0KUVVJQyB2MSB3aWxsIHVz ZSBUTFMuIEFsbCB0aGUgcXVlc3Rpb25zIEkgYW0gYXNraW5nIHJlbGF0ZSBzcGVjaWZpY2FsbHkg dG8gdGhhdCB2ZXJzaW9uLiBJIG1hZGUgaXQgY2xlYXIgaW4gbXkgb3JpZ2luYWwgZW1haWwgdGhh dCB0aGVzZSBhcmUgdmVyc2lvbi1zcGVjaWZpYyBiaXRzLg0KDQpBIHByb3RvY29sIHRoYXQgdXNl cyBhIGRpZmZlcmVudCBjcnlwdG9ncmFwaGljIGhhbmRsZSBoYXMgdG8gdXNlIGEgZGlmZmVyZW50 IHZlcnNpb24gbnVtYmVyLg0K --_000_BYAPR08MB3944B68E350A800DE562FC0FDA200BYAPR08MB3944namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7i gKZidXQgdGhlIGRlZmluaXRpb24gb2YgdGhhdCB2ZXJzaW9uIGNvdWxkIFZlcnkgQ2xvc2VseSBS ZXNlbWJsZSBRVUlDIHYxIChvciB3aGF0ZXZlciB2ZXJzaW9uIHdlIHdpbmQgdXAgY2FsbGluZyB0 aGlzKSB3aXRoIGEgZGlmZmVyZW50IHByb3RvY29sIGNhcnJpZWQgaW4gQ1JZUFRPIGZyYW1lcyAv IHByb3ZpZGluZyBrZXlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJ QyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTWFy dGluIFRob21zb248YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgNiwgMjAxOCAyOjM4 IEFNPGJyPg0KPGI+VG86PC9iPiBEaXJramFuIE9jaHRtYW4gJmx0O2RpcmtqYW5Ab2NodG1hbi5u bCZndDs8YnI+DQo8Yj5DYzo8L2I+IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBUaGUgZmlyc3Qgb2N0ZXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgNiBBdWcuIDIw MTgsIDE4OjEwIERpcmtqYW4gT2NodG1hbiwgJmx0OzxhIGhyZWY9Im1haWx0bzpkaXJramFuQG9j aHRtYW4ubmwiPmRpcmtqYW5Ab2NodG1hbi5ubDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1v biwgQXVnIDYsIDIwMTggYXQgNzo1NiBBTSBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhvc2Ugd2hvIHJlYWQgdGhpcyBmYXIs IGlmIHlvdSBoYXZlIG9waW5pb25zIG9uIHdoYXQgcHJpbmNpcGxlczxicj4NCnNob3VsZCBkcml2 ZSB0aGlzIGRlc2lnbiwgcGxlYXNlIHJlc3BvbmQgaGVyZS4mbmJzcDsgSWYgeW91IGhhdmUgYSBw cm9wb3NlZDxicj4NCmRlc2lnbiAob3IgZGVzaWducykgYW5kIGNhbiBleHBsYWluIHRoZSBwcmlu Y2lwbGVzIHRoYXQgYXJlIGV4cHJlc3NlZCw8YnI+DQp0aGF0J3MgT0sgdG9vLiZuYnNwOyBJZiB0 aGlzIGdldHMgZW5vdWdoIGZlZWRiYWNrLCBJIG1pZ2h0IGFycmFuZ2UgYSBjYWxsPGJyPg0KZm9y IGludGVyZXN0ZWQgcGFydGllcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZW4ndCBkdWcgZGVlcGx5IGludG8gdGhpcywg YnV0IEkgaGF2ZSBiZWVuIHdvbmRlcmluZyBhYm91dCBlbmFibGluZyBhbHRlcm5hdGl2ZXMgdG8g VExTIGZvciBpbnRlZ3JpdHkgYW5kIGNvbmZpZGVudGlhbGl0eS4gTm90YWJseSwgSSB0aGluayB0 aGUgTm9pc2UgcHJvdG9jb2wgdmFyaWFudHMgYXJlIGxvb2tpbmcgdmVyeSBpbnRlcmVzdGluZyBp bnRvIHRoaXMgc3BhY2UuIEFzc3VtaW5nIHRoYXQgdGhlDQogY3VycmVudCBzdHJlYW0gMCBkZXNp Z24gbWFrZXMgaXQgcG9zc2libGUgdG8gc29tZXdoYXQgZ2VuZXJpY2FsbHkgc3dhcCBvdXQgVExT IGZvciBzb21ldGhpbmcgYW5kIHRoYXQgTm9pc2UgcHJvdmlkZXMgdGhlIHJpZ2h0IHByaW1pdGl2 ZXMgdG8gZml0IHRoYXQgY29uY2VwdHVhbCBBUEksIGl0IHNlZW1zIHJlc2VydmluZyBzb21lIGJp dHMgaW4gdGhlIGxvbmcgaGVhZGVyIHBhY2tldHMgbWlnaHQgaGVscCBlbmFibGUgdGhpcz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UVVJQyB2MSB3aWxsIHVzZSBUTFMuIEFs bCB0aGUgcXVlc3Rpb25zIEkgYW0gYXNraW5nIHJlbGF0ZSBzcGVjaWZpY2FsbHkgdG8gdGhhdCB2 ZXJzaW9uLiBJIG1hZGUgaXQgY2xlYXIgaW4gbXkgb3JpZ2luYWwgZW1haWwgdGhhdCB0aGVzZSBh cmUgdmVyc2lvbi1zcGVjaWZpYyBiaXRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHByb3RvY29sIHRoYXQgdXNlcyBhIGRpZmZlcmVudCBj cnlwdG9ncmFwaGljIGhhbmRsZSBoYXMgdG8gdXNlIGEgZGlmZmVyZW50IHZlcnNpb24gbnVtYmVy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_BYAPR08MB3944B68E350A800DE562FC0FDA200BYAPR08MB3944namp_-- From nobody Mon Aug 6 13:17:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0397B130E58 for ; Mon, 6 Aug 2018 13:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQzunDTcsHFM for ; Mon, 6 Aug 2018 13:17:55 -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 4FC89126F72 for ; Mon, 6 Aug 2018 13:17:55 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id p81-v6so20007052itp.1 for ; Mon, 06 Aug 2018 13:17:55 -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=zN2yKhQKrb8HtljGI+TjGZWanw40An1xfYlp0DPAVsw=; b=IJdpCofjSanvmD1ksU1pEq2VCo+O8CKObRDSQpHKu2LS5JMVehBKMTzf4u36wKKZrf dbp8PeOESHC01vVTEXHI5nfRxze/pd+h1av0drcNJJkRWKVoIlCDRgl6LJnEhBUtkfkj Hye2Wx/DiFt9mL7oqGqUO98SX2w5CkCJaAAmmueYPGY90rWnwGYjbQZ7RFdtFB0RV4Sc AotEzNTvTMAEYmQpjFcMzuSZx5aQsenjHxAEl0oZwKe1xO3osbDr/JKkaKXvHEU0lxiC agQM8IGJi7T+HgIyfZ65DDmQEvijwXTKq1jb+Lv07kmf/UNBshiOb9f6NT+WpFsVbStm zPew== 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=zN2yKhQKrb8HtljGI+TjGZWanw40An1xfYlp0DPAVsw=; b=QpJDmVKOI1rUwt54D7KlPmUnYMZNcnZbJ+Xog0spOVvkWIbMZL1xoZcsBrFkgcg9jx 0y64glmeueR4FAtkALsmSDcBjd+hWYjHRR21R/QjbqeiyVclhzAout0CH/blOfjYfm88 Z1CVsIAVR+30HnKDL9NH9JYOuTgc7ZpSTZacpheZdpRsnxvKjgmKQTkxYcKdP/fke6nm /p/vmhpF4wm69/A7UfIBg6zQxPm3KpLH0qyfkkGpEffh+kq+6+UJby0b/DtWSPMwD6H2 shavegJNJls+lwqYHS3Gxit+hoPL55ZUL00GdsUxLkcF6nPxhkWdig9MRgSNmLJl2XAx CHZQ== X-Gm-Message-State: AOUpUlEkqJcHvTLEMokHihBVk0OeBRNpNaJ3uY9s5iq5jCjluIPnke8X c0eQcQm0qEMffEVWC2/pLEQc9BzUG4rR5Sij50ZOyA== X-Google-Smtp-Source: AAOMgpfjX+MRIoX1pPV6Ndf+KOa+7VM0mgMK0BjIaca6bbgDKBOyqK8orWLvHQeoCT9SGVkrn2eLybWmJZaYV6VOmxg= X-Received: by 2002:a24:534c:: with SMTP id n73-v6mr16644997itb.25.1533586674746; Mon, 06 Aug 2018 13:17:54 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 6 Aug 2018 13:17:53 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <5440ceb8-681a-bdf7-b663-d6ffd0682247@huitema.net> References: <5440ceb8-681a-bdf7-b663-d6ffd0682247@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 6 Aug 2018 13:17:53 -0700 Message-ID: Subject: Re: The first octet To: Martin Thomson , Christian Huitema , quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000fb10590572c9f87b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 20:17:57 -0000 --000000000000fb10590572c9f87b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 6 August 2018 at 20.13.05, Christian Huitema (huitema@huitema.net) wrote= : > A. What do we want to do with unused bits? Do we want to ensure that > they are always used? Or can they be reserved? If so, how would they > be reserved (fixed values, random values, greasing, etc...)? My fast-brain response would be to use random values, 0b1RRRRRxx, and do T=3Doctet|0b01111100 when decoding the long header. But that's probably wrong, because of side channels, etc. The next alternative is to define several QUIC versions, with different codes for the four long header types. That would grease both the types and the version field, and would probably be a better way to teach middle-boxes not to make assumptions. You could also overlay with a mask based on PN encryption. If the mask doesn=E2=80=99t match the PN that packet is invalid and can be discarded ea= rly - useful for DoS rejection. I know there are arguments about timing attacks etc. but I think really fast packet rejection can be valuable defense. I don=E2=80=99t like the masking idea so much if it works against removing = PNE from AEAD so decoding can happen without buffer mutation, however, if that fails to land, the space might be as well be used constructively. --000000000000fb10590572c9f87b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 6 August 2018 at = 20.13.05, Christian Huitema (huitema= @huitema.net) wrote:
> A. What do we want to do with unused bits? Do= we want to ensure that=C2=A0<= /span>
> they are alway= s used? Or can they be reserved? If so, how would they=C2=A0
> be reserved (fixed values, random values, greasing, etc...= )?=C2=A0

My fast-brain response would be to use random value= s, 0b1RRRRRxx, and do=C2=A0
T=3Doctet|0b01111100 = when decoding the long header. But that's probably=C2=A0
wrong, because of side channels, etc. The next alternative is t= o define=C2=A0
several QUIC versions, with differ= ent codes for the four long header=C2= =A0
types. T= hat would grease both the types and the version field, and would=C2=A0
probably be a better way to teach middle-boxes not to= make assumptions.=C2=A0

You could also overlay with a mask base= d on PN encryption. If the mask doesn=E2=80=99t match the PN that packet is= invalid and can be discarded early - useful for DoS rejection.

I kno= w there are arguments about timing attacks etc. but I think really fast pac= ket rejection can be valuable defense.

I don=E2=80=99t like the maski= ng idea so much if it works against removing PNE from AEAD so decoding can = happen without buffer mutation, however, if that fails to land, the space m= ight be as well be used constructively.

--000000000000fb10590572c9f87b-- From nobody Mon Aug 6 17:20:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932CD130E48 for ; Mon, 6 Aug 2018 17:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Gvv-SD-d_oYL for ; Mon, 6 Aug 2018 17:20:11 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9E1130E3F for ; Mon, 6 Aug 2018 17:20:11 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id x192-v6so10297170qkb.3 for ; Mon, 06 Aug 2018 17:20:11 -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=x6MU2SD1ndXTg800RW/ExLNSH3bMYZj3ZVMNDRKWDsA=; b=xL9pdpL2vOLUZBhl6JSiRa+gJQ4lw5KgS2QXvMQXZMSOvImQUts2RKDpwCC57wjan+ UpbBAaHCAR9xrGM1TRFW78HUX3l/YeOEgqg1/n1MxOXdI6+DrmUB+ew9pnIZIhdj7DQi f9A/U6eTo64lN3M7uMZOLOk93FRIDEscZfcm23jKMFlwQK5OoHSda7VE80BUq4b3P5ju HoLOYHIHjYdLtPgpixEXHaxTvzYUIEyRK+ZbUFRsvv61YwbEqWQKXDHMbSfq24/xysZA U1s6bofb+0ACzWqLVebjlCYPFT8dASYO56sygUPTkAfQA0va5DaHJ0cGdrTcgOUv4JM2 /stQ== 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=x6MU2SD1ndXTg800RW/ExLNSH3bMYZj3ZVMNDRKWDsA=; b=p59a+vtbFLysB78qrUb+r3NHjSC3hhX8Zc8O0Dv29Ql5+ictKvuD8hqo15ztNW3T2T Fg7WkXeu9Ec3LY8/0yJgwW+h1dA675KZdc9G64MfY/fd3He8Sj291LgnAB/mB6YpZWYA W6Z/KrUxHIcVc9AM/5LgvuYCQw1PU+fv0mqO1a5LtWTUh+bjJtOg5nURRQZ6qfhzChrn QjA0tHQ7d1doxDtaFpRMMuLUnzoUtZYW1iu9KteWs3UNLU/E4kulpziRyJ2D1XqT3iFZ 4tTOA/WU+Vkm0lEL4MLobQGrO/as+ghRZnOOx2g4+SfQpmSsOCXUtR+Kr8tFv1zN2P0m VaQA== X-Gm-Message-State: AOUpUlFquezHqNPX+ZVCwZZzILQ0P0ZqOQnUDt8XuSTvFfiSsqzSYT5L hSrzl7SU+zB1vgEloyVOVzlHyg== X-Google-Smtp-Source: AAOMgpcwLPNp/m2z0n70D3zz83/yh09ZyXevvV7Zhq3i9kTxC1J+o09R+lljlo9TYu5hwdz8gpHINg== X-Received: by 2002:a37:14cd:: with SMTP id 74-v6mr15624932qku.184.1533601210913; Mon, 06 Aug 2018 17:20:10 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id c11-v6sm9730028qkb.22.2018.08.06.17.20.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 17:20:10 -0700 (PDT) Date: Mon, 6 Aug 2018 20:20:05 -0400 From: Dmitri Tikhonov To: Alan Frindell , Kazuho Oku , Martin Thomson , QUIC WG Subject: Re: Proposal: drop QPACK encoder stream framing Message-ID: <20180807002003.GA24583@ubuntu-dmitri> Mail-Followup-To: Alan Frindell , Kazuho Oku , Martin Thomson , QUIC WG References: <20180607151112.GA28823@ubuntu-dmitri> <20180609155530.GA6795@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180609155530.GA6795@ubuntu-dmitri> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 00:20:14 -0000 On Sat, Jun 09, 2018 at 11:55:30AM -0400, Dmitri Tikhonov wrote: > And I hope I have demonstrated that the complexity increase is > minimal. Soon, I will demonstrate the same using C code. Here is working code. The function lsqpack_enc_dec_in() ingests the next chunk of the encoder stream -- any number of bytes. It never buffers any of the bytes it reads; nor does it reparse. https://github.com/litespeedtech/ls-qpack/blob/e5fd044d52c3a9c6b0891993e3f7ec9f3f7274cb/src/lsqpack.c#L3174 The increase in complexity -- saving state -- is offset handsomely by not having to buffer anything inside or outside the QPACK library. This makes the interface simple: have more encoder bytes? pass them to the decoder. - Dmitri. From nobody Mon Aug 6 17:21:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F27130E48 for ; Mon, 6 Aug 2018 17:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 n6pO9R5EAhZp for ; Mon, 6 Aug 2018 17:21:17 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 356E1130E3F for ; Mon, 6 Aug 2018 17:21:17 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id 126-v6so10288380qke.5 for ; Mon, 06 Aug 2018 17:21:17 -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=ZmUq+1J9yaoHJdJnnONDXDHtYqeF6n4+h5A8/CtdrBk=; b=RB+7uVDQa20JcPjdGHTrO1IgvZY9tlrHJ/dftFZ0P0O1FSRWC4OrWSLVqioFfA9XYc 5h6EMd+iT2enZGqz9BCVYZAbKimdixDmyNYzcikWAUk9TwFCN1Ai9GX/V0HhJvRunwqQ AnmDx0KPBh5hkTxvclBJVyXLGmpWGtpgF4mVrD+vsPV5ImMHGl+e+b221kbi7MkTuFbI 8mIsxwyEThgTjAjulHgHFCvCblIz4qbb3ENuOmAOmtKKz7HbLuYZYvbwQJZgmcP+OM94 TMgFptQ9Iipk5hBekEtLSkqtcu9FJ3/uZgf854Qayx4IsZJ8nuGstF2wysWkYHoRFz4j R1hA== 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=ZmUq+1J9yaoHJdJnnONDXDHtYqeF6n4+h5A8/CtdrBk=; b=sjDv7C+AMgRjme7a/8695umUmoQkgx9l2G5lxjYoy3XYnB5xxR86kpxcEZ/KsdXnlQ KDC2bjhojnk3JLkKqR8FXSV24MhbKHx4chxWUVAwF4SJZnnjlUCGxguZAgUzUOOAp8tB Y+McGdl7YLXNmxlUqeth3kDwv8fsBy2Av1iO1cbej3d2IDBsi05mFn+KTxDqBdtb+3BG 6IwLgm9n+98g8L+jNT9OxMa6hDrnSMOt1mt7utFVXRIjAvQt6nQnAvG8OR8BaEfA6/h3 M/lDVLfyw9gfACKI7xn/xvCZxbN73BUeinuPSnuqY9PfZBtlJg3og2dnTk031OCKopsv OnqA== X-Gm-Message-State: AOUpUlFe/UBNxhvDdOvy7OTu5hiBMrPbMkM8GU9jzuoE38EEwspqZ0dr MoBFHHkseKbLzxWs4ByJzCTcXA== X-Google-Smtp-Source: AAOMgpcphGlwebjH/eB1+AsPuwp63pAGFCnXm0V/yJLpIasgvzUEBQQ+wyo/S0yCCHsDg+GPx6JEPw== X-Received: by 2002:a37:c3cf:: with SMTP id r76-v6mr15659816qkl.150.1533601276347; Mon, 06 Aug 2018 17:21:16 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id n41-v6sm12906893qtn.73.2018.08.06.17.21.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 17:21:15 -0700 (PDT) Date: Mon, 6 Aug 2018 20:21:14 -0400 From: Dmitri Tikhonov To: Alan Frindell , Kazuho Oku , Martin Thomson , QUIC WG Subject: Re: Proposal: drop QPACK encoder stream framing Message-ID: <20180807002113.GB24583@ubuntu-dmitri> Mail-Followup-To: Alan Frindell , Kazuho Oku , Martin Thomson , QUIC WG References: <20180607151112.GA28823@ubuntu-dmitri> <20180609155530.GA6795@ubuntu-dmitri> <20180807002003.GA24583@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180807002003.GA24583@ubuntu-dmitri> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 00:21:18 -0000 On Mon, Aug 06, 2018 at 08:20:03PM -0400, Dmitri Tikhonov wrote: > On Sat, Jun 09, 2018 at 11:55:30AM -0400, Dmitri Tikhonov wrote: > > And I hope I have demonstrated that the complexity increase is > > minimal. Soon, I will demonstrate the same using C code. > > Here is working code. The function lsqpack_enc_dec_in() ingests ^^^^^^^^^^^^^^^^^^ This should read lsqpack_dec_enc_in(). - Dmitri. From nobody Mon Aug 6 17:36:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF98C130E53 for ; Mon, 6 Aug 2018 17:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnJNPXug8C0Q for ; Mon, 6 Aug 2018 17:36:35 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB08130E04 for ; Mon, 6 Aug 2018 17:36:35 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id s198-v6so25437152oih.11 for ; Mon, 06 Aug 2018 17:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oUMhbx6jpcMklORhOxaf3ase0K/8NbclEMb4g+0IOsU=; b=LVuGyGtNSEH1PiE7cUjto0WY5XY7amvIlew20JmhrYb1mgwwhWXUIfnTCPpafe26A3 GejthMEebq89T1sHWJVlsH6weCd98dr2Wd4Ek1THyfiralmdMO9iqA2OJublYpf5uJf3 QeO4GcYcMtZSB9PImHNTCF/PfL4LPc9Yi3iLSLhE4MQRumHk9mt5T5CmXOoQ5KLdHHJ4 IAR6puDWbak86BVIhbOkWFo6xevhb4Ov1nlsH+kzI+dMJrKONI/yOQy8AA+BprMXXW8j 52gPK+JUYLnH6p0wMTkk3ZaxW5nGnrIJ01LXInC8JIZBKEfbFDSU7i/t8RNOt7yWP9rX Ikrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oUMhbx6jpcMklORhOxaf3ase0K/8NbclEMb4g+0IOsU=; b=NLoFf2WS8W/r+BTRx3QXjCuAS0nOSHiOl084v8WbTOOJIbsir1ZXMUI4p5hcQ1rE8O DHMKxo4oQR8ZW1Czxz2Ryf4bZKMoOo0mwCu1JBPF4QMAvu9YA1nd0oJ72/QgbUHRsWVH tI1VL6vhWzXWnALVMrou3krHb3r0HbMqQEdrECRGIAFm8ytngA40b1i2Ws0Q8r4hsG9c BL353pZiznyE+ufIzCKoCE90g1+lR0uwHMfHES4bt8uiRNrEyo//JtctHBZUiPFXCdtN vuKoBMlLdjT74Pr7/KULKknmqMmVDdTMeB3qG6qcPM4EPHX9PuX8uXuZPdMr9fjadHKU P+Qw== X-Gm-Message-State: AOUpUlFVQi+Ax3s/u4gEOumtQF5MC0EtwpJIt7g914ugC97BrXgLp5QG BMRzTU0eQqQDIyUxYmqNS4r4JBhARbgewK2oASE= X-Google-Smtp-Source: AAOMgpfL/f6lqqJFBaFMqbNKAzbBMAT81nAStXkx521rtDqoiT9sVrAGB7pH2PidThPHJTSBVp+wBsEC8ljPoblKeWk= X-Received: by 2002:aca:5841:: with SMTP id m62-v6mr18108216oib.346.1533602194403; Mon, 06 Aug 2018 17:36:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Tue, 7 Aug 2018 10:36:23 +1000 Message-ID: Subject: Re: Key updates To: Ian Swett Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 00:36:37 -0000 On Mon, Aug 6, 2018 at 10:43 PM Ian Swett wrote: > I think we seriously considered the option of "Close the connection and 0RTT a new one". Yes, and the TLS working group did too. This is what we got. I implemented a limit to the number of records we send in TLS and haven't heard a complaint (even though we have non-trivial numbers of DES connections, where the limit is fairly low). Which suggests that this might be an OK strategy... for the web. However, I also know that people were using h2 for things like connections between gateways and origin servers and were very annoyed at the 2^31 cap on the number of streams, which caused them all sorts of performance problems during changeovers. 2^31 streams happens well after you need to rekey GCM. I don't think that we can reasonably punt on this. My writeup was long, but I think that the fix is simple. As much as Nick might like to destroy TLS state (the essential parts of which aren't a real burden, being comprised of two 32 octet secrets and an epoch counter), I don't believe that we can just kick this particular can down the road, tempting as it might seem. I do want to explore the notion of binding key changes to connection ID. It has some nice properties. I can't make it work without making things more complicated than what I proposed though. From nobody Mon Aug 6 17:39:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5287F130E53 for ; Mon, 6 Aug 2018 17:39:36 -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, FREEMAIL_FROM=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 oD3aKZIhDsRT for ; Mon, 6 Aug 2018 17:39:35 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2ED130E60 for ; Mon, 6 Aug 2018 17:39:34 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id v8-v6so25490840oie.5 for ; Mon, 06 Aug 2018 17:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wtlsPD0521nq8YQu1i1c3OYqB0n7m2k2oQUz92I4lfc=; b=ld7yG8evMNKWrK4Fhfj1wnFOgx7GbMJn7OWb9psVyLyb6qSPckA0Mh6NGoeBcJZjcI +Fjn7LMPP8z32WK4cBHwau4C82WdGeETsEE/NeJO4YyBza5aCs/GZGTr0HrwY6uTg2/+ DWlQDsj2qNhwCTe09cq18o4yv0qu+ph8S5YdHk36lPqFdBm96wqUnMcGfgV6hgPrfcFF ZqNnmp6va5LaOfRQ5ukBt0W++wK769oLFxtwuKLaPQa12mfPasm4hkoSpGJPd2DHEWgR Q8vBrQ3qEvtN/CgDkzs5SHwyENHrrHY35/82uTVj6BC2pw9SFSZh/rFT/+31wIGeNNdF l+8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wtlsPD0521nq8YQu1i1c3OYqB0n7m2k2oQUz92I4lfc=; b=RAagY+G5xcwx4VwDqI6lS4aExvwyXARMauBwmQSx5OwbhzrQYiGfPIywnVichK7b4v mAVe88tTji3RnieQUGYDzaDf8mlNA7DyJ6Z4LLmrwBKO8b45cPd0C751doUiX3bURxU/ c6iNLdY/y2LoNLqiZbN1jJzj38WYxTnY1KkhFKCfjA7RpEKCYflYKUujq0eOWmO3jwvt Bs8CGgpICw7l/BqPU8ULWYToJsSEmJNbg+USySVulJcsIWzzaAL3fscD/02OQC228EoX m9lPNfYI34q6z8hWoZemAUhSA/yNoz5CJ7e3SL179zkHFuKSRQkSyR2t4WwG0gRtOz7o svIA== X-Gm-Message-State: AOUpUlFuFpfbpuVEKYLIVNIM+I72kJwqP9nvZxlFmzXRfetvLnP0LeV8 HU6vs4lZLlGGqnLlUM3p9xCdcdKm9/kbD4re90I0VBi2 X-Google-Smtp-Source: AA+uWPzn+/Hx1ftCkNN5EqmvMPcwdT5g4DqxD9mORTkknaQjnSpgOkExK/7xdRHR2azbgycgBahxa4bfcUBcWGWJNLM= X-Received: by 2002:aca:a8c1:: with SMTP id r184-v6mr17817863oie.215.1533602374123; Mon, 06 Aug 2018 17:39:34 -0700 (PDT) MIME-Version: 1.0 References: <193166ED-C8C3-4A6B-9483-5546C34B5BDA@tik.ee.ethz.ch> In-Reply-To: <193166ED-C8C3-4A6B-9483-5546C34B5BDA@tik.ee.ethz.ch> From: Martin Thomson Date: Tue, 7 Aug 2018 10:39:23 +1000 Message-ID: Subject: Re: Key updates To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Ian Swett , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 00:39:36 -0000 On Mon, Aug 6, 2018 at 11:06 PM Mirja K=C3=BChlewind wrote: > However, this brings us back to Martin=E2=80=99s other question: does it = make sense to have a couple of reserved bits to make it easy to add a bit f= or the next version with minimal changes to the protocol machinery/wire ima= ge? I think that was Dirkjan who asked that question. The driving principle behind defining invariants was to avoid having to come back to this question repeatedly. We have a version negotiation mechanism that allows us to change an awful lot between different protocol version. We don't need to reserve a few bits because most of them are already reserved. From nobody Mon Aug 6 21:55:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37848130E6B for ; Mon, 6 Aug 2018 21:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWRpCRQXgTts for ; Mon, 6 Aug 2018 21:55:47 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985DB130E69 for ; Mon, 6 Aug 2018 21:55:46 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id v22-v6so10652873lfe.8 for ; Mon, 06 Aug 2018 21:55:46 -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=MV/lJRx/z/ALWE2gG/2gBDeflVaBLZeEB4VQn3VHDh4=; b=hUJa4P0jwU9t5kVB3RDCajmLhgpcWzfxDmdN0lnu17F+/KGQVjJM+b+NXeibck36ZI Ca6ae/Nc7X3+YvaKIlHqvwc/U98RdhLQzAgBwoLG7EwyDCPSPT4mW3XvLKi22EpQ/GJH nAxT5DmX5u4o1jRAT8HRCwcYm4B7wqsdlincu78+OSwxuRBiFp6g7+fYVsZVvNZ4kTEv bZElzcqFL13wqN0zkyKp7nsgDUBaH8k0Y2s/gBq/+iB6dTxAHwoHB70Dp6DfsSOdGSZH L0dhXUCfi7M48W6yWs3ZQIspk3+1URjzCj1sL9ziTuSYyTCRvg76lTP7p5vpeuU4Fr7e joTw== 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=MV/lJRx/z/ALWE2gG/2gBDeflVaBLZeEB4VQn3VHDh4=; b=toPDCwE8lUsWt+Yn8UBzh+0W/MMrHU6SWlAPel73mcHHpV5TYGlYPtoxzv7dSfLtPw RJGMyEG3VfxAUH9GLqlw/sNu1EPwKUBgt8XvHiSutfEdjrQIwjVrr+OJX7CW+AS0Umln VGJ0rWPRe/SOQPjzFN6GyPPCZs3LZ62GNuilD3OYWH1RyVyGpd2zPF4ttNHQ+HSYxcmP BKTJbFPk3CFeiYKOzMPtxoiu0fP8JibDsYKMSjcgdpYCIzTLKe/464FcM3rol3yYH1P4 mcUMLXici/OK2r0adH5DP2oLMnAx0UWdoG2Z9iZxUCMsMUrT6kU9OyqlLJnv0L0EPLp8 kiuQ== X-Gm-Message-State: AOUpUlEELkvG5xjks8CH0Sw9SaN/dv23p3J6023lgzKzMiFXTiupDD7L NckwYhOKQNVuu3edudNWOr7io5k06HxxO3L2bXs= X-Google-Smtp-Source: AAOMgpfilKeJxeXtVMedUjS/lqqyy9kkdcFP7iwkObxZiWAK7IsizGDdqpDDHQ5yDX+reZLc+OE0pfSCuktHse2n/O8= X-Received: by 2002:a19:6b03:: with SMTP id d3-v6mr12364723lfa.81.1533617744831; Mon, 06 Aug 2018 21:55:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 21:55:44 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Tue, 7 Aug 2018 13:55:44 +0900 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 04:55:49 -0000 2018-08-06 14:55 GMT+09:00 Martin Thomson : > One of the open items out of the design team work was the interaction > between TLS and key updates. As you might know, TLS key updates are > synchronous, which works well in TCP, but less well in QUIC, where you > need at least two active keys for reception around a key change. > > As it is, I think that there are two serious options: > > 1. Use KEY_PHASE to signal a change. This requires that both > endpoints are loosely synchronized, which disadvantages asymmetric > data exchanges. > > 2. Use a prepare-commit style. DTLS does this by having each peer > send a KeyUpdate message, then requiring that to be acknowledged > before they can switch to the new epoch. QUIC could do the same. The > change is still signaled in the key phase bit, but only after this > signaling exchange. > > The weakness of the first option is that packets marked with a change > of key phase trigger trial decryption. I think that I might prefer option 1. I do not think that the current mechanism requires trial decryption. IIUC, the endpoints are not allowed to start sending packets at epoch N+1 until they see peers acknowledging packets that were sent in epoch N. That means that an endpoint only needs to have at most 2 keys (for epoch N+1 and N). The epoch (either N or N+1) can be recovered from the KEY_PHASE bit and there is no need for trial decryption. Am I missing something? The issue that might exist with option 2 is that it does not work well with our model of using QUIC to transport TLS handshake messages. In the model, the TLS stack never waits for ACK. Handling of retransmits in the responsibility of QUIC. This is fine for "handshake", because the moment when a new encryption key becomes usable is indicated by a TLS message. However, for key update, the TLS stack needs to wait for the peer to acknowledge the receipt of the KeyUpdate message before it can start using it. At least that is what is defined in the DTLS draft. Section 8 of the draft states, quote: "In order to facilitate epoch reconstruction Section 4.2.2 implementations MUST NOT send with the new keys or send a new KeyUpdate until the previous KeyUpdate has been acknowledged (this avoids having too many epochs in active use)." I am not sure if adding a way to signal the receipt of ACK for a particular TLS message from QUIC to TLS stack is worth the cost. We do not have that kind of mechanism. I am scared that such mechanism could become very complex, considering the fact that the QUIC stack can split TLS handshake in any way that it would like. Or are you suggesting a mechanism other than what is defined in DTLS? > And it requires synchronized > changes, where if one endpoint moves to epoch N (epoch == encryption > level with fewer characters to type), then the other has to follow > before either can move to epoch N+1. The second has more moving > parts, but avoids both of these problems. > > I tend to think that the second is a better design on balance, if only > to dispense with the trial decryption, which we've managed to avoid in > every other case thus far. The complication might also present some > opportunities, which I will explain below, but that's a secondary > concern. > > If we want to use this signaling method, we need to decide who drives > key updating, TLS or QUIC: > > TLS: The DTLS design might work in QUIC, but with the KeyUpdate > message hidden in an opaque CRYPTO frame, it could be a little tricky > to manage properly. If we let TLS drive the key update, then it will > send a KeyUpdate message in a CRYPTO frame and inform QUIC of the > change in sending keys. From here, QUIC can keep using old keys until > all CRYPTO frames from that epoch are acknowledged. The receiver will > inform QUIC of new receive keys when it receives KeyUpdate, which can > be installed. > > QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC > sends when it wants to update keys. When this is acknowledged, new > keys can be installed and used for sending. A new API is needed to > TLS to support cranking the key schedule forward. Invoking that API > would lead to TLS signaling the availability of new keys. The receive > side isn't any different from the TLS option. If this was to have > parity with TLS, this would probably need to be two frame types so > that a unilateral update could be distinguished from an update that > includes a request for a mutual update. > > In both cases, QUIC will install new receive keys, but retain old > receive keys so that it can deal with reordering. A few round trips, > an RTO, 2MSL, or whatever we decide for the handshake is probably > fine. Sending keys can be discarded immediately. > > The advantage of having TLS drive is that it uses the same machinery > we have for the handshake. And there is no disparity between what TLS > and QUIC understand to be current: when TLS wants to send something (a > NewSessionTicket message for example), then it asks for an epoch that > matches what QUIC is using. > > The disadvantage of using TLS is that there are more moving parts > involved. It fits the rules we have for the handshake neatly: for > instance, the CRYPTO frame would be retransmitted using the strict > encryption-level rules, reusing that code from the handshake. But > those rules aren't really necessary given that the rules for a > KEY_UPDATE easily have the same effect. > > My inclination here is to have TLS drive this. The additional > complexity seems to be manageable in the sense that it uses mechanisms > that should already exist for the handshake. I also don't think that > a new API for this feature is a good way to ensure that it is used. > > Those who are implementing, I know that key updates are often a long > way down the list of priorities, but has anyone spent time considering > the options here? (I personally implemented key updates for TLS, but > I still haven't managed to find time to do it for DTLS, which might > say something...) > > -- > Addendum: Optional Key Phase ? > > One of the nice things about either prepare-commit design is that it > opens a new option for how we use bits in headers. If there is a > concern about spending a bit on every packet for the key phase (a > whole bit!), we could design an encoding that only included the key > phase if a longer packet number encoding was in use. > > The idea would be that you could use the longer packet number encoding > while you have a key update outstanding, so that the key phase was > available for the entirety of the changeover. Once packets with the > new epoch were acknowledged, you could switch back to a shorter > encoding that didn't include a key phase. The receiver would switch > to expecting the new epoch after receiving the first packet in the new > epoch. > > That's a saving that might allow endpoints to use the shortest packet > number encoding in more cases. Of course, the header design is > already complex enough, so maybe we don't actually *want* more options > to consider there :) > -- Kazuho Oku From nobody Mon Aug 6 21:58:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F58F130E5D for ; Mon, 6 Aug 2018 21:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3jODOm7GZVK for ; Mon, 6 Aug 2018 21:58:56 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 67BB8130E2C for ; Mon, 6 Aug 2018 21:58:55 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id w16-v6so12336712ljh.12 for ; Mon, 06 Aug 2018 21:58:55 -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=73h9z9/nxtf+Qie1S4Ziqhua60NBTAM+AFMYBIz/8G4=; b=d83EBtEB+RgXy9dqVnlHK+DS5ZzoRCYT0Tpt5zO7u2ywioAvkj8nscXLlKrEcVNzyM 9kAX10uCrRPabchJeZPWlSu6/JJlwNZZD5rqyi2laFiQ2iVl3Z2pOlcvlLhkTRLZR9FD tMh7Ui2PNyRbpOyDh/MqscAbYzmLYgNmLADChGdEkNZ8I+d0jtnNWPT16BVWL1iT8qIF p7CGxQbIgNxNc7pUeKSORIdgl0vf42vAbpE0TNI80rQC+7hNRdkcdCwN5BeajESgsuJM 4xSn3uo+t2WoOxrcKF3l3UiQ289qksxhxhvbOWM+6qL4bkjX1jSM5nzROx08128e+j48 tvfg== 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=73h9z9/nxtf+Qie1S4Ziqhua60NBTAM+AFMYBIz/8G4=; b=jW/FdYT1/9+w9RUt8vRT7tI8YvGV7XoIFrPIuTRV8xED/mM0fgrvKzXX2/siZW+naP dog5mhTGKWoIWFDwQnONal13LbalBWrW5brI0LW6ieSdKryAwxoy5fz+X0hkoi98yWU/ HDd22lVdCdAPGYTXRs0JlSGw5r7ZzG2ekmzsSk7ECy9LuY4/S8Ed9v4FR5vO+cNR7gOK eG3CB5l9nNX8SZAzdS9R/F8v/qsBJE0ledut9uceoPPGcRmWZi2SAmzcPQYpgw8c/+Co UwT+lzMw0hLXSLgKJ4XofTEJKC9bXb5VlnFaUwQzR6eY79gnpQA9h6AmepqJezaJUooE 526Q== X-Gm-Message-State: AOUpUlEgwwEJTw5m2LNddhOdQIjduYoMvqoHxNuMMajT86I46iH2varn eEze5HsWTJ0nl1yvSl2rq+GmgjSJkrnCAGlz448= X-Google-Smtp-Source: AAOMgpdjHIxObLmzi1sdRGCJ/03lBmgqCDjyjWP9tUHIe0MmC3Xg+av2+54eh5S5EqUqS3Z9Uf4FFV2E4BmmAvD5Zrc= X-Received: by 2002:a2e:2e02:: with SMTP id u2-v6mr15094538lju.77.1533617933615; Mon, 06 Aug 2018 21:58:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 21:58:52 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Tue, 7 Aug 2018 13:58:52 +0900 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 04:58:58 -0000 2018-08-06 18:31 GMT+09:00 Martin Thomson : > > > On Mon, 6 Aug. 2018, 19:22 Mikkel Fahn=C3=B8e J=C3=B8rgensen, > wrote: >> >> On the last part: using a longer packet number - that would create an >> observable signal similar to an unencrypted key-phase bit because many >> packets would tend to have similar sizes, then suddenly spike a few byte= s in >> length. > > > The size of a packet number is hidden. Given that most packets are full > sized, the only effect on those would be less available space for payload= . > ACK packets would increase in size by a couple of octets, which could be > masked easily and cheaply if necessary. > >> Key phase could also be tied to connection id, and perhaps some >> consideration should be given to a possible multi-path design before opt= ing >> for the more complex solution. > > > This is definitely an option I have considered. If you have a workable > design, I would be interested. I couldn't reconcile the desired rates of > updates. Connection IDs are needed in spikes, where the rate for key upda= tes > is more measured. The other issue with tying key phase to connection ID is that such design would not allow key update to happen when a zero-length connection ID is used. We allow the use of zero-length connection IDs, and I'd assume that it would be fairly popular for the client-side. I think that we would prefer such endpoints to have the ability to update the keys as well. > >> As I understand it, the commit option still requires synchronised key >> updates in both directions. How about one-sided key updates? > > > The option I describe doesn't require that both sides update at the same > time, not do endpoints need to update in lock-step (they can require > reciprocal updates, but that is discretionary). > >> >> On 6 August 2018 at 07.56.18, Martin Thomson (martin.thomson@gmail.com) >> wrote: >> >> One of the open items out of the design team work was the interaction >> between TLS and key updates. As you might know, TLS key updates are >> synchronous, which works well in TCP, but less well in QUIC, where you >> need at least two active keys for reception around a key change. >> >> As it is, I think that there are two serious options: >> >> 1. Use KEY_PHASE to signal a change. This requires that both >> endpoints are loosely synchronized, which disadvantages asymmetric >> data exchanges. >> >> 2. Use a prepare-commit style. DTLS does this by having each peer >> send a KeyUpdate message, then requiring that to be acknowledged >> before they can switch to the new epoch. QUIC could do the same. The >> change is still signaled in the key phase bit, but only after this >> signaling exchange. >> >> The weakness of the first option is that packets marked with a change >> of key phase trigger trial decryption. And it requires synchronized >> changes, where if one endpoint moves to epoch N (epoch =3D=3D encryption >> level with fewer characters to type), then the other has to follow >> before either can move to epoch N+1. The second has more moving >> parts, but avoids both of these problems. >> >> I tend to think that the second is a better design on balance, if only >> to dispense with the trial decryption, which we've managed to avoid in >> every other case thus far. The complication might also present some >> opportunities, which I will explain below, but that's a secondary >> concern. >> >> If we want to use this signaling method, we need to decide who drives >> key updating, TLS or QUIC: >> >> TLS: The DTLS design might work in QUIC, but with the KeyUpdate >> message hidden in an opaque CRYPTO frame, it could be a little tricky >> to manage properly. If we let TLS drive the key update, then it will >> send a KeyUpdate message in a CRYPTO frame and inform QUIC of the >> change in sending keys. From here, QUIC can keep using old keys until >> all CRYPTO frames from that epoch are acknowledged. The receiver will >> inform QUIC of new receive keys when it receives KeyUpdate, which can >> be installed. >> >> QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC >> sends when it wants to update keys. When this is acknowledged, new >> keys can be installed and used for sending. A new API is needed to >> TLS to support cranking the key schedule forward. Invoking that API >> would lead to TLS signaling the availability of new keys. The receive >> side isn't any different from the TLS option. If this was to have >> parity with TLS, this would probably need to be two frame types so >> that a unilateral update could be distinguished from an update that >> includes a request for a mutual update. >> >> In both cases, QUIC will install new receive keys, but retain old >> receive keys so that it can deal with reordering. A few round trips, >> an RTO, 2MSL, or whatever we decide for the handshake is probably >> fine. Sending keys can be discarded immediately. >> >> The advantage of having TLS drive is that it uses the same machinery >> we have for the handshake. And there is no disparity between what TLS >> and QUIC understand to be current: when TLS wants to send something (a >> NewSessionTicket message for example), then it asks for an epoch that >> matches what QUIC is using. >> >> The disadvantage of using TLS is that there are more moving parts >> involved. It fits the rules we have for the handshake neatly: for >> instance, the CRYPTO frame would be retransmitted using the strict >> encryption-level rules, reusing that code from the handshake. But >> those rules aren't really necessary given that the rules for a >> KEY_UPDATE easily have the same effect. >> >> My inclination here is to have TLS drive this. The additional >> complexity seems to be manageable in the sense that it uses mechanisms >> that should already exist for the handshake. I also don't think that >> a new API for this feature is a good way to ensure that it is used. >> >> Those who are implementing, I know that key updates are often a long >> way down the list of priorities, but has anyone spent time considering >> the options here? (I personally implemented key updates for TLS, but >> I still haven't managed to find time to do it for DTLS, which might >> say something...) >> >> -- >> Addendum: Optional Key Phase ? >> >> One of the nice things about either prepare-commit design is that it >> opens a new option for how we use bits in headers. If there is a >> concern about spending a bit on every packet for the key phase (a >> whole bit!), we could design an encoding that only included the key >> phase if a longer packet number encoding was in use. >> >> The idea would be that you could use the longer packet number encoding >> while you have a key update outstanding, so that the key phase was >> available for the entirety of the changeover. Once packets with the >> new epoch were acknowledged, you could switch back to a shorter >> encoding that didn't include a key phase. The receiver would switch >> to expecting the new epoch after receiving the first packet in the new >> epoch. >> >> That's a saving that might allow endpoints to use the shortest packet >> number encoding in more cases. Of course, the header design is >> already complex enough, so maybe we don't actually *want* more options >> to consider there :) >> > --=20 Kazuho Oku From nobody Mon Aug 6 22:15:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93C130E6F for ; Mon, 6 Aug 2018 22:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvbZSLh5xyAY for ; Mon, 6 Aug 2018 22:15:35 -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 C344E130DF2 for ; Mon, 6 Aug 2018 22:15:35 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id b16-v6so12924540oic.9 for ; Mon, 06 Aug 2018 22:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y5WgzPvQxrE3t3YO7XnFvCiN9E7obc43RaeAbu5l9cE=; b=M2ecf78QKEJj0Hsk2+BDbfWPPRZtpNJS7O4oV4H5rxX/tr0hJyBfO/2xnD/rAwuwIc Wr889stbtRAL3PTy07az9J9lyj9dst3/uzlh3xFgKqe80HUuLiR/Ovf954dR3DqtsxCj 8RBpFKB0pClYT0b3pwi8yUEGFca6oSxPbOAs/IOV9L6OluYj7vjBpLKrR6DkYLbFAO/q rTDyffSIQDQyz2oZEx085d+8ejNs+3Xnhkji01nTJ7WLFX5sNBsJG+I+++3acMMAVMKa M7/VjG0dgrJ/BP4Vmdg5/4eP/y17yeZQT0CFRCb0LGtBNy9/wr1ZSCmr5wPr1Lev8PgY nmrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y5WgzPvQxrE3t3YO7XnFvCiN9E7obc43RaeAbu5l9cE=; b=RVJvDpAJb5QqMIqchRmqZFcrLbZcvuE27/4SmnVudq4rbir4XFh2rzVQMm7j3/oB3X 3ok/2TsZv2/dRKyIUJMIgbRi4lvtGAzqC2SZsyofRteOfs2ip7Mj5t2WlIPNdC/YeAEL ICX7KYgqaBbnqgIOBDNw2OYJMSiciQqTb0Gq/wl2tY/K5DvBIow3h6DtYfr0YaNXRfsw D5ot2bhSj4ozbepYMJ+LVBYp+KKjEKt4FFvM65z0PpKOV8tSgMwuuE4ROIgmz4OpDlB8 s6t+VT4Ck1lU9JeSgdUBuu0p0pG5m+Oy5B9fF6vOc/DT7dypTziINasmIRGHJQI2T+zc mXdw== X-Gm-Message-State: AOUpUlGTLUPCKiSJMbHyxlKafXpUyWgDNTRhToqWGVZ2zHwNVIB4cGuN l7qx2/p5A73KKhroRC0k6LjMFLMvQBOYdz/5unbFOw== X-Google-Smtp-Source: AAOMgpdrTRnXaBFAt1fDNrfeVVr+jMZutWE5sdn0NvxvuPJaia0r8JMv6PPfXM67zOjvvuAsR5+jubGrWPvSKUJvfs8= X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr18537579oiq.110.1533618934921; Mon, 06 Aug 2018 22:15:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Tue, 7 Aug 2018 15:15:24 +1000 Message-ID: Subject: Re: Key updates To: Kazuho Oku Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 05:15:37 -0000 On Tue, Aug 7, 2018 at 2:55 PM Kazuho Oku wrote: > I do not think that the current mechanism requires trial decryption. > IIUC, the endpoints are not allowed to start sending packets at epoch > N+1 until they see peers acknowledging packets that were sent in epoch > N. That means that an endpoint only needs to have at most 2 keys (for > epoch N+1 and N). The epoch (either N or N+1) can be recovered from > the KEY_PHASE bit and there is no need for trial decryption. > > Am I missing something? There is a problem right now with concurrent updates. If both peers bump at the same time, then N-1 packets could still be in flight. A little reordering will cause them to be interpreted as N+1 instead (because they arrive after packets at N and we only have one bit of signal). So if you want to avoid loss spikes around rekeying, you have to do a little trial decryption at that point. Also, the way you ratchet forward is to observe a bit flip, at which point you decrypt with N+1. If that works, then you do something. It's not quite trial decryption in the sense that you only try one key, but - having implemented it - it's a little annoying to get right. > I am not sure if adding a way to signal the receipt of ACK for a > particular TLS message from QUIC to TLS stack is worth the cost. We do > not have that kind of mechanism. I am scared that such mechanism could > become very complex, considering the fact that the QUIC stack can > split TLS handshake in any way that it would like. > > Or are you suggesting a mechanism other than what is defined in DTLS? It's pretty close that in DTLS. Here's what I imagined would work: You let TLS send its KeyUpdate, which gets bundled into a CRYPTO frame. TLS moves to the new epoch, and advertises the availability of new keys. However, you continue to send in the old epoch until you have flushed all pending CRYPTO data from the old epoch (i.e., the CRYPTO frame has all been acknowledged). All other processing stays the same: CRYPTO frames are always sent using the same keys, even on retransmission, new TLS messages would be sent in the new epoch, and ACK frames would need to send using the epoch of the packets they acknowledge. The reason we don't have problems with the handshake is that we *know* that the peer has keys for the new epoch. Otherwise we would have to do the same thing. There, following these rules would mean sending in the clear, which isn't smart. Here, it's just a key update. From nobody Mon Aug 6 22:40:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1146130F6D for ; Mon, 6 Aug 2018 22:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVZ9SRH0Ni1P for ; Mon, 6 Aug 2018 22:40:01 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 3B1DF130EAF for ; Mon, 6 Aug 2018 22:39:51 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id s12-v6so12434656ljj.0 for ; Mon, 06 Aug 2018 22:39:51 -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=gHfQ9Cljg6p6zHI3tl9V4s6am19mabnr2X0dS+SgkQQ=; b=eSAgak1guma/5tFZAWgFJZPyDIF0J3yUTXWSo8DhJ+i2tXzCqFM8D0NK6nOeu8KHpq EHwFlv5IM+Mitd8tAMYp/hW4FNw3eonixeOFbm3a/ifHht+68JTtV3lnt767o1o7KKiw m68sV+Y43VyGruXtmNI743WXsyO+Z1TJgyZmk69bw4YYxJzwfpMijKPF1e0JQByOQXJ3 /cImaWH4rhfG0S5jKxpbzIQYezHKJ5QYoBj0+sWWw9Z1kk0sCQ3JxcW+THRAnCnD0Hxq FxX+ilfJDN9XtdUxfu/eCcn+4LE/8dVTn8gLm4aJmkSQIhXB2gcHKV4pzOUZFZBq2rzE g5/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gHfQ9Cljg6p6zHI3tl9V4s6am19mabnr2X0dS+SgkQQ=; b=WIwaUokARiwKbAzxyYjLAI1lly+CZZnzYrM+2yo9VtlU+zM/9hwTc3mNAGCgpfLv79 GfN0LUFghIvzuwDYD5nkfVi+JCYibup3N4TGv5L+HzsA5M/Yls+A9rETaOnaPJe4mUyD sS8Myc6VmQd4ccEOmXLlbOSexvMpuIPSBKhR74lgS+b/veiCc70EC7pepbLmx22wN4Ub U8dYT1OcfglF0le2Ho6NDwOKb2MdQbz4Aqb0ifutb2dhWB4WlYfwqi/m6ue6tU5V9oqE gXrhSOGmpFshqUWufwqQjZgO3zaasR5PLPivB7f3KqaUqzaXoBkdkVUelNxnwEmIp+Hi yQPg== X-Gm-Message-State: AOUpUlGfr8WZtjo/w3nJyPQWX1U88tSjWmdiiPXp9nw3tmGB8VBULcwe EvkscvaEG9Ae8/INPO4YnSHeVSgLtTjqofIcfaE= X-Google-Smtp-Source: AAOMgpfkd4KeRlL2bZAk1Cw9FTfsb5rADcTicQfS82cBP8e5AS4+aH80RU4cXJbmTpi4mYhwXmMAAfDIdrZYiw+VUhw= X-Received: by 2002:a2e:9e55:: with SMTP id g21-v6mr15337165ljk.116.1533620389432; Mon, 06 Aug 2018 22:39:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 22:39:48 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Tue, 7 Aug 2018 14:39:48 +0900 Message-ID: Subject: Re: The first octet To: Martin Thomson Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 05:40:06 -0000 2018-08-06 14:55 GMT+09:00 Martin Thomson : > It appears as though we're about to get some information about how > deployable the QUIC invariants are. Ian tells me that Google are most > of the way to deploying a protocol that uses QUIC invariants and > should be able to confirm that this works by the interim. Well, > either that or to be able to tell us what doesn't work, which I'm > hoping isn't a problem we have to deal with. > > I'd like to spend some time at the interim on what we do with the type > bits in the protocol. This email is an attempt to thoroughly cover > the constraints that we have here and attempt to describe a process > that I hope should get us to a conclusion shortly after Bangkok. > > Looking at open design issues, this cluster is the one that is the > biggest threat to our schedule. > > Design Status and Constraints > > Long Header > > The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we > have are currently allocated to the 4 types of long header packet, > using only 252-255. All other values are currently unused. > > With respect to design constraints, there is only one that I'm aware > of and that is a potential collision with RTP (and RTCP) on this octet > (see RFC 7983), which use 0x10xxxxxx (128-191). > > The open question here is what we do with unused types. We might > debate creating a registry for unused values. We might want to grease > values. We could even decide to encrypt these values (though the > design of Retry makes that more difficult, because the contents of > that packet aren't encrypted at all). > > I'm not aware of any plans to use these bits, except perhaps what > might be done to be consistent with the short header changes, so we > might have some latitude here. > > Short Header > > The short header uses the 0b0xxxxxxx pattern (0-127). This is far > more complex and we have a bunch of open questions that will make this > difficult. > > Right now, we use the 0b0K110RRR as the pattern, with K being the key > phase, and RRR being reserved for the spin bit experiment. > > Those fixed bits are (largely) temporary, and might be reclaimed once > existing deployments of Google QUIC (pre-44) are phased out, so I > think that we might want to reclaim some or all of them. > > There is a chance that the reserved bits will also become available > (if not all, then maybe 2 of them). That will be decided in Bangkok, > but we might want to have a plan for those bits. > > The constraints that I am then aware of are these: > > 1. RFC 7983 has the lower half of the first octet fairly densely > populated for demux. Of the protocols there, my understanding of > their relative importance puts STUN (0-4) as fairly critical, if not > mandatory, then TLS (20-63) as optional. ZRTP (16-19) and TURN > channels (64-79) are both apparently unimportant, though each might be > opportunistically accommodated. > > 2. Passive RTT measurement (spin bit) will take 0, 1, or 3 bits. I > suggest that we allow for this, not counting on having any more bits > than N-3, or assuming that only that many bits will be available. > > 3. Kazuho points out that the key phase is a linkability vector. We > might want to consider encrypting that. We could do that by fixing > the packet number key and not updating it after key updates and using > more output from that process to mask the bit (and maybe other bits in > this field). > > 4. I realize that we don't have to put a key phase in every packet if > we are less concerned about being able to update immediately. If we > adopt a scheme to what was proposed in DTLS, then a longer encoding > can be used during the preparation and signaling phase. I'll follow > up with another email on this subject. > > One thing that we could use extra bits for is to move the packet > number size back into this octet. We could even move packet number > bits back, depending on available space. That might make some > difference to the number of bytes we allocate for packet numbers. > > Process > > Given that we don't have answers to some questions we might conclude > several ways. I proposed that we agree on principles, starting with: > > 0. (This should already be agreed, but I'm repeating it because it's > important.) The low 7 bits of the first octet are version-specific > and can change in the next version of the protocol. > > A. What do we want to do with unused bits? Do we want to ensure that > they are always used? Or can they be reserved? If so, how would they > be reserved (fixed values, random values, greasing, etc...)? As Jana has suggested, I think that the bits must look like random to observers, based on our agreement that the bits are version-dependent. Unless we make them look like random, there is fair chance that they will be ossified. > > B. Should things in the first octet be encrypted where possible (for > example, using an extension of packet number encoding). I would rather rephrase the question to "do we need to encrypt foo?" I think that we should decide what will go into the first octet based on the agreement of what needs to be encrypted. Having that said, I think that we need to encrypt packet number, packet number length, and the key-phase bit. The packet type bits and the spin bit(s) need to be in cleartext. Unused bits can be seemingly-randomized as an output of encryption, or could be a random value. My preference regarding the design will be to have the packet number length bits and the key-phase bit in the first-octet next to each other, encrypting the two using the PNE key. Having packet number length at a different location than the packet number itself will simplify the implementation, gives us more chance to use shorter encodings for packet numbers. For example, the long and short packet header will look like below (e - encrypted values of PN length and key-phase, t - long header type bits, s - spin bit, R - reserved bit). long: 1 e e e R R t t short: 0 e e e R s s s I do not have a preferred way of randomizing the R bits. They could be randomized by PNE along with the e bits, or we could require them to be randomized separately. > > C. Should packet number encodings should be consistent between long > and short header forms? Yes. I do not think that we need to be clever in saving one bit or two. We already waste certain number of bits. The fact that we are using varint encoding that changes the length at octet-level (i.e., 8 bits, 16 bits, 32 bits, ...) means that we are wasting something like 4 bits by average per varint. We are also wasting 2 bits per frame, considering the fact that the upper 2 bits of a frame is not used. > D. What should we do with key phase? This was an open issue from the > stream 0 design team, which might alter the outcome here. I have > another email that covers this in more detail. I think we should the bit in every packet as an encrypted value. The reason why having I consider that the bit in every packet is stated above. > E. How should we accommodate multiplexing? For me, the big questions > here are whether we allow for RTP to collide with the long header and > which of the protocols we privilege by avoiding with the short header. I would prefer not caring about multiplexing. We do not guarantee multiplexing between QUICvX and other protocols. Considering that, I am inclined to not discussing about multiplexability of QUICv2 (formerly v1), because that would raise the chance of QUIC becoming ossified. > My hope is that reaching conclusion on those principles should allow > us to to agree on designs that allow for 0, 1, or 3 bits of spin bit. > That way we know what to do with the outcome of the discussions we > plan to have in Bangkok and can implement the changes relatively > quickly. > > For those who read this far, if you have opinions on what principles > should drive this design, please respond here. If you have a proposed > design (or designs) and can explain the principles that are expressed, > that's OK too. If this gets enough feedback, I might arrange a call > for interested parties. > > I don't expect that we'll reach a conclusion before the interim, but I > don't think that we can let this go unresolved much beyond that point. > -- Kazuho Oku From nobody Mon Aug 6 23:10:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A537E130E72 for ; Mon, 6 Aug 2018 23:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttQEvKsah-Sd for ; Mon, 6 Aug 2018 23:10:44 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 8A78F130E5C for ; Mon, 6 Aug 2018 23:10:44 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id f8-v6so12475146ljk.1 for ; Mon, 06 Aug 2018 23:10:44 -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=XjfKyhrujdi4Z0sRYorImjL3v29d5x2jDwjrKu0KcNU=; b=YC5aKfrG1cQHI+DE0p+3WK34eVv/EFveCpVh5yHutB1bbUgVKrKYgviu+vAmjiFuNI FmtJtz07vJC7BMmV40cRTYIRepnjnMjzPBge+vg8cVwmt1n1dCmm8ydRZ5/UirxIXGBd 6JPuE+dqSj6W7WVM5G2GWVViUl0A9edVCSMNAIN++EqhBPnGx1r2KVEdixD/CcM8unVW idU0pqmT7hZ+VFute+JzR081NM0qNAyXe4szcqNdIawFhgvFjwfxIfFXCxzpE0Xwvgyq CR8WCTbFfLkBC3qgfCMPt0KMUUvEbORFP4FD3tEf7XhPYiAj2hxJOOMdaTDexRpkuPwO lgmg== 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=XjfKyhrujdi4Z0sRYorImjL3v29d5x2jDwjrKu0KcNU=; b=aDw5ZlnfLsIRDRRk7YD7z5w9wd4g4p+TOpRVHUkLbcFVGzbQibcpIwr4LG0Eso7/Ae 5VCPwkLfaSSDWU3VAyilDW4edPsKCnL14yKoqQsSfNUrbt4FcUArrf8Wi/CCBsn7Kpbo o4vQJdahneuZHOigYubGf1ffo9tphnkEpbUJRQMeJhA2dnu/0xiparCe0oz55ymyTCxK szLmEs9dRPkre7cZuDHu/Hij9aqDS8VgekvZaVMsLpB7EQzSWwJhW5FKZwSu7PExMK7j 9mK0pzy6vFMioPvAktTu3cDwrlPkKLxq0zTfTbNIe1kLz6ChuJd6pVQmnLOnbYqCTbFn jlaQ== X-Gm-Message-State: AOUpUlF76RiI+n40olHh1lEIjFKiGV0eRgZDKP1zhJwUdhyEHfzuibwo 0FnDoHEVh66F6be1z7hgD1HukPkAaqVYbc04sVU= X-Google-Smtp-Source: AAOMgpcoU837dTfOat9DCdzYs8Kf0to6uaIFFVuPQ6hf8Wf3s9Bek7+GjMqWmsxMZLqJOFXraDqz4iqZ57g/AAqt57U= X-Received: by 2002:a2e:9e55:: with SMTP id g21-v6mr15423503ljk.116.1533622242843; Mon, 06 Aug 2018 23:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 23:10:42 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Tue, 7 Aug 2018 15:10:42 +0900 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 06:10:47 -0000 2018-08-07 14:15 GMT+09:00 Martin Thomson : > On Tue, Aug 7, 2018 at 2:55 PM Kazuho Oku wrote: >> I do not think that the current mechanism requires trial decryption. >> IIUC, the endpoints are not allowed to start sending packets at epoch >> N+1 until they see peers acknowledging packets that were sent in epoch >> N. That means that an endpoint only needs to have at most 2 keys (for >> epoch N+1 and N). The epoch (either N or N+1) can be recovered from >> the KEY_PHASE bit and there is no need for trial decryption. >> >> Am I missing something? > > There is a problem right now with concurrent updates. If both peers > bump at the same time, then N-1 packets could still be in flight. I think that we might be having different models in our minds. My view is that, in principle, an endpoint unilaterally updates its epoch that it uses for "sending" packets. An endpoint MUST NOT update the send epoch before it sees an acknowledgement for a packet that was sent encrypting using the current epoch. To implement reciprocal key update, we will also state that, if the send epoch used by the peer becomes greater than the value used by an endpoint, then the endpoint SHOULD increment it's send epoch as well. If we define the rules this way, I would assume that there is not chance of key getting updated twice even in case both the peers decide to update at the same moment. To put it another way, the issue with the reciprocal (D)TLS-style key update is that it is defined as a "request" rather than a state change with idempotency. The rules above is designed as an idempotent state change from N to N+1 that can be implemented by either peer without the fear of double update that will lead to potential loss (unless the endpoints retains more than two keys). > A > little reordering will cause them to be interpreted as N+1 instead > (because they arrive after packets at N and we only have one bit of > signal). > > So if you want to avoid loss spikes around rekeying, you have to do a > little trial decryption at that point. > > Also, the way you ratchet forward is to observe a bit flip, at which > point you decrypt with N+1. If that works, then you do something. > It's not quite trial decryption in the sense that you only try one > key, but - having implemented it - it's a little annoying to get > right. > > >> I am not sure if adding a way to signal the receipt of ACK for a >> particular TLS message from QUIC to TLS stack is worth the cost. We do >> not have that kind of mechanism. I am scared that such mechanism could >> become very complex, considering the fact that the QUIC stack can >> split TLS handshake in any way that it would like. >> >> Or are you suggesting a mechanism other than what is defined in DTLS? > > It's pretty close that in DTLS. Here's what I imagined would work: > > You let TLS send its KeyUpdate, which gets bundled into a CRYPTO > frame. TLS moves to the new epoch, and advertises the availability of > new keys. However, you continue to send in the old epoch until you > have flushed all pending CRYPTO data from the old epoch (i.e., the > CRYPTO frame has all been acknowledged). Thank you for the explanation. I think that the described algorithm will work fine, but I am not sure if I like the fact that it requires the QUIC stack to remember the new encryption key and the fact that a KeyUpdate message has been sent in a CRYPTO frame at certain offset, and switch to the new key when all the data up to that offset is acknowledged. In my view, the design is breaking the layer between the contents CRYPTO and the QUIC stack (QUIC stack needs to know what is carried in CRYPTO), and is also requiring the QUIC stack to handle the CRYPTO frames other than a conveyer of stream of data (by requiring to do specific action at specific offsets). > All other processing stays > the same: CRYPTO frames are always sent using the same keys, even on > retransmission, new TLS messages would be sent in the new epoch, and > ACK frames would need to send using the epoch of the packets they > acknowledge. > > The reason we don't have problems with the handshake is that we *know* > that the peer has keys for the new epoch. Otherwise we would have to > do the same thing. There, following these rules would mean sending in > the clear, which isn't smart. Here, it's just a key update. -- Kazuho Oku From nobody Mon Aug 6 23:37:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDA5130FA8 for ; Mon, 6 Aug 2018 23:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reWjBNR9tgmb for ; Mon, 6 Aug 2018 23:37:21 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC26130FBB for ; Mon, 6 Aug 2018 23:37:21 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id v8-v6so26559135oie.5 for ; Mon, 06 Aug 2018 23:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gi4Mi9vnvsU9VgVl+jPW9EsOxh32tfbtn2E4/45PPOI=; b=LNmsnBAOdTZ8deZLPTNBmXcuE37Ut/EPbqulv/CP/fXQ4cg5k0WnE53irx0IgWcQWx G1+VnOtYV+KzKUQt67Z6lTM/Gaq7t5Lxu3HUhna4J0PEFrSoZz339LH7fEIkm9SInRqA 84wbrUOTzG9Xt1zRftbyYs1hMeF/5Iz3xC4zcdnJaw/yRDEvwCPY/olDlQ6OkwNmMm6K hd0D2wht7pVO/ok9Uj1KCTgxwcVQ8IG8ufU5UfQlmOzJx0PpsAghJh0Nzk4m7Ta3Bm2T Rx01bFa75XR4XPv2+yVjHCcrwFciR4/rxGFj1AoCDKkSDZFoDAo+zMRh1fmtuDuGEHcY TCLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gi4Mi9vnvsU9VgVl+jPW9EsOxh32tfbtn2E4/45PPOI=; b=Kk4W8R5/lC/psucQY5TqovCXWtQ2NbeiyW2iJN+3A9mTu5M6TWq4/uSdBKbJocqbUv zGs8bgKUVDieFIvBLBJGiPrREdugrsJqe/QVb9X9I51YCz/thaJiDuFZ2ImU0N95gsLi AHFk59IoTrTSF45F5ySbS/7y2E/Ipuo8Y9DJP96X/oRB/uIi8O2wW0/sbhxmZdW+EsO/ lGeRhCM+vNkuWr1094NWc5/pNXTV/zM1v1RDNYCA41ZFRH8zxaoIBJbOTFtpsUc96guK Ii3w2ouj5ZX4uIrQTWS7md7u2/hskEIXTakCg3Hgsfj9OUes7vB//Ck4e3/s4+Zij0UI rGzA== X-Gm-Message-State: AOUpUlG+7cwbp401QHtuSuThmgy87Vc7H+JQh1HhuukmnRInsNsY6R+X /ZYPe0Th4MIUVAsjNfKZ38+oPw62lB8BRXPcnNk= X-Google-Smtp-Source: AAOMgpfP87OsQl22idMiHGMGoPYNooDi7nLtmKw+dXwJLs9N+6N7XVqG5fwyEwUK5obtYn2tLrMBn9bF39weg8yk/RA= X-Received: by 2002:aca:3d56:: with SMTP id k83-v6mr16905419oia.166.1533623840611; Mon, 06 Aug 2018 23:37:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Tue, 7 Aug 2018 16:37:09 +1000 Message-ID: Subject: Re: Key updates To: Kazuho Oku Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 06:37:38 -0000 On Tue, Aug 7, 2018 at 4:10 PM Kazuho Oku wrote: > > There is a problem right now with concurrent updates. If both peers > > bump at the same time, then N-1 packets could still be in flight. > > I think that we might be having different models in our minds. > > My view is that, in principle, an endpoint unilaterally updates its > epoch that it uses for "sending" packets. An endpoint MUST NOT update > the send epoch before it sees an acknowledgement for a packet that was > sent encrypting using the current epoch. > > To implement reciprocal key update, we will also state that, if the > send epoch used by the peer becomes greater than the value used by an > endpoint, then the endpoint SHOULD increment it's send epoch as well. > > If we define the rules this way, I would assume that there is not > chance of key getting updated twice even in case both the peers decide > to update at the same moment. > > To put it another way, the issue with the reciprocal (D)TLS-style key > update is that it is defined as a "request" rather than a state change > with idempotency. The rules above is designed as an idempotent state > change from N to N+1 that can be implemented by either peer without > the fear of double update that will lead to potential loss (unless the > endpoints retains more than two keys). There is nothing inherently wrong with the current design, but I recently realized that there is a corner case that is awkward at best without trial decryption, even if you follow those rules. A sends N+1 B sends N followed by N+1 around the same time. 0.5 RTT later both receive a packet at N+1, so both update (not naturally noticing that the response was a little faster than it should have been). A receives the packet from B at N, reordered a little (maybe the N+1 was a small packet at the tail of a burst). A thinks that this is N+2 and discards it. Now, this isn't a correctness issue. But it's annoying. It drives the congestion controller down more than is ideal and adds a bit of extra latency for anything depending on the contents of that packet (or those packets if there is more than one). You fix this by running trial decryption for N and N+2 for a short time, or you move to the prepare-commit style of update. > I think that the described algorithm will work fine, but I am not sure > if I like the fact that it requires the QUIC stack to remember the new > encryption key and the fact that a KeyUpdate message has been sent in > a CRYPTO frame at certain offset, and switch to the new key when all > the data up to that offset is acknowledged. The QUIC stack doesn't have to remember anything other than that is received new TLS data at epoch N and a key change after that. The rules for transmitting CRYPTO frames at the same encryption level ensure that everything works correctly. Now it has new send keys, but the only new rule it needs would be that until all crypto frames for N are acknowledged, you can't starting sending on N+1. I tend to think of this as not being a new rule, but instead that there are exceptional rules for this during the handshake. The rules for receiving are different: you install N+1 for reading immediately (discarding N-1 if that is still around). You can discard N+1 on a timer (that can start immediately, I think, based on what I worked out for key expiration timers, which I am about to put up as a PR). From nobody Tue Aug 7 00:01:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E91130DEB for ; Tue, 7 Aug 2018 00:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZammcKh7qFfg for ; Tue, 7 Aug 2018 00:01:35 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 8F5EB130D7A for ; Tue, 7 Aug 2018 00:01:34 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id j19-v6so12547059ljc.7 for ; Tue, 07 Aug 2018 00:01:34 -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=uEVZIUPFHsqXWHvrQMQdKRmqTnjGeqIa3RHqR9/QDSU=; b=hmBZVmljBTi/0bOGEMgq1gt5f61t45wYe+CIrlPfonuAmB+QkICLKBg6oAVxLd5j3U yuCYUD0YIFrp4oz34gTSjvhy2FgBnKIbPWmGJAiVHcZzg/SyZvg62VQTDZkWvV129mJt 2AI/37JEzdsfAYE7bDLYBkba6Jl/8Es29zCqU1txEUDCppMo0qWeLly2TMNxnUbolAC9 +LrsB3ue/B6HHuGO881UA4B+b5fX1YTaq8p+xZQFr/JDpdYZw7EV6Ri1xQX1BF4udHnF oSKT3Fq3dyPd5dVCfhGs9uygukchd/GMEjsigdv2S15gFRIc+YXP16RxDB6gqF/QUWUC 0CbA== 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=uEVZIUPFHsqXWHvrQMQdKRmqTnjGeqIa3RHqR9/QDSU=; b=cb9Z+zHChpU13zOPwlBKu6wJR7pxGMzcOhDOI44hqwM76dwVoSb+WBIDYeZLibyGVr 0ukquGZu1AJStLDj4fn4K+ZSEiuMuuGWKCPK84xjI2nWJhgBy3PMAATKNeCsxfvRLaPE IP9vBifbzBPwaj7axBD+Q+AnkEv0Q6vO5c0SdKYMYcpVJsF90T1IgmvQW19091jvAgV7 oaT7zZIKOxKsOYmVhU2UxMOJnFq1hztWODmf/wBJU+JFyGYRZRCu1PVhPrsvl9iw1wg6 5VL3SVMWhR4+1KwetmzitMOGwAaWmOynQzN8BXtgSWoyD5uXql9LTlXvDq3GCIci+rtx mAYA== X-Gm-Message-State: AOUpUlEHpxN6oedjXhiwutIDWp9VT3YMGDkZR5FfmkNUhXHuvSOBRQl4 MNzKYfQoKCuIbqxa6qBG9uJ86pkImzC+NmELugY= X-Google-Smtp-Source: AAOMgpfj5PezlxEyFCm1dkFk3/9TgoZM+Jr6IWQuDmhZZQMq6HSMYs5I2ldV9cILEfgpl4+7ihdQmNKbyzpK+/G1sKo= X-Received: by 2002:a2e:40c:: with SMTP id 12-v6mr15559056lje.146.1533625292819; Tue, 07 Aug 2018 00:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Tue, 7 Aug 2018 00:01:32 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Tue, 7 Aug 2018 16:01:32 +0900 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 07:01:37 -0000 2018-08-07 15:37 GMT+09:00 Martin Thomson : > On Tue, Aug 7, 2018 at 4:10 PM Kazuho Oku wrote: >> > There is a problem right now with concurrent updates. If both peers >> > bump at the same time, then N-1 packets could still be in flight. >> >> I think that we might be having different models in our minds. >> >> My view is that, in principle, an endpoint unilaterally updates its >> epoch that it uses for "sending" packets. An endpoint MUST NOT update >> the send epoch before it sees an acknowledgement for a packet that was >> sent encrypting using the current epoch. >> >> To implement reciprocal key update, we will also state that, if the >> send epoch used by the peer becomes greater than the value used by an >> endpoint, then the endpoint SHOULD increment it's send epoch as well. >> >> If we define the rules this way, I would assume that there is not >> chance of key getting updated twice even in case both the peers decide >> to update at the same moment. >> >> To put it another way, the issue with the reciprocal (D)TLS-style key >> update is that it is defined as a "request" rather than a state change >> with idempotency. The rules above is designed as an idempotent state >> change from N to N+1 that can be implemented by either peer without >> the fear of double update that will lead to potential loss (unless the >> endpoints retains more than two keys). > > There is nothing inherently wrong with the current design, but I > recently realized that there is a corner case that is awkward at best > without trial decryption, even if you follow those rules. > > A sends N+1 > B sends N followed by N+1 around the same time. > 0.5 RTT later both receive a packet at N+1, so both update (not > naturally noticing that the response was a little faster than it > should have been). My point is that the issue within the current design is that we require the endpoint to update if the peer initiates an update. I am suggesting to change that to "an endpoint updates its epoch if the peer starts using an epoch that is higher than it uses." Taking the example, A sends N+1 B sends N followed by N+1 around the same time 0.5 RTT later both receive a packet at N+1, and they will stay using N+1, because each of them initiated an update and because the epoch that one uses is not smaller than the value used by the peer > A receives the packet from B at N, reordered a little (maybe the N+1 > was a small packet at the tail of a burst). > A thinks that this is N+2 and discards it. > > Now, this isn't a correctness issue. But it's annoying. It drives > the congestion controller down more than is ideal and adds a bit of > extra latency for anything depending on the contents of that packet > (or those packets if there is more than one). > > You fix this by running trial decryption for N and N+2 for a short > time, or you move to the prepare-commit style of update. > >> I think that the described algorithm will work fine, but I am not sure >> if I like the fact that it requires the QUIC stack to remember the new >> encryption key and the fact that a KeyUpdate message has been sent in >> a CRYPTO frame at certain offset, and switch to the new key when all >> the data up to that offset is acknowledged. > > The QUIC stack doesn't have to remember anything other than that is > received new TLS data at epoch N and a key change after that. The > rules for transmitting CRYPTO frames at the same encryption level > ensure that everything works correctly. Now it has new send keys, but > the only new rule it needs would be that until all crypto frames for N > are acknowledged, you can't starting sending on N+1. I tend to think > of this as not being a new rule, but instead that there are > exceptional rules for this during the handshake. > > The rules for receiving are different: you install N+1 for reading > immediately (discarding N-1 if that is still around). You can discard > N+1 on a timer (that can start immediately, I think, based on what I > worked out for key expiration timers, which I am about to put up as a > PR). -- Kazuho Oku From nobody Tue Aug 7 00:10:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F8A130E5A for ; Tue, 7 Aug 2018 00:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYCnA13jZTUH for ; Tue, 7 Aug 2018 00:10:53 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFCC130D7A for ; Tue, 7 Aug 2018 00:10:53 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id q11-v6so26634269oic.12 for ; Tue, 07 Aug 2018 00:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ghkIvtIUfOCDnXcWyAhxeq6FvEOg1H6ry4thMtksSz8=; b=Paa/7qH2sTdXqxVD4031tavt7oPFWQsuXeTcbR1dPIgMbkZYFy4+dRQCATm6+z3zuI ZTmLd7buS0ND4FvpDu2EvDWTh+GSnYfd4g4Re7R3Gb78xRfQtvHSc/AKJx+2/4SY9KN6 RlhIGQloOlrVz6arejsbB8Mx4hMkeHx5NTDgANJK3Ml+0iK/BYv8kFhFNBGO+/pdWNka cznw3Ztx0U4gPO36k4o+9jBaw/hVKHsbCT0swbUK6Xply3QS4nJdpPC1oCWG6XxE3ja/ TS/kKHSXayii0nxL6Gbj67/DjXydDejIDCbYxEt8TgiVsqCFtCGrHENNqpHSGvKffz3q r2hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ghkIvtIUfOCDnXcWyAhxeq6FvEOg1H6ry4thMtksSz8=; b=Qts5E0PzKuF9WrowFyS0YGWehHwekc/3OqUp8PpItX06T+KjpADpfH0UxJ/gNn4Dzk fLJwFahdBZ7tk031z8mbau9kn6nu747POQi85HjV1auf7bZYlXc3NvvWLUPHJ0UeN1BL T+JJ3Uetan1GEnToKQLhb2ZGS1iQULAt9u1PG/3w91J/kksTbzWuOjBzbOm++YguVTjt a45jR8PDSEVuZ6TWvH0Fe9diKg/emV9ajpK40uy645zdiHknKws6U8Z4Q/GawT5oV6vn Z02l78mPtTDnd9fRwsSmW7Qzm2cyHqQbKHdO43rAHKFyubRSQ+OTrBAEiRxcCi5IfUKq qB8Q== X-Gm-Message-State: AOUpUlEs4zk36FAKofyPTCuCR2syB8Tbxbi+xS2h8fXKgi4aWjFF5EfS rUUXnpCBmP4ZCvadLmMriAQO/sSnFFmbHNsPc38= X-Google-Smtp-Source: AAOMgpeuwjkt3Ug7tNvCFdFpFdG1ZZWAditHWthf+dj18mQE+/qlZ5xxdPsBK4+XuHIgE2zLIStSKs6CMvP2K6chAWI= X-Received: by 2002:aca:3d56:: with SMTP id k83-v6mr16990881oia.166.1533625852691; Tue, 07 Aug 2018 00:10:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Tue, 7 Aug 2018 17:10:41 +1000 Message-ID: Subject: Re: Key updates To: Kazuho Oku Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 07:10:56 -0000 On Tue, Aug 7, 2018 at 5:01 PM Kazuho Oku wrote: > My point is that the issue within the current design is that we > require the endpoint to update if the peer initiates an update. > > I am suggesting to change that to "an endpoint updates its epoch if > the peer starts using an epoch that is higher than it uses." > > Taking the example, > > A sends N+1 > B sends N followed by N+1 around the same time > 0.5 RTT later both receive a packet at N+1, and they will stay using > N+1, because each of them initiated an update and because the epoch > that one uses is not smaller than the value used by the peer I see, thanks for clarifying. I don't think that this is a great idea because it means that reordered packets will be dropped. Reordering is common enough for at least some implementations to want to retain N for some time after this changeover. From nobody Tue Aug 7 00:39:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF4A130E79 for ; Tue, 7 Aug 2018 00:39: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfNqwjg9XjXo for ; Tue, 7 Aug 2018 00:39:41 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 E2CB2130E1D for ; Tue, 7 Aug 2018 00:39:40 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id u7-v6so12640145lji.3 for ; Tue, 07 Aug 2018 00:39:40 -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=GLeeLFwu6svHVeFKJNe2F6Xqrj2sTWeByK1mCQvQTgU=; b=VeIRzRRedBepxvd/0SDFRb7+uokMFHFcbLhcWvdnVDs8/6zRWv4HJ1kp3L8ebl9g40 p8ymJIIG7LDbJWJ25bdqYODiVBLBIcKd09HhoPNTRIeNailCA4Yhiu5G/NuGcBB3WtSv RwAoZUrsnbuvco4RZMzMLyWus8jtdautfTjUTifOnhM5fi9HR6fkfvIkuS0E6ZxnQn6n auUmaPJpkMpoHMbzxsQEKjzI3tXPTmkQFXb2ip6adNR/TUMMNip+E5aqDy+LPe7sT8Yt 5ZVph4u90EF+MweCvvpDG8rnel/gT7L7IO0IAuwJ95RiVaYrsVDXntUosxHHPoQj2Rbm ElsA== 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=GLeeLFwu6svHVeFKJNe2F6Xqrj2sTWeByK1mCQvQTgU=; b=hnzY7WvsXCP5pMihAPkUvdquFlNd+EV14kcG80F0XYumJKsxvE4wwm3Qyyi5yYXGW4 QyOTiZYhyvorODt+jDE8MJxsqaDu2CU6AWMSNCLKhB3gP0Xwfwltsw4e8mQ4YHOLUQyu MoIyigz606jk0tfBCP9ik22kZ1SdfDJyuAl/WeiAOLPSqWRq1HBtD1I+clbd6PPOBx6a 3KyPjyEeWaoAMMthO58QKEF2rlk77w8G1RbZmrVX8U731VFyymr5PSphFMqjkaIRoIsS vbN4SFusUaqo5W5bbPJPg+VFhyZjNYBBEbM/E5eV7HUriTLn0hXfKOimGK4rvinMz+Rf xQNA== X-Gm-Message-State: AOUpUlGFXo64r0a/ZHKR3RJe0QG+DFw64fd7Jxzvk/BypBTDj9r9pUgF xwDtxcNkkTlprIdgCo/n5PcUP+7Up71h00F3IkvsjfSf X-Google-Smtp-Source: AAOMgpc1DmC4K2edUS9XHwEPxiG0vdlRUKfKEgEZNEuoQIFKdOR+GOnxPL5iNUXeehtSV1D+zfJ8GE9tsZjliAhHHLs= X-Received: by 2002:a2e:9e55:: with SMTP id g21-v6mr15700502ljk.116.1533627579079; Tue, 07 Aug 2018 00:39:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Tue, 7 Aug 2018 00:39:38 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Tue, 7 Aug 2018 16:39:38 +0900 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 07:39:43 -0000 2018-08-07 16:10 GMT+09:00 Martin Thomson : > On Tue, Aug 7, 2018 at 5:01 PM Kazuho Oku wrote: >> My point is that the issue within the current design is that we >> require the endpoint to update if the peer initiates an update. >> >> I am suggesting to change that to "an endpoint updates its epoch if >> the peer starts using an epoch that is higher than it uses." >> >> Taking the example, >> >> A sends N+1 >> B sends N followed by N+1 around the same time >> 0.5 RTT later both receive a packet at N+1, and they will stay using >> N+1, because each of them initiated an update and because the epoch >> that one uses is not smaller than the value used by the peer > > I see, thanks for clarifying. I don't think that this is a great idea > because it means that reordered packets will be dropped. Reordering > is common enough for at least some implementations to want to retain N > for some time after this changeover. Reordered packets will not be dropped, assuming that an endpoint will not issue more than one key update within a short amount of time (a guarantee that is provided by the described design), that each endpoint will retain at most 2 keys for decryption. Nor there will be trial decryption. Generally speaking, I think that the designs can be evaluated in two aspects. 1. if retaining at most 2 keys is fine Retaining at most 2 keys will be fine if there is a guarantee that multiple updates within a small amount of time does not happen. That is guaranteed by the design I described above. It is not guaranteed by the current design, nor by the (D)TLS-based design. 2. if installation of a new key (or a retirement of an old key) is an explicit signal I agree that it is nice to have an explicit signal that instructs the peer to switch the decryption keys, from epochs=(N-1,N) to (N,N+1). OTOH, I might prefer requiring an endpoint to switch from (N-1,N) to (N,N+1) at the earliest moment. This is because then, you could start using the new key after quiescence. Considering the two, the (D)TLS-based approach does not have the first property, even setting the discussion about the complexity aside. I am fine with having an explicit signal for key installation, though I think that timer is fine based on my assumption (stated above) that we would prefer having older generation of keys being retired at the earliest moment. -- Kazuho Oku From nobody Tue Aug 7 05:23:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69941252B7 for ; Tue, 7 Aug 2018 05:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 GMR0mLEpwYAr for ; Tue, 7 Aug 2018 05:23:35 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A81130E59 for ; Tue, 7 Aug 2018 05:23:35 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id b15-v6so17482046qtp.11 for ; Tue, 07 Aug 2018 05:23:35 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VuZr61+6E0kQXUC4qDwbEV9/Hb6vzopy5GlmAN3vVI0=; b=oxiOhjc/4feQiFL11g6jGWALmiFVa8se6WL7AlR07q4APZ/oAQzv36EiKsET+l8u2X VfHcQsrwj9cGy2RSjWCKZ4dkra1QBuEM+M4Fp/vl1qN/cr/QiznbwFYe/yrwZViQ8TVS MT86LmJZnWt86LYDx9Wx59DIR8J35sBfRPtgdcU7WWnlMWhuIIGEPOVvGPewEuooWDO4 xjljqbHlF80zqLM+JtJ13jgbCyvMhoscroS6NhgO6IJC36oaDlfXLmwCTixRrsSGf9bb 6dp1sdUHjFAMHLmNT90YlDQsmBJZ28GAMecPusjalWwmVLRhKTRjILwWfLB64EjdwtVh qp3w== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=VuZr61+6E0kQXUC4qDwbEV9/Hb6vzopy5GlmAN3vVI0=; b=fHb4acVoaWAnWsEJFSLolv9exj2a/0Bjs7/4Tnhl3wAKVwNX0YVkOZUlzWhY41VyJV i+vqjsoAYpIE1N+u6OXckgzVCwRX3AXWYwbE9v3ZusMX9S5L4VEI0eTg8zkd9bdsuAsy 4zBXQ8FHtyrDg5FEI6fN2tPUSLZPVpBqWf2kgjYb0UFzCDU9DD5AGcPrsilqV1GE2Udx NGdDIey+xIShRHWKs12dHjYPuTjlj1QUE2ZUwDJDPPfpBSnXY46vC3qHZSxxbQ9MIwhC 5W5ILNTQ2DuMZzU7hKhqUPga+EJ0g0KNG7qzPSvzR0KO4m4UW1sP2EpopcvOkmgkU3FY P0+g== X-Gm-Message-State: AOUpUlFvex6RHsXfwFN6sA+NA2ysPDgFeuFpvmzZGzxo1/P4KMMgbnsK UIDmpV7+bk3N4dOT6vbbLQTqUQ== X-Google-Smtp-Source: AAOMgpcgEh8rGnJZ+zAyCDC+EaZyplGQBRF6n2m7YVx40wgvbEbAiuLlR01jqzP7mp8JN3ez8GtxVQ== X-Received: by 2002:ac8:3531:: with SMTP id y46-v6mr17775496qtb.92.1533644614173; Tue, 07 Aug 2018 05:23:34 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id k3-v6sm748672qkl.95.2018.08.07.05.23.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 05:23:33 -0700 (PDT) Date: Tue, 7 Aug 2018 08:23:29 -0400 From: Dmitri Tikhonov To: Kazuho Oku Cc: Martin Thomson , QUIC WG Subject: Re: Key updates Message-ID: <20180807122328.GA1645@ubuntu-dmitri> Mail-Followup-To: Kazuho Oku , Martin Thomson , QUIC WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 12:23:37 -0000 On Tue, Aug 07, 2018 at 04:39:38PM +0900, Kazuho Oku wrote: > Reordered packets will not be dropped, assuming that an endpoint will > not issue more than one key update within a short amount of time (a > guarantee that is provided by the described design), that each > endpoint will retain at most 2 keys for decryption. Nor there will be > trial decryption. This is my understanding as well. The key phase bit is simply an index into an array of keys of size 2 that each side uses as a ring buffer. A new key overwrites the old key and the current key becomes the old key. - Dmitri. From nobody Tue Aug 7 22:03:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3230D130DE4 for ; Tue, 7 Aug 2018 22:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 WiWqYZ0Ffsr8 for ; Tue, 7 Aug 2018 22:03:01 -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 7BD8F130DD9 for ; Tue, 7 Aug 2018 22:03:01 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fnGbt-0003HL-5y for quic@ietf.org; Wed, 08 Aug 2018 07:02:59 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fnGbl-0008Pr-AJ for quic@ietf.org; Wed, 08 Aug 2018 01:02:09 -0400 Received: (qmail 23796 invoked from network); 8 Aug 2018 05:02:01 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.107]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Aug 2018 05:02:01 -0000 To: Mark Nottingham , IETF QUIC WG Cc: Lars Eggert References: <1820B63B-D278-4E8A-95EC-5200664163FB@mnot.net> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <90211153-dcf7-921b-b6c9-093340e0b1e8@huitema.net> Date: Tue, 7 Aug 2018 22:01:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1820B63B-D278-4E8A-95EC-5200664163FB@mnot.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: Reminder: Registration for the September Interim X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5lEFcNnai3Ebsndc519T8O5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVilxuawy79nBIyvc1HB6Nh8c7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuzDn5j2tUhjYPVPi3bwTCB/TBCf6oYXAWGet lavcAjAiREicRPMV5adYQyNOvKmgizQS7ZJXB6rwDFOa1j0OJR6ijzwzq5HGxV3pRhOdYuobeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80D4WY7xWSn pVjQVprFFOt2hDWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SMPepZn00xVXQbuUt1pns FwEiRQv+PVjjwa+Z5RFCOMTwcD+deSsUec2uUy1l2Ykm/SkjHuYQDxaU4XDpGsg0T+yZTvADSBud 4xpTL+FLQRLUdLWq1MCLe4uzYlSTS/YzOILorw8hkXvCsQxELmff7J1gP4HWZlfj1ueWMBAfk0cY VXicmMOpI2clI133E9HJeoz65OD2C5IJ2sa6HdMmGe4jeF7MIDAd/+68q5OewVNNG/FpJKHpH9WN 3n6EeFcOSNDEWS6un19krZ9OmsFQ7oQKSK3P4ypiY56j+sEW5bT/pOdQlfBzqAqfm1gdq18TTAz/ vUCXk3dj4MGE7pxybrCSbdqFcK0JtqhNMg7Did/NTt/aVJj3FpzwJHlTKBf4P5hMT+A79/UQxSgW IabEpmvDK3PKrieG7T6bf9hS7hSjMM96sV7dcXymT/Bh/IEEdD/a7oKc1xB6o1ApfCO9+GHf4ys4 4rg2B8/9FmK9a1M2fwlGUBjVgiQQJUTeFgMs X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 05:03:03 -0000 On 8/6/2018 1:13 AM, Mark Nottingham wrote: > .... closes in roughly one week. > > Please see: > https://github.com/quicwg/wg-materials/blob/master/interim-18-09/arrangements.md Thanks for the reminder, I almost missed it! Any hotel recommendation? -- Christian Huitema From nobody Wed Aug 8 00:17:21 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB246130DC6 for ; Wed, 8 Aug 2018 00:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK7rR6dsP5co for ; Wed, 8 Aug 2018 00:17:15 -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 6F009130DC0 for ; Wed, 8 Aug 2018 00:17:15 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id d189-v6so2065636oib.6 for ; Wed, 08 Aug 2018 00:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lB/EZ9sS2dwgMbWOtbr3fSlt5WDcKLuIjwaWhnjr5Nc=; b=Zn8o/mXAGFnKivHp2e7KdkbJea8rWFpUIy6HCf0ZtpiAGspIYudcDobSfWWUE2RJla jOSPtnZlp5DC8LtRkCoww6iB9CH8VfYshz7/jCg4t4YbO0v+u7Vfh0nKIXyANiaBXSG1 ZE9t/1//MSkVy5gF2QjojFyt3SWqFQoCRdX5HuPwpEBnlG8UNssJPElZZy9pWzUCWktD bBeKD0PalQDBhdzcdciolS7b4OjRfFv7VWcD1n/ljPegmUxVGLPEn0ILgLDu1nYNCSUJ cLWAvvF0wqUb10ecEWPmF0nVtAULDvPMXVO/UpQhdQrdEcXRF07++mbaGIKhO9ZrETfb /X6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lB/EZ9sS2dwgMbWOtbr3fSlt5WDcKLuIjwaWhnjr5Nc=; b=NNjrlG8VUsVFDWUGSk7rHcRoYGu8hgusDbwoWdCCeDZMLoQp1CEV6tjbceaLxCjvDF ZSetrsJqpbj/RnX6t+EGwm27GmrCDkQPQI2YsMySJ3hzMFLhJNURZ+fLBN2OYpaUJonm 3RpWHcmzqd/8vTg+hK+N8xK82x9PEuE0FGQ3IO/AcMardS/qHgmuFTjQbbWYRGn9QeJd DQSlvnFX/4Ow13Yp73vY2ZhRAX9IsrNDlpwblLlTzOlIjHNfkDUKcY8a7LOQDpeiHU4a dK5cehecPECRM6e2Y0GchhjFvr9ufEXgyusn/oWgTMkhCF1oVZ5xrlgHU2EPoXYlXdnf c/ow== X-Gm-Message-State: AOUpUlErIJIDSoysHuP6B97BgEq8LvF1Rn6Zfksumn6M07TkX1/s8Al+ 0XPLaadajDq+y2kRcxgLxVvglsefhNmIwwD/sK32cTBYYzI= X-Google-Smtp-Source: AA+uWPz8STFpv38XK9bG8B2JXHLLesoxWEKve1LitwPT5ElGAsU8QeMdGuT8sPDQqrfDAscomOO3g8FoahxmrJp7wgU= X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr1868561oiq.110.1533712634649; Wed, 08 Aug 2018 00:17:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Wed, 8 Aug 2018 17:17:02 +1000 Message-ID: Subject: Re: The first octet To: Kazuho Oku Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 07:17:20 -0000 Thanks for sharing your perspective Kazuho, I have a slightly different view, but it's fairly consistent with yours. Reformulating the second question is good, and I too would like to encrypt this stuff. It should be easy enough to do so. I too like the common form for packet number lengths. I can even see adding key phase to long header packets for the purposes of consistency. This is my preferred layout for the case we have three bits for spin. 1 t t t t p p p 0 1 s s s p p p Where p p p is an encrypted key phase bit and two-bit packet number length (1,2,3,4). I think that we can afford to have fix tttt values with no greasing. Allocating four bits and using two of them isn't so bad. By doing that we can choose types that don't conflict with RTP. It's not necessary, but it's very cheap. The fixed bit keeps the short header away from most of the RFC 7983 protocols without costing much (you had a reserved bit anyway). The extra fixed bit here makes QUIC short header packets conflict only with TURN channels from 7983. That's totally acceptable and fairly cheap from our perspective. If you are concerned about ossification of this bit, we could give it to the spin bit(s) and force the people who want this sort of demux to negotiate the spin bit into a fixed value if they care to have good demux. If we have two fewer bits of spin, that's where things get interesting. I would prefer to keep the same ppp bits, but leave the two spare bits unallocated, but encrypted along with ppp. Encrypting means they can be forced to be zero unless agreed otherwise (MBZ normally means MUST send zero, MUST ignore non-zero, but I prefer MUST reject non-zero here): 1 t t z z p p p 0 1 s z z p p p The hit here is RTP. We would need all type values so we end up using 0b10xxxxxx. We can limit the damage by changing codepoints for 0-RTT and Retry packets, which can be avoided in most scenarios that use RTP (signaling FTW). If we have no spin bits, then we might as well change the single s bit to a fixed 1. Then we avoid TURN channels as well. On Tue, Aug 7, 2018 at 3:39 PM Kazuho Oku wrote: > > 2018-08-06 14:55 GMT+09:00 Martin Thomson : > > It appears as though we're about to get some information about how > > deployable the QUIC invariants are. Ian tells me that Google are most > > of the way to deploying a protocol that uses QUIC invariants and > > should be able to confirm that this works by the interim. Well, > > either that or to be able to tell us what doesn't work, which I'm > > hoping isn't a problem we have to deal with. > > > > I'd like to spend some time at the interim on what we do with the type > > bits in the protocol. This email is an attempt to thoroughly cover > > the constraints that we have here and attempt to describe a process > > that I hope should get us to a conclusion shortly after Bangkok. > > > > Looking at open design issues, this cluster is the one that is the > > biggest threat to our schedule. > > > > Design Status and Constraints > > > > Long Header > > > > The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we > > have are currently allocated to the 4 types of long header packet, > > using only 252-255. All other values are currently unused. > > > > With respect to design constraints, there is only one that I'm aware > > of and that is a potential collision with RTP (and RTCP) on this octet > > (see RFC 7983), which use 0x10xxxxxx (128-191). > > > > The open question here is what we do with unused types. We might > > debate creating a registry for unused values. We might want to grease > > values. We could even decide to encrypt these values (though the > > design of Retry makes that more difficult, because the contents of > > that packet aren't encrypted at all). > > > > I'm not aware of any plans to use these bits, except perhaps what > > might be done to be consistent with the short header changes, so we > > might have some latitude here. > > > > Short Header > > > > The short header uses the 0b0xxxxxxx pattern (0-127). This is far > > more complex and we have a bunch of open questions that will make this > > difficult. > > > > Right now, we use the 0b0K110RRR as the pattern, with K being the key > > phase, and RRR being reserved for the spin bit experiment. > > > > Those fixed bits are (largely) temporary, and might be reclaimed once > > existing deployments of Google QUIC (pre-44) are phased out, so I > > think that we might want to reclaim some or all of them. > > > > There is a chance that the reserved bits will also become available > > (if not all, then maybe 2 of them). That will be decided in Bangkok, > > but we might want to have a plan for those bits. > > > > The constraints that I am then aware of are these: > > > > 1. RFC 7983 has the lower half of the first octet fairly densely > > populated for demux. Of the protocols there, my understanding of > > their relative importance puts STUN (0-4) as fairly critical, if not > > mandatory, then TLS (20-63) as optional. ZRTP (16-19) and TURN > > channels (64-79) are both apparently unimportant, though each might be > > opportunistically accommodated. > > > > 2. Passive RTT measurement (spin bit) will take 0, 1, or 3 bits. I > > suggest that we allow for this, not counting on having any more bits > > than N-3, or assuming that only that many bits will be available. > > > > 3. Kazuho points out that the key phase is a linkability vector. We > > might want to consider encrypting that. We could do that by fixing > > the packet number key and not updating it after key updates and using > > more output from that process to mask the bit (and maybe other bits in > > this field). > > > > 4. I realize that we don't have to put a key phase in every packet if > > we are less concerned about being able to update immediately. If we > > adopt a scheme to what was proposed in DTLS, then a longer encoding > > can be used during the preparation and signaling phase. I'll follow > > up with another email on this subject. > > > > One thing that we could use extra bits for is to move the packet > > number size back into this octet. We could even move packet number > > bits back, depending on available space. That might make some > > difference to the number of bytes we allocate for packet numbers. > > > > Process > > > > Given that we don't have answers to some questions we might conclude > > several ways. I proposed that we agree on principles, starting with: > > > > 0. (This should already be agreed, but I'm repeating it because it's > > important.) The low 7 bits of the first octet are version-specific > > and can change in the next version of the protocol. > > > > A. What do we want to do with unused bits? Do we want to ensure that > > they are always used? Or can they be reserved? If so, how would they > > be reserved (fixed values, random values, greasing, etc...)? > > As Jana has suggested, I think that the bits must look like random to > observers, based on our agreement that the bits are version-dependent. > > Unless we make them look like random, there is fair chance that they > will be ossified. > > > > > B. Should things in the first octet be encrypted where possible (for > > example, using an extension of packet number encoding). > > I would rather rephrase the question to "do we need to encrypt foo?" I > think that we should decide what will go into the first octet based on > the agreement of what needs to be encrypted. > > Having that said, I think that we need to encrypt packet number, > packet number length, and the key-phase bit. The packet type bits and > the spin bit(s) need to be in cleartext. Unused bits can be > seemingly-randomized as an output of encryption, or could be a random > value. > > My preference regarding the design will be to have the packet number > length bits and the key-phase bit in the first-octet next to each > other, encrypting the two using the PNE key. > > Having packet number length at a different location than the packet > number itself will simplify the implementation, gives us more chance > to use shorter encodings for packet numbers. > > For example, the long and short packet header will look like below (e > - encrypted values of PN length and key-phase, t - long header type > bits, s - spin bit, R - reserved bit). > > long: 1 e e e R R t t > short: 0 e e e R s s s > > I do not have a preferred way of randomizing the R bits. They could be > randomized by PNE along with the e bits, or we could require them to > be randomized separately. > > > > > C. Should packet number encodings should be consistent between long > > and short header forms? > > Yes. > > I do not think that we need to be clever in saving one bit or two. We > already waste certain number of bits. The fact that we are using > varint encoding that changes the length at octet-level (i.e., 8 bits, > 16 bits, 32 bits, ...) means that we are wasting something like 4 bits > by average per varint. We are also wasting 2 bits per frame, > considering the fact that the upper 2 bits of a frame is not used. > > > D. What should we do with key phase? This was an open issue from the > > stream 0 design team, which might alter the outcome here. I have > > another email that covers this in more detail. > > I think we should the bit in every packet as an encrypted value. The > reason why having I consider that the bit in every packet is stated > above. > > > E. How should we accommodate multiplexing? For me, the big questions > > here are whether we allow for RTP to collide with the long header and > > which of the protocols we privilege by avoiding with the short header. > > I would prefer not caring about multiplexing. > > We do not guarantee multiplexing between QUICvX and other protocols. > Considering that, I am inclined to not discussing about > multiplexability of QUICv2 (formerly v1), because that would raise > the chance of QUIC becoming ossified. > > > My hope is that reaching conclusion on those principles should allow > > us to to agree on designs that allow for 0, 1, or 3 bits of spin bit. > > That way we know what to do with the outcome of the discussions we > > plan to have in Bangkok and can implement the changes relatively > > quickly. > > > > For those who read this far, if you have opinions on what principles > > should drive this design, please respond here. If you have a proposed > > design (or designs) and can explain the principles that are expressed, > > that's OK too. If this gets enough feedback, I might arrange a call > > for interested parties. > > > > I don't expect that we'll reach a conclusion before the interim, but I > > don't think that we can let this go unresolved much beyond that point. > > > > > > -- > Kazuho Oku From nobody Wed Aug 8 00:41:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C7E130DC9 for ; Wed, 8 Aug 2018 00:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFFZNnA-tX-e for ; Wed, 8 Aug 2018 00:41:48 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 1333A130DD1 for ; Wed, 8 Aug 2018 00:41:47 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id p10-v6so975508ljg.2 for ; Wed, 08 Aug 2018 00:41:46 -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=5L/a24Rx2TyPzmV7VdwxO5nrpmJIorS9OIgcmd1d4+4=; b=BZeJnvSL+xYbKbXBPRw2SjemuHaoMhnA0A1nnPzI6LeqvJGs2FAWQvVRg3zKQBf4Vr EOuozX4xS8zlae/xP/0MQA9hnGzDPZBrNasFm91JBMIDGrDAYjbmqp4/eztKXaZu7xgL x47H7Ytfh4kICfmptkT6oNwPR0IVJ5OPGqUzUJTCj/9opWtHavag3x0ryUnfr6ds/Czs Hv+2Z+4G/sLWfl/iMMoJcy8DT+Gl0ZDrZfjPKTRJe7Y6U5/UlN3/go23l97XrQcAAUSY 2pLwDcCXdK1p1uQZ/KnoBWZdy/hKR2iRhOYmC4JysCpPmpScq3wZgL8+Cev0PvpFAQx8 Pd7Q== 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=5L/a24Rx2TyPzmV7VdwxO5nrpmJIorS9OIgcmd1d4+4=; b=msTAeN0bPNkuf4aJ+S1CKHgrcwj/0EZxwehtV67ZblMyFy1o816r1XLsiLSMRSlhoG +z4uajo9pFRT5EvSwFfV2TjLC/Z7gHlfXUGttT+XiKhBMwngBf9Rm2A1gUCp+ekIWMcE DRV1a53K39/FoV1ddU3pw8hFN1+Ro9UI2Pu30x3Fwn/psARaCOMHazrh0QD29mgN8nj+ RwLRoXswBcm9sfafMnJx4juld1kbFcia61KdszK/3gR1+qN/c5oD1jpMXATUHdUpoEM/ TArV/ykvrAORmsxw410h8OFhGc/whHkQ1xTC5xRX4FevyObUuiFdOpy9muZtnBSxNyPl KAWw== X-Gm-Message-State: AOUpUlFSCj6HO6xpA1sym5ebDIhHPKLFoKclOx/11fTR5g/Op9hZYUie UTdiNKcijCn6CWR7ThrSmvlYsfzQOqqhOWUe1Xc= X-Google-Smtp-Source: AA+uWPxmf4GjJQrzi9BowCJWCZ4EIZlSKWTL3bozn+qt3xXsKI62FoMGy04hZ67BtiAEjfkJpMKBzGZrkadwZYig0gE= X-Received: by 2002:a2e:2e02:: with SMTP id u2-v6mr74139lju.77.1533714105211; Wed, 08 Aug 2018 00:41:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 00:41:44 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Wed, 8 Aug 2018 16:41:44 +0900 Message-ID: Subject: Re: The first octet To: Martin Thomson Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 07:41:51 -0000 2018-08-08 16:17 GMT+09:00 Martin Thomson : > Thanks for sharing your perspective Kazuho, I have a slightly > different view, but it's fairly consistent with yours. Martin, thank you for sharing your view and how you think we might encode the bits. I agree that our views are mostly consistent. IMO, the only disagreement is if we should try to avoid conflict with other protocols. My understanding is that we do not avoid conflict in the invariants, but you suggest to avoid them in v2. Would you mind elaborating why you think we should make such a decision? For example, is it the case that you think avoiding conflict in the short term is worthwhile, at the same time keeping the possibility to change the decision in the future versions of QUIC? Honestly, I do not have a strong opinion here, although I worry about ossification when we decide not to grease the bits. Therefore, I would like to understand why you think avoiding conflict in v2 but not in invariant is worth considering. Thank you in advance. > Reformulating > the second question is good, and I too would like to encrypt this > stuff. It should be easy enough to do so. > > I too like the common form for packet number lengths. I can even see > adding key phase to long header packets for the purposes of > consistency. > > This is my preferred layout for the case we have three bits for spin. > > 1 t t t t p p p > 0 1 s s s p p p > > Where p p p is an encrypted key phase bit and two-bit packet number > length (1,2,3,4). I think that we can afford to have fix tttt values > with no greasing. Allocating four bits and using two of them isn't so > bad. By doing that we can choose types that don't conflict with RTP. > It's not necessary, but it's very cheap. The fixed bit keeps the > short header away from most of the RFC 7983 protocols without costing > much (you had a reserved bit anyway). > > The extra fixed bit here makes QUIC short header packets conflict only > with TURN channels from 7983. That's totally acceptable and fairly > cheap from our perspective. If you are concerned about ossification > of this bit, we could give it to the spin bit(s) and force the people > who want this sort of demux to negotiate the spin bit into a fixed > value if they care to have good demux. > > If we have two fewer bits of spin, that's where things get > interesting. I would prefer to keep the same ppp bits, but leave the > two spare bits unallocated, but encrypted along with ppp. Encrypting > means they can be forced to be zero unless agreed otherwise (MBZ > normally means MUST send zero, MUST ignore non-zero, but I prefer MUST > reject non-zero here): > > 1 t t z z p p p > 0 1 s z z p p p > > The hit here is RTP. We would need all type values so we end up using > 0b10xxxxxx. We can limit the damage by changing codepoints for 0-RTT > and Retry packets, which can be avoided in most scenarios that use RTP > (signaling FTW). > > If we have no spin bits, then we might as well change the single s bit > to a fixed 1. Then we avoid TURN channels as well. > > On Tue, Aug 7, 2018 at 3:39 PM Kazuho Oku wrote: >> >> 2018-08-06 14:55 GMT+09:00 Martin Thomson : >> > It appears as though we're about to get some information about how >> > deployable the QUIC invariants are. Ian tells me that Google are most >> > of the way to deploying a protocol that uses QUIC invariants and >> > should be able to confirm that this works by the interim. Well, >> > either that or to be able to tell us what doesn't work, which I'm >> > hoping isn't a problem we have to deal with. >> > >> > I'd like to spend some time at the interim on what we do with the type >> > bits in the protocol. This email is an attempt to thoroughly cover >> > the constraints that we have here and attempt to describe a process >> > that I hope should get us to a conclusion shortly after Bangkok. >> > >> > Looking at open design issues, this cluster is the one that is the >> > biggest threat to our schedule. >> > >> > Design Status and Constraints >> > >> > Long Header >> > >> > The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we >> > have are currently allocated to the 4 types of long header packet, >> > using only 252-255. All other values are currently unused. >> > >> > With respect to design constraints, there is only one that I'm aware >> > of and that is a potential collision with RTP (and RTCP) on this octet >> > (see RFC 7983), which use 0x10xxxxxx (128-191). >> > >> > The open question here is what we do with unused types. We might >> > debate creating a registry for unused values. We might want to grease >> > values. We could even decide to encrypt these values (though the >> > design of Retry makes that more difficult, because the contents of >> > that packet aren't encrypted at all). >> > >> > I'm not aware of any plans to use these bits, except perhaps what >> > might be done to be consistent with the short header changes, so we >> > might have some latitude here. >> > >> > Short Header >> > >> > The short header uses the 0b0xxxxxxx pattern (0-127). This is far >> > more complex and we have a bunch of open questions that will make this >> > difficult. >> > >> > Right now, we use the 0b0K110RRR as the pattern, with K being the key >> > phase, and RRR being reserved for the spin bit experiment. >> > >> > Those fixed bits are (largely) temporary, and might be reclaimed once >> > existing deployments of Google QUIC (pre-44) are phased out, so I >> > think that we might want to reclaim some or all of them. >> > >> > There is a chance that the reserved bits will also become available >> > (if not all, then maybe 2 of them). That will be decided in Bangkok, >> > but we might want to have a plan for those bits. >> > >> > The constraints that I am then aware of are these: >> > >> > 1. RFC 7983 has the lower half of the first octet fairly densely >> > populated for demux. Of the protocols there, my understanding of >> > their relative importance puts STUN (0-4) as fairly critical, if not >> > mandatory, then TLS (20-63) as optional. ZRTP (16-19) and TURN >> > channels (64-79) are both apparently unimportant, though each might be >> > opportunistically accommodated. >> > >> > 2. Passive RTT measurement (spin bit) will take 0, 1, or 3 bits. I >> > suggest that we allow for this, not counting on having any more bits >> > than N-3, or assuming that only that many bits will be available. >> > >> > 3. Kazuho points out that the key phase is a linkability vector. We >> > might want to consider encrypting that. We could do that by fixing >> > the packet number key and not updating it after key updates and using >> > more output from that process to mask the bit (and maybe other bits in >> > this field). >> > >> > 4. I realize that we don't have to put a key phase in every packet if >> > we are less concerned about being able to update immediately. If we >> > adopt a scheme to what was proposed in DTLS, then a longer encoding >> > can be used during the preparation and signaling phase. I'll follow >> > up with another email on this subject. >> > >> > One thing that we could use extra bits for is to move the packet >> > number size back into this octet. We could even move packet number >> > bits back, depending on available space. That might make some >> > difference to the number of bytes we allocate for packet numbers. >> > >> > Process >> > >> > Given that we don't have answers to some questions we might conclude >> > several ways. I proposed that we agree on principles, starting with: >> > >> > 0. (This should already be agreed, but I'm repeating it because it's >> > important.) The low 7 bits of the first octet are version-specific >> > and can change in the next version of the protocol. >> > >> > A. What do we want to do with unused bits? Do we want to ensure that >> > they are always used? Or can they be reserved? If so, how would they >> > be reserved (fixed values, random values, greasing, etc...)? >> >> As Jana has suggested, I think that the bits must look like random to >> observers, based on our agreement that the bits are version-dependent. >> >> Unless we make them look like random, there is fair chance that they >> will be ossified. >> >> > >> > B. Should things in the first octet be encrypted where possible (for >> > example, using an extension of packet number encoding). >> >> I would rather rephrase the question to "do we need to encrypt foo?" I >> think that we should decide what will go into the first octet based on >> the agreement of what needs to be encrypted. >> >> Having that said, I think that we need to encrypt packet number, >> packet number length, and the key-phase bit. The packet type bits and >> the spin bit(s) need to be in cleartext. Unused bits can be >> seemingly-randomized as an output of encryption, or could be a random >> value. >> >> My preference regarding the design will be to have the packet number >> length bits and the key-phase bit in the first-octet next to each >> other, encrypting the two using the PNE key. >> >> Having packet number length at a different location than the packet >> number itself will simplify the implementation, gives us more chance >> to use shorter encodings for packet numbers. >> >> For example, the long and short packet header will look like below (e >> - encrypted values of PN length and key-phase, t - long header type >> bits, s - spin bit, R - reserved bit). >> >> long: 1 e e e R R t t >> short: 0 e e e R s s s >> >> I do not have a preferred way of randomizing the R bits. They could be >> randomized by PNE along with the e bits, or we could require them to >> be randomized separately. >> >> > >> > C. Should packet number encodings should be consistent between long >> > and short header forms? >> >> Yes. >> >> I do not think that we need to be clever in saving one bit or two. We >> already waste certain number of bits. The fact that we are using >> varint encoding that changes the length at octet-level (i.e., 8 bits, >> 16 bits, 32 bits, ...) means that we are wasting something like 4 bits >> by average per varint. We are also wasting 2 bits per frame, >> considering the fact that the upper 2 bits of a frame is not used. >> >> > D. What should we do with key phase? This was an open issue from the >> > stream 0 design team, which might alter the outcome here. I have >> > another email that covers this in more detail. >> >> I think we should the bit in every packet as an encrypted value. The >> reason why having I consider that the bit in every packet is stated >> above. >> >> > E. How should we accommodate multiplexing? For me, the big questions >> > here are whether we allow for RTP to collide with the long header and >> > which of the protocols we privilege by avoiding with the short header. >> >> I would prefer not caring about multiplexing. >> >> We do not guarantee multiplexing between QUICvX and other protocols. >> Considering that, I am inclined to not discussing about >> multiplexability of QUICv2 (formerly v1), because that would raise >> the chance of QUIC becoming ossified. >> >> > My hope is that reaching conclusion on those principles should allow >> > us to to agree on designs that allow for 0, 1, or 3 bits of spin bit. >> > That way we know what to do with the outcome of the discussions we >> > plan to have in Bangkok and can implement the changes relatively >> > quickly. >> > >> > For those who read this far, if you have opinions on what principles >> > should drive this design, please respond here. If you have a proposed >> > design (or designs) and can explain the principles that are expressed, >> > that's OK too. If this gets enough feedback, I might arrange a call >> > for interested parties. >> > >> > I don't expect that we'll reach a conclusion before the interim, but I >> > don't think that we can let this go unresolved much beyond that point. >> > >> >> >> >> -- >> Kazuho Oku -- Kazuho Oku From nobody Wed Aug 8 00:50:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E4C130DC9 for ; Wed, 8 Aug 2018 00:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.291 X-Spam-Level: X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PIQxISsicOt for ; Wed, 8 Aug 2018 00:50:36 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4D4126CB6 for ; Wed, 8 Aug 2018 00:50:36 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 41lk896pZYz30cY; Wed, 8 Aug 2018 09:50:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 41lk895d2qzCqjj; Wed, 8 Aug 2018 09:50:33 +0200 (CEST) Received: from [10.193.4.89] (10.168.234.4) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 8 Aug 2018 09:50:33 +0200 Subject: Re: The first octet To: Martin Thomson , Kazuho Oku CC: QUIC WG References: From: Message-ID: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> Date: Wed, 8 Aug 2018 09:50:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.4] Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 07:50:38 -0000 Hello Martin, Since you're discussing spin bit allocation variants, maybe it's worth taking a step back: how strong is the "bit pressure" really ? Are we really fighting over the last single bits in an otherwise optimally packed protocol ? Or could the ~70 bytes of a typical ACK-only packet afford an extra byte without endangering polar bears ? The reason I'm asking is I'm wondering about the set of arguments that will be used to decide the final number of "s" bits: - space: it's a sheer coincidence that, at some point, the first byte happened to have three seemingly spare bits, and that the "spin bit + VEC" approach also needs three. Your message seems to indicate that might no longer be the case, since you've got a use case for the spare. - ossification and linkability vs need for measurement: this is the real name of the game, will be discussed in due time. I'm concerned that the second set might somehow be masked by the first one. How about the following alternative: (1) decide how many bits to allocate to measurement, fully focusing on the trade-off between manageability and key QUIC goals above; (2) decide where to fit them, including in a possible extra, hum, byte. What do you think ? On 08/08/18 09:17, Martin Thomson wrote: > Thanks for sharing your perspective Kazuho, I have a slightly > different view, but it's fairly consistent with yours. Reformulating > the second question is good, and I too would like to encrypt this > stuff. It should be easy enough to do so. > > I too like the common form for packet number lengths. I can even see > adding key phase to long header packets for the purposes of > consistency. > > This is my preferred layout for the case we have three bits for spin. > > 1 t t t t p p p > 0 1 s s s p p p > > Where p p p is an encrypted key phase bit and two-bit packet number > length (1,2,3,4). I think that we can afford to have fix tttt values > with no greasing. Allocating four bits and using two of them isn't so > bad. By doing that we can choose types that don't conflict with RTP. > It's not necessary, but it's very cheap. The fixed bit keeps the > short header away from most of the RFC 7983 protocols without costing > much (you had a reserved bit anyway). > > The extra fixed bit here makes QUIC short header packets conflict only > with TURN channels from 7983. That's totally acceptable and fairly > cheap from our perspective. If you are concerned about ossification > of this bit, we could give it to the spin bit(s) and force the people > who want this sort of demux to negotiate the spin bit into a fixed > value if they care to have good demux. > > If we have two fewer bits of spin, that's where things get > interesting. I would prefer to keep the same ppp bits, but leave the > two spare bits unallocated, but encrypted along with ppp. Encrypting > means they can be forced to be zero unless agreed otherwise (MBZ > normally means MUST send zero, MUST ignore non-zero, but I prefer MUST > reject non-zero here): > > 1 t t z z p p p > 0 1 s z z p p p > > The hit here is RTP. We would need all type values so we end up using > 0b10xxxxxx. We can limit the damage by changing codepoints for 0-RTT > and Retry packets, which can be avoided in most scenarios that use RTP > (signaling FTW). > > If we have no spin bits, then we might as well change the single s bit > to a fixed 1. Then we avoid TURN channels as well. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Aug 8 02:39:14 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1887130E1E for ; Wed, 8 Aug 2018 02:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 7wuO-GiZATBr for ; Wed, 8 Aug 2018 02:39:07 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEE8130E1D for ; Wed, 8 Aug 2018 02:39:07 -0700 (PDT) Received: from [81.187.2.149] (port=36287 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fnKvl-0006Dt-9I; Wed, 08 Aug 2018 10:39:05 +0100 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B0CD7D3F-D6C1-4E68-B2FF-30BE27E7DD11" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The first octet Date: Wed, 8 Aug 2018 10:38:58 +0100 In-Reply-To: Cc: quic@ietf.org To: Martin Thomson References: X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 24 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 09:39:11 -0000 --Apple-Mail=_B0CD7D3F-D6C1-4E68-B2FF-30BE27E7DD11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Aug 2018, at 06:55, Martin Thomson = wrote: >=20 > It appears as though we're about to get some information about how > deployable the QUIC invariants are. Ian tells me that Google are most > of the way to deploying a protocol that uses QUIC invariants and > should be able to confirm that this works by the interim. Well, > either that or to be able to tell us what doesn't work, which I'm > hoping isn't a problem we have to deal with. >=20 > I'd like to spend some time at the interim on what we do with the type > bits in the protocol. This email is an attempt to thoroughly cover > the constraints that we have here and attempt to describe a process > that I hope should get us to a conclusion shortly after Bangkok. >=20 > Looking at open design issues, this cluster is the one that is the > biggest threat to our schedule. >=20 > Design Status and Constraints >=20 > Long Header >=20 > The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we > have are currently allocated to the 4 types of long header packet, > using only 252-255. All other values are currently unused. >=20 > With respect to design constraints, there is only one that I'm aware > of and that is a potential collision with RTP (and RTCP) on this octet > (see RFC 7983), which use 0x10xxxxxx (128-191). >=20 > The open question here is what we do with unused types. We might > debate creating a registry for unused values. We might want to grease > values. We could even decide to encrypt these values (though the > design of Retry makes that more difficult, because the contents of > that packet aren't encrypted at all). >=20 > I'm not aware of any plans to use these bits, except perhaps what > might be done to be consistent with the short header changes, so we > might have some latitude here. >=20 > Short Header >=20 > The short header uses the 0b0xxxxxxx pattern (0-127). This is far > more complex and we have a bunch of open questions that will make this > difficult. >=20 > Right now, we use the 0b0K110RRR as the pattern, with K being the key > phase, and RRR being reserved for the spin bit experiment. >=20 > Those fixed bits are (largely) temporary, and might be reclaimed once > existing deployments of Google QUIC (pre-44) are phased out, so I > think that we might want to reclaim some or all of them. >=20 > There is a chance that the reserved bits will also become available > (if not all, then maybe 2 of them). That will be decided in Bangkok, > but we might want to have a plan for those bits. >=20 > The constraints that I am then aware of are these: >=20 > 1. RFC 7983 has the lower half of the first octet fairly densely > populated for demux. Of the protocols there, my understanding of > their relative importance puts STUN (0-4) as fairly critical, if not > mandatory, then TLS (20-63) as optional. ZRTP (16-19) and TURN > channels (64-79) are both apparently unimportant, though each might be > opportunistically accommodated. >=20 > 2. Passive RTT measurement (spin bit) will take 0, 1, or 3 bits. I > suggest that we allow for this, not counting on having any more bits > than N-3, or assuming that only that many bits will be available. >=20 > 3. Kazuho points out that the key phase is a linkability vector. We > might want to consider encrypting that. We could do that by fixing > the packet number key and not updating it after key updates and using > more output from that process to mask the bit (and maybe other bits in > this field). >=20 > 4. I realize that we don't have to put a key phase in every packet if > we are less concerned about being able to update immediately. If we > adopt a scheme to what was proposed in DTLS, then a longer encoding > can be used during the preparation and signaling phase. I'll follow > up with another email on this subject. >=20 > One thing that we could use extra bits for is to move the packet > number size back into this octet. We could even move packet number > bits back, depending on available space. That might make some > difference to the number of bytes we allocate for packet numbers. >=20 > Process >=20 > Given that we don't have answers to some questions we might conclude > several ways. I proposed that we agree on principles, starting with: >=20 > A. What do we want to do with unused bits? Do we want to ensure that > they are always used? Or can they be reserved? If so, how would they > be reserved (fixed values, random values, greasing, etc=E2=80=A6)? I suggest either random or greased somehow, but with a note that = implementations that know they=E2=80=99ll be multiplexing another = protocol on the same port will need to take care to avoid collisions = with that other protocol when doing so. > =E2=80=A6 > E. How should we accommodate multiplexing? For me, the big questions > here are whether we allow for RTP to collide with the long header and > which of the protocols we privilege by avoiding with the short header. I think we have two demultiplexing concerns: in the longer-term how to = do NAT binding discovery for peer-to-peer QUIC, and in the short term = how to demux with RTP, DTLS, etc. As a long term issue, if we want to support peer-to-peer use of QUIC, = then we=E2=80=99ll need a NAT binding discovery protocol. STUN provides = such a mechanism that we could re-use, or we could choose to re-invent a = similar mechanism inside QUIC. I=E2=80=99d prefer not to reinvent the = wheel here, but that=E2=80=99s a decision the group will need to make. If we use STUN, we must ensure it can be de-multiplexed from QUIC. STUN = packets have their first two bits set to 0b00 and bits 32-63 set to the = magic number 0x2112A442. It=E2=80=99s trivial to demultiplex STUN from = QUIC long header and version negotiation packets, since those packets = have their first bit set to 1.=20 To demultiplex STUN and QUIC short header packets, we could change the = invariant for QUIC short header packets to start 0b01. This is the = smallest change needed to guarantee trivial demuxing with STUN, and = doesn=E2=80=99t significantly constrain future evolution of QUIC. = Alternatively, we could specify something based on the STUN magic number = and QUIC DCID, but that seems unnecessarily complex to me. As a short term issue, we also need to consider demuxing with RTP, DTLS, = and so on (I expect that media will run over QUIC in time, so demuxing = with these protocols will gradually become less important).=20 RTP packets have their first two bits set to 0b10, so are simple to = demux with both QUIC short header packets and with the currently defined = QUIC long header packet types. I think this is sufficient, and we can = revisit in future versions of QUIC if we decide to change the QUIC long = header packet types. A DTLS handshake is used to key secure RTP flows, so we also need to = demultiplex DTLS. The RFC 7983 heuristic for this demuxing is that = packets with first octet in the range 20-63 are DTLS. That doesn=E2=80=99t= conflict with QUIC long header packets, or short header packets as = defined in the -13 QUIC drafts, but we=E2=80=99ll need to be careful to = avoid collisions if we rearrange the bits in the short header (the above = suggestion to make short header packets start 0b01 avoids conflicts). RFC 7983 also defines demuxing with TURN and ZRTP. My opinion is that = this is not important, but I accept that others may disagree. Colin --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_B0CD7D3F-D6C1-4E68-B2FF-30BE27E7DD11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 6 Aug 2018, at 06:55, Martin Thomson <martin.thomson@gmail.com> wrote:

It = appears as though we're about to get some information about how
deployable the QUIC invariants are.  Ian tells me that = Google are most
of the way to deploying a protocol that = uses QUIC invariants and
should be able to confirm that = this works by the interim.  Well,
either that or to = be able to tell us what doesn't work, which I'm
hoping = isn't a problem we have to deal with.

I'd = like to spend some time at the interim on what we do with the type
bits in the protocol.  This email is an attempt to = thoroughly cover
the constraints that we have here and = attempt to describe a process
that I hope should get us to = a conclusion shortly after Bangkok.

Looking = at open design issues, this cluster is the one that is the
biggest threat to our schedule.

Design Status and Constraints

Long= Header

The long header uses the 0b1xxxxxxx = pattern (128-255). The 7 bits we
have are currently = allocated to the 4 types of long header packet,
using only = 252-255.  All other values are currently unused.

With respect to design constraints, there is only one that = I'm aware
of and that is a potential collision with RTP = (and RTCP) on this octet
(see RFC 7983), which use = 0x10xxxxxx (128-191).

The open question = here is what we do with unused types.  We might
debate = creating a registry for unused values.  We might want to grease
values.  We could even decide to encrypt these values = (though the
design of Retry makes that more difficult, = because the contents of
that packet aren't encrypted at = all).

I'm not aware of any plans to use = these bits, except perhaps what
might be done to be = consistent with the short header changes, so we
might have = some latitude here.

Short Header

The short header uses the 0b0xxxxxxx pattern = (0-127).  This is far
more complex and we have a = bunch of open questions that will make this
difficult.

Right now, we use the 0b0K110RRR as the = pattern, with K being the key
phase, and RRR being = reserved for the spin bit experiment.

Those = fixed bits are (largely) temporary, and might be reclaimed once
existing deployments of Google QUIC (pre-44) are phased out, = so I
think that we might want to reclaim some or all of = them.

There is a chance that the reserved = bits will also become available
(if not all, then maybe 2 = of them).  That will be decided in Bangkok,
but we = might want to have a plan for those bits.

The= constraints that I am then aware of are these:

1. RFC 7983 has the lower half of the first octet fairly = densely
populated for demux.  Of the protocols there, = my understanding of
their relative importance puts STUN = (0-4) as fairly critical, if not
mandatory, then TLS = (20-63) as optional.  ZRTP (16-19) and TURN
channels = (64-79) are both apparently unimportant, though each might be
opportunistically accommodated.

2.= Passive RTT measurement (spin bit) will take 0, 1, or 3 bits. =  I
suggest that we allow for this, not counting on = having any more bits
than N-3, or assuming that only that = many bits will be available.

3. Kazuho = points out that the key phase is a linkability vector.  We
might want to consider encrypting that.  We could do = that by fixing
the packet number key and not updating it = after key updates and using
more output from that process = to mask the bit (and maybe other bits in
this field).

4. I realize that we don't have to put a key = phase in every packet if
we are less concerned about being = able to update immediately.  If we
adopt a scheme to = what was proposed in DTLS, then a longer encoding
can be = used during the preparation and signaling phase.    I'll = follow
up with another email on this subject.

One thing that we could use extra bits for is = to move the packet
number size back into this octet. =  We could even move packet number
bits back, = depending on available space.  That might make some
difference to the number of bytes we allocate for packet = numbers.

Process

Given that we don't have answers to some questions we might = conclude
several ways.  I proposed that we agree on = principles, starting with:

A. What do we want to do with unused bits? =  Do we want to ensure that
they are always used? =  Or can they be reserved?  If so, how would they
be reserved (fixed values, random values, greasing, = etc=E2=80=A6)?

I= suggest either random or greased somehow, but with a note that = implementations that know they=E2=80=99ll be multiplexing another = protocol on the same port will need to take care to avoid collisions = with that other protocol when doing so.

=E2=80=A6
E. How should we accommodate multiplexing? =  For me, the big questions
here are whether we allow = for RTP to collide with the long header and
which of the = protocols we privilege by avoiding with the short header.

I = think we have two demultiplexing concerns: in the longer-term how to do = NAT binding discovery for peer-to-peer QUIC, and in the short term how = to demux with RTP, DTLS, etc.

As a long term issue, if we want to support peer-to-peer = use of QUIC, then we=E2=80=99ll need a NAT binding discovery protocol. = STUN provides such a mechanism that we could re-use, or we could choose = to re-invent a similar mechanism inside QUIC. I=E2=80=99d prefer not to = reinvent the wheel here, but that=E2=80=99s a decision the group will = need to make.

If we use STUN, we = must ensure it can be de-multiplexed from QUIC. STUN packets have their = first two bits set to 0b00 and bits 32-63 set to the magic number = 0x2112A442. It=E2=80=99s trivial to demultiplex STUN from QUIC long = header and version negotiation packets, since those packets have their = first bit set to 1. 

To = demultiplex STUN and QUIC short header packets, we could change the = invariant for QUIC short header packets to start 0b01. This is the = smallest change needed to guarantee trivial demuxing with STUN, and = doesn=E2=80=99t significantly constrain future evolution of QUIC. = Alternatively, we could specify something based on the STUN magic number = and QUIC DCID, but that seems unnecessarily complex to me.

As a short term issue, we also = need to consider demuxing with RTP, DTLS, and so on (I expect that media = will run over QUIC in time, so demuxing with these protocols will = gradually become less important). 

RTP packets have their first two bits set to 0b10, = so are simple to demux with both QUIC short header packets and with the = currently defined QUIC long header packet types. I think this is = sufficient, and we can revisit in future versions of QUIC if we decide = to change the QUIC long header packet types.

A DTLS handshake is used to key secure RTP flows, = so we also need to demultiplex DTLS. The RFC 7983 heuristic for this = demuxing is that packets with first octet in the range 20-63 are DTLS. = That doesn=E2=80=99t conflict with QUIC long header packets, or short = header packets as defined in the -13 QUIC drafts, but we=E2=80=99ll need = to be careful to avoid collisions if we rearrange the bits in the short = header (the above suggestion to make short header packets start 0b01 = avoids conflicts).

RFC 7983 also = defines demuxing with TURN and ZRTP. My opinion is that this is not = important, but I accept that others may disagree.

Colin






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




= --Apple-Mail=_B0CD7D3F-D6C1-4E68-B2FF-30BE27E7DD11-- From nobody Wed Aug 8 02:51:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DDB130E1A for ; Wed, 8 Aug 2018 02:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiDcMOp9YthG for ; Wed, 8 Aug 2018 02:51:21 -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 30F0D130E1D for ; Wed, 8 Aug 2018 02:51:21 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w126-v6so2672381oie.7 for ; Wed, 08 Aug 2018 02:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I9sQd/HHL10D9MixX3XLitmkgHql909kUe9BaGNNATA=; b=I5vFUl+3VVVDjmbYe7fPRAXWjDPWQvaB2hV2BT4/7Qtcchs2wZE7LplNBufEOniDsy wO7d1nBHDdagpao++wuaurn2+5oe6nAqfhVZHKQJPgJMwwPZxgHe8LJ5UbTNv3t/zJH5 dsUM0xbits+7QIvE04AEeMMGn6T4kBHQqKxmgyYO/wBgQ5I7QEhnUD13ssBVRrqbWboM xvDG83FLAvvHAuDM2Fe53KxIP4VELzlPhgXS0DVHKNBXNrv+uKfjQKcYlOQLND0B4A0s 25uUgd2EaRPsvwQ5a9d8pCvtMgI0vDojJGuvzDxdEzrYCQyA28BbOmOSxDVxRrcnLiPQ GyHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I9sQd/HHL10D9MixX3XLitmkgHql909kUe9BaGNNATA=; b=d1MMA6lf1quq4k3swOqpRxN0NUKugqlMh8bdzD4g00OViuSvumFRDYNhfArJuvUX5X xXH8hvFNXd+jkTFQqXK+pwu7/NjzyG0qjqLcBeyRZvi+pl0084pe/gLDfFAwarcqaXpc oeNJP7Oginz95jRE+teGloWEPR5KoCXjCs2e1FpBWfR5WnamPe5ZAWJ0CW87eo24tQH/ UjfB+8I8k6QcAtnH/vo1dciKJEe+6VMt7cbsjep2AE8pD9mSkzSy+jqe+BG62jsjPlNB nslY8NxuiQz1f7pEsMPZ2yUFA8ztzYSF+md/uNjTTQ/j5TSLF+xprMpXohN1RnWCQk9K CsjA== X-Gm-Message-State: AOUpUlF3RmMYgF3rv9Vjmp/Ql1EGw2NLAbbrCnYsA3B1QYLR2zsyXGUy X/GXAwVTpaydhMpbdlnd97N7q6aE2yewlbXZj6M= X-Google-Smtp-Source: AA+uWPwGMK6h03+bndYMF4zpvtqJIrVnLnkjYk5sYcCED3pEJaw5APdUOETWM4dWpbrrHxa77bzeVoBegTOHrtxM0H8= X-Received: by 2002:aca:5155:: with SMTP id f82-v6mr2338392oib.272.1533721880421; Wed, 08 Aug 2018 02:51:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Wed, 8 Aug 2018 19:51:11 +1000 Message-ID: Subject: Re: The first octet To: Kazuho Oku Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 09:51:23 -0000 On Wed, Aug 8, 2018 at 5:41 PM Kazuho Oku wrote: > My understanding is that we do not avoid conflict in the invariants, > but you suggest to avoid them in v2. v1. Yes, that was the idea. The protocols we're talking about could have the luxury of being able to negotiate versions carefully, and avoid any version that doesn't suit. > For example, is it the case that you think avoiding conflict in the > short term is worthwhile, at the same time keeping the possibility to > change the decision in the future versions of QUIC? That is certainly true. See Colin's response too. He managed to summarize the thinking here fairly well. > Honestly, I do not have a strong opinion here, although I worry about > ossification when we decide not to grease the bits. Therefore, I would > like to understand why you think avoiding conflict in v2 but not in > invariant is worth considering. Yes, the risk exists. We could, for example decide to try to mitigate this risk by choosing something maximally bad for 7983 demux and force folks who want to do that to define a new version, thereby generating two variants in relatively quick succession and pinning our hopes on that helping. I tend to think that things ossify on longer timescales than that and so am willing to risk those bits sticking for this gain. For the short header, it would be exactly one bit. Invariants is part of our protection here. It might turn out to be futile, I don't know. But I would be very happy to define a new variant that set that bit to zero. From nobody Wed Aug 8 03:05:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F7A130E00 for ; Wed, 8 Aug 2018 03:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJDNiJRNHOWc for ; Wed, 8 Aug 2018 03:05:37 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B861B126CB6 for ; Wed, 8 Aug 2018 03:05:37 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id v8-v6so2755034oie.5 for ; Wed, 08 Aug 2018 03:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sR0Iu8jto+vccc0ixsR/ACuxV6Vwb4JjxFTqIsxaIfc=; b=N2KcHwMev0RFZM2jEYFC17F+ZRyi2uI9FMAqIDvh9Ge7fdwn9+A4QKUeilN3Tlk+ez m9HrS/rAI3Wv1XHZBQiLrDs93Nb4AseEhBQJVPU4+6tgtBnPFlDMfmA9i9xkJKUWRJpe qlTxu00Y5d5/LpB1/SuHTA+vL+XFiJmCJe579dQ7dQnXP1KlacIaAtqUjqRBn8PINevR qLoEDY50qZlurpZfmGqUZ9lPabVZmwsRgEL6GjPx94xzHu7Brl52/dMKe3m3dXuIYIf7 3gricgn9+TZT9qubkEHHXjSKtWaL46YKmWTu33NBJSFhGwBm1V3uhES7idge8hK/xb/q aR7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sR0Iu8jto+vccc0ixsR/ACuxV6Vwb4JjxFTqIsxaIfc=; b=N5Zva5oGUAYFjwq5129ZevbHeUT1TW9AwZ8mavOfJ5lslhxx+CTTHtxQhnXh2Pz6Jf C3It+FBhjZDcFgTaSLXgWr1DMnrZMd2uv+RlgwdxxI3nr122LyWGvrA5ph3G3VhGlot5 lkBMY0aMeghfeyu/enbB3LibRo07Q4NvVFtI75kXpeez5bpYSQSTX9+rADa0CCT5Kbgu 0KOAMKDrav1ePq0bb1PSQTxWSJ2ussOotm1RLAHlYrkUHKPl9x1x+bPB6Qf24RIPoldE 2TW4bSlqCPpOZRzRtNeixE+lRGxlttdgz1q0oTRdLxK64TOcY1c4f67YFqpz9cE/2300 4iQQ== X-Gm-Message-State: AOUpUlGwxuPdTJY88uR0PYE2pLglfy/vzGjR/TXbNJUOt3hXu1/o5uBS PzyhrSTcN8fD+I/BrYad/SkeJ74TEQWQruThUl8= X-Google-Smtp-Source: AA+uWPw567YiN3DUttMUn/fsZvQTJ+mV5XoxAB/O+oRZ/mFMnUCd6zVYLIKqAFI90GDbxMwu8b8/47W/Acz5vuG7zDg= X-Received: by 2002:aca:5155:: with SMTP id f82-v6mr2385813oib.272.1533722737041; Wed, 08 Aug 2018 03:05:37 -0700 (PDT) MIME-Version: 1.0 References: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> In-Reply-To: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> From: Martin Thomson Date: Wed, 8 Aug 2018 20:05:28 +1000 Message-ID: Subject: Re: The first octet To: alexandre.ferrieux@orange.com Cc: Kazuho Oku , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 10:05:39 -0000 On Wed, Aug 8, 2018 at 5:50 PM wrote: > Hello Martin, > > Since you're discussing spin bit allocation variants, maybe it's worth taking a > step back: how strong is the "bit pressure" really ? Are we really fighting over > the last single bits in an otherwise optimally packed protocol ? Or could the > ~70 bytes of a typical ACK-only packet afford an extra byte without endangering > polar bears ? > > The reason I'm asking is I'm wondering about the set of arguments that will be > used to decide the final number of "s" bits: > > - space: it's a sheer coincidence that, at some point, the first byte happened > to have three seemingly spare bits, and that the "spin bit + VEC" approach also > needs three. Your message seems to indicate that might no longer be the case, > since you've got a use case for the spare. > > - ossification and linkability vs need for measurement: this is the real name > of the game, will be discussed in due time. > > I'm concerned that the second set might somehow be masked by the first one. > How about the following alternative: (1) decide how many bits to allocate to > measurement, fully focusing on the trade-off between manageability and key QUIC > goals above; (2) decide where to fit them, including in a possible extra, hum, byte. > > What do you think ? We agreed to reserve 3 bits. If we decide not to use those bits, we need to do something with them (octets don't get smaller after all, and an octet used is better safeguarded than one that is not). The intent of this discussion is to prepare for the outcome of the discussion in Bangkok. I know you discussed taking more bits and even bytes, but the case hasn't been made in this working group to my knowledge. I certainly don't think that's justified; it improved fidelity of measurements, but the spin bit appears to be pretty good at that without the extra overheads. And overheads do matter (on that point, your claim of 70 seems overly large, if it's based on ACK encoding in gQUIC, the differences are now significant enough that it might not be representative - my estimation is that you might get as low as 28 octets, plus connection ID size for a typical, unpadded ACK, certainly not more than double that). From nobody Wed Aug 8 06:22:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84C130E4F for ; Wed, 8 Aug 2018 06:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.291 X-Spam-Level: X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK1YJRs3PnkM for ; Wed, 8 Aug 2018 06:22:35 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6576130E7B for ; Wed, 8 Aug 2018 06:22:35 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 41lsWF2fHnz7wKl; Wed, 8 Aug 2018 15:22:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 41lsWF1tfMz2xC0; Wed, 8 Aug 2018 15:22:33 +0200 (CEST) Received: from [10.193.4.89] (10.168.234.4) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 8 Aug 2018 15:22:32 +0200 Subject: Re: The first octet To: Martin Thomson CC: Kazuho Oku , QUIC WG References: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> From: Message-ID: <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.com> Date: Wed, 8 Aug 2018 15:22:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: fr-xx-moderne Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.4] Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 13:22:37 -0000 On 08/08/18 12:05, Martin Thomson wrote: > > I know you discussed taking more bits and even bytes, but the case > hasn't been made in this working group to my knowledge. I certainly > don't think that's justified; it improved fidelity of measurements, > but the spin bit appears to be pretty good at that without the extra > overheads. Fidelity is indeed the criterion to decide 1 (spin bit) vs 3 (spin bit + VEC) for RTT measurements, right. However, measurements also include packet loss, which is typically more widespread than delay in big pipes (which don't have enough RAM to keep a packet for too long at line rate). And spin+VEC do not address packet loss at all, hence our 7-bit spin counter proposal shown in London. I admit that 7 is hefty if you're starting from Christian's songle spin bit ; however: - I assume nobody will emit any doubt about the criticality of non-delay-related (big pipe) loss location. Unless everybody here has perfect networks and ideal reporting, that is. - Stick the spin bit on top of these 7, make that an extra easurement byte and you've got your three spare bits again in the first byte. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Aug 8 06:29:55 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573FA12785F for ; Wed, 8 Aug 2018 06:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 cg3BC557NUnP for ; Wed, 8 Aug 2018 06:29:50 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB961252B7 for ; Wed, 8 Aug 2018 06:29:50 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id r3-v6so1513646ywc.5 for ; Wed, 08 Aug 2018 06:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MWLVhPKh6tWb+avJbhjfKTjXhJdBThFbEhUidoaohT4=; b=reiMfknZaIfzOkEQMU31vp9maE6Z/jMKp5pwTiXwn2BfCgfIjnQGvjzwXVPYJiLxKU g0+s+bKSTD+plcFqcSZc86gdSWP3iLpYJgbJ5EQeiZug8S1jgnFYN2XJN7/qcVd9JhV+ u7Tp8LCFVMMH+yKLLK/fXYoVIvlmfZSqVCMP2yhoKflydJuBxlSbiPMHQQP20rs6yPS9 sWHdkMpDZE7c5L5G4+BIEVSXLk/glqEELU7WBRaUeN74Q9c+EX3HcbEYubh3NKzm8cMB vSBq5SkuH0pkCeiJy1oB9462G4p85kVcE5dVKJ4kFIDVAiDQeMaki5Te+fi5fdseBSlm fslg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MWLVhPKh6tWb+avJbhjfKTjXhJdBThFbEhUidoaohT4=; b=JN6WgBSwni6tZhV6lFdnVERV7xfEz63FmOeyIZ7ozNjviiYLZg5z/piSBJ5PJuwE72 KARCSmduwDGhLWpjKrGZmzK5W6k5oe3745vUQJvfIgEQlMaCaCusqPbpMA7N59Ta79Ad fJWNrQWyAHbdIMblYoCCW0Q5t3q58qcIAMJcWYfhC8absJSUoLqvcEfdqVxKZo9rIyzi FuTF1yBpERMIZtxvigZzxw6ikjf/2nVTsyXquVJjOus1CrqbS/Yc93z2njJ+wuksjl5R zlEiDa71rPU/Q0q6WOfc26/oRC0JMKJ0Xf5Sc/Mwd7/KdVeyJ8kG5MyFLmA1NTEQbup/ LXYA== X-Gm-Message-State: AOUpUlFPyTLXiAuHON8BSr5TeS3ccsP+ZjttN/Gwak/WRdcIcoUsC1PV zSOXKi7bslzoTGc0ZbYCRvCQdMHldeHBIctceXkKiA== X-Google-Smtp-Source: AA+uWPzo2ttWjLNl3qMy4L0//KFzL0lew4w+zSl8j7cdcql2NMcfUZ4JTbIAgFp71MhjVCROx2xzDh80osVEFcZbSPE= X-Received: by 2002:a25:ac8c:: with SMTP id x12-v6mr1429384ybi.43.1533734989653; Wed, 08 Aug 2018 06:29:49 -0700 (PDT) MIME-Version: 1.0 References: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.com> In-Reply-To: <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.com> From: Ian Swett Date: Wed, 8 Aug 2018 09:29:38 -0400 Message-ID: Subject: Re: The first octet To: alexandre.ferrieux@orange.com Cc: Martin Thomson , IETF QUIC WG , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000003db6600572ec8102" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 13:29:53 -0000 --0000000000003db6600572ec8102 Content-Type: text/plain; charset="UTF-8" I'm having a hard time understanding why you'd need 7 bits to measure packet loss(1 seems sufficient in most cases), can you send a link to the spin + VEC and 7 bit proposals you mentioned? I'll also note I think the chances the WG will agree to 7 bits is extremely close to 0, but I'm curious why you'd even want them. On Wed, Aug 8, 2018 at 9:22 AM wrote: > On 08/08/18 12:05, Martin Thomson wrote: > > > > I know you discussed taking more bits and even bytes, but the case > > hasn't been made in this working group to my knowledge. I certainly > > don't think that's justified; it improved fidelity of measurements, > > but the spin bit appears to be pretty good at that without the extra > > overheads. > > Fidelity is indeed the criterion to decide 1 (spin bit) vs 3 (spin bit + > VEC) > for RTT measurements, right. > > However, measurements also include packet loss, which is typically more > widespread than delay in big pipes (which don't have enough RAM to keep a > packet > for too long at line rate). And spin+VEC do not address packet loss at > all, > hence our 7-bit spin counter proposal shown in London. > > I admit that 7 is hefty if you're starting from Christian's songle spin > bit ; > however: > > - I assume nobody will emit any doubt about the criticality of > non-delay-related (big pipe) loss location. Unless everybody here has > perfect > networks and ideal reporting, that is. > > - Stick the spin bit on top of these 7, make that an extra easurement > byte and > you've got your three spare bits again in the first byte. > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > --0000000000003db6600572ec8102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm having a hard time understanding why you'd nee= d 7 bits to measure packet loss(1 seems sufficient in most cases), can you = send a link to the spin=C2=A0+ VEC and 7 bit proposals you mentioned?
<= br>
I'll also note I think the chances the WG will agree to 7= bits is extremely close to 0, but I'm curious why you'd even want = them.

On Wed, Au= g 8, 2018 at 9:22 AM <a= lexandre.ferrieux@orange.com> wrote:
On 08/08/18 12:05, Martin Thomson wrote:
>
> I know you discussed taking more bits and even bytes, but the case
> hasn't been made in this working group to my knowledge.=C2=A0 I ce= rtainly
> don't think that's justified; it improved fidelity of measurem= ents,
> but the spin bit appears to be pretty good at that without the extra > overheads.

Fidelity is indeed the criterion to decide 1 (spin bit) vs 3 (spin bit + VE= C)
for RTT measurements, right.

However, measurements also include packet loss, which is typically more widespread than delay in big pipes (which don't have enough RAM to keep= a packet
for too long at line rate). And spin+VEC do not address packet loss at all,=
hence our 7-bit spin counter proposal shown in London.

I admit that 7 is hefty if you're starting from Christian's songle = spin bit ;
however:

=C2=A0 - I assume nobody will emit any doubt about the criticality of
non-delay-related (big pipe) loss location. Unless everybody here has perfe= ct
networks and ideal reporting, that is.

=C2=A0 - Stick the spin bit on top of these 7, make that an extra easuremen= t byte and
you've got your three spare bits again in the first byte.


___________________________________________________________________________= ______________________________________________

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

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

--0000000000003db6600572ec8102-- From nobody Wed Aug 8 06:42:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9AA12F295 for ; Wed, 8 Aug 2018 06:42: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, 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 xH1F64XKs0Ip for ; Wed, 8 Aug 2018 06:42:12 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138C61252B7 for ; Wed, 8 Aug 2018 06:42:12 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E1A64CD3E9B10 for ; Wed, 8 Aug 2018 14:42:06 +0100 (IST) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 8 Aug 2018 14:42:08 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.158]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0399.000; Wed, 8 Aug 2018 21:42:01 +0800 From: "Roni Even (A)" To: Ian Swett , "alexandre.ferrieux@orange.com" CC: IETF QUIC WG , Martin Thomson , Kazuho Oku Subject: RE: The first octet Thread-Topic: The first octet Thread-Index: AQHULxv+decNTZUJlk6OslajB0gFnKS12iCw Date: Wed, 8 Aug 2018 13:42:00 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8BB1D0@DGGEMM506-MBX.china.huawei.com> References: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.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.143] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8BB1D0DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 13:42:14 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8BB1D0DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KSWYgIGluIHRoZSBmdXR1cmUgdGhlcmUgd2lsbCBiZSBjb25zZW5zdXMgdGhhdCBhbiBl eHRyYSBieXRlIGlzIG5lZWRlZCBpdCBpcyBub3QgcmVsYXRlZCB0byB0aGUgZmlyc3Qgb2N0ZXQg YXMgYW4gaW52YXJpYW50LiAgSXQgZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGUgaW52YXJpYW50 IGRyYWZ0IHNpbmNlIGl0IHdpbGwgYmUgdmVyc2lvbiBkZXBlbmRlbnQsIGl0IG9ubHkgbWVhbnMg dGhhdCBpdCB3aWxsIGhhdmUgdG8gYmUgYWZ0ZXIgdGhlIGludmFyaWFudHMgcGFydHMgb2YgdGhl IHNob3J0IGhlYWRlci4NCg0KUm9uaQ0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSWFuIFN3ZXR0DQpTZW50OiBXZWRuZXNkYXksIEF1Z3Vz dCAwOCwgMjAxOCA0OjMwIFBNDQpUbzogYWxleGFuZHJlLmZlcnJpZXV4QG9yYW5nZS5jb20NCkNj OiBJRVRGIFFVSUMgV0c7IE1hcnRpbiBUaG9tc29uOyBLYXp1aG8gT2t1DQpTdWJqZWN0OiBSZTog VGhlIGZpcnN0IG9jdGV0DQoNCkknbSBoYXZpbmcgYSBoYXJkIHRpbWUgdW5kZXJzdGFuZGluZyB3 aHkgeW91J2QgbmVlZCA3IGJpdHMgdG8gbWVhc3VyZSBwYWNrZXQgbG9zcygxIHNlZW1zIHN1ZmZp Y2llbnQgaW4gbW9zdCBjYXNlcyksIGNhbiB5b3Ugc2VuZCBhIGxpbmsgdG8gdGhlIHNwaW4gKyBW RUMgYW5kIDcgYml0IHByb3Bvc2FscyB5b3UgbWVudGlvbmVkPw0KDQpJJ2xsIGFsc28gbm90ZSBJ IHRoaW5rIHRoZSBjaGFuY2VzIHRoZSBXRyB3aWxsIGFncmVlIHRvIDcgYml0cyBpcyBleHRyZW1l bHkgY2xvc2UgdG8gMCwgYnV0IEknbSBjdXJpb3VzIHdoeSB5b3UnZCBldmVuIHdhbnQgdGhlbS4N Cg0KT24gV2VkLCBBdWcgOCwgMjAxOCBhdCA5OjIyIEFNIDxhbGV4YW5kcmUuZmVycmlldXhAb3Jh bmdlLmNvbTxtYWlsdG86YWxleGFuZHJlLmZlcnJpZXV4QG9yYW5nZS5jb20+PiB3cm90ZToNCk9u IDA4LzA4LzE4IDEyOjA1LCBNYXJ0aW4gVGhvbXNvbiB3cm90ZToNCj4NCj4gSSBrbm93IHlvdSBk aXNjdXNzZWQgdGFraW5nIG1vcmUgYml0cyBhbmQgZXZlbiBieXRlcywgYnV0IHRoZSBjYXNlDQo+ IGhhc24ndCBiZWVuIG1hZGUgaW4gdGhpcyB3b3JraW5nIGdyb3VwIHRvIG15IGtub3dsZWRnZS4g IEkgY2VydGFpbmx5DQo+IGRvbid0IHRoaW5rIHRoYXQncyBqdXN0aWZpZWQ7IGl0IGltcHJvdmVk IGZpZGVsaXR5IG9mIG1lYXN1cmVtZW50cywNCj4gYnV0IHRoZSBzcGluIGJpdCBhcHBlYXJzIHRv IGJlIHByZXR0eSBnb29kIGF0IHRoYXQgd2l0aG91dCB0aGUgZXh0cmENCj4gb3ZlcmhlYWRzLg0K DQpGaWRlbGl0eSBpcyBpbmRlZWQgdGhlIGNyaXRlcmlvbiB0byBkZWNpZGUgMSAoc3BpbiBiaXQp IHZzIDMgKHNwaW4gYml0ICsgVkVDKQ0KZm9yIFJUVCBtZWFzdXJlbWVudHMsIHJpZ2h0Lg0KDQpI b3dldmVyLCBtZWFzdXJlbWVudHMgYWxzbyBpbmNsdWRlIHBhY2tldCBsb3NzLCB3aGljaCBpcyB0 eXBpY2FsbHkgbW9yZQ0Kd2lkZXNwcmVhZCB0aGFuIGRlbGF5IGluIGJpZyBwaXBlcyAod2hpY2gg ZG9uJ3QgaGF2ZSBlbm91Z2ggUkFNIHRvIGtlZXAgYSBwYWNrZXQNCmZvciB0b28gbG9uZyBhdCBs aW5lIHJhdGUpLiBBbmQgc3BpbitWRUMgZG8gbm90IGFkZHJlc3MgcGFja2V0IGxvc3MgYXQgYWxs LA0KaGVuY2Ugb3VyIDctYml0IHNwaW4gY291bnRlciBwcm9wb3NhbCBzaG93biBpbiBMb25kb24u DQoNCkkgYWRtaXQgdGhhdCA3IGlzIGhlZnR5IGlmIHlvdSdyZSBzdGFydGluZyBmcm9tIENocmlz dGlhbidzIHNvbmdsZSBzcGluIGJpdCA7DQpob3dldmVyOg0KDQogIC0gSSBhc3N1bWUgbm9ib2R5 IHdpbGwgZW1pdCBhbnkgZG91YnQgYWJvdXQgdGhlIGNyaXRpY2FsaXR5IG9mDQpub24tZGVsYXkt cmVsYXRlZCAoYmlnIHBpcGUpIGxvc3MgbG9jYXRpb24uIFVubGVzcyBldmVyeWJvZHkgaGVyZSBo YXMgcGVyZmVjdA0KbmV0d29ya3MgYW5kIGlkZWFsIHJlcG9ydGluZywgdGhhdCBpcy4NCg0KICAt IFN0aWNrIHRoZSBzcGluIGJpdCBvbiB0b3Agb2YgdGhlc2UgNywgbWFrZSB0aGF0IGFuIGV4dHJh IGVhc3VyZW1lbnQgYnl0ZSBhbmQNCnlvdSd2ZSBnb3QgeW91ciB0aHJlZSBzcGFyZSBiaXRzIGFn YWluIGluIHRoZSBmaXJzdCBieXRlLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwN Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3Uu DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD8BB1D0DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsxPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JZiAmbmJzcDtpbiB0aGUgZnV0dXJlIHRoZXJlIHdpbGwgYmUgY29uc2Vuc3VzIHRoYXQgYW4g ZXh0cmEgYnl0ZSBpcyBuZWVkZWQgaXQgaXMgbm90IHJlbGF0ZWQgdG8gdGhlIGZpcnN0IG9jdGV0 IGFzIGFuIGludmFyaWFudC4gJm5ic3A7SXQgZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGUNCiBp bnZhcmlhbnQgZHJhZnQgc2luY2UgaXQgd2lsbCBiZSB2ZXJzaW9uIGRlcGVuZGVudCwgaXQgb25s eSBtZWFucyB0aGF0IGl0IHdpbGwgaGF2ZSB0byBiZSBhZnRlciB0aGUgaW52YXJpYW50cyBwYXJ0 cyBvZiB0aGUgc2hvcnQgaGVhZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9uaTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgQXVndXN0IDA4LCAyMDE4IDQ6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IGFsZXhhbmRyZS5m ZXJyaWV1eEBvcmFuZ2UuY29tPGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0c7IE1hcnRpbiBU aG9tc29uOyBLYXp1aG8gT2t1PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBUaGUgZmlyc3Qgb2N0 ZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gaGF2aW5nIGEgaGFy ZCB0aW1lIHVuZGVyc3RhbmRpbmcgd2h5IHlvdSdkIG5lZWQgNyBiaXRzIHRvIG1lYXN1cmUgcGFj a2V0IGxvc3MoMSBzZWVtcyBzdWZmaWNpZW50IGluIG1vc3QgY2FzZXMpLCBjYW4geW91IHNlbmQg YSBsaW5rIHRvIHRoZSBzcGluJm5ic3A7JiM0MzsgVkVDIGFuZCA3IGJpdCBwcm9wb3NhbHMgeW91 IG1lbnRpb25lZD88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkknbGwgYWxzbyBub3RlIEkgdGhpbmsgdGhlIGNoYW5jZXMgdGhlIFdHIHdpbGwgYWdyZWUgdG8g NyBiaXRzIGlzIGV4dHJlbWVseSBjbG9zZSB0byAwLCBidXQgSSdtIGN1cmlvdXMgd2h5IHlvdSdk IGV2ZW4gd2FudCB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyA4LCAyMDE4IGF0IDk6MjIgQU0gJmx0OzxhIGhyZWY9 Im1haWx0bzphbGV4YW5kcmUuZmVycmlldXhAb3JhbmdlLmNvbSI+YWxleGFuZHJlLmZlcnJpZXV4 QG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ T24gMDgvMDgvMTggMTI6MDUsIE1hcnRpbiBUaG9tc29uIHdyb3RlOjxicj4NCiZndDsgPGJyPg0K Jmd0OyBJIGtub3cgeW91IGRpc2N1c3NlZCB0YWtpbmcgbW9yZSBiaXRzIGFuZCBldmVuIGJ5dGVz LCBidXQgdGhlIGNhc2U8YnI+DQomZ3Q7IGhhc24ndCBiZWVuIG1hZGUgaW4gdGhpcyB3b3JraW5n IGdyb3VwIHRvIG15IGtub3dsZWRnZS4mbmJzcDsgSSBjZXJ0YWlubHk8YnI+DQomZ3Q7IGRvbid0 IHRoaW5rIHRoYXQncyBqdXN0aWZpZWQ7IGl0IGltcHJvdmVkIGZpZGVsaXR5IG9mIG1lYXN1cmVt ZW50cyw8YnI+DQomZ3Q7IGJ1dCB0aGUgc3BpbiBiaXQgYXBwZWFycyB0byBiZSBwcmV0dHkgZ29v ZCBhdCB0aGF0IHdpdGhvdXQgdGhlIGV4dHJhPGJyPg0KJmd0OyBvdmVyaGVhZHMuPGJyPg0KPGJy Pg0KRmlkZWxpdHkgaXMgaW5kZWVkIHRoZSBjcml0ZXJpb24gdG8gZGVjaWRlIDEgKHNwaW4gYml0 KSB2cyAzIChzcGluIGJpdCAmIzQzOyBWRUMpIDxicj4NCmZvciBSVFQgbWVhc3VyZW1lbnRzLCBy aWdodC48YnI+DQo8YnI+DQpIb3dldmVyLCBtZWFzdXJlbWVudHMgYWxzbyBpbmNsdWRlIHBhY2tl dCBsb3NzLCB3aGljaCBpcyB0eXBpY2FsbHkgbW9yZSA8YnI+DQp3aWRlc3ByZWFkIHRoYW4gZGVs YXkgaW4gYmlnIHBpcGVzICh3aGljaCBkb24ndCBoYXZlIGVub3VnaCBSQU0gdG8ga2VlcCBhIHBh Y2tldCA8YnI+DQpmb3IgdG9vIGxvbmcgYXQgbGluZSByYXRlKS4gQW5kIHNwaW4mIzQzO1ZFQyBk byBub3QgYWRkcmVzcyBwYWNrZXQgbG9zcyBhdCBhbGwsIDxicj4NCmhlbmNlIG91ciA3LWJpdCBz cGluIGNvdW50ZXIgcHJvcG9zYWwgc2hvd24gaW4gTG9uZG9uLjxicj4NCjxicj4NCkkgYWRtaXQg dGhhdCA3IGlzIGhlZnR5IGlmIHlvdSdyZSBzdGFydGluZyBmcm9tIENocmlzdGlhbidzIHNvbmds ZSBzcGluIGJpdCA7IDxicj4NCmhvd2V2ZXI6PGJyPg0KPGJyPg0KJm5ic3A7IC0gSSBhc3N1bWUg bm9ib2R5IHdpbGwgZW1pdCBhbnkgZG91YnQgYWJvdXQgdGhlIGNyaXRpY2FsaXR5IG9mIDxicj4N Cm5vbi1kZWxheS1yZWxhdGVkIChiaWcgcGlwZSkgbG9zcyBsb2NhdGlvbi4gVW5sZXNzIGV2ZXJ5 Ym9keSBoZXJlIGhhcyBwZXJmZWN0IDxicj4NCm5ldHdvcmtzIGFuZCBpZGVhbCByZXBvcnRpbmcs IHRoYXQgaXMuPGJyPg0KPGJyPg0KJm5ic3A7IC0gU3RpY2sgdGhlIHNwaW4gYml0IG9uIHRvcCBv ZiB0aGVzZSA3LCBtYWtlIHRoYXQgYW4gZXh0cmEgZWFzdXJlbWVudCBieXRlIGFuZCA8YnI+DQp5 b3UndmUgZ290IHlvdXIgdGhyZWUgc3BhcmUgYml0cyBhZ2FpbiBpbiB0aGUgZmlyc3QgYnl0ZS48 YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPGJyPg0KcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8YnI+DQph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLDxicj4NCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48YnI+DQo8YnI+DQpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozxi cj4NCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLjxicj4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC48YnI+DQpUaGFuayB5b3UuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E58094ECC8D8344914996DAD28F1CCD8BB1D0DGGEMM506MBXchina_-- From nobody Wed Aug 8 06:44:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FE812F1A2 for ; Wed, 8 Aug 2018 06:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.291 X-Spam-Level: X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2U_e_Rjupqv for ; Wed, 8 Aug 2018 06:44:24 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C6F1252B7 for ; Wed, 8 Aug 2018 06:44:24 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 41lt0R3dJyz11cr; Wed, 8 Aug 2018 15:44:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 41lt0R2PLMzDq7N; Wed, 8 Aug 2018 15:44:23 +0200 (CEST) Received: from [10.193.4.89] (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 8 Aug 2018 15:44:22 +0200 Subject: Re: The first octet To: Ian Swett CC: Martin Thomson , IETF QUIC WG , Kazuho Oku References: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.com> From: Message-ID: <24749_1533735863_5B6AF3B7_24749_220_1_604c6e2a-2ded-ed00-3089-3e4db36996a6@orange.com> Date: Wed, 8 Aug 2018 15:44:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: fr-xx-moderne Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.168.234.6] Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 13:44:27 -0000 Sure: - spin+VEC are documented in draft-trammel-spin-03 - 7 bits for packet loss were presented at http://snaggletooth.akam.ai/IETF-101-HotRFC/10-Ferrieux.pdf Re "I'm curious why you'd even want them": please clarify which applies: (a) you recognize the criticality of loss location, but you have a clever= er=20 algorithm to do the same with fewer than 7 bits (b) you don't believe network operators need to locate losses On 08/08/18 15:29, Ian Swett wrote: > I'm having a hard time understanding why you'd need 7 bits to measure pac= ket=20 > loss(1 seems sufficient in most cases), can you send a link to the spin= =C2=A0+ VEC=20 > and 7 bit proposals you mentioned? >=20 > I'll also note I think the chances the WG will agree to 7 bits is extreme= ly=20 > close to 0, but I'm curious why you'd even want them. >=20 > On Wed, Aug 8, 2018 at 9:22 AM > wrote: >=20 > On 08/08/18 12:05, Martin Thomson wrote: > > > > I know you discussed taking more bits and even bytes, but the case > > hasn't been made in this working group to my knowledge.=C2=A0 I ce= rtainly > > don't think that's justified; it improved fidelity of measurements, > > but the spin bit appears to be pretty good at that without the ext= ra > > overheads. >=20 > Fidelity is indeed the criterion to decide 1 (spin bit) vs 3 (spin bi= t + VEC) > for RTT measurements, right. >=20 > However, measurements also include packet loss, which is typically mo= re > widespread than delay in big pipes (which don't have enough RAM to ke= ep a > packet > for too long at line rate). And spin+VEC do not address packet loss a= t all, > hence our 7-bit spin counter proposal shown in London. >=20 > I admit that 7 is hefty if you're starting from Christian's songle sp= in bit ; > however: >=20 > =C2=A0 - I assume nobody will emit any doubt about the criticality of > non-delay-related (big pipe) loss location. Unless everybody here has= perfect > networks and ideal reporting, that is. >=20 > =C2=A0 - Stick the spin bit on top of these 7, make that an extra ea= surement > byte and > you've got your three spare bits again in the first byte. >=20 >=20 > _____________________________________________________________________= ____________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messa= ges > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, defor= me ou > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileg= ed > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have= been > modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Aug 8 06:55:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261D3130DF5 for ; Wed, 8 Aug 2018 06:54:52 -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, 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 fuD3Hjmffo5l for ; Wed, 8 Aug 2018 06:54:49 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA5F130E42 for ; Wed, 8 Aug 2018 06:54:49 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 41A5BEE55B0E2 for ; Wed, 8 Aug 2018 14:54:45 +0100 (IST) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 8 Aug 2018 14:54:47 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.158]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0399.000; Wed, 8 Aug 2018 21:54:43 +0800 From: "Roni Even (A)" To: "alexandre.ferrieux@orange.com" , Ian Swett CC: IETF QUIC WG , Martin Thomson , Kazuho Oku Subject: RE: The first octet Thread-Topic: The first octet Thread-Index: AQHULx3odecNTZUJlk6OslajB0gFnKS13iXg Date: Wed, 8 Aug 2018 13:54:43 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8BB1FD@DGGEMM506-MBX.china.huawei.com> References: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.com> <24749_1533735863_5B6AF3B7_24749_220_1_604c6e2a-2ded-ed00-3089-3e4db36996a6@orange.com> In-Reply-To: <24749_1533735863_5B6AF3B7_24749_220_1_604c6e2a-2ded-ed00-3089-3e4db36996a6@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 13:55:00 -0000 SGksDQpJbiBMb25kb24gdGhlIHNwaW4gYml0IGFuZCBWRUMgd2VyZSBub3QgZGlzY3Vzc2VkIGlu IHRoZSBzZXNzaW9uLCBteSB0YWtlIGZyb20gdGhlIG9mZmxpbmUgZGlzY3Vzc2lvbnMgd2UgaGFk IHdhcyB0aGF0IGN1cnJlbnRseSB3ZSBleHBlcmltZW50ZWQgd2l0aCBnb29kIHJlc3VsdHMgb25s eSB0aGUgc3BpbiBiaXQuIEl0IGFsc28gc2VlbWVkIHRoYXQgdGhlIGN1cnJlbnQgVkVDIGFzIHBy b3Bvc2VkIGluIEJyaWFucydzIGRyYWZ0IGlzIG5vdCBnb29kIGVub3VnaCBhbmQgd2UgaW50ZW5k IHRvIGxvb2sgYXQgb3RoZXIgYWxnb3JpdGhtcyB0aGF0IHdpbGwgcHJvdmlkZSBiZXR0ZXIgcmVz dWx0cyBmb3IgcGFja2V0IGxvc3MgdXNpbmcgdGhlIDIgYml0cy4NCkkgdGhpbmsgdGhhdCB0aGlz IGRpc2N1c3Npb24gaXMgcHJlIG1hdHVyZSBhbmQgdGhhdCBpdCBzaG91bGQgYmUgZGlzY3Vzc2Vk IGluIHRoZSBmdXR1cmUNClJvbmkgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgYWxleGFu ZHJlLmZlcnJpZXV4QG9yYW5nZS5jb20NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA4LCAyMDE4 IDQ6NDQgUE0NClRvOiBJYW4gU3dldHQNCkNjOiBJRVRGIFFVSUMgV0c7IE1hcnRpbiBUaG9tc29u OyBLYXp1aG8gT2t1DQpTdWJqZWN0OiBSZTogVGhlIGZpcnN0IG9jdGV0DQoNClN1cmU6DQoNCiAg LSBzcGluK1ZFQyBhcmUgZG9jdW1lbnRlZCBpbiBkcmFmdC10cmFtbWVsLXNwaW4tMDMNCg0KICAt IDcgYml0cyBmb3IgcGFja2V0IGxvc3Mgd2VyZSBwcmVzZW50ZWQgYXQNCiAgICAgIGh0dHA6Ly9z bmFnZ2xldG9vdGguYWthbS5haS9JRVRGLTEwMS1Ib3RSRkMvMTAtRmVycmlldXgucGRmDQoNClJl ICJJJ20gY3VyaW91cyB3aHkgeW91J2QgZXZlbiB3YW50IHRoZW0iOiBwbGVhc2UgY2xhcmlmeSB3 aGljaCBhcHBsaWVzOg0KDQogIChhKSB5b3UgcmVjb2duaXplIHRoZSBjcml0aWNhbGl0eSBvZiBs b3NzIGxvY2F0aW9uLCBidXQgeW91IGhhdmUgYSBjbGV2ZXJlciBhbGdvcml0aG0gdG8gZG8gdGhl IHNhbWUgd2l0aCBmZXdlciB0aGFuIDcgYml0cw0KDQogIChiKSB5b3UgZG9uJ3QgYmVsaWV2ZSBu ZXR3b3JrIG9wZXJhdG9ycyBuZWVkIHRvIGxvY2F0ZSBsb3NzZXMNCg0KDQpPbiAwOC8wOC8xOCAx NToyOSwgSWFuIFN3ZXR0IHdyb3RlOg0KPiBJJ20gaGF2aW5nIGEgaGFyZCB0aW1lIHVuZGVyc3Rh bmRpbmcgd2h5IHlvdSdkIG5lZWQgNyBiaXRzIHRvIG1lYXN1cmUgDQo+IHBhY2tldA0KPiBsb3Nz KDEgc2VlbXMgc3VmZmljaWVudCBpbiBtb3N0IGNhc2VzKSwgY2FuIHlvdSBzZW5kIGEgbGluayB0 byB0aGUgDQo+IHNwaW7CoCsgVkVDIGFuZCA3IGJpdCBwcm9wb3NhbHMgeW91IG1lbnRpb25lZD8N Cj4gDQo+IEknbGwgYWxzbyBub3RlIEkgdGhpbmsgdGhlIGNoYW5jZXMgdGhlIFdHIHdpbGwgYWdy ZWUgdG8gNyBiaXRzIGlzIA0KPiBleHRyZW1lbHkgY2xvc2UgdG8gMCwgYnV0IEknbSBjdXJpb3Vz IHdoeSB5b3UnZCBldmVuIHdhbnQgdGhlbS4NCj4gDQo+IE9uIFdlZCwgQXVnIDgsIDIwMTggYXQg OToyMiBBTSA8YWxleGFuZHJlLmZlcnJpZXV4QG9yYW5nZS5jb20gDQo+IDxtYWlsdG86YWxleGFu ZHJlLmZlcnJpZXV4QG9yYW5nZS5jb20+PiB3cm90ZToNCj4gDQo+ICAgICBPbiAwOC8wOC8xOCAx MjowNSwgTWFydGluIFRob21zb24gd3JvdGU6DQo+ICAgICAgPg0KPiAgICAgID4gSSBrbm93IHlv dSBkaXNjdXNzZWQgdGFraW5nIG1vcmUgYml0cyBhbmQgZXZlbiBieXRlcywgYnV0IHRoZSBjYXNl DQo+ICAgICAgPiBoYXNuJ3QgYmVlbiBtYWRlIGluIHRoaXMgd29ya2luZyBncm91cCB0byBteSBr bm93bGVkZ2UuwqAgSSBjZXJ0YWlubHkNCj4gICAgICA+IGRvbid0IHRoaW5rIHRoYXQncyBqdXN0 aWZpZWQ7IGl0IGltcHJvdmVkIGZpZGVsaXR5IG9mIG1lYXN1cmVtZW50cywNCj4gICAgICA+IGJ1 dCB0aGUgc3BpbiBiaXQgYXBwZWFycyB0byBiZSBwcmV0dHkgZ29vZCBhdCB0aGF0IHdpdGhvdXQg dGhlIGV4dHJhDQo+ICAgICAgPiBvdmVyaGVhZHMuDQo+IA0KPiAgICAgRmlkZWxpdHkgaXMgaW5k ZWVkIHRoZSBjcml0ZXJpb24gdG8gZGVjaWRlIDEgKHNwaW4gYml0KSB2cyAzIChzcGluIGJpdCAr IFZFQykNCj4gICAgIGZvciBSVFQgbWVhc3VyZW1lbnRzLCByaWdodC4NCj4gDQo+ICAgICBIb3dl dmVyLCBtZWFzdXJlbWVudHMgYWxzbyBpbmNsdWRlIHBhY2tldCBsb3NzLCB3aGljaCBpcyB0eXBp Y2FsbHkgbW9yZQ0KPiAgICAgd2lkZXNwcmVhZCB0aGFuIGRlbGF5IGluIGJpZyBwaXBlcyAod2hp Y2ggZG9uJ3QgaGF2ZSBlbm91Z2ggUkFNIHRvIGtlZXAgYQ0KPiAgICAgcGFja2V0DQo+ICAgICBm b3IgdG9vIGxvbmcgYXQgbGluZSByYXRlKS4gQW5kIHNwaW4rVkVDIGRvIG5vdCBhZGRyZXNzIHBh Y2tldCBsb3NzIGF0IGFsbCwNCj4gICAgIGhlbmNlIG91ciA3LWJpdCBzcGluIGNvdW50ZXIgcHJv cG9zYWwgc2hvd24gaW4gTG9uZG9uLg0KPiANCj4gICAgIEkgYWRtaXQgdGhhdCA3IGlzIGhlZnR5 IGlmIHlvdSdyZSBzdGFydGluZyBmcm9tIENocmlzdGlhbidzIHNvbmdsZSBzcGluIGJpdCA7DQo+ ICAgICBob3dldmVyOg0KPiANCj4gICAgICDCoCAtIEkgYXNzdW1lIG5vYm9keSB3aWxsIGVtaXQg YW55IGRvdWJ0IGFib3V0IHRoZSBjcml0aWNhbGl0eSBvZg0KPiAgICAgbm9uLWRlbGF5LXJlbGF0 ZWQgKGJpZyBwaXBlKSBsb3NzIGxvY2F0aW9uLiBVbmxlc3MgZXZlcnlib2R5IGhlcmUgaGFzIHBl cmZlY3QNCj4gICAgIG5ldHdvcmtzIGFuZCBpZGVhbCByZXBvcnRpbmcsIHRoYXQgaXMuDQo+IA0K PiAgICAgIMKgIC0gU3RpY2sgdGhlIHNwaW4gYml0IG9uIHRvcCBvZiB0aGVzZSA3LCBtYWtlIHRo YXQgYW4gZXh0cmEgZWFzdXJlbWVudA0KPiAgICAgYnl0ZSBhbmQNCj4gICAgIHlvdSd2ZSBnb3Qg eW91ciB0aHJlZSBzcGFyZSBiaXRzIGFnYWluIGluIHRoZSBmaXJzdCBieXRlLg0KPiANCj4gDQo+ ICAgICANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gDQo+ICAgICBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gICAgIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+ICAgICBwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UNCj4gICAgIGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXINCj4gICAgIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KPiAgICAgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiAgICAgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UNCj4gICAg IGZhbHNpZmllLiBNZXJjaS4NCj4gDQo+ICAgICBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KPiAgICAgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCj4gICAgIHRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0K PiAgICAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZA0KPiAgICAgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzLg0KPiAgICAgQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4NCj4gICAgIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4NCj4gICAgIFRoYW5rIHlvdS4NCj4gDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQpUaGFuayB5b3UuDQoNCg== From nobody Wed Aug 8 06:57:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76375130DC0 for ; Wed, 8 Aug 2018 06:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 1wX5tPv_OEpI for ; Wed, 8 Aug 2018 06:57:23 -0700 (PDT) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3DF12F1A6 for ; Wed, 8 Aug 2018 06:57:23 -0700 (PDT) Received: by mail-yw1-xc31.google.com with SMTP id z143-v6so1575175ywa.7 for ; Wed, 08 Aug 2018 06:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AMbmLfoGp3DocVksAWoIVW+y6M5RxMP3p/4ihr+hn64=; b=ogzIXL0V5lEk+h/yiEm2Ha/AC7KOb1/E40qSwJCnMJ7QIq+5apOLiYDFZiHew/dKHm h7ZK1PN4o5tOyylg8cPNnD06dZqtt3PNd66tN3wtaUP30bJhydpLFnW8cFWIoYtt6Ayr lEkzNBOLase1fGKzY5vN1A/m2Xz4FKFjqusXuy9sPwMN6JUisnY2tCZURjiz9IKBo6We ueu2WWga8jpojsAsFG4K0gWEI+Qfi8lcaQzBwcJ4nvmHEXhjxlcVzBnEts9AK7Jz+l1t 211zXJrPVCNqiPoDNuZFD1T+OPvKyq7N++6qFkIOQ5Tg/Vgo19HuhJi5iU2uLnUUDSV9 4weg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AMbmLfoGp3DocVksAWoIVW+y6M5RxMP3p/4ihr+hn64=; b=F/LDhq5MpVU/YPz4lzZDPwKvrlYVbrbzW/nFsdKCzRJmlGTPNJF2zGGlnaGoo0iFVy Zveqq2utoN1Pa7LFa1d1NKZbiHV6aAxWwRpkF0j0apb3dOjdsoD5y6D6CYV2dtRox7I+ 1scfpQq4W8/Q3EvtjdoCmrnsb6MSuv32aqDeb63lEYpq4NuZGftdBrh8WJ44qghBZxfB uW6hs6pHm/Z/GncDk81qlfHXEYPIESydXGsrAL2GGiWeuzzxipqbLf8M3M0QxN3IBWUK fLyhBcwEUJwqRw/NX2z9ivwwHM4iAQaHrAfKRY5PlC6NJ8tjHXrykqIY8OxOsvQ7htdk tS9A== X-Gm-Message-State: AOUpUlFSWP8yj69pbeAhEGrcSpQGBvojUamk0QLPXrJarEPNEwIXXe+q hxacolvxt49hz/m9gtnidLW+CC4i/EwLfplBo98XHjeSeeA= X-Google-Smtp-Source: AA+uWPzFzR/sN1pvo0u7LNCLUWqnjZM1HAlHpNL3H+ITLjBVye5SwTEEY2Sd0fqAKZq2pwEK4qGYq5Lnn6dEem0ALio= X-Received: by 2002:a81:5a42:: with SMTP id o63-v6mr1544995ywb.148.1533736642161; Wed, 08 Aug 2018 06:57:22 -0700 (PDT) MIME-Version: 1.0 References: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.com> <24749_1533735863_5B6AF3B7_24749_220_1_604c6e2a-2ded-ed00-3089-3e4db36996a6@orange.com> <6E58094ECC8D8344914996DAD28F1CCD8BB1FD@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8BB1FD@DGGEMM506-MBX.china.huawei.com> From: Ian Swett Date: Wed, 8 Aug 2018 09:56:52 -0400 Message-ID: Subject: Re: The first octet To: Roni Even Cc: alexandre.ferrieux@orange.com, IETF QUIC WG , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000bd03c00572ece31a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 13:57:26 -0000 --000000000000bd03c00572ece31a Content-Type: text/plain; charset="UTF-8" Thanks Roni, agreed, let's focus on the issues Martin raised. On Wed, Aug 8, 2018 at 9:55 AM Roni Even (A) wrote: > Hi, > In London the spin bit and VEC were not discussed in the session, my take > from the offline discussions we had was that currently we experimented with > good results only the spin bit. It also seemed that the current VEC as > proposed in Brians's draft is not good enough and we intend to look at > other algorithms that will provide better results for packet loss using the > 2 bits. > I think that this discussion is pre mature and that it should be discussed > in the future > Roni > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of > alexandre.ferrieux@orange.com > Sent: Wednesday, August 08, 2018 4:44 PM > To: Ian Swett > Cc: IETF QUIC WG; Martin Thomson; Kazuho Oku > Subject: Re: The first octet > > Sure: > > - spin+VEC are documented in draft-trammel-spin-03 > > - 7 bits for packet loss were presented at > http://snaggletooth.akam.ai/IETF-101-HotRFC/10-Ferrieux.pdf > > Re "I'm curious why you'd even want them": please clarify which applies: > > (a) you recognize the criticality of loss location, but you have a > cleverer algorithm to do the same with fewer than 7 bits > > (b) you don't believe network operators need to locate losses > > > On 08/08/18 15:29, Ian Swett wrote: > > I'm having a hard time understanding why you'd need 7 bits to measure > > packet > > loss(1 seems sufficient in most cases), can you send a link to the > > spin + VEC and 7 bit proposals you mentioned? > > > > I'll also note I think the chances the WG will agree to 7 bits is > > extremely close to 0, but I'm curious why you'd even want them. > > > > On Wed, Aug 8, 2018 at 9:22 AM > > wrote: > > > > On 08/08/18 12:05, Martin Thomson wrote: > > > > > > I know you discussed taking more bits and even bytes, but the case > > > hasn't been made in this working group to my knowledge. I > certainly > > > don't think that's justified; it improved fidelity of > measurements, > > > but the spin bit appears to be pretty good at that without the > extra > > > overheads. > > > > Fidelity is indeed the criterion to decide 1 (spin bit) vs 3 (spin > bit + VEC) > > for RTT measurements, right. > > > > However, measurements also include packet loss, which is typically > more > > widespread than delay in big pipes (which don't have enough RAM to > keep a > > packet > > for too long at line rate). And spin+VEC do not address packet loss > at all, > > hence our 7-bit spin counter proposal shown in London. > > > > I admit that 7 is hefty if you're starting from Christian's songle > spin bit ; > > however: > > > > - I assume nobody will emit any doubt about the criticality of > > non-delay-related (big pipe) loss location. Unless everybody here > has perfect > > networks and ideal reporting, that is. > > > > - Stick the spin bit on top of these 7, make that an extra > easurement > > byte and > > you've got your three spare bits again in the first byte. > > > > > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu > > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages > > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > deforme ou > > falsifie. Merci. > > > > This message and its attachments may contain confidential or > privileged > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > have been > > modified, changed or falsified. > > Thank you. > > > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > --000000000000bd03c00572ece31a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Roni, agreed, let's focus on the issues Martin = raised.

On Wed, Au= g 8, 2018 at 9:55 AM Roni Even (A) <roni.even@huawei.com> wrote:
Hi,
In London the spin bit and VEC were not discussed in the session, my take f= rom the offline discussions we had was that currently we experimented with = good results only the spin bit. It also seemed that the current VEC as prop= osed in Brians's draft is not good enough and we intend to look at othe= r algorithms that will provide better results for packet loss using the 2 b= its.
I think that this discussion is pre mature and that it should be discussed = in the future
Roni

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of alexandre.ferrieux@orange.com
Sent: Wednesday, August 08, 2018 4:44 PM
To: Ian Swett
Cc: IETF QUIC WG; Martin Thomson; Kazuho Oku
Subject: Re: The first octet

Sure:

=C2=A0 - spin+VEC are documented in draft-trammel-spin-03

=C2=A0 - 7 bits for packet loss were presented at
=C2=A0 =C2=A0 =C2=A0 http://snaggletooth.= akam.ai/IETF-101-HotRFC/10-Ferrieux.pdf

Re "I'm curious why you'd even want them": please clarify= which applies:

=C2=A0 (a) you recognize the criticality of loss location, but you have a c= leverer algorithm to do the same with fewer than 7 bits

=C2=A0 (b) you don't believe network operators need to locate losses

On 08/08/18 15:29, Ian Swett wrote:
> I'm having a hard time understanding why you'd need 7 bits to = measure
> packet
> loss(1 seems sufficient in most cases), can you send a link to the > spin=C2=A0+ VEC and 7 bit proposals you mentioned?
>
> I'll also note I think the chances the WG will agree to 7 bits is =
> extremely close to 0, but I'm curious why you'd even want them= .
>
> On Wed, Aug 8, 2018 at 9:22 AM <alexandre.ferrieux@orange.com
> <mailto:alexandre.ferrieux@orange.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 08/08/18 12:05, Martin Thomson wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I know you discussed taking more bits and eve= n bytes, but the case
>=C2=A0 =C2=A0 =C2=A0 > hasn't been made in this working group to= my knowledge.=C2=A0 I certainly
>=C2=A0 =C2=A0 =C2=A0 > don't think that's justified; it impr= oved fidelity of measurements,
>=C2=A0 =C2=A0 =C2=A0 > but the spin bit appears to be pretty good at= that without the extra
>=C2=A0 =C2=A0 =C2=A0 > overheads.
>
>=C2=A0 =C2=A0 =C2=A0Fidelity is indeed the criterion to decide 1 (spin = bit) vs 3 (spin bit + VEC)
>=C2=A0 =C2=A0 =C2=A0for RTT measurements, right.
>
>=C2=A0 =C2=A0 =C2=A0However, measurements also include packet loss, whi= ch is typically more
>=C2=A0 =C2=A0 =C2=A0widespread than delay in big pipes (which don't= have enough RAM to keep a
>=C2=A0 =C2=A0 =C2=A0packet
>=C2=A0 =C2=A0 =C2=A0for too long at line rate). And spin+VEC do not add= ress packet loss at all,
>=C2=A0 =C2=A0 =C2=A0hence our 7-bit spin counter proposal shown in Lond= on.
>
>=C2=A0 =C2=A0 =C2=A0I admit that 7 is hefty if you're starting from= Christian's songle spin bit ;
>=C2=A0 =C2=A0 =C2=A0however:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - I assume nobody will emit any doubt about= the criticality of
>=C2=A0 =C2=A0 =C2=A0non-delay-related (big pipe) loss location. Unless = everybody here has perfect
>=C2=A0 =C2=A0 =C2=A0networks and ideal reporting, that is.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Stick the spin bit on top of these 7, mak= e that an extra easurement
>=C2=A0 =C2=A0 =C2=A0byte and
>=C2=A0 =C2=A0 =C2=A0you've got your three spare bits again in the f= irst byte.
>
>
>=C2=A0 =C2=A0 =C2=A0
> ______________________________________________________________________=
> ___________________________________________________
>
>=C2=A0 =C2=A0 =C2=A0Ce message et ses pieces jointes peuvent contenir d= es informations
>=C2=A0 =C2=A0 =C2=A0confidentielles ou privilegiees et ne doivent donc<= br> >=C2=A0 =C2=A0 =C2=A0pas etre diffuses, exploites ou copies sans autoris= ation. Si vous avez recu
>=C2=A0 =C2=A0 =C2=A0ce message par erreur, veuillez le signaler
>=C2=A0 =C2=A0 =C2=A0a l'expediteur et le detruire ainsi que les pie= ces jointes. Les messages
>=C2=A0 =C2=A0 =C2=A0electroniques etant susceptibles d'alteration,<= br> >=C2=A0 =C2=A0 =C2=A0Orange decline toute responsabilite si ce message a= ete altere, deforme ou
>=C2=A0 =C2=A0 =C2=A0falsifie. Merci.
>
>=C2=A0 =C2=A0 =C2=A0This message and its attachments may contain confid= ential or privileged
>=C2=A0 =C2=A0 =C2=A0information that may be protected by law;
>=C2=A0 =C2=A0 =C2=A0they should not be distributed, used or copied with= out authorisation.
>=C2=A0 =C2=A0 =C2=A0If you have received this email in error, please no= tify the sender and
>=C2=A0 =C2=A0 =C2=A0delete this message and its attachments.
>=C2=A0 =C2=A0 =C2=A0As emails may be altered, Orange is not liable for = messages that have been
>=C2=A0 =C2=A0 =C2=A0modified, changed or falsified.
>=C2=A0 =C2=A0 =C2=A0Thank you.
>



___________________________________________________________________________= ______________________________________________

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

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

--000000000000bd03c00572ece31a-- From nobody Wed Aug 8 07:17:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C05130E35 for ; Wed, 8 Aug 2018 07:17: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, 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 glqo_oE--nEx for ; Wed, 8 Aug 2018 07:17:17 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1DB130E3D for ; Wed, 8 Aug 2018 07:17:16 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id ECA9F29E98620 for ; Wed, 8 Aug 2018 15:17:10 +0100 (IST) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 8 Aug 2018 15:17:12 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.158]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0399.000; Wed, 8 Aug 2018 22:17:09 +0800 From: "Roni Even (A)" To: Ian Swett CC: "alexandre.ferrieux@orange.com" , "IETF QUIC WG" , Martin Thomson , "Kazuho Oku" Subject: RE: The first octet Thread-Topic: The first octet Thread-Index: AQHULx3odecNTZUJlk6OslajB0gFnKS13iXg//981ACAAIuyEA== Date: Wed, 8 Aug 2018 14:17:09 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8BB21B@DGGEMM506-MBX.china.huawei.com> References: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.com> <24749_1533735863_5B6AF3B7_24749_220_1_604c6e2a-2ded-ed00-3089-3e4db36996a6@orange.com> <6E58094ECC8D8344914996DAD28F1CCD8BB1FD@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.143] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8BB21BDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 14:17:27 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8BB21BDGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJIG1lYW50IE1vbnRyZWFsIG5vdCBMb25kb24NCg0KRnJvbTogSWFuIFN3ZXR0IFttYWls dG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA4LCAyMDE4 IDQ6NTcgUE0NClRvOiBSb25pIEV2ZW4gKEEpDQpDYzogYWxleGFuZHJlLmZlcnJpZXV4QG9yYW5n ZS5jb207IElFVEYgUVVJQyBXRzsgTWFydGluIFRob21zb247IEthenVobyBPa3UNClN1YmplY3Q6 IFJlOiBUaGUgZmlyc3Qgb2N0ZXQNCg0KVGhhbmtzIFJvbmksIGFncmVlZCwgbGV0J3MgZm9jdXMg b24gdGhlIGlzc3VlcyBNYXJ0aW4gcmFpc2VkLg0KDQpPbiBXZWQsIEF1ZyA4LCAyMDE4IGF0IDk6 NTUgQU0gUm9uaSBFdmVuIChBKSA8cm9uaS5ldmVuQGh1YXdlaS5jb208bWFpbHRvOnJvbmkuZXZl bkBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSwNCkluIExvbmRvbiB0aGUgc3BpbiBiaXQgYW5kIFZF QyB3ZXJlIG5vdCBkaXNjdXNzZWQgaW4gdGhlIHNlc3Npb24sIG15IHRha2UgZnJvbSB0aGUgb2Zm bGluZSBkaXNjdXNzaW9ucyB3ZSBoYWQgd2FzIHRoYXQgY3VycmVudGx5IHdlIGV4cGVyaW1lbnRl ZCB3aXRoIGdvb2QgcmVzdWx0cyBvbmx5IHRoZSBzcGluIGJpdC4gSXQgYWxzbyBzZWVtZWQgdGhh dCB0aGUgY3VycmVudCBWRUMgYXMgcHJvcG9zZWQgaW4gQnJpYW5zJ3MgZHJhZnQgaXMgbm90IGdv b2QgZW5vdWdoIGFuZCB3ZSBpbnRlbmQgdG8gbG9vayBhdCBvdGhlciBhbGdvcml0aG1zIHRoYXQg d2lsbCBwcm92aWRlIGJldHRlciByZXN1bHRzIGZvciBwYWNrZXQgbG9zcyB1c2luZyB0aGUgMiBi aXRzLg0KSSB0aGluayB0aGF0IHRoaXMgZGlzY3Vzc2lvbiBpcyBwcmUgbWF0dXJlIGFuZCB0aGF0 IGl0IHNob3VsZCBiZSBkaXNjdXNzZWQgaW4gdGhlIGZ1dHVyZQ0KUm9uaQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIGFsZXhhbmRyZS5m ZXJyaWV1eEBvcmFuZ2UuY29tPG1haWx0bzphbGV4YW5kcmUuZmVycmlldXhAb3JhbmdlLmNvbT4N ClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA4LCAyMDE4IDQ6NDQgUE0NClRvOiBJYW4gU3dldHQN CkNjOiBJRVRGIFFVSUMgV0c7IE1hcnRpbiBUaG9tc29uOyBLYXp1aG8gT2t1DQpTdWJqZWN0OiBS ZTogVGhlIGZpcnN0IG9jdGV0DQoNClN1cmU6DQoNCiAgLSBzcGluK1ZFQyBhcmUgZG9jdW1lbnRl ZCBpbiBkcmFmdC10cmFtbWVsLXNwaW4tMDMNCg0KICAtIDcgYml0cyBmb3IgcGFja2V0IGxvc3Mg d2VyZSBwcmVzZW50ZWQgYXQNCiAgICAgIGh0dHA6Ly9zbmFnZ2xldG9vdGguYWthbS5haS9JRVRG LTEwMS1Ib3RSRkMvMTAtRmVycmlldXgucGRmDQoNClJlICJJJ20gY3VyaW91cyB3aHkgeW91J2Qg ZXZlbiB3YW50IHRoZW0iOiBwbGVhc2UgY2xhcmlmeSB3aGljaCBhcHBsaWVzOg0KDQogIChhKSB5 b3UgcmVjb2duaXplIHRoZSBjcml0aWNhbGl0eSBvZiBsb3NzIGxvY2F0aW9uLCBidXQgeW91IGhh dmUgYSBjbGV2ZXJlciBhbGdvcml0aG0gdG8gZG8gdGhlIHNhbWUgd2l0aCBmZXdlciB0aGFuIDcg Yml0cw0KDQogIChiKSB5b3UgZG9uJ3QgYmVsaWV2ZSBuZXR3b3JrIG9wZXJhdG9ycyBuZWVkIHRv IGxvY2F0ZSBsb3NzZXMNCg0KDQpPbiAwOC8wOC8xOCAxNToyOSwgSWFuIFN3ZXR0IHdyb3RlOg0K PiBJJ20gaGF2aW5nIGEgaGFyZCB0aW1lIHVuZGVyc3RhbmRpbmcgd2h5IHlvdSdkIG5lZWQgNyBi aXRzIHRvIG1lYXN1cmUNCj4gcGFja2V0DQo+IGxvc3MoMSBzZWVtcyBzdWZmaWNpZW50IGluIG1v c3QgY2FzZXMpLCBjYW4geW91IHNlbmQgYSBsaW5rIHRvIHRoZQ0KPiBzcGluICsgVkVDIGFuZCA3 IGJpdCBwcm9wb3NhbHMgeW91IG1lbnRpb25lZD8NCj4NCj4gSSdsbCBhbHNvIG5vdGUgSSB0aGlu ayB0aGUgY2hhbmNlcyB0aGUgV0cgd2lsbCBhZ3JlZSB0byA3IGJpdHMgaXMNCj4gZXh0cmVtZWx5 IGNsb3NlIHRvIDAsIGJ1dCBJJ20gY3VyaW91cyB3aHkgeW91J2QgZXZlbiB3YW50IHRoZW0uDQo+ DQo+IE9uIFdlZCwgQXVnIDgsIDIwMTggYXQgOToyMiBBTSA8YWxleGFuZHJlLmZlcnJpZXV4QG9y YW5nZS5jb208bWFpbHRvOmFsZXhhbmRyZS5mZXJyaWV1eEBvcmFuZ2UuY29tPg0KPiA8bWFpbHRv OmFsZXhhbmRyZS5mZXJyaWV1eEBvcmFuZ2UuY29tPG1haWx0bzphbGV4YW5kcmUuZmVycmlldXhA b3JhbmdlLmNvbT4+PiB3cm90ZToNCj4NCj4gICAgIE9uIDA4LzA4LzE4IDEyOjA1LCBNYXJ0aW4g VGhvbXNvbiB3cm90ZToNCj4gICAgICA+DQo+ICAgICAgPiBJIGtub3cgeW91IGRpc2N1c3NlZCB0 YWtpbmcgbW9yZSBiaXRzIGFuZCBldmVuIGJ5dGVzLCBidXQgdGhlIGNhc2UNCj4gICAgICA+IGhh c24ndCBiZWVuIG1hZGUgaW4gdGhpcyB3b3JraW5nIGdyb3VwIHRvIG15IGtub3dsZWRnZS4gIEkg Y2VydGFpbmx5DQo+ICAgICAgPiBkb24ndCB0aGluayB0aGF0J3MganVzdGlmaWVkOyBpdCBpbXBy b3ZlZCBmaWRlbGl0eSBvZiBtZWFzdXJlbWVudHMsDQo+ICAgICAgPiBidXQgdGhlIHNwaW4gYml0 IGFwcGVhcnMgdG8gYmUgcHJldHR5IGdvb2QgYXQgdGhhdCB3aXRob3V0IHRoZSBleHRyYQ0KPiAg ICAgID4gb3ZlcmhlYWRzLg0KPg0KPiAgICAgRmlkZWxpdHkgaXMgaW5kZWVkIHRoZSBjcml0ZXJp b24gdG8gZGVjaWRlIDEgKHNwaW4gYml0KSB2cyAzIChzcGluIGJpdCArIFZFQykNCj4gICAgIGZv ciBSVFQgbWVhc3VyZW1lbnRzLCByaWdodC4NCj4NCj4gICAgIEhvd2V2ZXIsIG1lYXN1cmVtZW50 cyBhbHNvIGluY2x1ZGUgcGFja2V0IGxvc3MsIHdoaWNoIGlzIHR5cGljYWxseSBtb3JlDQo+ICAg ICB3aWRlc3ByZWFkIHRoYW4gZGVsYXkgaW4gYmlnIHBpcGVzICh3aGljaCBkb24ndCBoYXZlIGVu b3VnaCBSQU0gdG8ga2VlcCBhDQo+ICAgICBwYWNrZXQNCj4gICAgIGZvciB0b28gbG9uZyBhdCBs aW5lIHJhdGUpLiBBbmQgc3BpbitWRUMgZG8gbm90IGFkZHJlc3MgcGFja2V0IGxvc3MgYXQgYWxs LA0KPiAgICAgaGVuY2Ugb3VyIDctYml0IHNwaW4gY291bnRlciBwcm9wb3NhbCBzaG93biBpbiBM b25kb24uDQo+DQo+ICAgICBJIGFkbWl0IHRoYXQgNyBpcyBoZWZ0eSBpZiB5b3UncmUgc3RhcnRp bmcgZnJvbSBDaHJpc3RpYW4ncyBzb25nbGUgc3BpbiBiaXQgOw0KPiAgICAgaG93ZXZlcjoNCj4N Cj4gICAgICAgIC0gSSBhc3N1bWUgbm9ib2R5IHdpbGwgZW1pdCBhbnkgZG91YnQgYWJvdXQgdGhl IGNyaXRpY2FsaXR5IG9mDQo+ICAgICBub24tZGVsYXktcmVsYXRlZCAoYmlnIHBpcGUpIGxvc3Mg bG9jYXRpb24uIFVubGVzcyBldmVyeWJvZHkgaGVyZSBoYXMgcGVyZmVjdA0KPiAgICAgbmV0d29y a3MgYW5kIGlkZWFsIHJlcG9ydGluZywgdGhhdCBpcy4NCj4NCj4gICAgICAgIC0gU3RpY2sgdGhl IHNwaW4gYml0IG9uIHRvcCBvZiB0aGVzZSA3LCBtYWtlIHRoYXQgYW4gZXh0cmEgZWFzdXJlbWVu dA0KPiAgICAgYnl0ZSBhbmQNCj4gICAgIHlvdSd2ZSBnb3QgeW91ciB0aHJlZSBzcGFyZSBiaXRz IGFnYWluIGluIHRoZSBmaXJzdCBieXRlLg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiAg ICAgQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zDQo+ICAgICBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYw0KPiAgICAgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1DQo+ICAgICBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+ICAgICBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMN Cj4gICAgIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4g ICAgIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91DQo+ICAgICBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+ICAgICBU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZA0KPiAgICAgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsNCj4gICAgIHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiAgICAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KPiAgICAgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiAgICAgQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4NCj4gICAgIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gICAgIFRoYW5r IHlvdS4NCj4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD8BB21BDGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBtZWFudCBNb250cmVhbCBu b3QgTG9uZG9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJYW4g U3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgQXVndXN0IDA4LCAyMDE4IDQ6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvbmkgRXZl biAoQSk8YnI+DQo8Yj5DYzo8L2I+IGFsZXhhbmRyZS5mZXJyaWV1eEBvcmFuZ2UuY29tOyBJRVRG IFFVSUMgV0c7IE1hcnRpbiBUaG9tc29uOyBLYXp1aG8gT2t1PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBUaGUgZmlyc3Qgb2N0ZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MgUm9uaSwgYWdyZWVkLCBsZXQncyBmb2N1cyBvbiB0aGUgaXNzdWVzIE1hcnRpbiBy YWlzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBX ZWQsIEF1ZyA4LCAyMDE4IGF0IDk6NTUgQU0gUm9uaSBFdmVuIChBKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tIj5yb25pLmV2ZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQpJbiBMb25kb24gdGhl IHNwaW4gYml0IGFuZCBWRUMgd2VyZSBub3QgZGlzY3Vzc2VkIGluIHRoZSBzZXNzaW9uLCBteSB0 YWtlIGZyb20gdGhlIG9mZmxpbmUgZGlzY3Vzc2lvbnMgd2UgaGFkIHdhcyB0aGF0IGN1cnJlbnRs eSB3ZSBleHBlcmltZW50ZWQgd2l0aCBnb29kIHJlc3VsdHMgb25seSB0aGUgc3BpbiBiaXQuIEl0 IGFsc28gc2VlbWVkIHRoYXQgdGhlIGN1cnJlbnQgVkVDIGFzIHByb3Bvc2VkIGluIEJyaWFucydz IGRyYWZ0IGlzIG5vdCBnb29kDQogZW5vdWdoIGFuZCB3ZSBpbnRlbmQgdG8gbG9vayBhdCBvdGhl ciBhbGdvcml0aG1zIHRoYXQgd2lsbCBwcm92aWRlIGJldHRlciByZXN1bHRzIGZvciBwYWNrZXQg bG9zcyB1c2luZyB0aGUgMiBiaXRzLjxicj4NCkkgdGhpbmsgdGhhdCB0aGlzIGRpc2N1c3Npb24g aXMgcHJlIG1hdHVyZSBhbmQgdGhhdCBpdCBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRoZSBmdXR1 cmU8YnI+DQpSb25pIDxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K RnJvbTogUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YN CjxhIGhyZWY9Im1haWx0bzphbGV4YW5kcmUuZmVycmlldXhAb3JhbmdlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmFsZXhhbmRyZS5mZXJyaWV1eEBvcmFuZ2UuY29tPC9hPjxicj4NClNlbnQ6IFdlZG5l c2RheSwgQXVndXN0IDA4LCAyMDE4IDQ6NDQgUE08YnI+DQpUbzogSWFuIFN3ZXR0PGJyPg0KQ2M6 IElFVEYgUVVJQyBXRzsgTWFydGluIFRob21zb247IEthenVobyBPa3U8YnI+DQpTdWJqZWN0OiBS ZTogVGhlIGZpcnN0IG9jdGV0PGJyPg0KPGJyPg0KU3VyZTo8YnI+DQo8YnI+DQombmJzcDsgLSBz cGluJiM0MztWRUMgYXJlIGRvY3VtZW50ZWQgaW4gZHJhZnQtdHJhbW1lbC1zcGluLTAzPGJyPg0K PGJyPg0KJm5ic3A7IC0gNyBiaXRzIGZvciBwYWNrZXQgbG9zcyB3ZXJlIHByZXNlbnRlZCBhdDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9zbmFnZ2xldG9vdGguYWth bS5haS9JRVRGLTEwMS1Ib3RSRkMvMTAtRmVycmlldXgucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwOi8vc25hZ2dsZXRvb3RoLmFrYW0uYWkvSUVURi0xMDEtSG90UkZDLzEwLUZlcnJpZXV4LnBk ZjwvYT48YnI+DQo8YnI+DQpSZSAmcXVvdDtJJ20gY3VyaW91cyB3aHkgeW91J2QgZXZlbiB3YW50 IHRoZW0mcXVvdDs6IHBsZWFzZSBjbGFyaWZ5IHdoaWNoIGFwcGxpZXM6PGJyPg0KPGJyPg0KJm5i c3A7IChhKSB5b3UgcmVjb2duaXplIHRoZSBjcml0aWNhbGl0eSBvZiBsb3NzIGxvY2F0aW9uLCBi dXQgeW91IGhhdmUgYSBjbGV2ZXJlciBhbGdvcml0aG0gdG8gZG8gdGhlIHNhbWUgd2l0aCBmZXdl ciB0aGFuIDcgYml0czxicj4NCjxicj4NCiZuYnNwOyAoYikgeW91IGRvbid0IGJlbGlldmUgbmV0 d29yayBvcGVyYXRvcnMgbmVlZCB0byBsb2NhdGUgbG9zc2VzPGJyPg0KPGJyPg0KPGJyPg0KT24g MDgvMDgvMTggMTU6MjksIElhbiBTd2V0dCB3cm90ZTo8YnI+DQomZ3Q7IEknbSBoYXZpbmcgYSBo YXJkIHRpbWUgdW5kZXJzdGFuZGluZyB3aHkgeW91J2QgbmVlZCA3IGJpdHMgdG8gbWVhc3VyZSA8 YnI+DQomZ3Q7IHBhY2tldDxicj4NCiZndDsgbG9zcygxIHNlZW1zIHN1ZmZpY2llbnQgaW4gbW9z dCBjYXNlcyksIGNhbiB5b3Ugc2VuZCBhIGxpbmsgdG8gdGhlIDxicj4NCiZndDsgc3BpbiZuYnNw OyYjNDM7IFZFQyBhbmQgNyBiaXQgcHJvcG9zYWxzIHlvdSBtZW50aW9uZWQ/PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEknbGwgYWxzbyBub3RlIEkgdGhpbmsgdGhlIGNoYW5jZXMgdGhlIFdHIHdpbGwg YWdyZWUgdG8gNyBiaXRzIGlzIDxicj4NCiZndDsgZXh0cmVtZWx5IGNsb3NlIHRvIDAsIGJ1dCBJ J20gY3VyaW91cyB3aHkgeW91J2QgZXZlbiB3YW50IHRoZW0uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IE9uIFdlZCwgQXVnIDgsIDIwMTggYXQgOToyMiBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhh bmRyZS5mZXJyaWV1eEBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWxleGFuZHJlLmZlcnJp ZXV4QG9yYW5nZS5jb208L2E+DQo8YnI+DQomZ3Q7ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OmFsZXhhbmRyZS5mZXJyaWV1eEBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWxleGFuZHJl LmZlcnJpZXV4QG9yYW5nZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtPbiAwOC8wOC8xOCAxMjowNSwgTWFydGluIFRob21zb24g d3JvdGU6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmd0OyBJIGtub3cgeW91IGRpc2N1c3NlZCB0YWtpbmcgbW9yZSBiaXRz IGFuZCBldmVuIGJ5dGVzLCBidXQgdGhlIGNhc2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyBoYXNuJ3QgYmVlbiBtYWRlIGluIHRoaXMgd29ya2luZyBncm91cCB0byBteSBrbm93 bGVkZ2UuJm5ic3A7IEkgY2VydGFpbmx5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsgZG9uJ3QgdGhpbmsgdGhhdCdzIGp1c3RpZmllZDsgaXQgaW1wcm92ZWQgZmlkZWxpdHkgb2Yg bWVhc3VyZW1lbnRzLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGJ1dCB0aGUg c3BpbiBiaXQgYXBwZWFycyB0byBiZSBwcmV0dHkgZ29vZCBhdCB0aGF0IHdpdGhvdXQgdGhlIGV4 dHJhPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgb3ZlcmhlYWRzLjxicj4NCiZn dDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7RmlkZWxpdHkgaXMgaW5kZWVkIHRoZSBj cml0ZXJpb24gdG8gZGVjaWRlIDEgKHNwaW4gYml0KSB2cyAzIChzcGluIGJpdCAmIzQzOyBWRUMp PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9yIFJUVCBtZWFzdXJlbWVudHMsIHJpZ2h0 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SG93ZXZlciwgbWVhc3Vy ZW1lbnRzIGFsc28gaW5jbHVkZSBwYWNrZXQgbG9zcywgd2hpY2ggaXMgdHlwaWNhbGx5IG1vcmU8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt3aWRlc3ByZWFkIHRoYW4gZGVsYXkgaW4gYmln IHBpcGVzICh3aGljaCBkb24ndCBoYXZlIGVub3VnaCBSQU0gdG8ga2VlcCBhPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7cGFja2V0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9y IHRvbyBsb25nIGF0IGxpbmUgcmF0ZSkuIEFuZCBzcGluJiM0MztWRUMgZG8gbm90IGFkZHJlc3Mg cGFja2V0IGxvc3MgYXQgYWxsLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2hlbmNlIG91 ciA3LWJpdCBzcGluIGNvdW50ZXIgcHJvcG9zYWwgc2hvd24gaW4gTG9uZG9uLjxicj4NCiZndDsg PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SSBhZG1pdCB0aGF0IDcgaXMgaGVmdHkgaWYg eW91J3JlIHN0YXJ0aW5nIGZyb20gQ2hyaXN0aWFuJ3Mgc29uZ2xlIHNwaW4gYml0IDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtob3dldmVyOjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtIEkgYXNzdW1lIG5vYm9keSB3aWxsIGVtaXQgYW55IGRv dWJ0IGFib3V0IHRoZSBjcml0aWNhbGl0eSBvZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O25vbi1kZWxheS1yZWxhdGVkIChiaWcgcGlwZSkgbG9zcyBsb2NhdGlvbi4gVW5sZXNzIGV2ZXJ5 Ym9keSBoZXJlIGhhcyBwZXJmZWN0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7bmV0d29y a3MgYW5kIGlkZWFsIHJlcG9ydGluZywgdGhhdCBpcy48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLSBTdGljayB0aGUgc3BpbiBiaXQgb24gdG9wIG9mIHRo ZXNlIDcsIG1ha2UgdGhhdCBhbiBleHRyYSBlYXN1cmVtZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7Ynl0ZSBhbmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt5b3UndmUgZ290 IHlvdXIgdGhyZWUgc3BhcmUgYml0cyBhZ2FpbiBpbiB0aGUgZmlyc3QgYnl0ZS48YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0Nl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9uczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Y2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO2EgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Vs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDtPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdTxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO2ZhbHNpZmllLiBNZXJjaS48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO1RoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDt0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0FzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7bW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1RoYW5rIHlvdS48YnI+ DQomZ3Q7IDxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUNCiBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPGJyPg0KPGJyPg0K VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsg dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uPGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuPGJyPg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLjxicj4NClRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD8BB21BDGGEMM506MBXchina_-- From nobody Wed Aug 8 07:25:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B16130E23 for ; Wed, 8 Aug 2018 07:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z6Y8XWq7Juo for ; Wed, 8 Aug 2018 07:25:12 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 373AE130E21 for ; Wed, 8 Aug 2018 07:25:12 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p6-v6so1874383ljc.5 for ; Wed, 08 Aug 2018 07:25:12 -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=hcPDZ75BPzCaF4imKHW1LoXyBWjzasL+DYCYDSK8A+c=; b=dd6HbQqXdkMS20EUtS/qY76X/XyhH87tvy7V2OiM7ZW4ebac7hF77MsjQdo4ER/Rju mKT7IZt47Jq78d/K2QXikvlbVb7U94CyKkA88V8DHoDp1y14p1fIrlZrxT7+85c8eLfr DlJRjYbt+s43s7w4J/Tsj7Ih3ViZYS5bUv5gSE9KiLSBh7hZIZWxrEogVHhQvyRageoD DhwsROAm4aeEjh3aYP7FXMqapSCQxWzWAYmgDvFggXd/6WMzZcojSrV2kDnb5McQC8PX Byrf8IVxSuvJtU/AsotLHT1KpQFX46iFaGeukc6jSatEDuordvMUQJpbFaciG2r3hlOP upzg== 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=hcPDZ75BPzCaF4imKHW1LoXyBWjzasL+DYCYDSK8A+c=; b=efZALDJV5uPiQQVGAMzkS/DNU+4nQG0QrPS0IyQjUWZXgbzTQXbmvnFEJPrwE7JhJl lmH6Z/HLHbKSgxLpOo/TAMkgWdCs8TjXBZdN8RVwTF9aOOaY7ka81qPczN2HWQWomiqf 8nbCPKxH0wJqikA4Ks6rU8Le8KlmayEtblVWYkg/NTDWfTI+IzNVBVfZs5T9FUtDM4IX DVSFxOXmCafRL+NMhkIeP2I0DNDvq3mG5SfzXjHJkD2g2XJasodo/Bgr1btQiONVUL3P BkioBpEF72G7nYuLiqWDxmNX3M3wBasZmK1w8lZXXIu1kvV6C0IpBgHH5LWiwj02iBgN p9JA== X-Gm-Message-State: AOUpUlG7HYDq9UJrJ7NintpLMp2weUb3bXm0b0jUDmRA1sm+aKUdtyIV dwx1FGcch2MxDpQmOoxg5g2iag8EUwuyhc2nxAw= X-Google-Smtp-Source: AA+uWPwJRPmkGxDnxrBMpSvPcdwQx7gy/a8ONQ30/NpIx/rjjPro0psfRBqrLm7F7xF1S7j5o49u3ZarR8sBPMpW8R4= X-Received: by 2002:a2e:40c:: with SMTP id 12-v6mr2363363lje.146.1533738310389; Wed, 08 Aug 2018 07:25:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 07:25:09 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Wed, 8 Aug 2018 23:25:09 +0900 Message-ID: Subject: Re: The first octet To: Martin Thomson Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 14:25:14 -0000 Hi Martin, Thank you for the clarifications. I now better understand the intent of your proposal. I think I'm fine with providing a way to demux the protocols without making that an invariant. I tend to agree with Colin that it is a good idea to have some form of randomization / greasing for endpoints that do not need to demux. We could potentially send a signal that instructs the peer to grease the demux bits by using TP. Or, a server could send a signal that tells the client it is free to grease the bits when it resumes a connection. But that is a slight preference. What is at stake here is just few bits. They do not expose the state of the connection, so the risk of ossification is simply that we might not be able to use the bits in the future. Considering how few the number of bits on the table are, I do not care much. 2018-08-08 18:51 GMT+09:00 Martin Thomson : > On Wed, Aug 8, 2018 at 5:41 PM Kazuho Oku wrote: >> My understanding is that we do not avoid conflict in the invariants, >> but you suggest to avoid them in v2. > > v1. > > Yes, that was the idea. The protocols we're talking about could have > the luxury of being able to negotiate versions carefully, and avoid > any version that doesn't suit. > >> For example, is it the case that you think avoiding conflict in the >> short term is worthwhile, at the same time keeping the possibility to >> change the decision in the future versions of QUIC? > > That is certainly true. See Colin's response too. He managed to > summarize the thinking here fairly well. > >> Honestly, I do not have a strong opinion here, although I worry about >> ossification when we decide not to grease the bits. Therefore, I would >> like to understand why you think avoiding conflict in v2 but not in >> invariant is worth considering. > > Yes, the risk exists. We could, for example decide to try to mitigate > this risk by choosing something maximally bad for 7983 demux and force > folks who want to do that to define a new version, thereby generating > two variants in relatively quick succession and pinning our hopes on > that helping. I tend to think that things ossify on longer timescales > than that and so am willing to risk those bits sticking for this gain. > For the short header, it would be exactly one bit. > > Invariants is part of our protection here. It might turn out to be > futile, I don't know. But I would be very happy to define a new > variant that set that bit to zero. -- Kazuho Oku From nobody Wed Aug 8 09:00:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522DD130E83 for ; Wed, 8 Aug 2018 09:00:40 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlvgIDX0otXZ for ; Wed, 8 Aug 2018 09:00:38 -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 96A0C130E7B for ; Wed, 8 Aug 2018 09:00:30 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3DDC83409AB; Wed, 8 Aug 2018 18:00:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.29685); Wed, 8 Aug 2018 18:00:26 +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, 8 Aug 2018 18:00:26 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 63591701; Wed, 08 Aug 2018 18:00:26 +0200 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C397E28E-1F9E-4B48-8A70-C2FED4018872"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: The first octet Date: Wed, 8 Aug 2018 18:00:25 +0200 In-Reply-To: Cc: Roni Even , IETF QUIC WG , Martin Thomson , alexandre.ferrieux@orange.com, Kazuho Oku To: Ian Swett References: <13948_1533714633_5B6AA0C9_13948_54_1_7bcd9ecb-c425-ecba-3caf-7bf004beb7d9@orange.com> <26969_1533734553_5B6AEE99_26969_131_1_373ed656-1dba-9b82-5c8b-eb2b7a5c9ad0@orange.com> <24749_1533735863_5B6AF3B7_24749_220_1_604c6e2a-2ded-ed00-3089-3e4db36996a6@orange.com> <6E58094ECC8D8344914996DAD28F1CCD8BB1FD@DGGEMM506-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 16:00:40 -0000 --Apple-Mail=_C397E28E-1F9E-4B48-8A70-C2FED4018872 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 to this is a separate thread we should pick up later. Note we (at ETH) are actively working on a few techniques for = loss/congestion measurement/exposure in QUIC. I've just seen an MSc = presentation on one part of this work, and another MSc thesis project = will begin in October. We aim to pull all this together into a coherent = proposal for v2, which might also propose (distinguishable on the wire) = alternate uses for the spin and/or VEC bits in v2. In any case I see the measurement experiment bits in v1 as a form of = greasing *in themselves*; techniques such as probabilistic = non-participation should keep the semantics of the bits themselves from = getting stuck. One minor correction in a derail below: > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of = alexandre.ferrieux@orange.com > Sent: Wednesday, August 08, 2018 4:44 PM > To: Ian Swett > Cc: IETF QUIC WG; Martin Thomson; Kazuho Oku > Subject: Re: The first octet >=20 > Sure: >=20 > - spin+VEC are documented in draft-trammel-spin-03 The canonical reference for this now (sorry, it's confusing) is = draft-trammell-tsvwg-spin-00; this now includes the spin bit for TCP as = well (which we've implemented for Linux, there's an short paper to = follow on this at IMC). Cheers, Brian --Apple-Mail=_C397E28E-1F9E-4B48-8A70-C2FED4018872 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAltrE5kACgkQihK3vwvq RqMZyRAAno5MA34ej/BmApw0vd/JtTttnQtLVbTESRen0X5sApU4piMjfDrxuBr1 u+IK1bzpx+/YVhrvEia1NMxmmIb2D2ZH8/Dw9ZxEemYc4iXlVtjkCAZWDVJvJswP UkWZAsFhg0LEL2TgCFMGtRt9LSkzyZxJxHiXZK8j/ZOtYnlE756+aq6VoBJT7uH4 I6sDfcZuFVXAJls2LYiQzP2dRSRDCmvzPDefQNUvRPMYe8BhSpl0WGBY0ZLGHLxG QqVR9EmYl+uZG/26nwVBbOZMrylIi7OoofoV5BKGAzVd9kuHiaopoe4dlI0WbdFb Ijmwk8MshGlI5b4eysRCwVhTTRY3xigmcC9P+KtI9mTmkNiGfMBSlvUjvMJrVRsX //zT6aUF0C1NgI7Giv383PbAUR0pkTpHKub9uvte1cOaBUaHWAUilfC5H1X4cBr6 My2ixUQvE/9WNBrht/eD/sdFE0iitRCgJfQuMT4GbsdgNLvNp3ApAk2+qwSKDQLu 27U5PyOM9Mb8c1DfoZPPSFNuHIWHF+G6aF1zVORd3lWi1J6SC9kEUuUoqvQTfnQF QB0+SsgLLL1aNaqPecB3iPt6hbNY5fLXew/ke9E5XHVHjG0oJTQTW26y7AA2PAGN bNrXdZls6Ws9fOgwZUp5t0AI5Z79eJlPbyFRT0b75xaVVly7VZk= =8tQG -----END PGP SIGNATURE----- --Apple-Mail=_C397E28E-1F9E-4B48-8A70-C2FED4018872-- From nobody Wed Aug 8 09:04:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B0D130E79 for ; Wed, 8 Aug 2018 09:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 p8x88Cjznkl5 for ; Wed, 8 Aug 2018 09:03:53 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 8FC25130E5A for ; Wed, 8 Aug 2018 09:03:53 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Aug 2018 09:03:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,458,1531810800"; d="scan'208";a="247197913" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by orsmga005.jf.intel.com with ESMTP; 08 Aug 2018 09:03:53 -0700 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.139]) by ORSMSX109.amr.corp.intel.com ([169.254.11.80]) with mapi id 14.03.0319.002; Wed, 8 Aug 2018 09:03:50 -0700 From: "Deval, Manasi" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: Subodh Iyengar , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , "Ian Swett" , Marten Seemann , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "IETF QUIC WG" , Martin Thomson , "Kazuho Oku" Subject: RE: Proposal to replace ACK block count with ACK length Thread-Topic: Proposal to replace ACK block count with ACK length Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFc4mOAAA2Oe4AAC1gQUACxPCCAAAyM/YAAAWbSgAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAAUH10ABdzFywAA7X+IAADpdCoAAAtMWAABL8DbAAVdcngAATwqWAAAPVigAAApb0gAK6iKdQAcxCLYD//6wwo4AavhmA//ZbnAA= Date: Wed, 8 Aug 2018 16:03:37 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B89CD2F@ORSMSX111.amr.corp.intel.com> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B86D457@ORSMSX111.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDU1ZTVjNDUtOTY4My00MjRmLWFmMjctZWM0MWFhYWVmZGM2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSUgyd2E4c053UEpXbUtyZ21NVTJSYmNpZCtmWGtQRXA5RDBpOGxabFVwNDg0UXkyWEJHZUxDVDlpNUlXK3QyRyJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 16:03:59 -0000 SGkgTWlyamEsDQoNCldoZW4gYSBwYWNrZXQgZ29lcyBvdXQgb24gdGhlIHdpcmUgdGhlIHNpemUg b2YgbGFyZ2VzdCBQRFUgaXMgaW5kaWNhdGVkIGJ5IHRoZSBNVFUuIFRoZSBFdGhlcm5ldCBwYWNr ZXQgY29tbW9ubHkgaGFzIGFuIE1UVSBvZiAxNTAwIGJ5dGVzLiBEZXBlbmRpbmcgb24gdGhlIG90 aGVyIGhlYWRlcnMgaW4gcGxhY2UsIHR1bm5lbGluZyBlbmFibGVkIG9yIG5vdCwgdGhlIHNpemUg b2YgcGF5bG9hZCBpbnNpZGUgdGhlIGlubmVybW9zdCBMNCBoZWFkZXIgaXMgY2FsbGVkIE1TUyAo bWF4aW11bSBzZWdtZW50IHNpemUpLiBJbiBRVUlDLCB0aGUgUVVJQyBoZWFkZXIsIGZyYW1lIGhl YWRlciBhbmQgUVVJQyBwYXlsb2FkIGxpdmUgaW5zaWRlIHRoZSAodHJhZGl0aW9uYWxseSBkZWZp bmVkKSBzZWdtZW50LiANCiANClRoZSB0YXNrIG9mIG1ha2luZyB0aGUgZGF0YSBmcmFtZSAic21h bGwiIGVub3VnaCB0byBmaXQgaW50byB0aGUgcGF5bG9hZCBpcyBhbiBleHBlbnNpdmUgYWN0aXZp dHkuIFRoZSBhYmlsaXR5IHRvIGRvIHNlZ21lbnRhdGlvbiBpbiBUQ1AgcHJvdmlkZXMgc2lnbmlm aWNhbnQgQ1BVIHNhdmluZ3MgLSBzb21lIHB1YmxpY2x5IHF1b3RlZCBudW1iZXJzIHN1Z2dlc3Qg dGhhdCBhIGhhcmR3YXJlIG9mZmxvYWQgaW5jcmVhc2VzIGVmZmljaWVuY3kgYnkgOHguIA0KDQpG b3IgYSBsYXJnZSBvYmplY3QgKHRoaW5rIHN0b3JhZ2Ugb3Igc3RyZWFtaW5nKSwgdGhlIFFVSUMg c3RhY2sgc2VuZCBtYXkgY3JlYXRlIGEgc3RyZWFtIHRoYXQgaXQgd291bGQgdHJhbnNsYXRlcyB0 byBtYW55IFFVSUMgLSBTdHJlYW0gLSBQYXlsb2FkIGtpbmQgb2YgcGFja2V0cyBvbiB0aGUgd2ly ZS4gSW4gc3VjaCBhIHNpdHVhdGlvbiwgdGhlIHNlZ21lbnRhdGlvbiBvZmZsb2FkIHdvdWxkIHVz ZSB0aGUgcnVsZXMgb2YgdGhlIFFVSUMgc3RhY2sgdG8gZG8gc2VnbWVudGF0aW9uLiANCg0KVGhh bmtzLA0KTWFuYXNpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaXJqYSBL w7xobGV3aW5kIFttYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaF0gDQpTZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAwMSwgMjAxOCA1OjM4IEFNDQpUbzogRGV2YWwsIE1hbmFzaSA8 bWFuYXNpLmRldmFsQGludGVsLmNvbT4NCkNjOiBTdWJvZGggSXllbmdhciA8c3Vib2RoQGZiLmNv bT47IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT47IEphbmEgSXllbmdhciA8anJpLmlldGZA Z21haWwuY29tPjsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+ OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBNYXJ0ZW4gU2VlbWFubiA8bWFydGVu c2VlbWFubkBnbWFpbC5jb20+OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBn bWFpbC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNYXJ0aW4gVGhvbXNvbiA8 bWFydGluLnRob21zb25AZ21haWwuY29tPjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNv bT4NClN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRo IEFDSyBsZW5ndGgNCg0KSGkgTWFuYXNpLA0KDQp0aGlzIGlkZWEgc291bmRzIHJlYWxseSBpbnRl cmVzdGluZywgaG93ZXZlciwgSSBiZWxpZXZlIHRoYXQgaW4gbW9zdCBjYXNlcyB0aGUgc2VnbWVu dGluZyB3b3VsZCBzdGlsbCBiZSBuZWVkZWQgdG8gYmUgZG9uZSBieSB0aGUgaGlnaGVyIGxheWVy IGJlY2F1c2UgdGhlIGRhdGEgZnJhbWVzIG5lZWQgdG8gYmUg4oCec21hbGzigJwgZW5vdWdoIHRv IGZpdCBpbiBhIHNlZ21lbnQgYW5kIEkgYmVsaWV2ZSB0aGF0IGluIG1hbnkgY2FzZXMgdGhlIGZy YW1lIHNpemUgd291bGQgYmUgY2hvc2VuIHRvIGV4YWN0bHkgZmlsbCB0aGUgc2VnbWVudCBzaXpl LCB0aHVzIHRoZXJlIGFyZSBub3QgbXVjaCBvcHRpb25zIHRvIHNlZ21lbnQgZGlmZmVyZW50bHkg aW4gdGhlIGtlcm5lbC4gT3IgZG8geW91IGhhdmUgYW5vdGhlciBzY2VuYXJpbyBpbiBtaW5kPw0K DQpNaXJqYQ0KDQoNCg0KPiBBbSAxNS4wNy4yMDE4IHVtIDIxOjE0IHNjaHJpZWIgRGV2YWwsIE1h bmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbT46DQo+IA0KPiBJIHRoaW5rIGlmIEFDS3MgYXJl IHNlbnQgZXZlcnkgMjAgdG8gNDAgcGFja2V0cywgdGhleSByZXF1aXJlIHRoZSBzZWdtZW50YXRp b24gY29kZSB0byBjYXJlIGFib3V0IHRoZW0uIA0KPiANCj4gQWxzbyBmcm9tIHRhbGtpbmcgdG8g dmFyaW91cyBmb2xrcyBJIGhlYXJkIGRpZmZlcmVudCB0aGluZ3MuIFNvbWUgaW1wbGVtZW50YXRp b25zIGxpa2UgdG8gcGlnZ3liYWNrIHRoZSBhY2sgd2l0aCBkYXRhIHdoaWxlIG90aGVycyBrZWVw IEFDSyBzZXBhcmF0ZS4gSW4gbXkgdW5kZXJzdGFuZGluZywgdGhlIHBpZ2d5YmFja2VkIGFzayBp cyB1c2VkIGZvciBiYW5kd2lkdGggcmVzdHJpY3RlZCBjYXNlcyB3aGVyZSB0aGV5IGF2b2lkIHBh ZGRpbmcuIA0KPiANCj4gVGhpcyBpcyBhbHNvIGFuIGV4Y2VsbGVudCBxdWVzdGlvbiBmb3IgdGhl IGltcGxlbWVudGVycyBhbmQgZGVwbG95ZXJzIG9uIHRoaXMgbGlzdC4NCj4gDQo+IFRoYW5rcywN Cj4gTWFuYXNpDQo+IA0KPiANCj4gT24gSnVsIDE1LCAyMDE4LCBhdCAxOjE1IFBNLCBTdWJvZGgg SXllbmdhciA8c3Vib2RoQGZiLmNvbT4gd3JvdGU6DQo+IA0KPj4gSGkgTWFuYXNpLA0KPj4gRG9l c24ndCB0aGUgc2VnbWVudGF0aW9uIG1ha2UgbW9yZSBzZW5zZSBmb3Igc3RyZWFtIGZyYW1lcyB0 aGFuIEFDSyBmcmFtZXM/IEFDSyBmcmFtZXMgYXJlIG5vdCBzZW50IHZlcnkgb2Z0ZW4gYW5kIGF0 IGxlYXN0IGluIHByb2R1Y3Rpb24gd2hhdCB3ZSd2ZSBzZWVuIGlzIHRoYXQgbW9zdCBvZiB0aGUg dGltZSBBQ0tzIG5hdHVyYWxseSBlbmQgdXAgZ2V0dGluZyBzZW50IGluIHRoZWlyIG93biBwdXJl IEFDSyBwYWNrZXRzLiANCj4+IA0KPj4gTm90IGFyZ3VpbmcgZm9yIG9yIGFnYWluc3QgdGhlIGxl bmd0aCBwcmVmaXggZGVzaWduLCBidXQgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2h5IGhhdmluZyBh IGxlbmd0aCBwcmVmaXggaW4gdGhlIEFDSyBmcmFtZSBoZWxwcyBzZWdtZW50YXRpb24gZm9yIHN0 cmVhbSBmcmFtZXMgZXZlbiBvbiB0aGUgcmVjdiBzaWRlLg0KPj4gDQo+PiBTdWJvZGgNCj4+IEZy b206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIERldmFsLCBNYW5h c2kgPG1hbmFzaS5kZXZhbEBpbnRlbC4uY29tPg0KPj4gU2VudDogU2F0dXJkYXksIEp1bHkgMTQs IDIwMTggODozNToxNCBQTQ0KPj4gVG86ICdNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuJzsgRXJp YyBSZXNjb3JsYTsgS2F6dWhvIE9rdQ0KPj4gQ2M6IEphbmEgSXllbmdhcjsgUHJhdmVlbiBCYWxh c3VicmFtYW5pYW47IElhbiBTd2V0dDsgTWFydGVuIFNlZW1hbm47IElFVEYgUVVJQyBXRzsgTWFy dGluIFRob21zb24NCj4+IFN1YmplY3Q6IFJFOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9j ayBjb3VudCB3aXRoIEFDSyBsZW5ndGgNCj4+ICANCj4+IEhpIEFsbCwNCj4+ICANCj4+IEkgd291 bGQgbGlrZSB0byByZXZpc2l0IHRoaXMgZGlzY3Vzc2lvbiBpbiB0aGUgY29udGV4dCBvZiBkaXN0 cmlidXRlZCBwcm9jZXNzaW5nLiBUaGUgZGlzdHJpYnV0ZWQgcHJvY2Vzc2luZyBkb2VzbuKAmXQg b25seSBhcHBseSB0byBtdWx0aS10aHJlYWRpbmcgYnV0IGFsc28gdG8gbGF5ZXJlZCBwcm9jZXNz aW5nLg0KPj4gIA0KPj4gT25lIGV4YW1wbGUgb2YgbGF5ZXJlZCBwcm9jZXNzaW5nIGlzIHNlZ21l bnRhdGlvbi4gVGhlIGN1cnJlbnQgQ2hyb21pdW0gaW1wbGVtZW50YXRpb24gY3VycmVudGx5IGNy ZWF0ZXMgdGhlIHNlZ21lbnRzIGFuZCBwYXNzZXMgdGhlbSBhcyBhIGJ1bmNoIGludG8gdGhlIExp bnV4IGtlcm5lbC4gVGhlcmUgaXMgYSBHU08gcGF0Y2ggdGhhdCB3b3VsZCBjaG9wIGF0IHRoZSBz ZWdtZW50IGJvdW5kYXJ5IGFuZCBlbmNhcHN1bGF0ZSBpbiBVRFAgaGVhZGVycy4gV2UgY2FuIGZ1 cnRoZXIgaW1wcm92ZSBwZXJmb3JtYW5jZSBieSBwbHVnZ2luZyBpbiBhIHNtYXJ0ZXIgc2VnbWVu dGF0aW9uIGFsZ29yaXRobSBzdWNoIHRoYXQgdGhlIHNlZ21lbnQgcHJvY2Vzc2luZyBjYW4gYWNj b3VudCBmb3IgdHlwZSBvZiBmcmFtZSwgaXRzIHNpemUgYW5kIG1ha2UgaW50ZWxsaWdlbnQgYm91 bmRhcnkgYW5kIHBhZGRpbmcgZGVjaXNpb25zIGF0IGEgbG93ZXIgbGF5ZXIgb3IgaW4gYW4gb2Zm bG9hZC4gVG8gdGhpcyBlbmQsIHRoZSBhbGdvcml0aG0gbmVlZHMgdG8gaWRlbnRpZnkgdGhlIHNp emUgb2YgZWFjaCBvZiB0aGUgZnJhbWVzLiBIYXZpbmcgYW4gQUNLIGxlbmd0aCB0aGF0IGNhbiBi ZSBkZXRlcm1pbmVkIGluIGEgc2luZ2xlIHJlYWQgaXMgbXVjaCBtb3JlIGVmZmljaWVudCB0aGFu IGhhdmluZyB0byBkbyBhIHNlcmllcyBvZiByZWFkcy4gDQo+PiAgDQo+PiBUaGFua3MsDQo+PiBN YW5hc2kNCj4+ICANCj4+IEZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzpt aWtrZWxmakBnbWFpbC5jb21dIA0KPj4gU2VudDogRnJpZGF5LCBKdW5lIDIyLCAyMDE4IDk6MTUg QU0NCj4+IFRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBLYXp1aG8gT2t1IDxrYXp1 aG9va3VAZ21haWwuY29tPg0KPj4gQ2M6IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29t PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgRGV2YWwsIE1hbmFzaSA8bWFuYXNpLmRl dmFsQGludGVsLmNvbT47IE1hcnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbT47 IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBJYW4gU3dldHQgPGlh bnN3ZXR0QGdvb2dsZS5jb20+OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9z b2Z0LmNvbT4NCj4+IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBj b3VudCB3aXRoIEFDSyBsZW5ndGgNCj4+ICANCj4+IEFub3RoZXIgb3B0aW9uIGlzIHRvIHdyaXRl IG91dCBmcmFtZXMgYXMgaXMgd2l0aG91dCBsZW5ndGggZXhjZXB0IGFzIG5lZWRlZCBmb3IgdmFy aW50cy4gV2hlbiBhIHBhY2tldCBpcyBuZWFybHkgZG9uZSwgYSBydW4tbGVuZ3RoIGVuY29kZWQg ZnJhbWUgaW5kZXggaXMgcGxhY2VkIGluIHRoZSBwYWNrZXQgdGFpbC4gSXQgY291bGQgYWxzbyBp bmNsdWRlIHRoZSBmcmFtZSB0eXBlcy4gQSByZWFkZXIgY2FuIG5vdyBkaXJlY3RseSBmaW5kIG9y IHNraXAgQUNLIGZyYW1lcyBhbmQgdGhlIHdyaXRlciBkb2VzIG5vdCBoYXZlIHRvIGNvbXB1dGUg bGVuZ3RocyBiZWZvcmUgd3JpdGluZy4gT2YgY291cnNlLCB0aGUgcmVhZGVyIG5lZWRzIHRvIGJl IGFibGUgdG8gbG9jYXRlIHRoZSBpbmRleCBhdCB0aGUgdGFpbCB3aGljaCBjYW4gYmUgdHJpY2t5 IHdpdGggY29hbGVzY2VkIHBhY2tldHMsIGJ1dCBub3QgaW1wb3NzaWJsZS4gSXNu4oCZdCB0aGlz IGxhcmdlbHkgaG93IHppcC1maWxlcyB3b3JrPw0KPj4gIA0KPj4gTWlra2VsDQo+PiAgDQo+PiBP biAyMiBKdW5lIDIwMTggYXQgMTcuMDAuNTIsIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gKG1p a2tlbGZqQGdtYWlsLi5jb20pIHdyb3RlOg0KPj4gDQo+PiBBcyBJIHNhaWQgZWFybGllciwgSSBh bHNvIGZhdm91ciBhIGxlbmd0aCBwcmVmaXguIEJ1dCwgSWFuIGRvZXMgaGF2ZSBhIHBvaW50Og0K Pj4gIA0KPj4gV3JpdGluZyBkYXRhIGlzIGdlbmVyYWxseSBtb3JlIGV4cGVuc2l2ZSB0aGFuIHJl YWRpbmcgZGF0YS4gRXNwZWNpYWxseSBpZiB5b3UgaGF2ZSB0byB0cmF2ZXJzZSBsb25nIGRhdGEg c3RydWN0dXJlcyB0byBmaW5kIHRoZSBsZW5ndGggYmVmb3JlIHlvdSBjYW4gc3RhcnQgd3JpdGlu ZyBhbmQvb3IgeW91IG1heSBoYXZlIHRvIGNvbnNlcnZhdGl2ZWx5IHJlc2VydmUgZXh0cmEgc3Bh Y2UgZm9yIGEgbGVuZ3RoIGZpZWxkLg0KPj4gIA0KPj4gU28gYmVmb3JlIGRlY2lkaW5nIG9uZSB3 YXkgb3IgdGhlIG90aGVyLCB0aGUgY29zdCBvZiB3cml0aW5nIG5lZWRzIHRvIGJlIHdlbGwgdW5k ZXJzdG9vZCwgYWxzbyBpbiBzY2VuYXJpb3Mgd2l0aCBsYXJnZSBNVFXigJlzLg0KPj4gIA0KPj4g SW4gdGhlIGZsYXRidWZmZXJzIHNwYWNlIHRoYXQgSeKAmW0gaW52b2x2ZWQgd2l0aCwgc3RyZWFt aW5nIGhhcyB0dXJuZWQgdG8gYmUgYW4gaXNzdWUgYmVjYXVzZSBkYXRhIGNhbm5vdCBiZSB0cmFu c21pdHRlZCBpbiBwYXJ0cyB3aXRob3V0IGluZGV4IGRhdGEgb24gYSBzZXBhcmF0ZSBjaGFubmVs IHRvIHJlY29tYmluZWQgZnJhZ21lbnRzLiBBIHNpbXBsZSwgYnV0IG5vbi1zdGFuZGFyZCwgY2hh bmdlIGluIHRoZSBmb3JtYXQgd291bGQgZml4IHRoaXMuIEpTT04gYW5kIENvQVAgYWxsb3dzIHN0 cmVhbWluZywgYnV0IG1hbnkgb3RoZXIgZm9ybWF0cyBkbyBub3QsIGluY2x1ZGluZyBsYXRlciB2 ZXJzaW9ucyBvZiBwcm90b2NvbCBidWZmZXJzLCBhcyBJIHVuZGVyc3RhbmQuDQo+PiAgDQo+PiBB biBvZGQgY29uc2VxdWVuY2Ugb2YgbWFraW5nIGJvdGggcmVhZCBhbmQgd3JpdGUgZWZmaWNpZW50 IGlzIHRoYXQgbGVuZ3RoIGJldHRlciB3b3JrIGJldHRlciBpZiBzdG9yZWQgYXQgdGhlIGVuZCBh bmQgcGFja2V0cyByZWFkIGJhY2t3YXJkcy4gVGhpcyByZXF1aXJlcyBhIHNpbmdsZSB0b3RhbCBs ZW5ndGggcHJlZml4IGJ1dCB0aGlzIGlzIHN0b3JlZCBpbiB0aGUgZGF0YWdyYW0gaGVhZGVyLiBU aGlzIGlzIHByb2JhYmx5IHRvbyBvZGQtYmFsbCwgYnV0IHN0aWxsIGEgY29uc2lkZXJhdGlvbiB3 b3J0aCBub3RpbmcuDQo+PiAgDQo+PiBUaGUgc2Vjb25kIGJlc3QgYWx0ZXJuYXRpdmUgbWF5IHRo ZXJlZm9yZSBiZSB0byBhbGxvdyB3cml0ZXMgdG8gYmUgZmFzdCBhbmQgcmVhZHMgdG8gYmUgZGVj ZW50Lg0KPj4gIA0KPj4gWWV0LCBJIHN0aWxsIGxpa2UgbGVuZ3RoIHByZWZpeGVzIGlmIHRoZXkg Y291bGQgYmUgbWFkZSB3cml0ZSBlZmZpY2llbnQgYmVjYXVzZSBoaWdoIHBlcmZvcm1hbmNlIGxv dy1sYXRlbmN5IHByb2Nlc3NlcyBjYXJlIHplcm8gYWJvdXQgQUNLIGFuZCBjYW4gY29uc3VtZSBh IHBhY2tldCBkaXJlY3RseSB3aGlsZSBhIGJhY2tncm91bmQgcHJvY2VzcyBoYW5kbGVzIGFsbCB0 aGUgbGF0ZW5jeSBpbnNlbnNpdGl2ZSBBQ0sgYW5kIHJldHJhbnNtaXNzaW9uIGxvZ2ljLg0KPj4g IA0KPj4gVGhlIHF1ZXN0aW9uIGlzIGFsc28sIHdoZXJlIGlzIHRoZSBwcmVzc3VyZTogYW4gSW9U IGFnZ3JlZ2F0b3IgbWlnaHQgYmUgbWFzc2l2ZWx5IHJlYWQgaW50ZW5zaXZlIHdoaWxlIGEgd2Vi IGNhY2hlIHdvdWxkIGJlIHZlcnkgd3JpdGUgaW50ZW5zaXZlLg0KPj4gIA0KPj4gIA0KPj4gS2lu ZCBSZWdhcmRzLA0KPj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KPj4gDQo+PiAgDQo+PiBP biAyMiBKdW5lIDIwMTggYXQgMTUuMTIuMDksIEVyaWMgUmVzY29ybGEgKGVrckBydGZtLmNvbSkg d3JvdGU6DQo+PiANCj4+IEl0IHNlZW1zIGxpa2UgdGhlcmUgYXJlIHR3byBxdWVzdGlvbnMgYXQg aGFuZCBoZXJlOg0KPj4gIA0KPj4gMS4gV291bGQgaXQgYmUgYXJjaGl0ZWN0dXJhbGx5IGJldHRl ciB0byBoYXZlIGZyYW1lcyBoYXZlIGEgY29uc2lzdGVudCBzZWxmLWNvbnRhaW5lZA0KPj4gcmVw cmVzZW50YXRpb24/DQo+PiAyLiBJcyBpdCBlbm91Z2ggYmV0dGVyIHRoYXQgd2Ugc2hvdWxkIGRv IHNvIG5vdy4NCj4+ICANCj4+IEkgYWdyZWUgd2l0aCBLYXp1aG8gdGhhdCAoYSkgd2UgZG9uJ3Qg aGF2ZSB0aGF0IHJlcHJlc2VudGF0aW9uIG5vdyBhbmQgKGIpIGl0IHdvdWxkDQo+PiBiZSBhIGJl dHRlciBkZXNpZ24gdG8gZG8gc28uIEknbSBwZXJoYXBzIHNvbWV3aGF0IG1vcmUgcG9zaXRpdmUg b24gKDIpIHRoYW4gaGUNCj4+IGlzLiBJIGRvbid0IHRoaW5rIGl0J3MgY3JpdGljYWxseSBpbXBv cnRhbnQgdGhhdCB3ZSBtYWtlIHRoZSBjaGFuZ2UsIGJ1dCBpZiB3ZSB3ZXJlDQo+PiB0byBob2xk IGEgY29uc2Vuc3VzIGNhbGwsIEkgdGhpbmsgSSB3b3VsZCBiZSBpbiBmYXZvci4gSSdkIGNlcnRh aW5seSBiZSBpbnRlcmVzdGVkDQo+PiBpbiBsb29raW5nIGF0IGEgcHJvcG9zYWwgaWYgc29tZW9u ZSBlbHNlIHdlcmUgdG8gbWFrZSBvbmUuDQo+PiAgDQo+PiAtRWtyDQo+PiAgDQo+PiAgDQo+PiAg DQo+PiBPbiBUaHUsIEp1biAyMSwgMjAxOCBhdCA4OjQ1IFBNLCBLYXp1aG8gT2t1IDxrYXp1aG9v a3VAZ21haWwuY29tPiB3cm90ZToNCj4+IDIwMTgtMDYtMjIgODowOCBHTVQrMDk6MDAgRGV2YWws IE1hbmFzaSA8bWFuYXNpLmRldmFsQGludGVsLmNvbT46DQo+PiA+IEkgZmVlbCB0aGF0IHRoZSBy ZXF1aXJlbWVudCB0byBoYXZlIGV2ZXJ5IHZhbHVlIHZhbGlkIGlzIHNvbWV3aGF0IGFjYWRlbWlj Lg0KPj4gDQo+PiBJIHRoaW5rIHRoYXQgTWFydGVuIGlzIGNvcnJlY3QgaW4gcG9pbnRpbmcgb3V0 IHRoYXQgbWFraW5nIHRoZSBBQ0sNCj4+IGZyYW1lIHNlbGYtY29udGFpbmluZyAoYnkgaGF2aW5n IGEgZmllbGQgdGhhdCByZXByZXNlbnRzIHRoZSBudW1iZXIgb2YNCj4+IG9jdGV0cyBiZWluZyBj b25zdW1lZCBieSB0aGUgZnJhbWUpIHdvdWxkIGJlIGFuIGV4Y2VwdGlvbiBmcm9tIHRoZQ0KPj4g ZGVzaWduIHBhdHRlcm4gd2UgaGF2ZS4NCj4+IA0KPj4gTG9vayBhdCBTVFJFQU0gZnJhbWUuIFRo ZSBmaWVsZCBpcyBub3Qgc2VsZi1jb250YWluZWQuIEluc3RlYWQsIGl0IGhhcw0KPj4gYSBMZW5n dGggZmllbGQgZm9yIHRoZSBTdHJlYW0gRGF0YSwgd2hpY2ggaXMgYSBsZWFmLiBUaGUgc2FtZSBn b2VzIGZvcg0KPj4gTkVXX0NPTk5FQ1RJT05fSUQgZnJhbWUgKHRoYXQgaGFzIHRoZSBsZW5ndGgg ZmllbGQgZm9yIENvbm5lY3Rpb24gSUQNCj4+IGZpZWxkICh3aGljaCBpcyBhbHNvIGEgbGVhZikp LCBDT05ORUNUSU9OX0NMT1NFIChsZW5ndGggZmllbGQgZm9yDQo+PiBSZWFzb24gUGhhc2UpLg0K Pj4gDQo+PiBJIGFncmVlIHdpdGggTWFydGVuLCBNaWtrZWwgKGFuZCBwb3NzaWJseSBvdGhlcnMg YXMgd2VsbCkgdGhhdCBoYXZpbmcNCj4+IGNvbnNpc3RlbmN5IGlzIGltcG9ydGFudC4NCj4+IA0K Pj4gVGhlcmVmb3JlLCBJIGFncmVlIHdpdGggTWlra2VsIHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVy IG1ha2luZyBldmVyeQ0KPj4gZnJhbWUgc2VsZi1jb250YWluZWQgb3Iga2VlcGluZyBldmVyeSBm cmFtZSBhcy1pcyAoaS5lLiBub3QNCj4+IHNlbGYtY29udGFpbmVkKS4NCj4+IA0KPj4gRldJVywg YXMgZGVzY3JpYmVkIGluIHRoZSBsYXR0ZXIgaGFsZiBvZg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9xdWljL2N1cnJlbnQvbXNnMDQyODcuaHRtbCwgaXQNCj4+IGlz IHBvc3NpYmxlIHRvIG1ha2UgZXZlcnkgZnJhbWUgc2VsZi1jb250YWluZWQgKmFuZCogYWxzbyBt YWtlIEFDSw0KPj4gZnJhbWVzIHNtYWxsZXIgdGhhbiB0aGUgY3VycmVudCBkcmFmdC4gTWFraW5n IGV2ZXJ5IGZyYW1lDQo+PiBzZWxmLWNvbnRhaW5lZCBnaXZlcyB1cyB0aGUgcG9zc2liaWxpdHkg dG8gc2VuZCBuZXcgZXh0ZW5zaW9uIGZyYW1lcw0KPj4gd2l0aG91dCBuZWdvdGlhdGlvbi4NCj4+ IA0KPj4gSSBkbyBub3QgdGhpbmsgdGhhdCBJIHdvdWxkIHB1c2ggZm9yIG1ha2luZyBldmVyeSBm cmFtZSBzZWxmLWNvbnRhaW5lZA0KPj4gYnkgbXlzZWxmIChiZWNhdXNlIEkgZG8gbm90IHRoaW5r IGl0IG1lZXRzIHRoZSBoaWdoIGJhciB0byBoYXZlIGENCj4+IGNoYW5nZSBhdCBzdWNoIGEgbGF0 ZSBtb21lbnQgb2Ygc3RhbmRhcmRpemF0aW9uKSwgYnV0IGFzIHN0YXRlZCwgbXkNCj4+IHByZWZl cmVuY2UgZ29lcyB0byBzZWVpbmcgZXZlcnkgZnJhbWUgbWFkZSBzZWxmLWNvbnRhaW5lZCBvciBu b25lIG9mDQo+PiB0aGVtIG1hZGUgYXMgc3VjaC4NCj4+IA0KPj4gPiBUaGUgbGVuZ3RoIHZhbHVl IHByb3ZpZGVzIG11Y2ggbW9yZSB2YWx1ZSB0aGFuIHRoZSBibG9jayBjb3VudCBhbmQgdGhlIGZh Y3QNCj4+ID4gdGhhdCBjZXJ0YWluIHZhbHVlcyBjYW4gbmV2ZXIgYmUgYWNoaWV2ZWQgaXMgYW4g aW5oZXJlbnQgcHJvcGVydHkgb2YgdGhlDQo+PiA+IGxlbmd0aC4NCj4+ID4NCj4+ID4NCj4+ID4N Cj4+ID4gT25lIGludGVyZXN0aW5nIG9ic2VydmF0aW9uIGlzIHRoYXQgdGhpcyBwcm9wZXJ0eSBp cyBub3QgbGltaXRlZCB0byBsZW5ndGguDQo+PiA+IE9uZSBjYW4gZXZlbiBtYWtlIGEgc2ltaWxh ciBhcmd1bWVudCBhYm91dCBBQ0sgYmxvY2sgY291bnQuIFRoZSBtYXhpbXVtDQo+PiA+IG51bWJl ciBvZiBBQ0sgYmxvY2tzIHRoYXQgY2FuIGJlIGRlZmluZWQgd2lsbCBub3QgYWx3YXlzIGhhdmUg YSBtZWFuaW5nZnVsDQo+PiA+IHZhbHVlLiBJbiBvdXQgZXhhbXBsZXMsIDAsMSwyLDMgYXJlIGFs bCB2YWxpZC4gSWYgSSBzZXQgdGhlIHZhbHVlIG9mIEFDSw0KPj4gPiBibG9jayBjb3VudCB0byBo YXZlIGxvd2VyIHR3byBiaXRzIHRvIGJlIDExLCB0aGUgbWF4aW11bSB2YWx1ZSBpcyBvZiBBQ0sN Cj4+ID4gYmxvY2tzIGlzIOKAkyA0NjExNjg2MDE4NDI3Mzg3OTAzLiBUaGlzIGlzIHRoZSBzYW1l IHZhbHVlIG9mIGxhcmdlc3QNCj4+ID4gYWNrbm93bGVkZ2VkIHNvIGlmIHRoZSBBQ0sgYmxvY2sg Y291bnQgd2FzIHNldCB0byB0aGlzIHZhbHVlLCBpdCB3b3VsZCBzdGlsbA0KPj4gPiBiZSBtZWFu aW5nbGVzcy4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gVGhhbmtzLA0KPj4gPg0KPj4gPiBNYW5h c2kNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gRnJvbTog TWFydGVuIFNlZW1hbm4gW21haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbV0NCj4+ID4gU2Vu dDogVHVlc2RheSwgSnVuZSAxOSwgMjAxOCA2OjQ0IFBNDQo+PiA+IFRvOiBEZXZhbCwgTWFuYXNp IDxtYW5hc2kuLmRldmFsQGludGVsLmNvbT4NCj4+ID4gQ2M6IElhbiBTd2V0dCA8aWFuc3dldHRA Z29vZ2xlLmNvbT47IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+OyBFcmljDQo+PiA+ IFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNv bT47IFByYXZlZW4NCj4+ID4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsg SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWFydGluDQo+PiA+IFRob21zb24gPG1hcnRp bi50aG9tc29uQGdtYWlsLmNvbT4NCj4+ID4NCj4+ID4NCj4+ID4gU3ViamVjdDogUmU6IFByb3Bv c2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KPj4gPg0KPj4g Pg0KPj4gPg0KPj4gPiBIaSBNYW5hc2ksDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+PiBUaGUgcmlz ayBvZiBkaXNhZ3JlZW1lbnQgYmV0d2VlbiBhY2sgYmxvY2tzIGFuZCBhY2sgYmxvY2sgY291bnQg aXMgc2FtZSBhcw0KPj4gPj4gdGhlIHJpc2sgb2YgZGlzYWdyZWVtZW50IGJldHdlZW4gYWNrIGJs b2NrcyBhbmQgYWNrIGxlbmd0aC4gRWl0aGVyIHdheSB0aGlzDQo+PiA+PiBuZWVkcyB0byBiZSBj b3VudGVkIHVwIHdoaWxlIGNyZWF0aW5nIHRoZSBBQ0sgYW5kIGNvdW50ZWQgZG93biB3aGlsZSBw YXJzaW5nDQo+PiA+PiBpdC4gVGhlIHBvc3NpYmlsaXR5IG9mIGVycm9yIGlzIHRoZSBzYW1lLiBH ZXR0aW5nIHRoZSBhY2sgYmxvY2sgY291bnQgd3JvbmcNCj4+ID4+IGlzIGFzIHByb2JsZW1hdGlj IGFzIGdldHRpbmcgdGhlIGFjayBsZW5ndGggd3JvbmcuIERvIHlvdSBhZ3JlZT8NCj4+ID4NCj4+ ID4NCj4+ID4NCj4+ID4gSSBkaXNhZ3JlZS4gTGV0J3MgdGFrZSBhbiBleGFtcGxlIG9mIGFuIEFD SyBmcmFtZSB3aXRoIG9uZSBBQ0sgcmFuZ2UsIHRoYXQNCj4+ID4gbmVlZHMgYSAyIGJ5dGUgdmFy aW50IHRvIHJlcHJlc2VudCB0aGUgRmlyc3QgQUNLIEJsb2NrIGFuZCBhbm90aGVyIDIgYnl0ZQ0K Pj4gPiB2YXJpbnQgdG8gcmVwcmVzZW50IHRoZSBHYXAuDQo+PiA+DQo+PiA+IFdpdGggeW91ciBw cm9wb3NhbDoNCj4+ID4NCj4+ID4gVGhlIHZhbHVlcyAwIGFuZCAxIGFyZSBpbnZhbGlkLCBzaW5j ZSB0aGUgbGVuZ3RoIGZpZWxkcyBpdHNlbGYgaXMgaW5jbHVkZWQNCj4+ID4gaW4gdGhlIGxlbmd0 aC4NCj4+ID4gVGhlIHZhbHVlcyAyLCAzLCAuLi4sICgyICsgbGVuKExhcmdlc3RBY2tub3dsZWRn ZWQpICsgbGVuKEFja0RlbGF5KSkgLSAxIGFyZQ0KPj4gPiBpbnZhbGlkLCBzaW5jZSB0aGUgbGVu Z3RoIG5lZWRzIHRvIGluY2x1ZGUgdGhlIExhcmdlc3QgQWNrbm93bGVkZ2VkIGFuZCB0aGUNCj4+ ID4gQWNrIERlbGF5Lg0KPj4gPiBUaGUgdmFsdWUgMiArIGxlbihMYXJnZXN0QWNrbm93bGVkZ2Vk KSArIGxlbihBY2tEZWxheSkgd291bGQgYmUgdGhlIGZpcnN0DQo+PiA+IHZhbGlkIHZhbHVlLCBh bmQgY29ycmVzcG9uZCB0byBhbiBBQ0sgZnJhbWUgd2l0aCBubyBibG9ja3MuDQo+PiA+IFRoZSB2 YWx1ZSAyICsgbGVuKExhcmdlc3RBY2tub3dsZWRnZWQpICsgbGVuKEFja0RlbGF5KSArIDEgaXMg aW52YWxpZCwgc2luY2UNCj4+ID4gaXQgd291bGQgY3V0IHRoZSB2YXJpbnQgZm9yIHRoZSBGaXJz dCBBQ0sgQmxvY2sNCj4+ID4gVGhlIHZhbHVlIDIgKyBsZW4oTGFyZ2VzdEFja25vd2xlZGdlZCkg KyBsZW4oQWNrRGVsYXkpICsgMiBpcyBpbnZhbGlkLCBzaW5jZQ0KPj4gPiBpdCB3b3VsZCBjdXQg dGhlIGZyYW1lIGFmdGVyIHRoZSBGaXJzdCBBQ0sgQmxvY2sgKGJ1dCBldmVyeSBibG9jayBtdXN0 IGJlDQo+PiA+IGZvbGxvd2VkIGJ5IGEgZ2FwIGxlbmd0aCkNCj4+ID4gVGhlIHZhbHVlIDIgKyBs ZW4oTGFyZ2VzdEFja25vd2xlZGdlZCkgKyBsZW4oQWNrRGVsYXkpICsgMyBpcyBpbnZhbGlkLCBz aW5jZQ0KPj4gPiBpdCB3b3VsZCBjdXQgdGhlIHZhcmludCBmb3IgdGhlIEdhcA0KPj4gPiBGaW5h bGx5LCB0aGUgdmFsdWUgMiArIGxlbihMYXJnZXN0QWNrbm93bGVkZ2VkKSArIGxlbihBY2tEZWxh eSkgKyA0IGlzIHZhbGlkDQo+PiA+DQo+PiA+IFRoZXJlIGFyZSAqYSBsb3QqIG9mIGludmFsaWQg dmFsdWVzIHRoYXQgeW91IGNhbiBlbmNvZGUgaW50byB0aGUgQUNLIGxlbmd0aA0KPj4gPiBmaWVs ZC4gTW9yZSBpbXBvcnRhbnRseSwgKm5vbmUqIG9mIHRoZXNlIGVycm9yIGNhc2VzIGV4aXN0cyB3 aXRoIHRoZSBjdXJyZW50DQo+PiA+IGZyYW1lIGZvcm1hdC4NCj4+ID4NCj4+ID4gVGhlICpvbmx5 KiBlcnJvciBjYXNlIHRoYXQgY2FuIG9jY3VyIHdpdGggb3VyIGN1cnJlbnQgZm9ybWF0IGlzIHRo YXQgdGhlDQo+PiA+IHBhY2tldCBpcyB0b28gc2hvcnQgZm9yIHRoZSBudW1iZXIgb2YgQUNLIGJs b2NrcyB0aGF0IGFyZSBzdXBwb3NlZCB0bw0KPj4gPiBjb250YWluZWQgaW4gdGhlIGZyYW1lLiBU aGlzIGNhbiBvY2N1ciB3aXRoIHlvdXIgcHJvcG9zYWwgYXMgd2VsbCAoaW4NCj4+ID4gYWRkaXRp b24gdG8gdGhlIGVycm9yIGNhc2VzIGxpc3RlZCBhYm92ZSkuDQo+PiA+DQo+PiA+DQo+PiA+DQo+ PiA+IE15IGNvbmNlcm4gaXMgbm90IHRoYXQgaXQncyBpbXBvc3NpYmxlIG9yIGV2ZW4gcGFydGlj dWxhcmx5IGhhcmQgdG8gY2F0Y2gNCj4+ID4gdGhlc2UgZXJyb3JzLCBidXQgSSBkaXNsaWtlIHRo ZSBwcm9wZXJ0eSB0aGF0IHNvbWUgKGluIGZhY3QsIG1vc3QpIGVuY29kYWJsZQ0KPj4gPiB2YWx1 ZXMgYXJlIGludmFsaWQuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IEJlc3QsDQo+PiA+DQo+PiA+ IE1hcnRlbg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBPbiBXZWQsIEp1biAy MCwgMjAxOCBhdCAzOjIxIEFNIERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+ DQo+PiA+IHdyb3RlOg0KPj4gPg0KPj4gPiBIaSBJYW4sDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+ IEhlcmUgaXMgYW5vdGhlciBhdHRlbXB0IHRvIHNvbHZlIHRoZSBvYmplY3Rpb25zIHlvdSByYWlz ZWQ6DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+PkknbSBub3QgYSBmYW4gb2YgdGhpcyBwcm9wb3Nh bCwgYmVjYXVzZSBJIHRoaW5rIGl0IGlzIGltcHJhY3RpY2FsIHRvIGRyb3ANCj4+ID4+IHRoZSBu dW1iZXIgb2YgYWNrIGJsb2NrcywgYmVjYXVzZSB3aXRoIHRoZSBFQ04gcHJvcG9zYWwgaXQgYmVj b21lcw0KPj4gPj4gaW1wcmFjdGljYWxseSBjb21wbGV4IHRvIHBhcnNlLg0KPj4gPg0KPj4gPiBJ cyB0aGVyZSBhIHJlYXNvbiB0aGUgcHJvcG9zYWwgZnJvbSBDaHJpc3RpYW4gZG9lcyBub3Qgc29s dmUgdGhpcyBwcm9ibGVtPw0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPj5JZiB3ZSBkb24ndCByZW1v dmUgdGhlIG51bWJlciBvZiBhY2sgYmxvY2tzLCB0aGVuIHRoZSBhY2sgZnJhbWUgaXMgbGFyZ2Vy LA0KPj4gPj4gYnV0IEkgZG9uJ3QgdGhpbmsgdGhlIGV4dHJhIHNpemUgZmllbGQgaXMgdXNlZnVs IGZvciBtb3N0IGltcGxlbWVudGF0aW9ucy4NCj4+ID4+IEFsc28sIGl0IG1lYW5zIHRoZSBsZW5n dGggY2FuIGRpc2FncmVlIHdpdGggdGhlIGFjdHVhbCBsZW5ndGgsIHdoaWNoIGFkZA0KPj4gPj4g Y29tcGxleGl0eSBhbmQgdGhlIHBvc3NpYmlsaXR5IG9mIHdyaXRpbmcgZXJyb3ItcHJvbmUgY29k ZS4gIFRoZSBpZGVhIG9mDQo+PiA+PiBzb21lb25lIG9mZmxvYWRpbmcgYWNrIHByb2Nlc3Npbmcg YW5kIHRoZW4gcHJvY2VlZGluZyB0byB0cnVzdCB0aGUgbGVuZ3RoDQo+PiA+PiBzZWVtcyBsaWtl IHNvbWVvbmUgY291bGQgZ2V0IHdyb25nIGFuZCBjYXVzZSBzb21lIGNvbmNlcm5pbmcgaXNzdWVz Lg0KPj4gPg0KPj4gPiBUaGUgcmlzayBvZiBkaXNhZ3JlZW1lbnQgYmV0d2VlbiBhY2sgYmxvY2tz IGFuZCBhY2sgYmxvY2sgY291bnQgaXMgc2FtZSBhcw0KPj4gPiB0aGUgcmlzayBvZiBkaXNhZ3Jl ZW1lbnQgYmV0d2VlbiBhY2sgYmxvY2tzIGFuZCBhY2sgbGVuZ3RoLiBFaXRoZXIgd2F5IHRoaXMN Cj4+ID4gbmVlZHMgdG8gYmUgY291bnRlZCB1cCB3aGlsZSBjcmVhdGluZyB0aGUgQUNLIGFuZCBj b3VudGVkIGRvd24gd2hpbGUgcGFyc2luZw0KPj4gPiBpdC4gVGhlIHBvc3NpYmlsaXR5IG9mIGVy cm9yIGlzIHRoZSBzYW1lLiBHZXR0aW5nIHRoZSBhY2sgYmxvY2sgY291bnQgd3JvbmcNCj4+ID4g aXMgYXMgcHJvYmxlbWF0aWMgYXMgZ2V0dGluZyB0aGUgYWNrIGxlbmd0aCB3cm9uZy4gRG8geW91 IGFncmVlPw0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPj5NeSBleHBlcmllbmNlIGlzIG11bHRpdGhy ZWFkZWQgcGFja2V0IHByb2Nlc3NpbmcgaXMgbW9yZSBjb3N0IGFuZCB3b3JrIHRoYW4NCj4+ID4+ IGl0J3Mgd29ydGguICBTdXJlIHlvdSBjYW4ndCBmaWxsIGEgMTAwRyBOSUMgd2l0aCBvbmUgY29u bmVjdGlvbiwgYnV0IHRoYXQNCj4+ID4+IHNlZW1zIGxpa2UgYW4gYWNhZGVtaWMgcHJvYmxlbSwg bm90IG9uZSBmb3Igd29ya2xvYWRzIEkndmUgc2Vlbi4gIFR5cGljYWxseQ0KPj4gPj4gdGhlIGV4 dHJhIGNvc3Qgb2YgbXVsdGl0aHJlYWRpbmcgb3V0d2VpZ2hzIGl0cyB2YWx1ZS4NCj4+ID4NCj4+ ID4gVGhlIHZhbHVlIGlzIHR3byBmb2xkIOKAkyBwcmUtcHJvY2Vzc2luZyBhbmQgbXVsdGktdGhy ZWFkaW5nLiBJZiB3ZQ0KPj4gPiBwcmUtcHJvY2VzcyB0aGUgcmVjZWl2ZWQgcGFja2V0cyBzdWNo IHRoYXQgQUNLcyBhbmQgc3RyZWFtcyBjYW4gYmUNCj4+ID4gY29hbGVzY2VkLCB0aGUgcmVjZWl2 ZSBzaWRlIGNhbiBpbmRpY2F0ZSBhIGxhcmdlIGNodW5rIG9mIGluZm9ybWF0aW9uIHRob3VnaA0K Pj4gPiB0aGUga2VybmVsLCByZWR1Y2luZyB0aGUgY29zdCBvZiBzeXN0ZW0gY2FsbCBhbmQgcHJv dG9jb2wgb3ZlcmhlYWQuIFRoaXMgaXMNCj4+ID4gdGhlIHNhbWUgY29uY2VwdCBhcyBVRFAgc2Vn bWVudGF0aW9uIHRha2VuIGEgc3RlcCBmdXJ0aGVyIG9uIHJlY2VpdmUgc2lkZS4NCj4+ID4gQWZ0 ZXIgdGhpcyBjaHVuayBpcyBpbmRpY2F0ZWQgaW50byB0aGUgUVVJQyBwcm90b2NvbCwgdGhlIHBy b3RvY29sIG1heQ0KPj4gPiBwcm9jZXNzIHN0cmVhbSBhbmQgQUNLIGluIHBhcmFsbGVsLiBXaGls ZSBmb2xrcyBtYXkgb3IgbWF5IG5vdCB1dGlsaXplIHRoaXMsDQo+PiA+IHRoZXJlIGlzIGFuIGFk dmFudGFnZSBoZXJlLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBUaGFua3MsDQo+PiA+DQo+PiA+ IE1hbmFzaQ0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBGcm9tOiBJYW4gU3dl dHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KPj4gPiBTZW50OiBUdWVzZGF5LCBKdW5l IDE5LCAyMDE4IDExOjI2IEFNDQo+PiA+IFRvOiBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuLmRldmFs QGludGVsLmNvbT4NCj4+ID4gQ2M6IE1hcnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVtYW5uQGdtYWls LmNvbT47IEthenVobyBPa3UNCj4+ID4gPGthenVob29rdUBnbWFpbC5jb20+OyBFcmljIFJlc2Nv cmxhIDxla3JAcnRmbS5jb20+OyBKYW5hIEl5ZW5nYXINCj4+ID4gPGpyaS5pZXRmQGdtYWlsLmNv bT47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgSUVURg0K Pj4gPiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9t c29uQGdtYWlsLmNvbT4NCj4+ID4NCj4+ID4NCj4+ID4gU3ViamVjdDogUmU6IFByb3Bvc2FsIHRv IHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KPj4gPg0KPj4gPg0KPj4g Pg0KPj4gPiBJJ20gc3RpbGwgbm90IGludGVyZXN0ZWQgaW4gdGhpcyBjaGFuZ2UsIGZvciB0aGUg cmVhc29ucyBJIHN0YXRlZCBhYm92ZS4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gT24gVHVlLCBK dW4gMTksIDIwMTggYXQgMjoyMSBQTSBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwu Y29tPg0KPj4gPiB3cm90ZToNCj4+ID4NCj4+ID4gSGkgQWxsLA0KPj4gPg0KPj4gPg0KPj4gPg0K Pj4gPiBEbyB3ZSBoYXZlIGFncmVlbWVudCBoZXJlIHRvIGNyZWF0ZSBhIG5ldyBQUj8NCj4+ID4N Cj4+ID4NCj4+ID4NCj4+ID4gVGhhbmtzLA0KPj4gPg0KPj4gPiBNYW5hc2kNCj4+ID4NCj4+ID4N Cj4+ID4NCj4+ID4gRnJvbTogRGV2YWwsIE1hbmFzaQ0KPj4gPiBTZW50OiBTdW5kYXksIEp1bmUg MTcsIDIwMTggMjoyNSBQTQ0KPj4gPiBUbzogTWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1hbm5A Z21haWwuY29tPjsgS2F6dWhvIE9rdQ0KPj4gPiA8a2F6dWhvb2t1QGdtYWlsLmNvbT4NCj4+ID4g Q2M6IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPjsgRXJp YyBSZXNjb3JsYQ0KPj4gPiA8ZWtyQHJ0Zm0uY29tPjsgSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBn bWFpbC5jb20+OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KPj4gPiA8cHJhdmJAbWljcm9zb2Z0 LmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29uDQo+PiA+ IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQo+PiA+IFN1YmplY3Q6IFJFOiBQcm9wb3NhbCB0 byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGgNCj4+ID4NCj4+ID4NCj4+ ID4NCj4+ID4gSGkgQWxsLA0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBJIGhhdmUgbWFkZSBhIGxp c3Qgb2Ygb2JqZWN0aW9ucyB0byB0aGUgcHJvcG9zYWwgYW5kIHRoZSBzb2x1dGlvbnMgdG8gdGhv c2UNCj4+ID4gb2JqZWN0aW9ucyBkaXNjdXNzZWQgb24gdGhpcyB0aHJlYWQuDQo+PiA+DQo+PiA+ DQo+PiA+DQo+PiA+IGEuICAgICAgQ28tZXhpc3RlbmNlIG9mIGxlbmd0aCBmaWVsZCB3aXRoIEVD TiBmaWVsZCBhbmQgQUNLIGJsb2Nrcy4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gQ2hyaXN0aWFu IHN1Z2dlc3RlZCB0byBtb3ZlIHRoZSBFQ04gZmllbGRzIHRvIHByZWNlZGUgdGhlIEFDSyBibG9j a3MuIFRoaXMNCj4+ID4gaXMgYW4gZWxlZ2FudCBzb2x1dGlvbi4gUGFyc2luZyBlbnRpcmUgbGlz dCBvZiBBQ0sgYmxvY2tzIHRvIHJldmlldyBFQ04gYml0cw0KPj4gPiB3b3VsZCBoYXZlIGJlZW4g YW5ub3lpbmcsIGV2ZW4gdGhvdWdoIGl0IGNhbiB3b3JrLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4g PiBiLiAgICAgIFRoZXJlIGFyZSB0d28gY2FzZXMgdG8gYmUgcGFyc2VkIOKAkyBlbnRpcmUgQUNL IGFuZCBwYXJzZSBBQ0sgdG8NCj4+ID4gaWRlbnRpZnkgbGVuZ3RoLiBUaGVyZSBhcmUgc29tZSBy ZXNlcnZhdGlvbnMgd2hlbiBBQ0sgcGFyc2luZyBnZXRzIGhhcmRlcg0KPj4gPiBmb3IgdGhlIGNh c2Ugd2hlcmUgdGhlIGVudGlyZSBoZWFkZXIgbmVlZHMgdG8gYmUgcGFyc2VkLg0KPj4gPg0KPj4g Pg0KPj4gPg0KPj4gPiBBZ3JlZW1lbnQgZnJvbSBzZXZlcmFsIGZvbGtzIGhlcmUuIEluIHRoZSBv cmlnaW5hbCBBQ0sgZGVmaW5lZCBpbiBkcmFmdCAxMg0KPj4gPiBvZiB0aGUgc2xpZGUsIG9uZSB3 b3VsZCBjb3VudCBkb3duIG51bWJlciBvZiBBQ0sgYmxvY2tzIHRvIGdldCB0byB0aGUgZW5kIG9m DQo+PiA+IHRoZSBwYWNrZXQuIEluIHRoZSBwcm9wb3NhbCBJIG1hZGUsIG9uZSB3b3VsZCBjb3Vu dCBkb3duIHRoZSBsZW5ndGggdG8NCj4+ID4gaWRlbnRpZnkgdGhlIGVuZCBvZiB0aGUgcGFja2V0 LiBUaGUgbG9naWMgaXMgdmVyeSBzaW1pbGFyIGluIGN5Y2xlIGNvdW50IGFuZA0KPj4gPiBjb21w bGV4aXR5LiBTZXZlcmFsIGZvbGtzIGFsc28gY29tbWVudGVkIHRvIHRoaXMgZWZmZWN0Lg0KPj4g Pg0KPj4gPg0KPj4gPg0KPj4gPiBjLiAgICAgIE11bHRpLXRocmVhZGVkIHBhY2tldCBwcm9jZXNz aW5nDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IEkgd291bGQgZXhwZWN0IHRoYXQgdGhlcmUgYXJl IDEwcyBvZiAxMDAwcyBvZiBjb25uZWN0aW9ucyBpbiB1c2UgYXQgYW55IHRpbWUNCj4+ID4gZm9y IGEgc2VydmVyIHdpdGggYSBoaWdoIHNwZWVkIGxpbmsuIE11bHRpLXRocmVhZGluZyB0byBoYW5k bGUgZWFjaCBvZiB0aGVzZQ0KPj4gPiBmbG93cyAvIGNvbm5lY3Rpb25zIGluIHBhcmFsbGVsIGlz IG5lY2Vzc2l0eSB0byBiZSBhYmxlIHRvIHN1cHBvcnQgbGFyZ2UNCj4+ID4gbnVtYmVyIG9mIGNv bm5lY3Rpb25zIG9uIGEgaGlnaCBzcGVlZCBsaW5rLiBUeCBzZWdtZW50YXRpb24sIFJ4IGNvYWxl c2NpbmcNCj4+ID4gYXJlIHdlbGwga25vd24gc3RyYXRlZ2llcyB0byByZWR1Y2UgdGhlIHByb2Nl c3NpbmcgY29zdC4gSW4gaW5pdGlhbCBzdGFnZXMsDQo+PiA+IGNvZGUgaXMgb2Z0ZW4gd3JpdHRl biBhcyBhIHNpbmdsZS10aHJlYWRlZCBhbmQgdGhlbiByZS1mYWN0b3JlZCB0bw0KPj4gPiBwYXJh bGxlbGl6ZSBjeWNsZSBpbnRlbnNpdmUgb3BlcmF0aW9ucy4gSW4gb3JkZXIgdG8gYWxsb3cgdGhp cyBwcm90b2NvbCB0bw0KPj4gPiBzY2FsZSBpbiBmdXR1cmUsIEkgd291bGQgc3VnZ2VzdCB3ZSBk byBub3QgcHJlY2x1ZGUgdGhpcyBjYXNlLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBkLiAgICAg IEluY3JlYXNlIGluIEFDSyBzaXplIGJ5IDEgYnl0ZS4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4g SSBkbyBub3Qgc2VlIHRoaXMgYXMgYSBzZXJpb3VzIGlzc3VlIGJ1dCBpZiBmb2xrcyBidXQgd2Ug Y2FuIGNvbnNpZGVyIG1ha2luZw0KPj4gPiB0aGlzIGEgdmFyaW50LCBpZiBvdGhlcnMgaGF2ZSBz dHJvbmcgZmVlbGluZ3MgYWJvdXQgaXQuIEl04oCZcyBhIHRyYWRlLW9mZiA6IDINCj4+ID4gcmVh ZHMgdG8gc2F2ZSAxIGJ5dGUuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IGUuICAgICAgRXZlcnkg ZW5jb2RhYmxlIHZhbHVlIHNob3VsZCBiZSB2YWxpZA0KPj4gPg0KPj4gPiBOb3QgZXZlcnkgbGVu Z3RoIHdpbGwgYmUgdmFsaWQuIFRoaXMgaXMgaW5oZXJlbnQgdG8gbGVuZ3Rocy4gVGhpcyBzYW1l IGlzc3VlDQo+PiA+IGFpbHMgdGhlIOKAmHBheWxvYWQgbGVuZ3Ro4oCZIGluIFFVSUMgaGVhZGVy LiBOb3Qgb25seSBkb2VzIHRoZSBpc3N1ZSBleGlzdCBmb3INCj4+ID4gc21hbGwgdmFsdWVzLCBp dCBhbHNvIGFwcGxpZXMgdG8gbGFyZ2UgdmFsdWVzIHNpbmNlIGRhdGEgc3RyZWFtIHdpbGwgYmUg c2VudA0KPj4gPiBhZnRlciBjcnlwdG8gbmVnb3RpYXRpb24uICBFLmcuICAtIGhvdyBkb2VzIG9u ZSBjcmFmdCBhIHBheWxvYWQgd2l0aCA2MiBiaXQNCj4+ID4gcGF5bG9hZCBsZW5ndGggaW4gYSBs YXJnZSBoZWFkZXI/DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IFRoYW5rcywN Cj4+ID4NCj4+ID4gTWFuYXNpDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IEZy b206IE1hcnRlbiBTZWVtYW5uIFttYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb21dDQo+PiA+ IFNlbnQ6IFN1bmRheSwgSnVuZSAxNywgMjAxOCA2OjU5IEFNDQo+PiA+IFRvOiBLYXp1aG8gT2t1 IDxrYXp1aG9va3VAZ21haWwuY29tPg0KPj4gPiBDYzogSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdv b2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+OyBFcmljIFJlc2NvcmxhDQo+PiA+IDxla3JAcnRmbS5j b20+OyBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbT47IFByYXZlZW4gQmFsYXN1YnJh bWFuaWFuDQo+PiA+IDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGll dGYub3JnPjsgTWFydGluIFRob21zb24NCj4+ID4gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47 IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+DQo+PiA+IFN1YmplY3Q6IFJl OiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGgNCj4+ ID4NCj4+ID4NCj4+ID4NCj4+ID4gTWF5YmUgaXQncyBzcGVjaWZpYyB0byBHbywgYnV0IEknbSB1 c2luZyBhIHNpbmdsZSBpby5SZWFkZXIgZm9yIHRoZSB3aG9sZQ0KPj4gPiBwYWNrZXQsIHNvIGFz IGxvbmcgYXMgdGhlIHBhY2tldCBwYXlsb2FkIGlzIGxvbmcgZW5vdWdoLCB0aGUgdmFyaW50IHBh cnNpbmcNCj4+ID4gd2lsbCBub3QgZmFpbC4NCj4+ID4NCj4+ID4gSSBkb24ndCB0aGluayB0aGF0 IHNwZWNpZmljcyBvZiBwcm9ncmFtbWluZyBsYW5ndWFnZXMgbWF0dGVyIGhlcmUgdGhvdWdoLA0K Pj4gPiBhbmQgSSdtIHN1cmUgYm90aCBmcmFtZSBmb3JtYXRzIGNhbiBiZSByZWFzb25hYmx5IGlt cGxlbWVudGVkIGluIEMgYXMgd2VsbA0KPj4gPiBhcyBpbiBHby4gVGhlIHJlYXNvbnMgSSdtIG9w cG9zZWQgdG8gTWFuYXNpJ3MgcHJvcG9zYWwgYXJlIHRoYXQgaXQgbW92ZXMgdXMNCj4+ID4gYXdh eSBmcm9tIHRoZSBwcmluY2lwbGUgdGhhdCBvbmx5IHJlYXNvbmFibGUgdmFsdWVzIHNob3VsZCBi ZSBlbmNvZGFibGUsIGFuZA0KPj4gPiB0aGF0IGl0IGluY3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUg QUNLIGZyYW1lLCBmb3IgdGhlIHF1ZXN0aW9uYWJsZSBiZW5lZml0IG9mDQo+PiA+IGJlaW5nIGFi bGUgdG8gcGFyYWxsZWxpc2UgdGhlIGZyYW1lIHBhcnNlci4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ ID4gT24gU3VuLCBKdW4gMTcsIDIwMTggYXQgODo0OCBQTSBLYXp1aG8gT2t1IDxrYXp1aG9va3VA Z21haWwuY29tPiB3cm90ZToNCj4+ID4NCj4+ID4gMjAxOC0wNi0xNyAyMjozNiBHTVQrMDk6MDAg TWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1hbm5AZ21haWwuY29tPjoNCj4+ID4+IEF0IGxlYXN0 IGZvciBteSBpbXBsZW1lbnRhdGlvbiwgcGFyc2luZyBkb2Vzbid0IGJlY29tZSBlYXNpZXIsIGl0 IGJlY29tZXMNCj4+ID4+IG1vcmUgY29tcGxleCB3aXRoIHRoaXMgcHJvcG9zYWwuIE15IHZhcmlu dC1wYXJzZXIgYWx3YXlzIGNvbnN1bWVzIGFzIG1hbnkNCj4+ID4+IGJ5dGVzIGFzIHRoZSB2YXJp bnQgcmVxdWlyZXMsIHNvIGFmdGVyIHBhcnNpbmcgYSB2YXJpbnQsIEknZCBoYXZlIHRvDQo+PiA+ PiBpbnRyb2R1Y2UgYW4gYWRkaXRpb25hbCBjaGVjayB0aGF0IHRoaXMgZGlkbid0IG92ZXJmbG93 IHRoZSBBQ0sgbGVuZ3RoDQo+PiA+PiAoZS5nLg0KPj4gPj4gY29uc2lkZXIgdGhhdCBJIHBhcnNl ZCB0aGUgQUNLIGZyYW1lIHNvIGZhciB0aGF0IG9ubHkgMiBieXRlcyBhcmUNCj4+ID4+IHJlbWFp bmluZw0KPj4gPj4gYWNjb3JkaW5nIHRvIEFDSyBsZW5ndGggZmllbGQsIGJ1dCB0aGUgbmV4dCB2 YXJpbnQgaXMgNCBieXRlcyBsb25nKS4NCj4+ID4NCj4+ID4gSXNuJ3QgeW91ciB2YXJpbnQgcGFy c2VyIGNoZWNraW5nIHRoYXQgaXQgaGFzIG5vdCAob3Igd2lsbCBub3QpIHJ1bg0KPj4gPiBhY3Jv c3MgdGhlIGVuZCBvZiB0aGUgcGFja2V0IHBheWxvYWQgZm9yIGV2ZXJ5IEFDSyBibG9jayBpdCBw YXJzZXM/DQo+PiA+IEknZCBhc3N1bWUgdGhhdCB5b3Ugd291bGQgYmUgZG9pbmcgdGhhdCwgYmVj YXVzZSBJIHRoaW5rIHRoYXQgaXMNCj4+ID4gbmVjZXNzYXJ5IHRvIGF2b2lkIGJ1ZmZlciBvdmVy cnVuLg0KPj4gPg0KPj4gPiBXaGF0IEkgYW0gc2F5aW5nIHRoYXQgdGhhdCBjaGVjayBjb3VsZCBi ZSBjb252ZXJ0ZWQgdG8gYSBvdmVycnVuIGNoZWNrDQo+PiA+IGFnYWluc3QgdGhlIGVuZCBvZiB0 aGUgImZyYW1lIHBheWxvYWQiLCBhbmQgdGhhdCBjaGVja2luZyB0aGUNCj4+ID4gcmVtYWluaW5n IGJsb2NrIGNvdW50IGJlY29tZXMgdW5uZWNlc3NhcnksIGluIGNhc2Ugd2UgcmVwbGFjZSBBQ0sN Cj4+ID4gQmxvY2sgQ291bnQgd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLg0KPj4gPg0KPj4gPj4NCj4+ ID4+IEluIGdlbmVyYWwsIHdlJ3ZlIGJlZW4gbW92aW5nIHRoZSB3aXJlIGltYWdlIHRvd2FyZHMg bWFraW5nIGV2ZXJ5DQo+PiA+PiBlbmNvZGFibGUNCj4+ID4+IHZhbHVlIHZhbGlkLiBUaGlzIHBy b3Bvc2FsIG1vdmVzIHVzIGF3YXkgZnJvbSB0aGF0IHByaW5jaXBsZToNCj4+ID4+ICogc29tZSBz bWFsbCB2YWx1ZXMgYXJlIGFsd2F5cyBpbnZhbGlkICh0aGUgbGVuZ3RoIGNhbiBuZXZlciBiZSBi ZXR3ZWVuIDANCj4+ID4+IGFuZCAzKQ0KPj4gPj4gKiBhIGxvdCBvZiBpbnRlcm1lZGlhdGUgdmFs dWVzIGFyZSBpbnZhbGlkIChpZiB0aGUgYm91bmRhcnkgZmFsbHMgaW5zaWRlIGENCj4+ID4+IHZh cmludCwgYXMgZGVzY3JpYmVkIGFib3ZlKQ0KPj4gPj4gQm90aCB0aGVzZSBjYXNlcyBjYW4ndCBv Y2N1ciB3aXRoIHRoZSBjdXJyZW50IEFDSyBmcmFtZSBmb3JtYXQuLg0KPj4gPj4NCj4+ID4+IE9u IFN1biwgSnVuIDE3LCAyMDE4IGF0IDc6NTQgUE0gS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWls LmNvbT4gd3JvdGU6DQo+PiA+Pj4NCj4+ID4+PiAyMDE4LTA2LTE3IDg6MzQgR01UKzA5OjAwIElh biBTd2V0dA0KPj4gPj4+IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+Og0K Pj4gPj4+ID4gSSdtIG5vdCBhIGZhbiBvZiB0aGlzIHByb3Bvc2FsLCBiZWNhdXNlIEkgdGhpbmsg aXQgaXMgaW1wcmFjdGljYWwgdG8NCj4+ID4+PiA+IGRyb3ANCj4+ID4+PiA+IHRoZSBudW1iZXIg b2YgYWNrIGJsb2NrcywgYmVjYXVzZSB3aXRoIHRoZSBFQ04gcHJvcG9zYWwgaXQgYmVjb21lcw0K Pj4gPj4+ID4gaW1wcmFjdGljYWxseSBjb21wbGV4IHRvIHBhcnNlLg0KPj4gPj4+DQo+PiA+Pj4g Rm9yIHRoZSBFQ04gcHJvcG9zYWwsIGFzIENocmlzdGlhbiBoYXMgc3VnZ2VzdGVkLCB3ZSBjYW4g bW92ZSB0aGUgRUNODQo+PiA+Pj4gY291bnRlcnMgYmVmb3JlIHRoZSBBQ0sgYmxvY2tzLiBUaGVu LCBpdCB3b3VsZCBub3QgYmUgY29tcGxleCB0bw0KPj4gPj4+IHBhcnNlLg0KPj4gPj4+DQo+PiA+ Pj4gQW5kIG15IHZpZXcgaXMgdGhhdCBwYXJzaW5nIGJlY29tZXMgZWFzaWVyIGlmIHdlIHJlcGxh Y2UgQUNLIEJsb2NrDQo+PiA+Pj4gQ291bnQgd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLg0KPj4gPj4+ DQo+PiA+Pj4gTm93LCB3aXRoIEFDSyBCbG9jayBDb3VudCwgd2UgbmVlZCB0byBjaGVjayB0aGUg cmVtYWluaW5nIG51bWJlciBvZg0KPj4gPj4+IGJsb2NrcyBhbmQgdGhlIHJlbWFpbmluZyBzcGFj ZSBpbiB0aGUgcGFja2V0IHBheWxvYWQgZm9yIGV2ZXJ5IGJsb2NrDQo+PiA+Pj4gdGhhdCB3ZSBw YXJzZS4gRmFpbGluZyB0byBjaGVjayBlaXRoZXIgbGVhZHMgdG8gYSBidWcgb3IgYSBzZWN1cml0 eQ0KPj4gPj4+IGlzc3VlLg0KPj4gPj4+DQo+PiA+Pj4gSWYgd2Ugc3dpdGNoIHRvIEFDSyBGcmFt ZSBMZW5ndGgsIHdlIG5lZWQgdG8gb25seSBjaGVjayB0aGUgcmVtYWluaW5nDQo+PiA+Pj4gc3Bh Y2UgaW4gdGhlIGZyYW1lLg0KPj4gPj4+DQo+PiA+Pj4gSSB0aGluayB0aGF0IHRoaXMgaXMgdGhl IGJpZ2dlc3QgYmVuZWZpdCBvZiByZXBsYWNpbmcgQUNLIEJsb2NrIENvdW50DQo+PiA+Pj4gd2l0 aCBBQ0sgRnJhbWUgTGVuZ3RoLiBPVE9IIHRoZSBkb3duc2lkZSBpcyB0aGF0IHlvdSBuZWVkIGV4 dHJhIG9uZSB0bw0KPj4gPj4+IHR3byBiaXRzIChvbmUgaWYgdGhlIHNpemUgb2YgYmxvY2sgLyBn YXAgaXMgZXhwZWN0ZWQgdG8gYmUgYmVsb3cgNjUsDQo+PiA+Pj4gdHdvIGlmIHRoZXkgYXJlIGV4 cGVjdGVkIHRvIGJlIGFib3ZlIHRoYXQpIGZvciBlbmNvZGluZyBBQ0sgRnJhbWUNCj4+ID4+PiBM ZW5ndGggY29tcGFyZWQgdG8gQUNLIEJsb2NrIENvdW50Lg0KPj4gPj4+DQo+PiA+Pj4NCj4+ID4+ Pg0KPj4gPj4+IEhhdmluZyBzYWlkIHRoYXQsIEkgaG9uZXN0bHkgd29uZGVyIGlmIGFsbCB0aGUg ZnJhbWVzIGNvdWxkIGhhdmUgaXQncw0KPj4gPj4+IGxlbmd0aCBiZWluZyBlbmNvZGVkIChlaXRo ZXIgZXhwbGljaXRseSBvciBlaXRoZXIgYXMgYSBzaWduYWwgdGhhdA0KPj4gPj4+IHNheXMgInRv IHRoZSBlbmQgb2YgdGhlIHBhY2tldCIpLiBDb25zaWRlciBzb21ldGhpbmcgbGlrZSBiZWxvdzoN Cj4+ID4+Pg0KPj4gPj4+IHwwfCBmcmFtZS10eXBlICg3KSB8IGZyYW1lLXBheWxvYWQtbGVuZ3Ro IChpKSB8IGZyYW1lLXBheWxvYWQgKCopIHwNCj4+ID4+PiAgb3INCj4+ID4+PiB8MXwgZnJhbWUt dHlwZSAoNykgfCBmcmFtZS1wYXlsb2FkICgqKSB8DQo+PiA+Pj4NCj4+ID4+PiBXaGVuIE1TQiBv ZiB0aGUgZmlyc3Qgb2N0ZXQgc2V0IHRvIHplcm8sIHRoZSBsZW5ndGggb2YgdGhlIGZyYW1lDQo+ PiA+Pj4gcGF5bG9hZCBpcyBkZXNpZ25hdGVkIGJ5IHRoZSB2YXJpbnQgdGhhdCBpbW1lZGlhdGVs eSBmb2xsb3dzIHRoZSBmcmFtZQ0KPj4gPj4+IHR5cGUuDQo+PiA+Pj4gV2hlbiBNU0Igb2YgdGhl IGZpcnN0IG9jdGV0IHNldCB0byBvbmUsIHRoZSBsZW5ndGggb2YgdGhlIGZyYW1lDQo+PiA+Pj4g cGF5bG9hZCBzcGFucyB0byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQuDQo+PiA+Pj4NCj4+ID4+PiBJ biB0aGlzIGVuY29kaW5nLCB3ZSBjYW4gYWx3YXlzIG9taXQgdGhlIExlbmd0aCBmaWVsZCBvZiBh IFNUUkVBTQ0KPj4gPj4+IGZyYW1lLiBTbyB0aGUgb3ZlcmhlYWQgZm9yIGNhcnJ5aW5nIHN0cmVh bSBkYXRhIHdpbGwgYmUgaW5kaWZmZXJlbnQgaW4NCj4+ID4+PiBwcmFjdGljZS4NCj4+ID4+Pg0K Pj4gPj4+IEZvciB0aGUgQUNLIGZyYW1lLCB3ZSBjYW4gb21pdCB0aGUgQUNLIEJsb2NrIENvdW50 IGZpZWxkLiBBbmQgdGhlDQo+PiA+Pj4gb3ZlcmhlYWQgd2lsbCBiZSBvbmUgdG8gdHdvIGJpdHMg aWYgdGhlIEFDSyBmcmFtZSBpcyBzZW50IGluIHRoZQ0KPj4gPj4+IG1pZGRsZSBvZiB0aGUgcGFj a2V0ICh0aGVyZWJ5IHVzaW5nIHRoZSBlbmNvZGluZyB3aXRoIGV4cGxpY2l0IGZyYW1lDQo+PiA+ Pj4gcGF5bG9hZCBsZW5ndGgpLCBvciBvbmUgb2N0ZXQgb3IgbW9yZSBzaG9ydGVyIGlmIEFDSyBp cyB0aGUgbGFzdCBmcmFtZQ0KPj4gPj4+IG9mIHRoZSBwYWNrZXQuDQo+PiA+Pj4NCj4+ID4+PiBX ZSBhcmUgbGlrZWx5IHRvIHNlZSBpbmNyZWFzZSBvZiBvdmVyaGVhZCBmb3IgbW9zdCBvZiB0aGUg b3RoZXIgdHlwZXMNCj4+ID4+PiBvZiBmcmFtZXMsIGJ1dCBJIGRvIG5vdCB0aGluayB0aGF0IHdv dWxkIGJlIGFuIGlzc3VlIGNvbnNpZGVyaW5nIHRoYXQNCj4+ID4+PiB0aGV5IHdpbGwgYmUgZmFy IHNlbGRvbSBzZWVuIGNvbXBhcmVkIHRvIFNUUkVBTXMgYW5kIEFDS3MuDQo+PiA+Pj4NCj4+ID4+ PiBUbyBzdW1tYXJpemUsIG15IGFudGljaXBhdGlvbiBpcyB0aGF0IHdlIGNhbiBtYWtlIGFsbCB0 aGUgZnJhbWVzDQo+PiA+Pj4gc2VsZi1jb250YWluZWQgKGkuZS4gdGhlIGxlbmd0aCBjYW4gYmUg ZGV0ZXJtaW5lZCB3aXRob3V0IHRoZQ0KPj4gPj4+IGtub3dsZWRnZSBvZiBob3cgZWFjaCBmcmFt ZSBpcyBlbmNvZGVkKSB3aXRob3V0IGFueSBvdmVyaGVhZCwgaWYgd2UNCj4+ID4+PiBhZ3JlZSBv biBtYWtpbmcgdGhlIGZyYW1lIHR5cGUgc3BhY2UgMSBiaXQgc21hbGxlci4NCj4+ID4+Pg0KPj4g Pj4+IEZpbmFsbHksIHRoZSBiaWdnZXN0IGJlbmVmaXQgb2YgdXNpbmcgYSBzZWxmLWNvbnRhaW5l ZCBlbmNvZGluZyBvZg0KPj4gPj4+IGZyYW1lcyBpcyB0aGF0IHdlIHdvdWxkIGhhdmUgdGhlIGFi aWxpdHkgdG8gaW50cm9kdWNlIG5ldyBvcHRpb25hbA0KPj4gPj4+IGZyYW1lcyB3aXRob3V0IG5l Z290aWF0aW9uLiBCeSBtYWtpbmcgdGhlIGZyYW1lcyBzZWxmLWNvbnRhaW5lZCwgUVVJQw0KPj4g Pj4+IGVuZHBvaW50cyB3aWxsIGhhdmUgdGhlIGZyZWVkb20gb2YgaWdub3JpbmcgdGhlIGZyYW1l cyB0aGF0IHRoZXkgZG8NCj4+ID4+PiBub3QgdW5kZXJzdGFuZC4NCj4+ID4+Pg0KPj4gPj4+IEJl aW5nIGFibGUgdG8gc2VuZCBRVUlDIGZyYW1lcyBkZWZpbmVkIGluIGV4dGVuc2lvbnMgd2l0aG91 dA0KPj4gPj4+IG5lZ290aWF0aW5nIHVzaW5nIFRyYW5zcG9ydCBQYXJhbWV0ZXJzIHdpbGwgYmUg YSB3aW4gaW4gYm90aCB0ZXJtcyBvZg0KPj4gPj4+IHNlY3VyaXR5IChiZWNhdXNlIGNsaWVudHMn IFRQIGlzIHNlbnQgaW4gY2xlYXIpIGFuZCBmbGV4aWJpbGl0eQ0KPj4gPj4+IChiZWNhdXNlIHdl IHdpbGwgYmUgcG9zc2libGUgdG8gc2VuZCB0aGUgZXh0ZW5zaW9ucyBiZWZvcmUgd2UgZmlndXJl DQo+PiA+Pj4gb3V0IHdoZXRoZXIgdGhlIHBlZXIgc3VwcG9ydHMgdGhhdCBleHRlbnNpb24pLg0K Pj4gPj4+DQo+PiA+Pj4gPiBJZiB3ZSBkb24ndCByZW1vdmUgdGhlIG51bWJlciBvZiBhY2sgYmxv Y2tzLCB0aGVuIHRoZSBhY2sgZnJhbWUgaXMNCj4+ID4+PiA+IGxhcmdlciwNCj4+ID4+PiA+IGJ1 dCBJIGRvbid0IHRoaW5rIHRoZSBleHRyYSBzaXplIGZpZWxkIGlzIHVzZWZ1bCBmb3IgbW9zdA0K Pj4gPj4+ID4gaW1wbGVtZW50YXRpb25zLg0KPj4gPj4+ID4gQWxzbywgaXQgbWVhbnMgdGhlIGxl bmd0aCBjYW4gZGlzYWdyZWUgd2l0aCB0aGUgYWN0dWFsIGxlbmd0aCwgd2hpY2gNCj4+ID4+PiA+ IGFkZA0KPj4gPj4+ID4gY29tcGxleGl0eSBhbmQgdGhlIHBvc3NpYmlsaXR5IG9mIHdyaXRpbmcg ZXJyb3ItcHJvbmUgY29kZS4gIFRoZSBpZGVhDQo+PiA+Pj4gPiBvZg0KPj4gPj4+ID4gc29tZW9u ZSBvZmZsb2FkaW5nIGFjayBwcm9jZXNzaW5nIGFuZCB0aGVuIHByb2NlZWRpbmcgdG8gdHJ1c3Qg dGhlDQo+PiA+Pj4gPiBsZW5ndGgNCj4+ID4+PiA+IHNlZW1zIGxpa2Ugc29tZW9uZSBjb3VsZCBn ZXQgd3JvbmcgYW5kIGNhdXNlIHNvbWUgY29uY2VybmluZyBpc3N1ZXMuDQo+PiA+Pj4gPg0KPj4g Pj4+ID4gTXkgZXhwZXJpZW5jZSBpcyBtdWx0aXRocmVhZGVkIHBhY2tldCBwcm9jZXNzaW5nIGlz IG1vcmUgY29zdCBhbmQgd29yaw0KPj4gPj4+ID4gdGhhbg0KPj4gPj4+ID4gaXQncyB3b3J0aC4g IFN1cmUgeW91IGNhbid0IGZpbGwgYSAxMDBHIE5JQyB3aXRoIG9uZSBjb25uZWN0aW9uLCBidXQN Cj4+ID4+PiA+IHRoYXQNCj4+ID4+PiA+IHNlZW1zIGxpa2UgYW4gYWNhZGVtaWMgcHJvYmxlbSwg bm90IG9uZSBmb3Igd29ya2xvYWRzIEkndmUgc2Vlbi4NCj4+ID4+PiA+IFR5cGljYWxseQ0KPj4g Pj4+ID4gdGhlIGV4dHJhIGNvc3Qgb2YgbXVsdGl0aHJlYWRpbmcgb3V0d2VpZ2hzIGl0cyB2YWx1 ZS4NCj4+ID4+PiA+DQo+PiA+Pj4gPiBUbyBiZSBjbGVhciwgSSBkb24ndCB0aGluayB0aGlzIGlz IGFuIGF3ZnVsIGlkZWEsIGJ1dCBJIGFsc28gZG9uJ3Qgc2VlDQo+PiA+Pj4gPiB0aGUNCj4+ID4+ PiA+IHZhbHVlIGFuZCBpdCBhZGRzIGNvbXBsZXhpdHkuICBJIHJlYWQgTWFuYXNpJ3MgZW1haWws IGJ1dCBJIGRvbid0IHRoaW5rDQo+PiA+Pj4gPiBJDQo+PiA+Pj4gPiB1bmRlcnN0YW5kIHdoeSBh bnkgb2YgdGhvc2UgbWF0dGVyIGluIHByYWN0aWNlLg0KPj4gPj4+ID4NCj4+ID4+PiA+IE9uIFNh dCwgSnVuIDE2LCAyMDE4IGF0IDQ6MTMgUE0gRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPiB3 cm90ZToNCj4+ID4+PiA+Pg0KPj4gPj4+ID4+IE9uIEZyaSwgSnVuIDE1LCAyMDE4IGF0IDY6NDYg UE0sIE1hcnRlbiBTZWVtYW5uDQo+PiA+Pj4gPj4gPG1hcnRlbnNlZW1hbm5AZ21haWwuY29tPg0K Pj4gPj4+ID4+IHdyb3RlOg0KPj4gPj4+ID4+Pg0KPj4gPj4+ID4+PiBUaGlzIHByb3Bvc2FsIGlu Y3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUgQUNLIGZyYW1lIGJ5IDEgYnl0ZSBpbiB0aGUNCj4+ID4+ PiA+Pj4gY29tbW9uDQo+PiA+Pj4gPj4+IGNhc2UgKGxlc3MgdGhhbiA2MyBBQ0sgcmFuZ2VzKSwg c2luY2UgdGhlIEFDSyBsZW5ndGggZmllbGQgaGVyZQ0KPj4gPj4+ID4+PiBhbHdheXMNCj4+ID4+ PiA+Pj4gY29uc3VtZXMgMiBieXRlcywgd2hlcmVhcyB0aGUgQUNLIEJsb2NrIENvdW50IGlzIGEg dmFyaWFibGUtbGVuZ3RoDQo+PiA+Pj4gPj4+IGludGVnZXIuDQo+PiA+Pj4gPj4+IENvbnNpZGVy aW5nIGhvdyBtdWNoIHdvcmsgd2UgcHV0IGludG8gbWluaW1pc2luZyB0aGUgc2l6ZSBvZiB0aGUN Cj4+ID4+PiA+Pj4gZnJhbWVzLA0KPj4gPj4+ID4+PiB0aGlzIGZlZWxzIGxpa2UgYSBzdGVwIGlu IHRoZSB3cm9uZyBkaXJlY3Rpb24uLg0KPj4gPj4+ID4+Pg0KPj4gPj4+ID4+PiBSZWdhcmRpbmcg dGhlIHByb2Nlc3NpbmcgY29zdCwgSSBhZ3JlZSB3aXRoIERtaXRyaS4gSGFuZGxpbmcgYW4gQUNL DQo+PiA+Pj4gPj4+IGZyYW1lDQo+PiA+Pj4gPj4+IHJlcXVpcmVzIGxvb3Bpbmcgb3ZlciBhbmQg bWFraW5nIGNoYW5nZXMgdG8gYSBkYXRhIHN0cnVjdHVyZSB0aGF0DQo+PiA+Pj4gPj4+IGtlZXBz DQo+PiA+Pj4gPj4+IHRyYWNrIG9mIHNlbnQgcGFja2V0cy4gVGhpcyBpcyBtdWNoIG1vcmUgZXhw ZW5zaXZlIHRoYW4gc2ltcGx5DQo+PiA+Pj4gPj4+IHBhcnNpbmcNCj4+ID4+PiA+Pj4gYQ0KPj4g Pj4+ID4+PiBidW5jaCBvZiB2YXJpbnRzIGluIHRoZSBBQ0sgZnJhbWUuIEl0IHNlZW1zIHVubGlr ZWx5IHRoYXQgYQ0KPj4gPj4+ID4+PiBtdWx0aS10aHJlYWRlZA0KPj4gPj4+ID4+PiBwYWNrZXQg cGFyc2VyIHdvdWxkIG9mZmVyIGFueSByZWFsLXdvcmxkIHBlcmZvcm1hbmNlIGJlbmVmaXRzLg0K Pj4gPj4+ID4+DQo+PiA+Pj4gPj4NCj4+ID4+PiA+PiBJIGRvbid0IHdhbnQgdG8gb3ZlcnN0YXRl IHRoZSBiZW5lZml0IGhlcmUsIGJ1dCBteSBwb2ludCBpc24ndCB0aGF0DQo+PiA+Pj4gPj4gcGFy c2luZyBpcyBleHBlbnNpdmUgYnV0IHRoYXQgaWYgeW91IHdhbnQgdG8gaGF2ZSBhIG11bHRpdGhy ZWFkZWQNCj4+ID4+PiA+PiBwYWNrZXQNCj4+ID4+PiA+PiBwcm9jZXNzaW5nIHN5c3RlbSwgdGhl biBpdCdzIG5pY2UgdG8gaGF2ZSBhIHNpbXBsZXIgZGF0YSBzdHJ1Y3R1cmUNCj4+ID4+PiA+PiAo dGhlDQo+PiA+Pj4gPj4gdW5wYXJzZWQgQUNLIGJsb2NrKSB0byBoYW5kIHRvIHRoZSBBQ0sgcHJv Y2Vzc2luZyB0aHJlYWQuDQo+PiA+Pj4gPj4NCj4+ID4+PiA+PiAtRWtyDQo+PiA+Pj4gPj4NCj4+ ID4+PiA+Pg0KPj4gPj4+ID4+Pg0KPj4gPj4+ID4+PiBPbiBTYXQsIEp1biAxNiwgMjAxOCBhdCA2 OjE5IEFNIE1hcnRpbiBUaG9tc29uDQo+PiA+Pj4gPj4+IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20+DQo+PiA+Pj4gPj4+IHdyb3RlOg0KPj4gPj4+ID4+Pj4NCj4+ID4+PiA+Pj4+IFdoZW4gd2Ug ZGlzY3Vzc2VkIHRoaXMgYmVmb3JlLCBzb21lIHBlb3BsZSBvYnNlcnZlZCB0aGF0IHRoaXMNCj4+ ID4+PiA+Pj4+IGNyZWF0ZXMNCj4+ID4+PiA+Pj4+IGEgbmVlZCB0byBlbmNvZGUgaW4gdHdvIHBh c3Nlcy4gIFRoYXQncyB0aGUgdHJhZGUtb2ZmIGhlcmUuICAoTm90DQo+PiA+Pj4gPj4+PiBleHBy ZXNzaW5nIGFuIG9waW5pb24uKQ0KPj4gPj4+ID4+Pj4gT24gRnJpLCBKdW4gMTUsIDIwMTggYXQg Mzo1MSBQTSBKYW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbT4NCj4+ID4+PiA+Pj4+IHdy b3RlOg0KPj4gPj4+ID4+Pj4gPg0KPj4gPj4+ID4+Pj4gPiBJIGRvbid0IGhhdmUgYSBzdHJvbmcg b3BpbmlvbiBvbiB0aGlzLiBJJ20gY2VydGFpbmx5IG5vdCBvcHBvc2VkDQo+PiA+Pj4gPj4+PiA+ IHRvDQo+PiA+Pj4gPj4+PiA+IGl0Lg0KPj4gPj4+ID4+Pj4gPiBEb2VzIGFueW9uZSBoYXZlIGEg c3Ryb25nIG9wcG9zaXRpb24/DQo+PiA+Pj4gPj4+PiA+DQo+PiA+Pj4gPj4+PiA+IE9uIEZyaSwg SnVuIDE1LCAyMDE4IGF0IDM6MTAgUE0gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NCj4+ID4+PiA+ Pj4+ID4gPHByYXZiQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPj4gPj4+ID4+Pj4gPj4NCj4+ID4+ PiA+Pj4+ID4+IEkgYWdyZWUgYXMgd2VsbCBzaW5jZSB0aGlzIGNhbiBoZWxwIHJlZHVjZSBwZXIg cGFja2V0IHByb2Nlc3NpbmcNCj4+ID4+PiA+Pj4+ID4+IG92ZXJoZWFkLiBBQ0tzIGFyZSBnb2lu ZyB0byBiZSB0aGUgc2Vjb25kIG1vc3QgY29tbW9uIGZyYW1lIHR5cGUNCj4+ID4+PiA+Pj4+ID4+ IHNvIG5vDQo+PiA+Pj4gPj4+PiA+PiBvYmplY3Rpb25zIHRvIHNwZWNpYWwgY2FzaW5nLg0KPj4g Pj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+PiA+Pg0KPj4gPj4+ID4+Pj4g Pj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEVyaWMNCj4+ID4+PiA+Pj4+ID4+IFJlc2NvcmxhDQo+PiA+Pj4gPj4+PiA+PiBTZW50OiBGcmlk YXksIEp1bmUgMTUsIDIwMTggOToxMSBBTQ0KPj4gPj4+ID4+Pj4gPj4gVG86IERldmFsLCBNYW5h c2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+DQo+PiA+Pj4gPj4+PiA+PiBDYzogSmFuYSBJeWVu Z2FyIDxqcmkuaWV0ZkBnbWFpbC5jb20+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KPj4gPj4+ ID4+Pj4gPj4gU3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50 IHdpdGggQUNLIGxlbmd0aA0KPj4gPj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4g Pj4+PiA+Pg0KPj4gPj4+ID4+Pj4gPj4gSSBhZ3JlZSB3aXRoIE1hbmFzaSBoZXJlLiBUaGlzIGNo YW5nZSB3b3VsZCBhbGxvdyBhY2sgZnJhbWUNCj4+ID4+PiA+Pj4+ID4+IHBhcnNpbmcNCj4+ID4+ PiA+Pj4+ID4+IHRvIGJlIG1vcmUgc2VsZi1jb250YWluZWQsIHdoaWNoIGlzIGFuIGFkdmFudGFn ZSBmb3IgdGhlIHBhcnNlcg0KPj4gPj4+ID4+Pj4gPj4gYW5kIGFsc28NCj4+ID4+PiA+Pj4+ID4+ IHBvdGVudGlhbGx5IGZvciBwYXJhbGxlbGlzbSAoYmVjYXVzZSB5b3UgY2FuIHF1aWNrbHkgZmlu ZCB0aGUNCj4+ID4+PiA+Pj4+ID4+IGZyYW1lIGFuZCB0aGVuDQo+PiA+Pj4gPj4+PiA+PiBwcm9j ZXNzIGl0IGluIHBhcmFsbGVsKS4NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+PiA+Pg0KPj4g Pj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+IC1Fa3INCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4g Pj4+PiA+Pg0KPj4gPj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+PiA+Pg0K Pj4gPj4+ID4+Pj4gPj4gT24gTW9uLCBKdW4gMTEsIDIwMTggYXQgNToyMiBQTSwgRGV2YWwsIE1h bmFzaQ0KPj4gPj4+ID4+Pj4gPj4gPG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+IHdyb3RlOg0KPj4g Pj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+IEluIGdlbmVyYWwsIHZhcmludHMgcmVxdWlyZSBz b21lIHNwZWNpZmljIGxvZ2ljIGZvciBwYXJzaW5nLiBUbw0KPj4gPj4+ID4+Pj4gPj4gc2tpcA0K Pj4gPj4+ID4+Pj4gPj4gb3ZlciBhbnkgaGVhZGVyLCBJIGhhdmUgdG8gcmVhZCBldmVyeSBzaW5n bGUgdmFyaW50LiBBcyB0aGUgY29kZQ0KPj4gPj4+ID4+Pj4gPj4gc2VlcyBTdHJlYW0NCj4+ID4+ PiA+Pj4+ID4+IGFuZCBBQ0sgaGVhZGVycyBtb3N0IGZyZXF1ZW50bHksIHRoYXQgaXMgbXkgZm9j dXMuICBUaGUgU3RyZWFtDQo+PiA+Pj4gPj4+PiA+PiBmcmFtZSBoYXMgYQ0KPj4gPj4+ID4+Pj4g Pj4gbGVuZ3RoIGluIGl0cyB0aGlyZCBmaWVsZC4NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+ PiA+Pg0KPj4gPj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+IEFDSyBwYXJzaW5nLCBob3dldmVy LCBuZWVkcyA2ICsgMipudW1fYmxvY2tzIHJlYWRzIHRvIGlkZW50aWZ5DQo+PiA+Pj4gPj4+PiA+ PiBsZW5ndGguIFRoZXJlIGFyZSB0d28gcmVhZHMgZWFjaCBmb3Ig4oCYbGFyZ2VzdCBhY2tub3ds ZWRnZWTigJksIOKAmEFDSw0KPj4gPj4+ID4+Pj4gPj4gZGVsYXnigJkgYW5kDQo+PiA+Pj4gPj4+ PiA+PiDigJhBQ0sgYmxvY2sgY291bnTigJkuIFRoZSBwYWluIHBvaW50IGlzIHRoZSB0b3RhbCBu dW1iZXIgb2YgY3ljbGVzDQo+PiA+Pj4gPj4+PiA+PiBwYXJzZSBhbg0KPj4gPj4+ID4+Pj4gPj4g QUNLLiBJZiBJIGFtIHByb2Nlc3NpbmcgMTBNIHBwcywgd2hlcmUgMTAlIC0gMzAlIG9mIHRoZSBw YWNrZXRzDQo+PiA+Pj4gPj4+PiA+PiBoYXZlIGENCj4+ID4+PiA+Pj4+ID4+IHBpZ2d5YmFja2Vk IEFDSywgdGhlc2UgY3ljbGVzIGJlY29tZXMgYSBzaWduaWZpY2FudCBib3R0bGVuZWNrLg0KPj4g Pj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+PiA+Pg0KPj4gPj4+ID4+Pj4g Pj4gVGhhbmtzLA0KPj4gPj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+IE1hbmFzaQ0KPj4gPj4+ ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+PiA+Pg0KPj4gPj4+ID4+Pj4gPj4N Cj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+PiA+Pg0KPj4gPj4+ID4+Pj4gPj4NCj4+ID4+PiA+ Pj4+ID4+IEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBKYW5hDQo+PiA+Pj4gPj4+PiA+PiBJeWVuZ2FyDQo+PiA+Pj4gPj4+PiA+PiBTZW50OiBN b25kYXksIEp1bmUgMTEsIDIwMTggMzoxMSBQTQ0KPj4gPj4+ID4+Pj4gPj4gVG86IERldmFsLCBN YW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb20+OyBRVUlDIFdHDQo+PiA+Pj4gPj4+PiA+PiA8 cXVpY0BpZXRmLm9yZz4NCj4+ID4+PiA+Pj4+ID4+IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byBy ZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGgNCj4+ID4+PiA+Pj4+ID4+DQo+ PiA+Pj4gPj4+PiA+Pg0KPj4gPj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+IFlvdSdyZSByaWdo dCB0aGF0IHdlIG5vIGxvbmdlciBoYXZlIHRoZSBhYmlsaXR5IHRvIHNraXAgYW4gQUNLDQo+PiA+ Pj4gPj4+PiA+PiBmcmFtZSwNCj4+ID4+PiA+Pj4+ID4+IGFuZCB0aGlzIGNyZXB0IGluIHdoZW4g d2UgbW92ZWQgdG8gdmFyaW50cy4NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+PiA+PiBJIGJl bGlldmUgeW91ciBwcm9ibGVtIHRob3VnaCBpcyBnZW5lcmFsbHkgdHJ1ZSBvZiBtb3N0IGZyYW1l cw0KPj4gPj4+ID4+Pj4gPj4gbm90DQo+PiA+Pj4gPj4+PiA+PiBqdXN0IEFDS3MsIHNpbmNlIGlk cywgcGFja2V0IG51bWJlcnMsIGFuZCBudW1iZXJzIGluIGFsbCBmcmFtZXMNCj4+ID4+PiA+Pj4+ ID4+IGFyZSBub3cgYWxsDQo+PiA+Pj4gPj4+PiA+PiB2YXJpbnRzLiBUbyBza2lwIGFueSBmcmFt ZSwgeW91J2xsIG5lZWQgdG8gcGFyc2UgdGhlIHZhcmludA0KPj4gPj4+ID4+Pj4gPj4gZmllbGRz DQo+PiA+Pj4gPj4+PiA+PiBpbiB0aG9zZQ0KPj4gPj4+ID4+Pj4gPj4gZnJhbWVzLiBJZiB5b3Ug aGF2ZSBsb2dpYyB0byBwcm9jZXNzIGFuZCBza2lwIHZhcmludHMsIHRoZW4NCj4+ID4+PiA+Pj4+ ID4+IHNraXBwaW5nIHRoZSBhY2sNCj4+ID4+PiA+Pj4+ID4+IGJsb2NrIHNlY3Rpb24gaXMgbWVy ZWx5IHJlcGVhdGluZyB0aGlzIG9wZXJhdGlvbiAoMipudW1fYmxvY2srMSkNCj4+ID4+PiA+Pj4+ ID4+IHRpbWVzLiBEbw0KPj4gPj4+ID4+Pj4gPj4geW91IHNlZSBzcGVjaWZpYyB2YWx1ZSBpbiBz a2lwcGluZyBBQ0sgZnJhbWVzIG92ZXIgdGhlIG90aGVyDQo+PiA+Pj4gPj4+PiA+PiBjb250cm9s IGZyYW1lcz8NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+PiA+Pg0KPj4gPj4+ID4+Pj4gPj4N Cj4+ID4+PiA+Pj4+ID4+DQo+PiA+Pj4gPj4+PiA+Pg0KPj4gPj4+ID4+Pj4gPj4gT24gTW9uLCBK dW4gMTEsIDIwMTggYXQgODo0MyBBTSBEbWl0cmkgVGlraG9ub3YNCj4+ID4+PiA+Pj4+ID4+IDxk dGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC4uY29tPiB3cm90ZToNCj4+ID4+PiA+Pj4+ID4+DQo+PiA+ Pj4gPj4+PiA+PiBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCAwMzozMzozNVBNICswMDAwLCBEZXZh bCwgTWFuYXNpIHdyb3RlOg0KPj4gPj4+ID4+Pj4gPj4gPiAtICAgICAgICBNb3ZpbmcgdGhlIEFD SyBsZW5ndGggdG8gdGhlIGZyb250IG9mIHRoZSBBQ0sgYWxsb3dzDQo+PiA+Pj4gPj4+PiA+PiA+ IHRoZQ0KPj4gPj4+ID4+Pj4gPj4gPiAgICAgICAgICBmbGV4aWJpbGl0eSBvZiBlaXRoZXIgcmVh ZGluZyB0aGUgZW50aXJlIEFDSyBvcg0KPj4gPj4+ID4+Pj4gPj4gPiByZWFkaW5nDQo+PiA+Pj4g Pj4+PiA+PiA+IHRoZQ0KPj4gPj4+ID4+Pj4gPj4gPiAgICAgICAgICBmaXJzdCAxNiBiaXRzIGFu ZCBza2lwcGluZyBvdmVyIHRoZSBsZW5ndGguIFRoaXMgaXMgYQ0KPj4gPj4+ID4+Pj4gPj4gPiB1 c2VmdWwNCj4+ID4+PiA+Pj4+ID4+ID4gICAgICAgICAgZmVhdHVyZSBmb3IgdGhlIGNhc2Ugd2hl cmUgQUNLIHByb2Nlc3NpbmcgaXMgc3BsaXQNCj4+ID4+PiA+Pj4+ID4+ID4gaW50bw0KPj4gPj4+ ID4+Pj4gPj4gPiAgICAgICAgICBtdWx0aXBsZSBsYXllcnMuIERlcGVuZGluZyBvbiB0aGUgcHJv Y2Vzc29yIHRoaXMgaXMNCj4+ID4+PiA+Pj4+ID4+ID4gcnVuDQo+PiA+Pj4gPj4+PiA+PiA+IG9u LA0KPj4gPj4+ID4+Pj4gPj4gPiAgICAgICAgICB0aGVyZSBhcmUgZGlmZmVyZW50IGFkdmFudGFn ZXMgLQ0KPj4gPj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+IEp1c3QgYSBub3RlLiAgSW4gbXkg ZXhwZXJpZW5jZSwgdGhlIGNvc3Qgb2YgcGFyc2luZyBhbiBBQ0sgZnJhbWUNCj4+ID4+PiA+Pj4+ ID4+IGlzDQo+PiA+Pj4gPj4+PiA+PiBuZWdsaWdpYmxlIGNvbXBhcmVkIHRvIHRoZSBjb3N0IG9m IHByb2Nlc3NpbmcgYW4gQUNLIGZyYW1lOiB0aGF0DQo+PiA+Pj4gPj4+PiA+PiBpcywNCj4+ID4+ PiA+Pj4+ID4+IHBva2luZyBhdCB2YXJpb3VzIG1lbW9yeSBsb2NhdGlvbnMgdG8gZGlzY2FyZCBu ZXdseSBBQ0tlZA0KPj4gPj4+ID4+Pj4gPj4gcGFja2V0cy4NCj4+ID4+PiA+Pj4+ID4+DQo+PiA+ Pj4gPj4+PiA+PiAgIC0gRG1pdHJpLg0KPj4gPj4+ID4+Pj4gPj4NCj4+ID4+PiA+Pj4+ID4+DQo+ PiA+Pj4gPj4+Pg0KPj4gPj4+ID4+DQo+PiA+Pj4gPg0KPj4gPj4+DQo+PiA+Pj4NCj4+ID4+Pg0K Pj4gPj4+IC0tDQo+PiA+Pj4gS2F6dWhvIE9rdQ0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiAtLQ0K Pj4gPiBLYXp1aG8gT2t1DQo+PiANCj4+IA0KPj4gDQo+PiAtLQ0KPj4gS2F6dWhvIE9rdQ0KDQo= From nobody Wed Aug 8 13:21:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785FC130E25 for ; Wed, 8 Aug 2018 13:21:25 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSl5HKoiX1Jq for ; Wed, 8 Aug 2018 13:21:23 -0700 (PDT) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9594812F1A5 for ; Wed, 8 Aug 2018 13:21:23 -0700 (PDT) Received: by mail-yw1-xc2d.google.com with SMTP id 139-v6so2527126ywg.12 for ; Wed, 08 Aug 2018 13:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V174novbfpX01rY51EB2rvep6Mlw45GiZ2zqFO5pYTE=; b=Ppy9ul9gxIJdMZ4X/ajV7JgKzAY/k+Ga7WRorGQvU5BCBbG2Q+yevrHelKRX0nQSik ug1YLbZGyqn8v9nsnnKwUq/aiydMXzhXofsyj2zdOpabvVynBudDl1sjMU2qO1PUiI9o iCdLLcJ5QHuXj9qVOz2dEtNKI43Lnji0G95aGX6BL4+PpCLSkNcfbf4RSkSOev9cZU5d xxoiUF4FwNoh9y3JUTxwGOY+o/+yJXG7gsA582ol5AC/G2r/656ItT1O7BiWniT2zU/5 8QKIRBwkdMHRzpP2JBFOtAovrAeDcEm6OGBXaXV7hmnN8xjceFTh3iJEFHl5uCvafjqM /XwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V174novbfpX01rY51EB2rvep6Mlw45GiZ2zqFO5pYTE=; b=dmIEXM8deQL4bWvMa4Zelk+Zq01oQHKs1Yke7U65FzNc1jro2/0yzu1lnhp8V0lgI/ oR9qFwnYEMfnpTrBlVMG+bYW5q5PityK5An9fB+pQJstFsA5t6CnlpLOsZN1NUjnxrIc sRh3/6Rd2o49MNUoImfR+JGH0T4MYWUjYtm1wflAiNdjRSE6qpNwqjH5R8RgTSlszDeC R8c0pLsvOa1pEb29NWwothjgaSPSxovMYY2DfA2Fs1TXAnwlTRgdnRO1b8N9oesHYzs2 Ou4V+eiY5SGtpKk7y9CBzCkBFK2srSq//r/bFqcESh8+fU6TpYOWPUxFJ5EHSIbOKeuN kRpw== X-Gm-Message-State: AOUpUlHo9NP9A8+CIn3dlK2pWTk+bLWfp9Ir5aApGeaDAGIfiQ/dLPvV NWUqDfUMa+sFnEG13NylEMwWTgcYLV4Zsym6hpM= X-Google-Smtp-Source: AA+uWPwSG5IqoViI3C8dHE9Ek+GN+S9KW90rCTjKnq5QOkB6cxTGkXoEy05MJ+A4e9rRYm6J2RCEaQA+tNaenOmiIBc= X-Received: by 2002:a25:a085:: with SMTP id y5-v6mr2301582ybh.110.1533759682464; Wed, 08 Aug 2018 13:21:22 -0700 (PDT) MIME-Version: 1.0 References: <193166ED-C8C3-4A6B-9483-5546C34B5BDA@tik.ee.ethz.ch> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 8 Aug 2018 15:21:09 -0500 Message-ID: Subject: Re: Key updates To: Martin Thomson Cc: Mirja Kuehlewind , IETF QUIC WG , ianswett=40google.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="0000000000000b510b0572f241aa" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 20:21:25 -0000 --0000000000000b510b0572f241aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW ... On Mon, Aug 6, 2018 at 7:39 PM Martin Thomson wrote: > On Mon, Aug 6, 2018 at 11:06 PM Mirja K=C3=BChlewind > wrote: > > However, this brings us back to Martin=E2=80=99s other question: does i= t make > sense to have a couple of reserved bits to make it easy to add a bit for > the next version with minimal changes to the protocol machinery/wire imag= e? > > I think that was Dirkjan who asked that question. > > The driving principle behind defining invariants was to avoid having > to come back to this question repeatedly. We have a version > negotiation mechanism that allows us to change an awful lot between > different protocol version. We don't need to reserve a few bits > because most of them are already reserved. > That was certainly my understanding when the working group adopted the invariants draft and added a milestone for it. Spencer --0000000000000b510b0572f241aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW ...

On Mon, Aug 6, 2018 at 7:39 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On Mon, Aug 6, 2018 at 11:06 PM Mirja K=C3=BChle= wind
<mi= rja.kuehlewind@tik.ee.ethz.ch> wrote:
> However, this brings us back to Martin=E2=80=99s other question: does = it make sense to have a couple of reserved bits to make it easy to add a bi= t for the next version with minimal changes to the protocol machinery/wire = image?

I think that was Dirkjan who asked that question.

The driving principle behind defining invariants was to avoid having
to come back to this question repeatedly.=C2=A0 We have a version
negotiation mechanism that allows us to change an awful lot between
different protocol version.=C2=A0 We don't need to reserve a few bits because most of them are already reserved.

<= div>That was certainly my understanding when the working group adopted the = invariants draft and added a milestone for it.

Spe= ncer
--0000000000000b510b0572f241aa-- From nobody Wed Aug 8 14:13:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC457130EAF for ; Wed, 8 Aug 2018 14:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 5dIH09dX1F1B for ; Wed, 8 Aug 2018 14:13:21 -0700 (PDT) Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E093130EA2 for ; Wed, 8 Aug 2018 14:13:21 -0700 (PDT) Received: by mail-yw1-xc34.google.com with SMTP id 139-v6so2643838ywg.12 for ; Wed, 08 Aug 2018 14:13:21 -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=d/dJfHG84iizStXn1NKaaCSKPBFGipyKec236xyjPMM=; b=UREMaAogsKGCidSfu8WXtM9uFbuW4fQKb2ono0TQHgNN2X0fMFm4i/e4hlYIO/whWW VSH3fybKDWt0Rzk/D3+q1QoJrlCdPAkfHZgLUAovhB1PrBuVzmBoe5yYjJzHKp4pnFBY XNCFu9Uf7o8QQWo3UKhPwA679TdTeQQCqXE/lYuQLEsYd6AEU0t8939eGnoj8KP/zK+b MVGENcJUSkZuNM23L3X8l/4pOyz4oBw+YmvZm3/3CZT1vl34gVhZaK0nMsP8LIvosHHL S8IsU7swPDTZ9W7jBx+yb2VuGVsm/x4qXMffk6XYO85wrBS8VVEbrHwp58F8BxmeV/a3 rJ/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:from:date:message-id:subject:to; bh=d/dJfHG84iizStXn1NKaaCSKPBFGipyKec236xyjPMM=; b=IF0E10WDWIwi7f2ZDzBuhpcynaYZolIgGkqWGnLeA39JKRrSzjTfk61PTgMtPTaVVD qQbsRYF6S22iYvygGyI/R5GXUb9TdmjSTm9MwfMuOFTemPpJV1DtpvTphpy9cYlh81HE GKnhkXzdMQ5yDfBIL1m9QYQboWtxnR99B+r1RlVjYp22GyNAsEf3kpFCiEmDdyZX5fcH zfuQuJj3uwUcRZnyDDRvps+ExluyP8yGLqt9VWgb2/X1PSIDxz8iyPV/ghByHB9u5t3K KJKrbFPKxAz+qI8vER0AiQ948PK7SYujDT/NpZWghi9iM0FJWZRpBi5SX/2jrcSjkBmD wazw== X-Gm-Message-State: AOUpUlFwe/0q1i2JQl6s40bsRN3KYid0yv3exAJ1KqGg+fy4Hd/Q3xcr FY3KdvGbEG1dxIU1lBOaIij2ihyYxc9pO5rjy61XL6dyDzc= X-Google-Smtp-Source: AA+uWPxOAsgELj0UJtmFuXRmWK4shY8NjbJTnqUkxlO/N7kVGfzh6ZSyTpFxX91NfAoHQXFy53brolUAcOipUmEEzTE= X-Received: by 2002:a25:38f:: with SMTP id 137-v6mr2294887ybd.314.1533762799606; Wed, 08 Aug 2018 14:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:8b11:0:0:0:0:0 with HTTP; Wed, 8 Aug 2018 14:13:18 -0700 (PDT) From: Ryan Hamilton Date: Wed, 8 Aug 2018 14:13:18 -0700 Message-ID: Subject: Reserved HTTP Frames To: IETF QUIC WG , Mike Bishop Content-Type: multipart/alternative; boundary="000000000000d7cd720572f2faa5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 21:13:23 -0000 --000000000000d7cd720572f2faa5 Content-Type: text/plain; charset="UTF-8" I've a question about this text from the HTTP mapping doc: 4.2.1 . Reserved Frame Types Frame types of the format "0xb + (0x1f * N)" are reserved to exercise the requirement that unknown types be ignored. For what values of "N" are we talking about? I assume [0,8)? Because, unless I'm doing the math wrong, if N can be [0,256) (and we're doing uint8_t math) then that covers all possible values. Cheers, Ryan --000000000000d7cd720572f2faa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've a question about this text from the HTTP mapping = doc:

4.2.1.  Reserved Frame Types
=


   Frame types of the format "0xb + (0x1f * N)" are reserved to e=
xercise
   the requirement that unknown types be ignored.

For what = values of "N" are we talking about? I assume [0,8)? Because, unle= ss I'm doing the math wrong, if N can be [0,256) (and we're doing u= int8_t math) then that covers all possible values.

Cheers,

Ryan
--000000000000d7cd720572f2faa5-- From nobody Wed Aug 8 14:32:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A03130E25 for ; Wed, 8 Aug 2018 14:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYw_gDKbSjKh for ; Wed, 8 Aug 2018 14:32:13 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3CA130E14 for ; Wed, 8 Aug 2018 14:32:12 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id n21-v6so6351600oig.3 for ; Wed, 08 Aug 2018 14:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oFfZef+kVlnTKxzLbvPcwh+qQyI/w7dcAyONeFjQjLw=; b=HUS8P/SuVc3MkpnTsauucC3Z5Tu2kNmS95ocpMbqbcmPKhy5rV9LEbb68fxnViUOEz ay7+be+q9LBgGbvqbhLUkUkLlkUAETINWQlByquRvs8Ob3Z15z34eavdDi3WrvskZ0pb dLGLP31xPVl0jlZaUGvquARIHYToN9iPpxQE/W+biHvKjc+YCj+2N+rLd5GxTu26Ai3d kohV7PDGchpi9TANnvbail6VRpnV5gOdUjguLzAtd1gVHHaLqm0uSic+IhIw9Au6wjjh zn3MjuhNgTjBsKtElTyfnJjnMqmFZD+ILn+El9bIlemyb9kqdWDGoWAM6fM8zz5WGwW9 op5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oFfZef+kVlnTKxzLbvPcwh+qQyI/w7dcAyONeFjQjLw=; b=Dq8ybsLW0A6uZGeHD1npwF/PImoIh8SxsyOsaAlxr53xpfS+Ael5qdYz5sydOLXBDm 0yxwVdc/62NSMu5ngQiPqUuRLVNWEnWOqOVDDi5M6MP1tR77s+0ALupC2m7D97xgRPTN 5MKBnqNwYtrjSWaUgbMETNfq5dpXo2jKhLW+P5RlZ6Hl2Z4/N3YFYA1uFvh0Q+23r9rt qzSuTnkHWKzFgxX3f5BqAz2L74ITcHpiZzEBx/J4tL2ujkWj/nThh93xwVwf+ges78om +ddMOWOfz6v+SrOaeK9xBmXyiABuXGBaTmqO0l3z3cGT70SVBKryo9XtF6WzOY7w9g8d fOGg== X-Gm-Message-State: AOUpUlFvj339AghZrxhJyBaT87tg195fyMsly31J1HjhRxRu9znWJJE9 KfEx52ziIjoIYwA3EeWcaWWveEaJxbX+duTAKVHY1w== X-Google-Smtp-Source: AA+uWPw3jUbM/Q1rDjDmYnlrBPR5Ci0DIuuaxZJuxCrO+yMWfLaYEJfPIciC5N4CkAtSRz2ssA1fuNu02Zx5bZTc0lA= X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr4904891oiq.110.1533763931917; Wed, 08 Aug 2018 14:32:11 -0700 (PDT) MIME-Version: 1.0 References: <20180805154649.GA14245@ubuntu-dmitri> <20180806043610.GC25402@ubuntu-dmitri> <20180806044626.GD25402@ubuntu-dmitri> <20180806121947.GA31889@ubuntu-dmitri> In-Reply-To: <20180806121947.GA31889@ubuntu-dmitri> From: Martin Thomson Date: Thu, 9 Aug 2018 07:32:01 +1000 Message-ID: Subject: Re: QPACK proposal: wrap absolute index values To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 21:32:15 -0000 So this is a really interesting idea, but I did a triage yesterday and missed it. Dmitri, would you mind creating an issue for this? On Mon, Aug 6, 2018 at 10:19 PM Dmitri Tikhonov wrote: > > On Mon, Aug 06, 2018 at 04:52:34PM +1000, Martin Thomson wrote: > > On Mon, Aug 6, 2018 at 2:46 PM Dmitri Tikhonov > > wrote: > > > bool > > > isHeaderBlocked (unsigned LargestRef) > > > > Thanks for sharing code. Note that I'm not just interested in whether > > I'm blocked, but for how many table updates I should block for, but I > > can use this function (repeatedly if necessary) to make that > > determination, I guess. > > Well, that's just pseudo-code, you know. I'd never CamelCase real > code! > > > It took me ages to understand this code. Are you expecting all the > > arithmetic for CurMax to be modulo MaxEntries*2 ? Because if that is > > the case, then this makes sense. Without that stipulation, I really > > struggled. > > Yes, all the arithmetic for the absolute index is modulo MaxEntries * 2. > > > 2. You can't receive a header block with a largest reference that is > > more than MaxEntries new. This doesn't hold because we don't cap the > > amount that a header block can be blocked by. > > This is true -- my assertion about the future horizon is incorrect. > Somehow I assumed that the mirror argument about the encoder worked, > but it does not. For example, nothing prevents the encoder from > pumping the table full of speculative updates, maybe even a few times > over, before ever using it. > > > Now, it's arguably a > > reasonable restriction, because it takes multiple round trips to reach > > a state where that header block can be used, but we don't currently > > prevent someone from doing something like that. > > > > Now, it's reasonable to assume that you can't have more than > > MaxEntries worth of updates in flight, which means that in one round > > trip, this will never happen. But we don't say that you can't > > reference dynamic table entries that are far in the future. For this > > to work, we would have to prohibit that. Maybe we should, because > > referencing entries that can't be sent is a footgun, just as > > referencing entries that have not yet been sent is a footgun (it can > > deadlock flow control if you do that). > > Yes, for the proposed mechanism to work, we'd have to mandate that the > encoder not create new entries past some limit, which is a function of > the known decoder state (based on TSS or Header Acks) and MaxEntries. > > Thanks for identifying this flaw. The change is larger than I was > hoping it would be. It's still worth it. > > - Dmitri. From nobody Wed Aug 8 20:54:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCDD130F2B for ; Wed, 8 Aug 2018 20:54:15 -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, FREEMAIL_FROM=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 5XhkEjpAZmuF for ; Wed, 8 Aug 2018 20:54:13 -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 78CDC130F25 for ; Wed, 8 Aug 2018 20:54:13 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id m11-v6so7579041oic.2 for ; Wed, 08 Aug 2018 20:54:13 -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=zztBMQTGNxRNfRhvIf10QJcIY6AxrIZsd1PkiOYDYqY=; b=cyMeMsza95ORcPtVCaFRFJHuXv3jx2H/5f7M2Jtne6w/Ra2HMhjjCLo6ZzrLv7qGyL jtSpQflOiLx2Mtj3b4A9igP+6PdnT77jN6rmeIN7+GR05mnJ6ycIUZtF05+ketZoB2Sh +J3iGheJHUxAvTRTyW8Qf3jtK4Zwq30bjXAbef0NWp0o2veIqc+MDHEZg/jzFv8kWSTq RocormT4AA3A3/xiwy1Sa96iJcPAhRh7JrNyoIJf9mb0SH6yfVVZ43PM64xQaYHgG81c XF6sFCk/ZjpEsO4U1S5k1gnBH2jpHVX50jibbkz1gh/ZFFTlpjibb5sT1uK7NBhSBAAk 94Lg== 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=zztBMQTGNxRNfRhvIf10QJcIY6AxrIZsd1PkiOYDYqY=; b=ITlc7Ip9Hnn5XBZJ9o0Wy5soutuWA3Ih8UAwMpYCyn2VxVF8k5DAAaPvLNwdXEZzAx ieKJYZIso+HZpI3d0cfNZxAXCx1Y+dSMQ2AKSXkXYMBl6qm3MXP0a6/dZKFfs76U88os 8wa0W23gwqRhTfUVfcNG95+M6JXQqx7OlTAW2zUXpMjuj6fOy1TphCTw+h2F8oC+30k7 OCrfWzoVN8NGkYQTpf5TqsoR9A7fj292F83nClNHWqh/zq85SKHmA0QNMTEILhsaAFbl 9/UyeAF8qVJl/AgZbAZuMpykKzWOdKH1lZptLmBFC3blKI5oMMpZqrqhWOmohlnYD1J6 aDIg== X-Gm-Message-State: AOUpUlEqIUZAuQ3VOqmLg/htXVk6QYqPKQ4Ko0VZaD8/VEMbekrRKNeG TA4IOkqGFNisDrowvZRUZGUwUJyOUMGEBxeuno2bUiBPwAY= X-Google-Smtp-Source: AA+uWPz5mtLZpbAnxvRz4OHT7pyAfGR9m6YoHHHuf76s8GMR/elWqzw5OyF51ryrypCK4zVSoIyG2cK+9YXe1VnwhYE= X-Received: by 2002:aca:df42:: with SMTP id w63-v6mr404073oig.295.1533786852567; Wed, 08 Aug 2018 20:54:12 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Thu, 9 Aug 2018 13:54:01 +1000 Message-ID: Subject: Unified ACK frame encoding To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 03:54:16 -0000 (More long emails. Sorry, I'm trying to either close these issues or prepare us for the interim.) We decided to take ACK_ECN to address an immediate need, but recognized that the encoding was suboptimal. In the issue (see https://github.com/quicwg/base-drafts/issues/1439) we've beendiscussing an option for frame encoding that fixes a bunch of issues. That discussion covered a lot of ground, but here is my summary. This is what we have currently (using C/TLS style notation because I don't think ASCII art works in email): struct ACK { varint largest_acknowledged; varint delay; varint additional_block_count; varint first_block; struct { varint gap; varint block; } blocks[additional_block_count]; }; struct ACK_ECN { ACK ack; varint ect0_count; varint ect1_count; varint ecnce_count; }; The most obvious issues are: A. There are two inconsistent encodings for acknowledgments depending on whether ECN is enabled. B. ACK_ECN has more overhead than ACK. Ideally there are fewer disincentives to use ACK_ECN. C. The counting scheme is imprecise (you don't always know which packet was CE marked, and that could matter), which makes counting of ECN markings fragile in the presence of ACK loss. This can lead to ECN being disabled despite it being fully functional. D. ECN counters always increase, and so they take more space to encode over time. Kazuho suggested a scheme that adds some modest complexity, but I think that it works and reduces other complexities such that it's probably a net win on the complexity front. It also fixes these issues at the same time. The observation is that there are 5 things that you might want to say about any given packet number: 0. say nothing (i.e., I'm not acknowledging this packet; this is a gap) 1. packet received, no marking 2. packet received with an ECT(0) marking 3. packet received with an ECT(1) marking 4. packet received with an ECN-CE marking Now, the current system of describing ranges of packets is still pretty good. An expression of the form "the next N packets are of type X" gets us an encoding that is small and fits traffic patterns well. No point changing what is a fundamentally good encoding. So, we retain the maximum packet number and the idea of expressing ranges of packets. But each range is a tuple that expresses both the type of acknowledgement (or lack thereof) for that range and how many packets are in the range. That would produce an ACK frame in the following basic shape: struct ACK { varint largest_acknowledged; varint delay; varint range_count; struct { enum {gap,unmarked,ect0,ect1,ecnce} type; varint count; } ranges[range_count]; }; The problem now is that we lost efficiency in a big way because the enum takes up a ton of space, for just 5 values. If we observe that there are 5 types, but you don't need to repeat the same type, then we can express the type in two bits. That is, the type is interpreted as: type = last_type + 1 + encoded_type (mod 5) Kazuho suggested that we pack these bits into the low two bits of a varint. It's a little ugly, but I can't see a better option. For instance, defining a new varint type would be considerably worse. In addition to not being able to reuse varint code, my testing on encodings showed that a defining a new type with flags before the 2-bit length is surprisingly expensive. This produces a format like this: struct ACK { varint largest_acknowledged; varint delay; varint range_count; varint ranges[range_count]; }; As you can see, this is a considerable simplification. The only trick is that more data is packed into each range value. These values are encoded using something like: encoded_type = (type + 4 - last_type) % 5 // encoded_type = type - last_type - 1 (mod 5) range = encoded_type | (count << 2) The cost is that ranges take one more byte once they get above 16 packets rather than at 64 packets as before. It's also possible with this to encode a non-acknowledgment at the end of an ACK frame, which I think we can either prohibit or ignore. But it fixes all the above problems. Is this a change worth making? Cheers, Martin A side note: This works whether we encode a count (as here) or a total number of octets (as has been proposed). Similarly, we could count from the bottom rather than the top if we wanted to. Those decisions are orthogonal to this; I'm trying as much as possible to retain the current design. Another note: We already have an issue on file for an ACK frame example. That is still planned and that should help with interpreting the text. From nobody Wed Aug 8 23:36:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2881130E27 for ; Wed, 8 Aug 2018 23:36:18 -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 gPDbyqzeBVhL for ; Wed, 8 Aug 2018 23:36:15 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0797012D7EA for ; Wed, 8 Aug 2018 23:36:15 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id f18-v6so3316146lfc.2 for ; Wed, 08 Aug 2018 23:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qw+9WsummIz69Xy0U1gYUJiA2Q5F+2Zo9xDLG5HAKBE=; b=fr2APFvu4NEN2oCYXJ8UCzh/pJCyJC1Ky9jFuPmIXaBOUz1gHRlBZUvK0VlAKgMkWo m/19w0LKLKdtfrEmLd9R1/vZ+PcJ7kWGZciXYyiBv0S5pqlHS1Yd9xh9e8iN1CM6g2we 5Bas644Xm3Tzqox86fZfWrIWtQGuoAgM6u4ZRsNXToYdp/lSbI5RDa4MKfoQrqCg+bWQ +eECyB0u5/xjvREEyw3u7myOeyJJQoPx5IWq9NOW+djP4wWZXzJVHNn9WpfzhXBQiylr njL7AwP174yqskYQnt0USUel3JOQP0sd+cO20kRkqN2tGwKkbl0lP2F9Ge069/4HkTgX 3FYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qw+9WsummIz69Xy0U1gYUJiA2Q5F+2Zo9xDLG5HAKBE=; b=DkmaA+nDRV7ThODwXZljkP9nzGtEYh1+2L3JVYrg4roHdrd4Y2n6EKfBq1l9bxgw0+ e/96GFQZa9McwkJJg2zxwaKjNh7wWqiZz5/5RrpuvEheS3Hbo/FFos7slZ0BgLeY8jTt MeCdebqVpHVaQbDjkxWxddZBaQqwG0+yQStOaoCKOld9BS2BPKWi9FAUjqQ/l1oZUfp5 YY0WYvWX22OuiT5SSuIgHMxP++no+195Aku+DFvHd11thIyhbITjr/O3tBw1Vfuengej ifJWTLWH69+nmZc3doCXGE5a8Bjx0BsdLUf4ubB1VMLtJBE8kXlG/8TPx2GOcBr0ssuF WvRg== X-Gm-Message-State: AOUpUlEEk0bYJz/8Ds2iB1B6at20tz/p64BWSOU3fLi4YFXPkxi4eQ1i /eQ+dba1Md0dKXEo/RLWx0/mJsmMTTLcIRVQOhk= X-Google-Smtp-Source: AA+uWPx67AvbSTPfsXQsIybowW8IxYqtz3saPA0EBlFgxfksufdLn4xJptu7WVzpRlTn2sgsAWuJhA3zzCN0P1rOPnU= X-Received: by 2002:a19:d8e8:: with SMTP id r101-v6mr531820lfi.121.1533796573219; Wed, 08 Aug 2018 23:36:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Wed, 8 Aug 2018 23:36:02 -0700 Message-ID: Subject: Re: Unified ACK frame encoding To: Martin Thomson Cc: QUIC WG , Magnus Westerlund Content-Type: multipart/alternative; boundary="000000000000e793840572fad72b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 06:36:19 -0000 --000000000000e793840572fad72b Content-Type: text/plain; charset="UTF-8" Thanks for picking this one up, Martin. As I've said to you and to Kazuho, I think if we can unify ACK and ACK_ECN frames "reasonably", I think there's a lot of value in having a single frame format. The question of course is if we can make this reasonable, so thanks for trying. I need to think some more when I'm not as fried as I am right now, but I'm not convinced about the encoding yet. A couple of more simplifying assumptions might help: 1. A receiver receives 3 types of packets: Non-ECT, ECT, CE. It only reports packets it has received. 2. We can assume that a sender uses ECT(0) or ECT(1), not both. Let's call this default-ECT. If a future mechanism wants to use both, they can define a new ACK frame. (Magnus and I checked on this with David Black, and he agrees on the use of a single default ECT value.) This means that you only need to report 3 types of ranges. Further, if you have a separate bit to communicate ECN/non-ECN, meaning that the receiver has seen ECT/CE bits and will echo them back, or the receiver has not seen ECT/CE bits and won't echo them back, then you have 1 or 2 types of ranges. ECN bit = 0: every range is of packets received, there's no ECN echo. This is exactly the same ACK format as what we have now. ECN bit = 1: ranges are of 2 types, default-ECT or CE. We need exactly 1 bit here to distinguish between these two ranges. I'm aware that if we move this ECN bit to the frame type, then we end up with two ACK frames again, but this is still far more unified than what we have now. I'm also aware that we need a way for a receiver to say that it received non-default ECT, but that can be separate, or an error even, and a receiver could stop reporting ECN assuming that a network box is messing with the bits. On Wed, Aug 8, 2018 at 8:54 PM Martin Thomson wrote: > (More long emails. Sorry, I'm trying to either close these issues or > prepare us for the interim.) > > We decided to take ACK_ECN to address an immediate need, but > recognized that the encoding was suboptimal. In the issue (see > https://github.com/quicwg/base-drafts/issues/1439) we've > beendiscussing an option for frame encoding that fixes a bunch of > issues. That discussion covered a lot of ground, but here is my > summary. > > This is what we have currently (using C/TLS style notation because I > don't think ASCII art works in email): > > struct ACK { > varint largest_acknowledged; > varint delay; > varint additional_block_count; > varint first_block; > struct { > varint gap; > varint block; > } blocks[additional_block_count]; > }; > > struct ACK_ECN { > ACK ack; > varint ect0_count; > varint ect1_count; > varint ecnce_count; > }; > > The most obvious issues are: > > A. There are two inconsistent encodings for acknowledgments depending > on whether ECN is enabled. > B. ACK_ECN has more overhead than ACK. Ideally there are fewer > disincentives to use ACK_ECN. > C. The counting scheme is imprecise (you don't always know which > packet was CE marked, and that could matter), which makes counting of > ECN markings fragile in the presence of ACK loss. This can lead to > ECN being disabled despite it being fully functional. > D. ECN counters always increase, and so they take more space to encode > over time. > > Kazuho suggested a scheme that adds some modest complexity, but I > think that it works and reduces other complexities such that it's > probably a net win on the complexity front. It also fixes these > issues at the same time. > > The observation is that there are 5 things that you might want to say > about any given packet number: > > 0. say nothing (i.e., I'm not acknowledging this packet; this is a gap) > 1. packet received, no marking > 2. packet received with an ECT(0) marking > 3. packet received with an ECT(1) marking > 4. packet received with an ECN-CE marking > > Now, the current system of describing ranges of packets is still > pretty good. An expression of the form "the next N packets are of > type X" gets us an encoding that is small and fits traffic patterns > well. No point changing what is a fundamentally good encoding. > > So, we retain the maximum packet number and the idea of expressing > ranges of packets. But each range is a tuple that expresses both the > type of acknowledgement (or lack thereof) for that range and how many > packets are in the range. > > That would produce an ACK frame in the following basic shape: > > struct ACK { > varint largest_acknowledged; > varint delay; > varint range_count; > struct { > enum {gap,unmarked,ect0,ect1,ecnce} type; > varint count; > } ranges[range_count]; > }; > > The problem now is that we lost efficiency in a big way because the > enum takes up a ton of space, for just 5 values. > > If we observe that there are 5 types, but you don't need to repeat the > same type, then we can express the type in two bits. That is, the > type is interpreted as: > > type = last_type + 1 + encoded_type (mod 5) > > Kazuho suggested that we pack these bits into the low two bits of a > varint. It's a little ugly, but I can't see a better option. For > instance, defining a new varint type would be considerably worse. In > addition to not being able to reuse varint code, my testing on > encodings showed that a defining a new type with flags before the > 2-bit length is surprisingly expensive. > > This produces a format like this: > > struct ACK { > varint largest_acknowledged; > varint delay; > varint range_count; > varint ranges[range_count]; > }; > > As you can see, this is a considerable simplification. The only trick > is that more data is packed into each range value. These values are > encoded using something like: > > encoded_type = (type + 4 - last_type) % 5 > // encoded_type = type - last_type - 1 (mod 5) > range = encoded_type | (count << 2) > > The cost is that ranges take one more byte once they get above 16 > packets rather than at 64 packets as before. It's also possible with > this to encode a non-acknowledgment at the end of an ACK frame, which > I think we can either prohibit or ignore. But it fixes all the above > problems. > > Is this a change worth making? > > Cheers, > Martin > > > A side note: This works whether we encode a count (as here) or a total > number of octets (as has been proposed). Similarly, we could count > from the bottom rather than the top if we wanted to. Those decisions > are orthogonal to this; I'm trying as much as possible to retain the > current design. > > Another note: We already have an issue on file for an ACK frame > example. That is still planned and that should help with interpreting > the text. > > --000000000000e793840572fad72b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for picking this one up, Martin. As I've said t= o you and to Kazuho, I think if we can unify ACK and ACK_ECN frames "r= easonably", I think there's a lot of value in having a single fram= e format. The question of course is if we can make this reasonable, so than= ks for trying.

I need to think some more when I'm not as fr= ied as I am right now, but I'm not convinced about the encoding yet. A = couple of more simplifying assumptions might help:
1. A receiver = receives 3 types of packets: Non-ECT, ECT, CE. It only reports packets it h= as received.
2. We can assume that a sender uses ECT(0) or EC= T(1), not both. Let's call this default-ECT. If a future mechanism want= s to use both, they can define a new ACK frame. (Magnus and I checked on th= is with David Black, and he agrees on the use of a single default ECT value= .)

This means that you only need to report 3 types= of ranges.

Further, if you have a separate bit to= communicate ECN/non-ECN, meaning that the receiver has seen ECT/CE bits an= d will echo them back, or the receiver has not seen ECT/CE bits and won'= ;t echo them back, then you have 1 or 2 types of ranges.
ECN bit = =3D 0: every range is of packets received, there's no ECN echo. This is= exactly the same ACK format as what we have now.
ECN bit =3D 1: = ranges are of 2 types, default-ECT or CE. We need exactly 1 bit here to dis= tinguish between these two ranges.

I'm aware that if = we move this ECN bit to the frame type, then we end up with two ACK frames = again, but this is still far more unified than what we have now. I'm al= so aware that we need a way for a receiver to say that it received non-defa= ult ECT, but that can be separate, or an error even, and a receiver could s= top reporting ECN assuming that a network box is messing with the bits.

On Wed, Aug 8, 2018= at 8:54 PM Martin Thomson <= martin.thomson@gmail.com> wrote:
(More long emails. Sorry, I'm trying to either close these issues = or
prepare us for the interim.)

We decided to take ACK_ECN to address an immediate need, but
recognized that the encoding was suboptimal.=C2=A0 In the issue (see
https://github.com/quicwg/base-drafts/issues/1439) we've
beendiscussing an option for frame encoding that fixes a bunch of
issues. That discussion covered a lot of ground, but here is my
summary.

This is what we have currently (using C/TLS style notation because I
don't think ASCII art works in email):

=C2=A0 =C2=A0struct ACK {
=C2=A0 =C2=A0 =C2=A0 varint largest_acknowledged;
=C2=A0 =C2=A0 =C2=A0 varint delay;
=C2=A0 =C2=A0 =C2=A0 varint additional_block_count;
=C2=A0 =C2=A0 =C2=A0 varint first_block;
=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0varint gap;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0varint block;
=C2=A0 =C2=A0 =C2=A0 } blocks[additional_block_count];
=C2=A0 =C2=A0};

=C2=A0 =C2=A0struct ACK_ECN {
=C2=A0 =C2=A0 =C2=A0 ACK ack;
=C2=A0 =C2=A0 =C2=A0 varint ect0_count;
=C2=A0 =C2=A0 =C2=A0 varint ect1_count;
=C2=A0 =C2=A0 =C2=A0 varint ecnce_count;
=C2=A0 =C2=A0};

The most obvious issues are:

A. There are two inconsistent encodings for acknowledgments depending
on whether ECN is enabled.
B. ACK_ECN has more overhead than ACK.=C2=A0 Ideally there are fewer
disincentives to use ACK_ECN.
C. The counting scheme is imprecise (you don't always know which
packet was CE marked, and that could matter), which makes counting of
ECN markings fragile in the presence of ACK loss.=C2=A0 This can lead to ECN being disabled despite it being fully functional.
D. ECN counters always increase, and so they take more space to encode
over time.

Kazuho suggested a scheme that adds some modest complexity, but I
think that it works and reduces other complexities such that it's
probably a net win on the complexity front.=C2=A0 It also fixes these
issues at the same time.

The observation is that there are 5 things that you might want to say
about any given packet number:

0. say nothing (i.e., I'm not acknowledging this packet; this is a gap)=
1. packet received, no marking
2. packet received with an ECT(0) marking
3. packet received with an ECT(1) marking
4. packet received with an ECN-CE marking

Now, the current system of describing ranges of packets is still
pretty good.=C2=A0 An expression of the form "the next N packets are o= f
type X" gets us an encoding that is small and fits traffic patterns well.=C2=A0 No point changing what is a fundamentally good encoding.

So, we retain the maximum packet number and the idea of expressing
ranges of packets. But each range is a tuple that expresses both the
type of acknowledgement (or lack thereof) for that range and how many
packets are in the range.

That would produce an ACK frame in the following basic shape:

=C2=A0 =C2=A0struct ACK {
=C2=A0 =C2=A0 =C2=A0 varint largest_acknowledged;
=C2=A0 =C2=A0 =C2=A0 varint delay;
=C2=A0 =C2=A0 =C2=A0 varint range_count;
=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum {gap,unmarked,ect0,ect1,ecnce} type;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0varint count;
=C2=A0 =C2=A0 =C2=A0 } ranges[range_count];
=C2=A0 =C2=A0};

The problem now is that we lost efficiency in a big way because the
enum takes up a ton of space, for just 5 values.

If we observe that there are 5 types, but you don't need to repeat the<= br> same type, then we can express the type in two bits.=C2=A0 That is, the
type is interpreted as:

=C2=A0 =C2=A0type =3D last_type + 1 + encoded_type (mod 5)

Kazuho suggested that we pack these bits into the low two bits of a
varint.=C2=A0 It's a little ugly, but I can't see a better option.= =C2=A0 For
instance, defining a new varint type would be considerably worse.=C2=A0 In<= br> addition to not being able to reuse varint code, my testing on
encodings showed that a defining a new type with flags before the
2-bit length is surprisingly expensive.

This produces a format like this:

=C2=A0 =C2=A0struct ACK {
=C2=A0 =C2=A0 =C2=A0 varint largest_acknowledged;
=C2=A0 =C2=A0 =C2=A0 varint delay;
=C2=A0 =C2=A0 =C2=A0 varint range_count;
=C2=A0 =C2=A0 =C2=A0 varint ranges[range_count];
=C2=A0 =C2=A0};

As you can see, this is a considerable simplification.=C2=A0 The only trick=
is that more data is packed into each range value.=C2=A0 These values are encoded using something like:

=C2=A0 =C2=A0encoded_type =3D (type + 4 - last_type) % 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0// encoded_type =3D type - last_type - 1 (mod 5)=
=C2=A0 =C2=A0range =3D encoded_type | (count << 2)

The cost is that ranges take one more byte once they get above 16
packets rather than at 64 packets as before.=C2=A0 It's also possible w= ith
this to encode a non-acknowledgment at the end of an ACK frame, which
I think we can either prohibit or ignore.=C2=A0 But it fixes all the above<= br> problems.

Is this a change worth making?

Cheers,
Martin


A side note: This works whether we encode a count (as here) or a total
number of octets (as has been proposed).=C2=A0 Similarly, we could count from the bottom rather than the top if we wanted to.=C2=A0 Those decisions<= br> are orthogonal to this; I'm trying as much as possible to retain the current design.

Another note: We already have an issue on file for an ACK frame
example.=C2=A0 That is still planned and that should help with interpreting=
the text.

--000000000000e793840572fad72b-- From nobody Thu Aug 9 00:06:51 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F601271FF for ; Thu, 9 Aug 2018 00:06:50 -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, FREEMAIL_FROM=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 qnjhRGu-4Bx7 for ; Thu, 9 Aug 2018 00:06:48 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B872124C04 for ; Thu, 9 Aug 2018 00:06:47 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id b22-v6so3373420lfa.3 for ; Thu, 09 Aug 2018 00:06:47 -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=fHAHquOpogLwdSGypZvGKwXZc7vjyWAS3+ZYwUCtAAU=; b=QaiAApznlFoO+4lrO7EQaLCwspI35uF9l9iIaOtNd+CgS1vjY2R7SlVAqNCtzXoZ3d FuiaoLFVdWa5oaJJpmA3PaKh57K8tCqsn3dKkX/ZQRFaCnEXHx/OutzGdsQ5tMhhNhTq NASvsGyqHyO5GGQOgNG2zA+y245vUsivcoRTdL4Kkw3uo8QbxYSMjmGEMT+iUtXspoiD UJ54cAZoRTw+LEIgcjLzn0uAZbsy2zG6kaOGzNLlrLVwhbInx1xYbICU3L5D1cdqTqgk TYjt6d5KOz5sk/6HU+oTS4/uGNlZQWMOdQAt70bu39lnZPeXI6HlSSy+D+rjxR4KVvXi qV/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fHAHquOpogLwdSGypZvGKwXZc7vjyWAS3+ZYwUCtAAU=; b=Xr9LUkpfwaGqeqJTh0EnvQYUYV+htHCB4DGTHm9QlL52jgwuD2lsa0+rNdjLdheEVR /cxy6e5twKehOiK0/h7vhAAn4N6UBSDB03UPEnZOWJk/LRo8PH5Mk9KYtbdkNGoqFnn1 gnfNWSs+bxzpPKCjqcrRNa4O6Qa76mLKVQFQ7Kan4nvqaY8lAZk0LKyZtyDU3602lGIx +Fen/zi7r0Lkr3cyZdgoKelZuNRUg+wk9h4no8+uaDKQH/0GKu1rMQaLk/MOO7/B7VKi DejxY90MEaROXrsGDjFL5SZMdu6WR/SzNQSMlFyGUZOL06JSGNbgN9ul+O6cCMRPf0ck QQGg== X-Gm-Message-State: AOUpUlGGFIR4H09knxZO/VQ6C6ktrpxP2CAaSkhviZEjGYp5s7RC/Of+ SwBEmhijuZoFhp/QUWnajLi7uqbomkAwCclqptM= X-Google-Smtp-Source: AA+uWPxFvl9ZH2yd2dG+VwYcf5Z8Djr6qW4iTiY1/QvHiCAJah1VYj7goXAohRKI8BnwcSHlQljvZXVje0O+ky1Jmqg= X-Received: by 2002:a19:de4e:: with SMTP id v75-v6mr643146lfg.14.1533798405686; Thu, 09 Aug 2018 00:06:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Thu, 9 Aug 2018 00:06:45 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Thu, 9 Aug 2018 16:06:45 +0900 Message-ID: Subject: Re: Unified ACK frame encoding To: Jana Iyengar Cc: Martin Thomson , Magnus Westerlund , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 07:06:50 -0000 2018-08-09 15:36 GMT+09:00 Jana Iyengar : > Thanks for picking this one up, Martin. As I've said to you and to Kazuho, I > think if we can unify ACK and ACK_ECN frames "reasonably", I think there's a > lot of value in having a single frame format. I am happy to see us arguing for unified frame type. IMO, the format that Martin and I have proposed has two important properties: unified frame type and precise signaling (i.e. indication of which PN was received with which ECN flags). I do not think that you have missed the latter (because your suggestion retains that property), but I would like to reemphasize the importance of having precise signals (Martin has covered that in his original mail). > The question of course is if > we can make this reasonable, so thanks for trying. > > I need to think some more when I'm not as fried as I am right now, but I'm > not convinced about the encoding yet. A couple of more simplifying > assumptions might help: > 1. A receiver receives 3 types of packets: Non-ECT, ECT, CE. It only reports > packets it has received. > 2. We can assume that a sender uses ECT(0) or ECT(1), not both. Let's call > this default-ECT. If a future mechanism wants to use both, they can define a > new ACK frame. (Magnus and I checked on this with David Black, and he agrees > on the use of a single default ECT value..) > This means that you only need to report 3 types of ranges. It's good to know that we can possibly go with having just 4 states (including gaps) rather than 5. Because if the number of the states can be reduced to 4, the modes can be encoded without making the diff-modulo calculation. Having that said, I might prefer having 5 states that encodes into 2 bits rather than having 4 states, if having 4 states means that we need to have a "prefilter" (i.e. a logic that remembers the default ECT flag and do things if a non-default ECT flag is observed). In my view, doing the diff-modulo calculation is easier than having a "prefilter" that has it's own state that is bound to the lifetime of the 5-tuple. > > Further, if you have a separate bit to communicate ECN/non-ECN, meaning that > the receiver has seen ECT/CE bits and will echo them back, or the receiver > has not seen ECT/CE bits and won't echo them back, then you have 1 or 2 > types of ranges. > ECN bit = 0: every range is of packets received, there's no ECN echo. This > is exactly the same ACK format as what we have now. > ECN bit = 1: ranges are of 2 types, default-ECT or CE. We need exactly 1 bit > here to distinguish between these two ranges. > > I'm aware that if we move this ECN bit to the frame type, then we end up > with two ACK frames again, but this is still far more unified than what we > have now. I'm also aware that we need a way for a receiver to say that it > received non-default ECT, but that can be separate, or an error even, and a > receiver could stop reporting ECN assuming that a network box is messing > with the bits. I am not sure if I like the approach, because it requires QUIC stacks to do a two-pass on the ack queue. I would rather prefer having an ACK frame format that allows us to serialize the ack queue (which will be an ordered list of PNs with ECN flags associated to each PN) in one-pass. > > On Wed, Aug 8, 2018 at 8:54 PM Martin Thomson > wrote: >> >> (More long emails. Sorry, I'm trying to either close these issues or >> prepare us for the interim.) >> >> We decided to take ACK_ECN to address an immediate need, but >> recognized that the encoding was suboptimal. In the issue (see >> https://github.com/quicwg/base-drafts/issues/1439) we've >> beendiscussing an option for frame encoding that fixes a bunch of >> issues. That discussion covered a lot of ground, but here is my >> summary. >> >> This is what we have currently (using C/TLS style notation because I >> don't think ASCII art works in email): >> >> struct ACK { >> varint largest_acknowledged; >> varint delay; >> varint additional_block_count; >> varint first_block; >> struct { >> varint gap; >> varint block; >> } blocks[additional_block_count]; >> }; >> >> struct ACK_ECN { >> ACK ack; >> varint ect0_count; >> varint ect1_count; >> varint ecnce_count; >> }; >> >> The most obvious issues are: >> >> A. There are two inconsistent encodings for acknowledgments depending >> on whether ECN is enabled. >> B. ACK_ECN has more overhead than ACK. Ideally there are fewer >> disincentives to use ACK_ECN. >> C. The counting scheme is imprecise (you don't always know which >> packet was CE marked, and that could matter), which makes counting of >> ECN markings fragile in the presence of ACK loss. This can lead to >> ECN being disabled despite it being fully functional. >> D. ECN counters always increase, and so they take more space to encode >> over time. >> >> Kazuho suggested a scheme that adds some modest complexity, but I >> think that it works and reduces other complexities such that it's >> probably a net win on the complexity front. It also fixes these >> issues at the same time. >> >> The observation is that there are 5 things that you might want to say >> about any given packet number: >> >> 0. say nothing (i.e., I'm not acknowledging this packet; this is a gap) >> 1. packet received, no marking >> 2. packet received with an ECT(0) marking >> 3. packet received with an ECT(1) marking >> 4. packet received with an ECN-CE marking >> >> Now, the current system of describing ranges of packets is still >> pretty good. An expression of the form "the next N packets are of >> type X" gets us an encoding that is small and fits traffic patterns >> well. No point changing what is a fundamentally good encoding. >> >> So, we retain the maximum packet number and the idea of expressing >> ranges of packets. But each range is a tuple that expresses both the >> type of acknowledgement (or lack thereof) for that range and how many >> packets are in the range. >> >> That would produce an ACK frame in the following basic shape: >> >> struct ACK { >> varint largest_acknowledged; >> varint delay; >> varint range_count; >> struct { >> enum {gap,unmarked,ect0,ect1,ecnce} type; >> varint count; >> } ranges[range_count]; >> }; >> >> The problem now is that we lost efficiency in a big way because the >> enum takes up a ton of space, for just 5 values. >> >> If we observe that there are 5 types, but you don't need to repeat the >> same type, then we can express the type in two bits. That is, the >> type is interpreted as: >> >> type = last_type + 1 + encoded_type (mod 5) >> >> Kazuho suggested that we pack these bits into the low two bits of a >> varint. It's a little ugly, but I can't see a better option. For >> instance, defining a new varint type would be considerably worse. In >> addition to not being able to reuse varint code, my testing on >> encodings showed that a defining a new type with flags before the >> 2-bit length is surprisingly expensive. >> >> This produces a format like this: >> >> struct ACK { >> varint largest_acknowledged; >> varint delay; >> varint range_count; >> varint ranges[range_count]; >> }; >> >> As you can see, this is a considerable simplification. The only trick >> is that more data is packed into each range value. These values are >> encoded using something like: >> >> encoded_type = (type + 4 - last_type) % 5 >> // encoded_type = type - last_type - 1 (mod 5) >> range = encoded_type | (count << 2) >> >> The cost is that ranges take one more byte once they get above 16 >> packets rather than at 64 packets as before. It's also possible with >> this to encode a non-acknowledgment at the end of an ACK frame, which >> I think we can either prohibit or ignore. But it fixes all the above >> problems. >> >> Is this a change worth making? >> >> Cheers, >> Martin >> >> >> A side note: This works whether we encode a count (as here) or a total >> number of octets (as has been proposed). Similarly, we could count >> from the bottom rather than the top if we wanted to. Those decisions >> are orthogonal to this; I'm trying as much as possible to retain the >> current design. >> >> Another note: We already have an issue on file for an ACK frame >> example. That is still planned and that should help with interpreting >> the text. >> > -- Kazuho Oku From nobody Thu Aug 9 00:52:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDA8124C04 for ; Thu, 9 Aug 2018 00:52:16 -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 U9cJGu8I0um8 for ; Thu, 9 Aug 2018 00:52:13 -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 0CF3D130DFA for ; Thu, 9 Aug 2018 00:52:11 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9220B340D9C; Thu, 9 Aug 2018 09:52:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.23181); Thu, 9 Aug 2018 09:52:09 +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, 9 Aug 2018 09:52:09 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 63658247; Thu, 09 Aug 2018 09:52:09 +0200 From: "Brian Trammell (IETF)" Message-Id: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_6C2F056F-0D9C-40CA-A3CB-C9D0D4CF6923"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Unified ACK frame encoding Date: Thu, 9 Aug 2018 09:52:08 +0200 In-Reply-To: Cc: Martin Thomson , Magnus Westerlund , QUIC WG To: Jana Iyengar References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 07:52:16 -0000 --Apple-Mail=_6C2F056F-0D9C-40CA-A3CB-C9D0D4CF6923 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, all, Also fried, but I've had a quick look at this... > On 9 Aug 2018, at 08:36, Jana Iyengar wrote: >=20 > Thanks for picking this one up, Martin. As I've said to you and to = Kazuho, I think if we can unify ACK and ACK_ECN frames "reasonably", I = think there's a lot of value in having a single frame format. The = question of course is if we can make this reasonable, so thanks for = trying. >=20 > I need to think some more when I'm not as fried as I am right now, but = I'm not convinced about the encoding yet. +1 to this -- if we find not-quite-varints in packet numbers = uncomfortable, I can't see us finding rolling five-in-four encoding in = the low bits of a different not-quite-varint less so. > A couple of more simplifying assumptions might help: > 1. A receiver receives 3 types of packets: Non-ECT, ECT, CE. It only = reports packets it has received. > 2. We can assume that a sender uses ECT(0) or ECT(1), not both. Let's = call this default-ECT. If a future mechanism wants to use both, they can = define a new ACK frame. (Magnus and I checked on this with David Black, = and he agrees on the use of a single default ECT value..) This also seems reasonable to me, and AFAICT lines up with all the = current proposals for using ECT0/1 signaling. > This means that you only need to report 3 types of ranges. >=20 > Further, if you have a separate bit to communicate ECN/non-ECN, = meaning that the receiver has seen ECT/CE bits and will echo them back, = or the receiver has not seen ECT/CE bits and won't echo them back, then = you have 1 or 2 types of ranges. > ECN bit =3D 0: every range is of packets received, there's no ECN = echo. This is exactly the same ACK format as what we have now. > ECN bit =3D 1: ranges are of 2 types, default-ECT or CE. We need = exactly 1 bit here to distinguish between these two ranges. >=20 > I'm aware that if we move this ECN bit to the frame type, then we end = up with two ACK frames again, but this is still far more unified than = what we have now. +1. I'm really not bothered by pushing some of the ACK signaling bits = into the frame type (especially if we describe these frames in a unified = way, as we do with STREAM frames), as long as the structure of the = frames is identical. Cheers, Brian > I'm also aware that we need a way for a receiver to say that it = received non-default ECT, but that can be separate, or an error even, = and a receiver could stop reporting ECN assuming that a network box is = messing with the bits. >=20 > On Wed, Aug 8, 2018 at 8:54 PM Martin Thomson = wrote: > (More long emails. Sorry, I'm trying to either close these issues or > prepare us for the interim.) >=20 > We decided to take ACK_ECN to address an immediate need, but > recognized that the encoding was suboptimal. In the issue (see > https://github.com/quicwg/base-drafts/issues/1439) we've > beendiscussing an option for frame encoding that fixes a bunch of > issues. That discussion covered a lot of ground, but here is my > summary. >=20 > This is what we have currently (using C/TLS style notation because I > don't think ASCII art works in email): >=20 > struct ACK { > varint largest_acknowledged; > varint delay; > varint additional_block_count; > varint first_block; > struct { > varint gap; > varint block; > } blocks[additional_block_count]; > }; >=20 > struct ACK_ECN { > ACK ack; > varint ect0_count; > varint ect1_count; > varint ecnce_count; > }; >=20 > The most obvious issues are: >=20 > A. There are two inconsistent encodings for acknowledgments depending > on whether ECN is enabled. > B. ACK_ECN has more overhead than ACK. Ideally there are fewer > disincentives to use ACK_ECN. > C. The counting scheme is imprecise (you don't always know which > packet was CE marked, and that could matter), which makes counting of > ECN markings fragile in the presence of ACK loss. This can lead to > ECN being disabled despite it being fully functional. > D. ECN counters always increase, and so they take more space to encode > over time. >=20 > Kazuho suggested a scheme that adds some modest complexity, but I > think that it works and reduces other complexities such that it's > probably a net win on the complexity front. It also fixes these > issues at the same time. >=20 > The observation is that there are 5 things that you might want to say > about any given packet number: >=20 > 0. say nothing (i.e., I'm not acknowledging this packet; this is a = gap) > 1. packet received, no marking > 2. packet received with an ECT(0) marking > 3. packet received with an ECT(1) marking > 4. packet received with an ECN-CE marking >=20 > Now, the current system of describing ranges of packets is still > pretty good. An expression of the form "the next N packets are of > type X" gets us an encoding that is small and fits traffic patterns > well. No point changing what is a fundamentally good encoding. >=20 > So, we retain the maximum packet number and the idea of expressing > ranges of packets. But each range is a tuple that expresses both the > type of acknowledgement (or lack thereof) for that range and how many > packets are in the range. >=20 > That would produce an ACK frame in the following basic shape: >=20 > struct ACK { > varint largest_acknowledged; > varint delay; > varint range_count; > struct { > enum {gap,unmarked,ect0,ect1,ecnce} type; > varint count; > } ranges[range_count]; > }; >=20 > The problem now is that we lost efficiency in a big way because the > enum takes up a ton of space, for just 5 values. >=20 > If we observe that there are 5 types, but you don't need to repeat the > same type, then we can express the type in two bits. That is, the > type is interpreted as: >=20 > type =3D last_type + 1 + encoded_type (mod 5) >=20 > Kazuho suggested that we pack these bits into the low two bits of a > varint. It's a little ugly, but I can't see a better option. For > instance, defining a new varint type would be considerably worse. In > addition to not being able to reuse varint code, my testing on > encodings showed that a defining a new type with flags before the > 2-bit length is surprisingly expensive. >=20 > This produces a format like this: >=20 > struct ACK { > varint largest_acknowledged; > varint delay; > varint range_count; > varint ranges[range_count]; > }; >=20 > As you can see, this is a considerable simplification. The only trick > is that more data is packed into each range value. These values are > encoded using something like: >=20 > encoded_type =3D (type + 4 - last_type) % 5 > // encoded_type =3D type - last_type - 1 (mod 5) > range =3D encoded_type | (count << 2) >=20 > The cost is that ranges take one more byte once they get above 16 > packets rather than at 64 packets as before. It's also possible with > this to encode a non-acknowledgment at the end of an ACK frame, which > I think we can either prohibit or ignore. But it fixes all the above > problems. >=20 > Is this a change worth making? >=20 > Cheers, > Martin >=20 >=20 > A side note: This works whether we encode a count (as here) or a total > number of octets (as has been proposed). Similarly, we could count > from the bottom rather than the top if we wanted to. Those decisions > are orthogonal to this; I'm trying as much as possible to retain the > current design. >=20 > Another note: We already have an issue on file for an ACK frame > example. That is still planned and that should help with interpreting > the text. >=20 --Apple-Mail=_6C2F056F-0D9C-40CA-A3CB-C9D0D4CF6923 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAltr8qgACgkQihK3vwvq RqPdexAApFcwRFliHkRZKDJ4kFMOZY/j+P1jUFlJkA4Lz5cZYuJaMskXMinbySMR yi1Q1chCxVJs2/J88GE75yfxf6rAPl0Db2rU7e+6roFOQW80F1rIc68bMIAHnXVk SbZqT0Z4A9PD9nurUCY9XrMXGjImUWV2TBUtcyMkzd9adQaVpzzUnjLe0Mt6xRUJ 3MlryReOt0+gtTHcSDHO6u168lCf0Fjx9cFj1o5g+H9GZ06GPTzmBn/Y/2wr9fDu Kn1ahOv2/rxngTHjBEf7eDehJqFPyBzjDRvpsQcS7pVC45B4FZpto2pu4Vhmf5py MOo6TwaAyWL0hbgv6NKHfwWiE48xzuINQmQDsEDCLgCLppmByqZABLg7aNhTUgsa paTiRRmUoIaNclkkI3VegMwM3m+n4IPuWNb+6IjwecZ6RPnyC7wEbauOHw6BJJ23 axdfAB6GfFNqtJVok2wNMAY9pu2LDIxbdg3LovNLd9H4OSVdFi6rIYHSp5tvoM7g MKU5pVR0O/1FnkqPMS6AmEq+8lpoHa0GzJ9H8hPLLT+0Cmri6wuCkLoD3CXriYrn 9Sp975+3MfRc9mU6pI0SoQx33DJ1hxEldayQO2StmDkRx5JcBl/6i6lJFP1MXAac GVBCZAdd419mENKlwfmS7Xm/2SkuDL9jiETEYxwBvRZT2Srqovo= =f8ro -----END PGP SIGNATURE----- --Apple-Mail=_6C2F056F-0D9C-40CA-A3CB-C9D0D4CF6923-- From nobody Thu Aug 9 06:17:34 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747A7130E4D for ; Thu, 9 Aug 2018 06:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 if1FrRXjUwdJ for ; Thu, 9 Aug 2018 06:17:30 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD05F130E14 for ; Thu, 9 Aug 2018 06:17:30 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id d4-v6so6352000qtn.13 for ; Thu, 09 Aug 2018 06:17:30 -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:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=yCBbisMbemG8l3vNIjYt870CtkafhL4hi8ClgXQC3bY=; b=H4DOUBpXuZbILU+tUJ55STs0zn6ZY8OaO6bUIYOdtXBb5o9DBfcPv0mkCDMiaS0N50 4c0uVIBCo2UbpJRPahDV171plqzwdXyJzuoK94dDKHboo9/1yaX6GeBfTVxIz+BOviwj 4bUXDjShHRZ3bNQ5HIdhVKqcWJWwluAtfMibnJhKjtm5wAaR687I/utIcUVShfPbcw33 XjuY2XhLMqrJ2HYdM054tqfFxnLkwCJ6OtknV3VD2AmH2bn0Vwq6Q7+HMjdrpBwdzV1h VBhm5gYrOAMCyHX/zUMyliE0KE9dNz0gGi8aBkowsQLfZaLtlEMkLRLdRyJduPhwnn+q hyyw== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=yCBbisMbemG8l3vNIjYt870CtkafhL4hi8ClgXQC3bY=; b=Hj6KRPrdV0i6LNjmkCDcdsyHOAJIDZb82EGhzqq1RqABVP6W3ZboUheQ0Zj2JVEM8b QucdwCEoV54iKz8Z0aZ11aVidvPy6DPzrx0b8cNtq0FXKnGlsByZMnSh+SLm6wKhUyc2 3sGBRdiNysTU/5w0MGnCwRsoDidlNdJBkmOl1iZJOJnOP1E4pnhti8I/QbH6DpsER0LD 4VPjTvRzy+rYiSAx5kaUqZkl/YtX8Hjzy05eQgjYCs540pn0uOtjHUxEmzm/JieAGSl2 nfugHfNb3Wldp5zx8MQ/mVhxlGWNVbwPIr2pMvU77LDBHSQUX8nFjp0QO/2QMX9c8b85 6wLA== X-Gm-Message-State: AOUpUlF/U6CRgsKbnx2wVc7y6RjvtqSG8zZBRq0yawSiTjwr0hE6QvVZ ny28uHdnBz2TzqYaI/gx6hKN5g== X-Google-Smtp-Source: AA+uWPxEYpf+vXNLQ9Wvf3T82eGd3sghv5Tos7Rj3fjFjKEo25VuKaUMVsBYRzt/CASLx0M7ZrX6HQ== X-Received: by 2002:ac8:fc9:: with SMTP id f9-v6mr1995381qtk.377.1533820649896; Thu, 09 Aug 2018 06:17:29 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id h51-v6sm5134144qte.17.2018.08.09.06.17.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 06:17:29 -0700 (PDT) Date: Thu, 9 Aug 2018 09:17:23 -0400 From: Dmitri Tikhonov To: Martin Thomson Cc: QUIC WG Subject: Re: QPACK proposal: wrap absolute index values Message-ID: <20180809131722.GA30883@ubuntu-dmitri> Mail-Followup-To: Martin Thomson , QUIC WG References: <20180805154649.GA14245@ubuntu-dmitri> <20180806043610.GC25402@ubuntu-dmitri> <20180806044626.GD25402@ubuntu-dmitri> <20180806121947.GA31889@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 13:17:32 -0000 On Thu, Aug 09, 2018 at 07:32:01AM +1000, Martin Thomson wrote: > So this is a really interesting idea, but I did a triage yesterday and > missed it. Dmitri, would you mind creating an issue for this? Not at all: https://github.com/quicwg/base-drafts/issues/1644 - Dmitri. From nobody Thu Aug 9 06:19:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A276130FAF for ; Thu, 9 Aug 2018 06:19:15 -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 bBnx32Bloc0v for ; Thu, 9 Aug 2018 06:19:13 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E59130F8D for ; Thu, 9 Aug 2018 06:19:13 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id n21-v6so9754278oig.3 for ; Thu, 09 Aug 2018 06:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=M2JbWf/ynPBOZuZWZVSU8Jyrgcjhu3cBTfH01bDsq9c=; b=q0heog9yL/1RiIyaNVIewELlJ6isvhBu7rhrzo3HKAuz228XxV0OyLhLKUVNR9580A 1qdXqQjQUVrQMhv2uuFkb/Jga/QeosbyYjymj7P2n8Y9aq8TbnrnKdU8n5kXEUkbcNUE Iwkua4dewbNYqTQMETEEz6X6LVxAdOl19PwYnlHB/imYwLMgO4z+o0bpnmQcAw+Ga2Ah A08FKbOMOVzA7kqf6yTfP2QMtMadFEDRw6/Na21VO1e/+FbNe9tt5WvTUMNAqMS1hbgy y6MVmjjxQRk5tqdOP+IpwttOaIT9zjPbZste+0Z5btZMBQTNOtQwsshb+dEz+QehEGkw Is2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=M2JbWf/ynPBOZuZWZVSU8Jyrgcjhu3cBTfH01bDsq9c=; b=azsg6hKHJGyndz1uHECbXgRP1/xHYb8Ic9naA17ypLkKMqEJ+jmCYSz3DW8FYrvXU3 YFnSH3qQTFLYcNC6K7lmNYzdeTYn0Ug3PubKO6g2hZOo8H968hA7J3/Ks65yFgj+5iez mk+j4xjQqbxuvsc60KQRUWgbUZ7Q6ItWHFC1yQhURAULY69GQ9z2zhxkferP4cQDjbIf +AXiOJnRdnQp4l0JHyT9eAyYdW9Sa/pfIL6qJTxz/jMieiWa1VXR6T96Taw0fBREzbXG tFc9EZ+BjIjKqI9aTkHdeNo0xcMo0hUhVdBHJLAXxGaZgRVnw9gKvySeKisl4ieMFGJd oBbA== X-Gm-Message-State: AOUpUlHDPhmFoa2joUaWI8bGB0s3qaXfGToc9TSR1XkahoSqcDvm7aU6 2PWzyT4AAizclcGYZmWqAQAdaEBHaAjyM+7TPzDxU4pu X-Google-Smtp-Source: AA+uWPwHxBT+mAgvEd1bRnY+2D2oOiZ6QidWgO9d0d00MttSU/cZdvvUSPh7YTkOOH05VanuRs1gQ4TxDEUgGgWSeQk= X-Received: by 2002:aca:b208:: with SMTP id b8-v6mr1988388oif.144.1533820752425; Thu, 09 Aug 2018 06:19:12 -0700 (PDT) MIME-Version: 1.0 References: <20180805154649.GA14245@ubuntu-dmitri> <20180806043610.GC25402@ubuntu-dmitri> <20180806044626.GD25402@ubuntu-dmitri> <20180806121947.GA31889@ubuntu-dmitri> <20180809131722.GA30883@ubuntu-dmitri> In-Reply-To: <20180809131722.GA30883@ubuntu-dmitri> From: Martin Thomson Date: Thu, 9 Aug 2018 23:19:00 +1000 Message-ID: Subject: Re: QPACK proposal: wrap absolute index values To: QUIC WG Content-Type: multipart/alternative; boundary="00000000000018fca5057300796e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 13:19:23 -0000 --00000000000018fca5057300796e Content-Type: text/plain; charset="UTF-8" On Thu, 9 Aug. 2018, 23:17 Dmitri Tikhonov, wrote: > On Thu, Aug 09, 2018 at 07:32:01AM +1000, Martin Thomson wrote: > > So this is a really interesting idea, but I did a triage yesterday and > > missed it. Dmitri, would you mind creating an issue for this? > > Not at all: > > https://github.com/quicwg/base-drafts/issues/1644 Thanks. > > --00000000000018fca5057300796e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 09, 2018 at 07:32:01AM +1000, Marti= n Thomson wrote:
> So this is a really interesting idea, but I did a triage yesterday and=
> missed it.=C2=A0 Dmitri, would you mind creating an issue for this?
Not at all:

=C2=A0 https://github.com/quicwg/base-dr= afts/issues/1644

Thanks.=C2=A0

--00000000000018fca5057300796e-- From nobody Thu Aug 9 08:52:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC3E130E3F for ; Thu, 9 Aug 2018 08:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt4PwJhjCq4s for ; Thu, 9 Aug 2018 08:52:00 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710095.outbound.protection.outlook.com [40.107.71.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB00130E21 for ; Thu, 9 Aug 2018 08:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mb5eNreglfO6EHJDXBJDaCdNu/ZFNda/qcSo787huzg=; b=SdzhdUr5zhdRvXMgRmz2/DPobfb+4XxGpxS3m3F+zRl9Y2KjEPHVWASyo2eTHdIwUJwsjwOVq8Cn/skfjiRaITKcFKeAn4PBnIgUNcmTF/yLe1qn3vFN4pHjK2v8UO/siD1O2xdepCyf/cfaAf1CI3tndFRObRj3KqxlDJpoqUI= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB3912.namprd08.prod.outlook.com (52.135.194.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.15; Thu, 9 Aug 2018 15:51:57 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::913f:4f09:ae22:b6db]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::913f:4f09:ae22:b6db%5]) with mapi id 15.20.1038.019; Thu, 9 Aug 2018 15:51:56 +0000 From: Mike Bishop To: Ryan Hamilton , IETF QUIC WG Subject: RE: Reserved HTTP Frames Thread-Topic: Reserved HTTP Frames Thread-Index: AQHUL1yjkMEVY37LVkuUUxvpaUrG6KS3kriw Date: Thu, 9 Aug 2018 15:51:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:8be:a343:806d:a3ba] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB3912; 6:7FeZyTLOBuxmvOL9ZPC+MRH2aBFyfzJw36j0o4K0Ml7sEMtogICWOSYWVvm+z7D0ERp40nC9wOrD5f8GHN9i8wtpItIetprlbRGwYOFd2oJHtNblyVu38VsTDLm0Tnp3XxdJ74SdYR8Q/OSXSyqCTxGe2fhSyTMlDKxZca2Aul6AGoD84B/OqxlNXC5nKsNkNOId74b7PpQ4iMpfyM4LTZ31K6UQ3Cnt5T3IkF7Tn8RLbUoHsEKZ1hFH9RA/yOXO9nlxe8uVW+wQXh9vC33HnrSV47gtkp8h/nzs41kHvzUzZyJLO2EMaWvKbFVj8rXF2D1ydkGuUEIqhnDgxSBIgzl0POKiv8YZpbFv3glNROQOynz73/gUfpABsHmMdpBM2KTzdsFce0+KuFdcydu4H/Zgtrt/385jWujyk8D1MpQ6//MSEg8htWPl3MDZQBmYDuSmlsBWFGg9dklX7Fx5Gg==; 5:TvkDBSb31dmTxTHe9qkrYbRV70rcIZrsJ0oTW9SM7F4LG45+Jo8tA69/EVMNtV+9l9pTcwa9tqoFVbYsDNMu/RqdZoJTA964YEYFtJchI7+/2D+gciswMYrDbZqVh2EzLIhfOwtM4lfIzxxwW1Jqrxn9JJX47zS7sA0c3x1AMLs=; 7:L9bPF3xBLbXqgAg6PemzPQzLNvvZmW8KwQsFxwEAFzIfTq0F5pQch/41h5eGDTPS1zqfqqbjWtwL1V8zxOr3NX5O70/mLWL7eqN1VxQwJtlt6LHL8j0Ipsp7HwQk79M5Amb88t+inBu9IeSDPocxGENehIjYwqgKb6FILDpXliN3rk3xK4MgwfNJ6EeOWz/+Mp7tE9eipaG2MK4EJQBEcRR1f3RPi7kH0WWq/uZiMJZPu6rpegxWrgDAyC081HxR x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: eaa40afa-5df7-4c41-4a3a-08d5fe100930 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB3912; x-ms-traffictypediagnostic: BYAPR08MB3912: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(211936372134217)(153496737603132)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(2016111802025)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB3912; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB3912; x-forefront-prvs: 0759F7A50A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(346002)(136003)(39830400003)(189003)(199004)(229853002)(6436002)(33656002)(236005)(9686003)(74316002)(55016002)(6306002)(54896002)(186003)(14454004)(606006)(6506007)(102836004)(46003)(25786009)(2900100001)(76176011)(7696005)(7736002)(6246003)(53546011)(256004)(53936002)(11346002)(446003)(478600001)(81166006)(81156014)(8936002)(8676002)(97736004)(486006)(3480700004)(99286004)(86362001)(2906002)(110136005)(5250100002)(316002)(105586002)(106356001)(68736007)(7116003)(476003)(6116002)(19609705001)(790700001)(5660300001)(74482002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB3912; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: Sn/bEFB3dVbGdOLwxt3jWQFNGBXcEtYRs78yTP3LITBcw50w7locnuqEO0ntx/PpxOSbunH6iGLSkdYlfW5gsqJlUrnJyzMaME0ou1KCM4I3HpPs/e0pFTPkIx0TGofDrYv9ZiFhWM48PCMIgSVEGvLvwdPaD7fAJxn+v1mqwP96Rvb58LeEJj8cll5W3sF04IgsC7DpbUzjWKhcE1Nf0S1OVZ4jPpYhQ4RZ+Cth6LplNPsXaEE1L4bTO4Oso8Ko9vhokpn8RgZPMSMhk3W+ccwWxApPai8K2+izgTa200KSsUv/gWHWxWZnXV58hf+N8igqKle7VDYXGm74JuZoh2Ae3Y9MMejKVPdRddgbUeA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB39440A7F570651111925E7A7DA250BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: eaa40afa-5df7-4c41-4a3a-08d5fe100930 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2018 15:51:56.8790 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB3912 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 15:52:03 -0000 --_000_BYAPR08MB39440A7F570651111925E7A7DA250BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gb3ZlcmZsb3dzLiAgVGhlIElBTkEgc2VjdGlvbiBpcyBtb3JlIGV4aGF1c3RpdmU6DQoNCkFk ZGl0aW9uYWxseSwgZWFjaCBjb2RlIG9mIHRoZSBmb3JtYXQgMHhiICsgKDB4MWYgKiBOKSBmb3Ig dmFsdWVzIG9mIE4gaW4gdGhlIHJhbmdlICgwLi43KSAodGhhdCBpcywgMHhiLCAweDJhLCAweDQ5 LCAweDY4LCAweDg3LCAweGE2LCAweGM1LCBhbmQgMHhlNCksIHRoZSBmb2xsb3dpbmcgdmFsdWVz IHNob3VsZCBiZSByZWdpc3RlcmVkOg0KDQpGcm9tOiBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xl LmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDgsIDIwMTggMjoxMyBQTQ0KVG86IElFVEYg UVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5i ZT4NClN1YmplY3Q6IFJlc2VydmVkIEhUVFAgRnJhbWVzDQoNCkkndmUgYSBxdWVzdGlvbiBhYm91 dCB0aGlzIHRleHQgZnJvbSB0aGUgSFRUUCBtYXBwaW5nIGRvYzoNCg0KNC4yLjE8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcXVpYy1odHRwLTEzI3NlY3Rpb24tNC4yLjE+ LiAgUmVzZXJ2ZWQgRnJhbWUgVHlwZXMNCg0KDQoNCg0KDQogICBGcmFtZSB0eXBlcyBvZiB0aGUg Zm9ybWF0ICIweGIgKyAoMHgxZiAqIE4pIiBhcmUgcmVzZXJ2ZWQgdG8gZXhlcmNpc2UNCg0KICAg dGhlIHJlcXVpcmVtZW50IHRoYXQgdW5rbm93biB0eXBlcyBiZSBpZ25vcmVkLg0KDQpGb3Igd2hh dCB2YWx1ZXMgb2YgIk4iIGFyZSB3ZSB0YWxraW5nIGFib3V0PyBJIGFzc3VtZSBbMCw4KT8gQmVj YXVzZSwgdW5sZXNzIEknbSBkb2luZyB0aGUgbWF0aCB3cm9uZywgaWYgTiBjYW4gYmUgWzAsMjU2 KSAoYW5kIHdlJ3JlIGRvaW5nIHVpbnQ4X3QgbWF0aCkgdGhlbiB0aGF0IGNvdmVycyBhbGwgcG9z c2libGUgdmFsdWVzLg0KDQpDaGVlcnMsDQoNClJ5YW4NCg== --_000_BYAPR08MB39440A7F570651111925E7A7DA250BYAPR08MB3944namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KaDQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzYW1wDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5nbWFpbC1oNA0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC1oNDt9DQpzcGFuLkhlYWRpbmc0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSGVhZGluZyA0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1z dHlsZS1saW5rOiJIZWFkaW5nIDQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IixzYW5z LXNlcmlmOw0KCWNvbG9yOiMyRjU0OTY7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vIG92ZXJmbG93cy4mbmJzcDsgVGhl IElBTkEgc2VjdGlvbiBpcyBtb3JlIGV4aGF1c3RpdmU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkFkZGl0aW9uYWxseSwgZWFjaCBjb2RlIG9mIHRoZSBmb3JtYXQN CjxzYW1wPjB4YiAmIzQzOyAoMHgxZiAqIE4pPC9zYW1wPiBmb3IgdmFsdWVzIG9mIE4gaW4gdGhl IHJhbmdlICgwLi43KSAodGhhdCBpcywgPHNhbXA+DQoweGI8L3NhbXA+LCA8c2FtcD4weDJhPC9z YW1wPiwgPHNhbXA+MHg0OTwvc2FtcD4sIDxzYW1wPjB4Njg8L3NhbXA+LCA8c2FtcD4weDg3PC9z YW1wPiwNCjxzYW1wPjB4YTY8L3NhbXA+LCA8c2FtcD4weGM1PC9zYW1wPiwgYW5kIDxzYW1wPjB4 ZTQ8L3NhbXA+KSwgdGhlIGZvbGxvd2luZyB2YWx1ZXMgc2hvdWxkIGJlIHJlZ2lzdGVyZWQ6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUnlhbiBIYW1pbHRvbiAm bHQ7cmNoQGdvb2dsZS5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3Vz dCA4LCAyMDE4IDI6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0Bp ZXRmLm9yZyZndDs7IE1pa2UgQmlzaG9wICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmVzZXJ2ZWQgSFRUUCBGcmFtZXM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkkndmUgYSBxdWVzdGlvbiBhYm91dCB0aGlzIHRleHQg ZnJvbSB0aGUgSFRUUCBtYXBwaW5nIGRvYzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxoNCBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQi PjxhIG5hbWU9InNlY3Rpb24tNC4yLjEiPjwvYT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLWh0dHAtMTMjc2VjdGlvbi00LjIuMSI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazomcXVvdDtzZWN0aW9uLTRcLjJcLjEmcXVvdDsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj40LjIuMTwvc3Bhbj48L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6JnF1b3Q7c2VjdGlvbi00XC4yXC4xJnF1b3Q7Ij48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPi4mbmJzcDsNCiBSZXNlcnZlZCBGcmFtZSBUeXBlczxv OnA+PC9vOnA+PC9zcGFuPjwvaDQ+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IEZyYW1lIHR5cGVzIG9mIHRoZSBmb3JtYXQgJnF1b3Q7MHhi ICYjNDM7ICgweDFmICogTikmcXVvdDsgYXJlIHJlc2VydmVkIHRvIGV4ZXJjaXNlPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IHRoZSByZXF1aXJlbWVudCB0aGF0IHVua25vd24gdHlwZXMgYmUgaWdub3JlZC4gPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJp ZiI+Rm9yIHdoYXQgdmFsdWVzIG9mICZxdW90O04mcXVvdDsgYXJlIHdlIHRhbGtpbmcgYWJvdXQ/ IEkgYXNzdW1lIFswLDgpPyBCZWNhdXNlLCB1bmxlc3MgSSdtIGRvaW5nIHRoZSBtYXRoIHdyb25n LCBpZiBOIGNhbiBiZSBbMCwyNTYpIChhbmQgd2UncmUgZG9pbmcgdWludDhfdCBtYXRoKSB0aGVu IHRoYXQgY292ZXJzIGFsbCBwb3NzaWJsZQ0KIHZhbHVlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Ry ZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5SeWFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR08MB39440A7F570651111925E7A7DA250BYAPR08MB3944namp_-- From nobody Thu Aug 9 09:30:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA07130DE7 for ; Thu, 9 Aug 2018 09:30:44 -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, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dsbV35rTtN6 for ; Thu, 9 Aug 2018 09:30:40 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43F4127598 for ; Thu, 9 Aug 2018 09:30:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41mYdn6Xrvz15L2J; Thu, 9 Aug 2018 18:30:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU_rbZN_rttv; Thu, 9 Aug 2018 18:30:36 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 9 Aug 2018 18:30:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Proposal to replace ACK block count with ACK length From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B89CD2F@ORSMSX111.amr.corp.intel.com> Date: Thu, 9 Aug 2018 18:30:34 +0200 Cc: Subodh Iyengar , Eric Rescorla , Jana Iyengar , Praveen Balasubramanian , Ian Swett , Marten Seemann , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson , Kazuho Oku Content-Transfer-Encoding: quoted-printable Message-Id: <8E95D332-BF30-4D39-B218-9BE22BDF40C4@tik.ee.ethz.ch> References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri> <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B86D457@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B89CD2F@ORSMSX111.amr.corp.intel.com> To: "Deval, Manasi" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 16:30:45 -0000 So are you proposing that you give a data stream to the hardware and the = hardware add the stream framing? > Am 08.08.2018 um 18:03 schrieb Deval, Manasi : >=20 > Hi Mirja, >=20 > When a packet goes out on the wire the size of largest PDU is = indicated by the MTU. The Ethernet packet commonly has an MTU of 1500 = bytes. Depending on the other headers in place, tunneling enabled or = not, the size of payload inside the innermost L4 header is called MSS = (maximum segment size). In QUIC, the QUIC header, frame header and QUIC = payload live inside the (traditionally defined) segment.=20 >=20 > The task of making the data frame "small" enough to fit into the = payload is an expensive activity. The ability to do segmentation in TCP = provides significant CPU savings - some publicly quoted numbers suggest = that a hardware offload increases efficiency by 8x.=20 >=20 > For a large object (think storage or streaming), the QUIC stack send = may create a stream that it would translates to many QUIC - Stream - = Payload kind of packets on the wire. In such a situation, the = segmentation offload would use the rules of the QUIC stack to do = segmentation.=20 >=20 > Thanks, > Manasi >=20 > -----Original Message----- > From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]=20 > Sent: Wednesday, August 01, 2018 5:38 AM > To: Deval, Manasi > Cc: Subodh Iyengar ; Eric Rescorla ; Jana = Iyengar ; Praveen Balasubramanian = ; Ian Swett ; Marten Seemann = ; Mikkel Fahn=C3=B8e J=C3=B8rgensen = ; IETF QUIC WG ; Martin Thomson = ; Kazuho Oku > Subject: Re: Proposal to replace ACK block count with ACK length >=20 > Hi Manasi, >=20 > this idea sounds really interesting, however, I believe that in most = cases the segmenting would still be needed to be done by the higher = layer because the data frames need to be =E2=80=9Esmall=E2=80=9C enough = to fit in a segment and I believe that in many cases the frame size = would be chosen to exactly fill the segment size, thus there are not = much options to segment differently in the kernel. Or do you have = another scenario in mind? >=20 > Mirja >=20 >=20 >=20 >> Am 15.07.2018 um 21:14 schrieb Deval, Manasi = : >>=20 >> I think if ACKs are sent every 20 to 40 packets, they require the = segmentation code to care about them.=20 >>=20 >> Also from talking to various folks I heard different things. Some = implementations like to piggyback the ack with data while others keep = ACK separate. In my understanding, the piggybacked ask is used for = bandwidth restricted cases where they avoid padding.=20 >>=20 >> This is also an excellent question for the implementers and deployers = on this list. >>=20 >> Thanks, >> Manasi >>=20 >>=20 >> On Jul 15, 2018, at 1:15 PM, Subodh Iyengar wrote: >>=20 >>> Hi Manasi, >>> Doesn't the segmentation make more sense for stream frames than ACK = frames? ACK frames are not sent very often and at least in production = what we've seen is that most of the time ACKs naturally end up getting = sent in their own pure ACK packets.=20 >>>=20 >>> Not arguing for or against the length prefix design, but trying to = understand why having a length prefix in the ACK frame helps = segmentation for stream frames even on the recv side. >>>=20 >>> Subodh >>> From: QUIC on behalf of Deval, Manasi = >>> Sent: Saturday, July 14, 2018 8:35:14 PM >>> To: 'Mikkel Fahn=C3=B8e J=C3=B8rgensen'; Eric Rescorla; Kazuho Oku >>> Cc: Jana Iyengar; Praveen Balasubramanian; Ian Swett; Marten = Seemann; IETF QUIC WG; Martin Thomson >>> Subject: RE: Proposal to replace ACK block count with ACK length >>>=20 >>> Hi All, >>>=20 >>> I would like to revisit this discussion in the context of = distributed processing. The distributed processing doesn=E2=80=99t only = apply to multi-threading but also to layered processing. >>>=20 >>> One example of layered processing is segmentation. The current = Chromium implementation currently creates the segments and passes them = as a bunch into the Linux kernel. There is a GSO patch that would chop = at the segment boundary and encapsulate in UDP headers. We can further = improve performance by plugging in a smarter segmentation algorithm such = that the segment processing can account for type of frame, its size and = make intelligent boundary and padding decisions at a lower layer or in = an offload. To this end, the algorithm needs to identify the size of = each of the frames. Having an ACK length that can be determined in a = single read is much more efficient than having to do a series of reads.=20= >>>=20 >>> Thanks, >>> Manasi >>>=20 >>> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]=20= >>> Sent: Friday, June 22, 2018 9:15 AM >>> To: Eric Rescorla ; Kazuho Oku >>> Cc: Jana Iyengar ; IETF QUIC WG ; = Deval, Manasi ; Marten Seemann = ; Martin Thomson ; = Ian Swett ; Praveen Balasubramanian = >>> Subject: Re: Proposal to replace ACK block count with ACK length >>>=20 >>> Another option is to write out frames as is without length except as = needed for varints. When a packet is nearly done, a run-length encoded = frame index is placed in the packet tail. It could also include the = frame types. A reader can now directly find or skip ACK frames and the = writer does not have to compute lengths before writing. Of course, the = reader needs to be able to locate the index at the tail which can be = tricky with coalesced packets, but not impossible. Isn=E2=80=99t this = largely how zip-files work? >>>=20 >>> Mikkel >>>=20 >>> On 22 June 2018 at 17.00.52, Mikkel Fahn=C3=B8e J=C3=B8rgensen = (mikkelfj@gmail..com) wrote: >>>=20 >>> As I said earlier, I also favour a length prefix. But, Ian does have = a point: >>>=20 >>> Writing data is generally more expensive than reading data. = Especially if you have to traverse long data structures to find the = length before you can start writing and/or you may have to = conservatively reserve extra space for a length field. >>>=20 >>> So before deciding one way or the other, the cost of writing needs = to be well understood, also in scenarios with large MTU=E2=80=99s. >>>=20 >>> In the flatbuffers space that I=E2=80=99m involved with, streaming = has turned to be an issue because data cannot be transmitted in parts = without index data on a separate channel to recombined fragments. A = simple, but non-standard, change in the format would fix this. JSON and = CoAP allows streaming, but many other formats do not, including later = versions of protocol buffers, as I understand. >>>=20 >>> An odd consequence of making both read and write efficient is that = length better work better if stored at the end and packets read = backwards. This requires a single total length prefix but this is stored = in the datagram header. This is probably too odd-ball, but still a = consideration worth noting. >>>=20 >>> The second best alternative may therefore be to allow writes to be = fast and reads to be decent. >>>=20 >>> Yet, I still like length prefixes if they could be made write = efficient because high performance low-latency processes care zero about = ACK and can consume a packet directly while a background process handles = all the latency insensitive ACK and retransmission logic. >>>=20 >>> The question is also, where is the pressure: an IoT aggregator might = be massively read intensive while a web cache would be very write = intensive. >>>=20 >>>=20 >>> Kind Regards, >>> Mikkel Fahn=C3=B8e J=C3=B8rgensen >>>=20 >>>=20 >>> On 22 June 2018 at 15.12.09, Eric Rescorla (ekr@rtfm.com) wrote: >>>=20 >>> It seems like there are two questions at hand here: >>>=20 >>> 1. Would it be architecturally better to have frames have a = consistent self-contained >>> representation? >>> 2. Is it enough better that we should do so now. >>>=20 >>> I agree with Kazuho that (a) we don't have that representation now = and (b) it would >>> be a better design to do so. I'm perhaps somewhat more positive on = (2) than he >>> is. I don't think it's critically important that we make the change, = but if we were >>> to hold a consensus call, I think I would be in favor. I'd certainly = be interested >>> in looking at a proposal if someone else were to make one. >>>=20 >>> -Ekr >>>=20 >>>=20 >>>=20 >>> On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku = wrote: >>> 2018-06-22 8:08 GMT+09:00 Deval, Manasi : >>>> I feel that the requirement to have every value valid is somewhat = academic. >>>=20 >>> I think that Marten is correct in pointing out that making the ACK >>> frame self-containing (by having a field that represents the number = of >>> octets being consumed by the frame) would be an exception from the >>> design pattern we have. >>>=20 >>> Look at STREAM frame. The field is not self-contained. Instead, it = has >>> a Length field for the Stream Data, which is a leaf. The same goes = for >>> NEW_CONNECTION_ID frame (that has the length field for Connection ID >>> field (which is also a leaf)), CONNECTION_CLOSE (length field for >>> Reason Phase). >>>=20 >>> I agree with Marten, Mikkel (and possibly others as well) that = having >>> consistency is important. >>>=20 >>> Therefore, I agree with Mikkel that we should consider making every >>> frame self-contained or keeping every frame as-is (i.e. not >>> self-contained). >>>=20 >>> FWIW, as described in the latter half of >>> https://www.ietf.org/mail-archive/web/quic/current/msg04287.html, it >>> is possible to make every frame self-contained *and* also make ACK >>> frames smaller than the current draft. Making every frame >>> self-contained gives us the possibility to send new extension frames >>> without negotiation. >>>=20 >>> I do not think that I would push for making every frame = self-contained >>> by myself (because I do not think it meets the high bar to have a >>> change at such a late moment of standardization), but as stated, my >>> preference goes to seeing every frame made self-contained or none of >>> them made as such. >>>=20 >>>> The length value provides much more value than the block count and = the fact >>>> that certain values can never be achieved is an inherent property = of the >>>> length. >>>>=20 >>>>=20 >>>>=20 >>>> One interesting observation is that this property is not limited to = length. >>>> One can even make a similar argument about ACK block count. The = maximum >>>> number of ACK blocks that can be defined will not always have a = meaningful >>>> value. In out examples, 0,1,2,3 are all valid. If I set the value = of ACK >>>> block count to have lower two bits to be 11, the maximum value is = of ACK >>>> blocks is =E2=80=93 4611686018427387903. This is the same value of = largest >>>> acknowledged so if the ACK block count was set to this value, it = would still >>>> be meaningless. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Manasi >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> From: Marten Seemann [mailto:martenseemann@gmail.com] >>>> Sent: Tuesday, June 19, 2018 6:44 PM >>>> To: Deval, Manasi >>>> Cc: Ian Swett ; Kazuho Oku = ; Eric >>>> Rescorla ; Jana Iyengar ; Praveen >>>> Balasubramanian ; IETF QUIC WG = ; Martin >>>> Thomson >>>>=20 >>>>=20 >>>> Subject: Re: Proposal to replace ACK block count with ACK length >>>>=20 >>>>=20 >>>>=20 >>>> Hi Manasi, >>>>=20 >>>>=20 >>>>=20 >>>>> The risk of disagreement between ack blocks and ack block count is = same as >>>>> the risk of disagreement between ack blocks and ack length. Either = way this >>>>> needs to be counted up while creating the ACK and counted down = while parsing >>>>> it. The possibility of error is the same. Getting the ack block = count wrong >>>>> is as problematic as getting the ack length wrong. Do you agree? >>>>=20 >>>>=20 >>>>=20 >>>> I disagree. Let's take an example of an ACK frame with one ACK = range, that >>>> needs a 2 byte varint to represent the First ACK Block and another = 2 byte >>>> varint to represent the Gap. >>>>=20 >>>> With your proposal: >>>>=20 >>>> The values 0 and 1 are invalid, since the length fields itself is = included >>>> in the length. >>>> The values 2, 3, ..., (2 + len(LargestAcknowledged) + = len(AckDelay)) - 1 are >>>> invalid, since the length needs to include the Largest Acknowledged = and the >>>> Ack Delay. >>>> The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the = first >>>> valid value, and correspond to an ACK frame with no blocks. >>>> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is = invalid, since >>>> it would cut the varint for the First ACK Block >>>> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is = invalid, since >>>> it would cut the frame after the First ACK Block (but every block = must be >>>> followed by a gap length) >>>> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is = invalid, since >>>> it would cut the varint for the Gap >>>> Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 = is valid >>>>=20 >>>> There are *a lot* of invalid values that you can encode into the = ACK length >>>> field. More importantly, *none* of these error cases exists with = the current >>>> frame format. >>>>=20 >>>> The *only* error case that can occur with our current format is = that the >>>> packet is too short for the number of ACK blocks that are supposed = to >>>> contained in the frame. This can occur with your proposal as well = (in >>>> addition to the error cases listed above). >>>>=20 >>>>=20 >>>>=20 >>>> My concern is not that it's impossible or even particularly hard to = catch >>>> these errors, but I dislike the property that some (in fact, most) = encodable >>>> values are invalid. >>>>=20 >>>>=20 >>>>=20 >>>> Best, >>>>=20 >>>> Marten >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi = >>>> wrote: >>>>=20 >>>> Hi Ian, >>>>=20 >>>>=20 >>>>=20 >>>> Here is another attempt to solve the objections you raised: >>>>=20 >>>>=20 >>>>=20 >>>>> I'm not a fan of this proposal, because I think it is impractical = to drop >>>>> the number of ack blocks, because with the ECN proposal it becomes >>>>> impractically complex to parse. >>>>=20 >>>> Is there a reason the proposal from Christian does not solve this = problem? >>>>=20 >>>>=20 >>>>=20 >>>>> If we don't remove the number of ack blocks, then the ack frame is = larger, >>>>> but I don't think the extra size field is useful for most = implementations. >>>>> Also, it means the length can disagree with the actual length, = which add >>>>> complexity and the possibility of writing error-prone code. The = idea of >>>>> someone offloading ack processing and then proceeding to trust the = length >>>>> seems like someone could get wrong and cause some concerning = issues. >>>>=20 >>>> The risk of disagreement between ack blocks and ack block count is = same as >>>> the risk of disagreement between ack blocks and ack length. Either = way this >>>> needs to be counted up while creating the ACK and counted down = while parsing >>>> it. The possibility of error is the same. Getting the ack block = count wrong >>>> is as problematic as getting the ack length wrong. Do you agree? >>>>=20 >>>>=20 >>>>=20 >>>>> My experience is multithreaded packet processing is more cost and = work than >>>>> it's worth. Sure you can't fill a 100G NIC with one connection, = but that >>>>> seems like an academic problem, not one for workloads I've seen. = Typically >>>>> the extra cost of multithreading outweighs its value. >>>>=20 >>>> The value is two fold =E2=80=93 pre-processing and multi-threading. = If we >>>> pre-process the received packets such that ACKs and streams can be >>>> coalesced, the receive side can indicate a large chunk of = information though >>>> the kernel, reducing the cost of system call and protocol overhead. = This is >>>> the same concept as UDP segmentation taken a step further on = receive side. >>>> After this chunk is indicated into the QUIC protocol, the protocol = may >>>> process stream and ACK in parallel. While folks may or may not = utilize this, >>>> there is an advantage here. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Manasi >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> From: Ian Swett [mailto:ianswett@google.com] >>>> Sent: Tuesday, June 19, 2018 11:26 AM >>>> To: Deval, Manasi >>>> Cc: Marten Seemann ; Kazuho Oku >>>> ; Eric Rescorla ; Jana Iyengar >>>> ; Praveen Balasubramanian = ; IETF >>>> QUIC WG ; Martin Thomson >>>>=20 >>>>=20 >>>> Subject: Re: Proposal to replace ACK block count with ACK length >>>>=20 >>>>=20 >>>>=20 >>>> I'm still not interested in this change, for the reasons I stated = above. >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi = >>>> wrote: >>>>=20 >>>> Hi All, >>>>=20 >>>>=20 >>>>=20 >>>> Do we have agreement here to create a new PR? >>>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Manasi >>>>=20 >>>>=20 >>>>=20 >>>> From: Deval, Manasi >>>> Sent: Sunday, June 17, 2018 2:25 PM >>>> To: Marten Seemann ; Kazuho Oku >>>> >>>> Cc: Ian Swett ; Eric = Rescorla >>>> ; Jana Iyengar ; Praveen = Balasubramanian >>>> ; IETF QUIC WG ; Martin Thomson >>>> >>>> Subject: RE: Proposal to replace ACK block count with ACK length >>>>=20 >>>>=20 >>>>=20 >>>> Hi All, >>>>=20 >>>>=20 >>>>=20 >>>> I have made a list of objections to the proposal and the solutions = to those >>>> objections discussed on this thread. >>>>=20 >>>>=20 >>>>=20 >>>> a. Co-existence of length field with ECN field and ACK blocks. >>>>=20 >>>>=20 >>>>=20 >>>> Christian suggested to move the ECN fields to precede the ACK = blocks. This >>>> is an elegant solution. Parsing entire list of ACK blocks to review = ECN bits >>>> would have been annoying, even though it can work. >>>>=20 >>>>=20 >>>>=20 >>>> b. There are two cases to be parsed =E2=80=93 entire ACK and = parse ACK to >>>> identify length. There are some reservations when ACK parsing gets = harder >>>> for the case where the entire header needs to be parsed. >>>>=20 >>>>=20 >>>>=20 >>>> Agreement from several folks here. In the original ACK defined in = draft 12 >>>> of the slide, one would count down number of ACK blocks to get to = the end of >>>> the packet. In the proposal I made, one would count down the length = to >>>> identify the end of the packet. The logic is very similar in cycle = count and >>>> complexity. Several folks also commented to this effect. >>>>=20 >>>>=20 >>>>=20 >>>> c. Multi-threaded packet processing >>>>=20 >>>>=20 >>>>=20 >>>> I would expect that there are 10s of 1000s of connections in use at = any time >>>> for a server with a high speed link. Multi-threading to handle each = of these >>>> flows / connections in parallel is necessity to be able to support = large >>>> number of connections on a high speed link. Tx segmentation, Rx = coalescing >>>> are well known strategies to reduce the processing cost. In initial = stages, >>>> code is often written as a single-threaded and then re-factored to >>>> parallelize cycle intensive operations. In order to allow this = protocol to >>>> scale in future, I would suggest we do not preclude this case. >>>>=20 >>>>=20 >>>>=20 >>>> d. Increase in ACK size by 1 byte. >>>>=20 >>>>=20 >>>>=20 >>>> I do not see this as a serious issue but if folks but we can = consider making >>>> this a varint, if others have strong feelings about it. It=E2=80=99s = a trade-off : 2 >>>> reads to save 1 byte. >>>>=20 >>>>=20 >>>>=20 >>>> e. Every encodable value should be valid >>>>=20 >>>> Not every length will be valid. This is inherent to lengths. This = same issue >>>> ails the =E2=80=98payload length=E2=80=99 in QUIC header. Not only = does the issue exist for >>>> small values, it also applies to large values since data stream = will be sent >>>> after crypto negotiation. E.g. - how does one craft a payload = with 62 bit >>>> payload length in a large header? >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Manasi >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> From: Marten Seemann [mailto:martenseemann@gmail.com] >>>> Sent: Sunday, June 17, 2018 6:59 AM >>>> To: Kazuho Oku >>>> Cc: Ian Swett ; Eric = Rescorla >>>> ; Jana Iyengar ; Praveen = Balasubramanian >>>> ; IETF QUIC WG ; Martin Thomson >>>> ; Deval, Manasi >>>> Subject: Re: Proposal to replace ACK block count with ACK length >>>>=20 >>>>=20 >>>>=20 >>>> Maybe it's specific to Go, but I'm using a single io.Reader for the = whole >>>> packet, so as long as the packet payload is long enough, the varint = parsing >>>> will not fail. >>>>=20 >>>> I don't think that specifics of programming languages matter here = though, >>>> and I'm sure both frame formats can be reasonably implemented in C = as well >>>> as in Go. The reasons I'm opposed to Manasi's proposal are that it = moves us >>>> away from the principle that only reasonable values should be = encodable, and >>>> that it increases the size of the ACK frame, for the questionable = benefit of >>>> being able to parallelise the frame parser. >>>>=20 >>>>=20 >>>>=20 >>>> On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku = wrote: >>>>=20 >>>> 2018-06-17 22:36 GMT+09:00 Marten Seemann = : >>>>> At least for my implementation, parsing doesn't become easier, it = becomes >>>>> more complex with this proposal. My varint-parser always consumes = as many >>>>> bytes as the varint requires, so after parsing a varint, I'd have = to >>>>> introduce an additional check that this didn't overflow the ACK = length >>>>> (e.g. >>>>> consider that I parsed the ACK frame so far that only 2 bytes are >>>>> remaining >>>>> according to ACK length field, but the next varint is 4 bytes = long). >>>>=20 >>>> Isn't your varint parser checking that it has not (or will not) run >>>> across the end of the packet payload for every ACK block it parses? >>>> I'd assume that you would be doing that, because I think that is >>>> necessary to avoid buffer overrun. >>>>=20 >>>> What I am saying that that check could be converted to a overrun = check >>>> against the end of the "frame payload", and that checking the >>>> remaining block count becomes unnecessary, in case we replace ACK >>>> Block Count with ACK Frame Length. >>>>=20 >>>>>=20 >>>>> In general, we've been moving the wire image towards making every >>>>> encodable >>>>> value valid. This proposal moves us away from that principle: >>>>> * some small values are always invalid (the length can never be = between 0 >>>>> and 3) >>>>> * a lot of intermediate values are invalid (if the boundary falls = inside a >>>>> varint, as described above) >>>>> Both these cases can't occur with the current ACK frame format.. >>>>>=20 >>>>> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku = wrote: >>>>>>=20 >>>>>> 2018-06-17 8:34 GMT+09:00 Ian Swett >>>>>> : >>>>>>> I'm not a fan of this proposal, because I think it is = impractical to >>>>>>> drop >>>>>>> the number of ack blocks, because with the ECN proposal it = becomes >>>>>>> impractically complex to parse. >>>>>>=20 >>>>>> For the ECN proposal, as Christian has suggested, we can move the = ECN >>>>>> counters before the ACK blocks. Then, it would not be complex to >>>>>> parse. >>>>>>=20 >>>>>> And my view is that parsing becomes easier if we replace ACK = Block >>>>>> Count with ACK Frame Length. >>>>>>=20 >>>>>> Now, with ACK Block Count, we need to check the remaining number = of >>>>>> blocks and the remaining space in the packet payload for every = block >>>>>> that we parse. Failing to check either leads to a bug or a = security >>>>>> issue. >>>>>>=20 >>>>>> If we switch to ACK Frame Length, we need to only check the = remaining >>>>>> space in the frame. >>>>>>=20 >>>>>> I think that this is the biggest benefit of replacing ACK Block = Count >>>>>> with ACK Frame Length. OTOH the downside is that you need extra = one to >>>>>> two bits (one if the size of block / gap is expected to be below = 65, >>>>>> two if they are expected to be above that) for encoding ACK Frame >>>>>> Length compared to ACK Block Count. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Having said that, I honestly wonder if all the frames could have = it's >>>>>> length being encoded (either explicitly or either as a signal = that >>>>>> says "to the end of the packet"). Consider something like below: >>>>>>=20 >>>>>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) = | >>>>>> or >>>>>> |1| frame-type (7) | frame-payload (*) | >>>>>>=20 >>>>>> When MSB of the first octet set to zero, the length of the frame >>>>>> payload is designated by the varint that immediately follows the = frame >>>>>> type. >>>>>> When MSB of the first octet set to one, the length of the frame >>>>>> payload spans to the end of the packet. >>>>>>=20 >>>>>> In this encoding, we can always omit the Length field of a STREAM >>>>>> frame. So the overhead for carrying stream data will be = indifferent in >>>>>> practice. >>>>>>=20 >>>>>> For the ACK frame, we can omit the ACK Block Count field. And the >>>>>> overhead will be one to two bits if the ACK frame is sent in the >>>>>> middle of the packet (thereby using the encoding with explicit = frame >>>>>> payload length), or one octet or more shorter if ACK is the last = frame >>>>>> of the packet. >>>>>>=20 >>>>>> We are likely to see increase of overhead for most of the other = types >>>>>> of frames, but I do not think that would be an issue considering = that >>>>>> they will be far seldom seen compared to STREAMs and ACKs. >>>>>>=20 >>>>>> To summarize, my anticipation is that we can make all the frames >>>>>> self-contained (i.e. the length can be determined without the >>>>>> knowledge of how each frame is encoded) without any overhead, if = we >>>>>> agree on making the frame type space 1 bit smaller. >>>>>>=20 >>>>>> Finally, the biggest benefit of using a self-contained encoding = of >>>>>> frames is that we would have the ability to introduce new = optional >>>>>> frames without negotiation. By making the frames self-contained, = QUIC >>>>>> endpoints will have the freedom of ignoring the frames that they = do >>>>>> not understand. >>>>>>=20 >>>>>> Being able to send QUIC frames defined in extensions without >>>>>> negotiating using Transport Parameters will be a win in both = terms of >>>>>> security (because clients' TP is sent in clear) and flexibility >>>>>> (because we will be possible to send the extensions before we = figure >>>>>> out whether the peer supports that extension). >>>>>>=20 >>>>>>> If we don't remove the number of ack blocks, then the ack frame = is >>>>>>> larger, >>>>>>> but I don't think the extra size field is useful for most >>>>>>> implementations. >>>>>>> Also, it means the length can disagree with the actual length, = which >>>>>>> add >>>>>>> complexity and the possibility of writing error-prone code. The = idea >>>>>>> of >>>>>>> someone offloading ack processing and then proceeding to trust = the >>>>>>> length >>>>>>> seems like someone could get wrong and cause some concerning = issues. >>>>>>>=20 >>>>>>> My experience is multithreaded packet processing is more cost = and work >>>>>>> than >>>>>>> it's worth. Sure you can't fill a 100G NIC with one connection, = but >>>>>>> that >>>>>>> seems like an academic problem, not one for workloads I've seen. >>>>>>> Typically >>>>>>> the extra cost of multithreading outweighs its value. >>>>>>>=20 >>>>>>> To be clear, I don't think this is an awful idea, but I also = don't see >>>>>>> the >>>>>>> value and it adds complexity. I read Manasi's email, but I = don't think >>>>>>> I >>>>>>> understand why any of those matter in practice. >>>>>>>=20 >>>>>>> On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla = wrote: >>>>>>>>=20 >>>>>>>> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann >>>>>>>> >>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> This proposal increases the size of the ACK frame by 1 byte in = the >>>>>>>>> common >>>>>>>>> case (less than 63 ACK ranges), since the ACK length field = here >>>>>>>>> always >>>>>>>>> consumes 2 bytes, whereas the ACK Block Count is a = variable-length >>>>>>>>> integer. >>>>>>>>> Considering how much work we put into minimising the size of = the >>>>>>>>> frames, >>>>>>>>> this feels like a step in the wrong direction.. >>>>>>>>>=20 >>>>>>>>> Regarding the processing cost, I agree with Dmitri. Handling = an ACK >>>>>>>>> frame >>>>>>>>> requires looping over and making changes to a data structure = that >>>>>>>>> keeps >>>>>>>>> track of sent packets. This is much more expensive than simply >>>>>>>>> parsing >>>>>>>>> a >>>>>>>>> bunch of varints in the ACK frame. It seems unlikely that a >>>>>>>>> multi-threaded >>>>>>>>> packet parser would offer any real-world performance benefits. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I don't want to overstate the benefit here, but my point isn't = that >>>>>>>> parsing is expensive but that if you want to have a = multithreaded >>>>>>>> packet >>>>>>>> processing system, then it's nice to have a simpler data = structure >>>>>>>> (the >>>>>>>> unparsed ACK block) to hand to the ACK processing thread. >>>>>>>>=20 >>>>>>>> -Ekr >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> When we discussed this before, some people observed that this >>>>>>>>>> creates >>>>>>>>>> a need to encode in two passes. That's the trade-off here. = (Not >>>>>>>>>> expressing an opinion.) >>>>>>>>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar = >>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I don't have a strong opinion on this. I'm certainly not = opposed >>>>>>>>>>> to >>>>>>>>>>> it. >>>>>>>>>>> Does anyone have a strong opposition? >>>>>>>>>>>=20 >>>>>>>>>>> On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian >>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I agree as well since this can help reduce per packet = processing >>>>>>>>>>>> overhead. ACKs are going to be the second most common frame = type >>>>>>>>>>>> so no >>>>>>>>>>>> objections to special casing. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric >>>>>>>>>>>> Rescorla >>>>>>>>>>>> Sent: Friday, June 15, 2018 9:11 AM >>>>>>>>>>>> To: Deval, Manasi >>>>>>>>>>>> Cc: Jana Iyengar ; QUIC WG = >>>>>>>>>>>> Subject: Re: Proposal to replace ACK block count with ACK = length >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> I agree with Manasi here. This change would allow ack frame >>>>>>>>>>>> parsing >>>>>>>>>>>> to be more self-contained, which is an advantage for the = parser >>>>>>>>>>>> and also >>>>>>>>>>>> potentially for parallelism (because you can quickly find = the >>>>>>>>>>>> frame and then >>>>>>>>>>>> process it in parallel). >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -Ekr >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> In general, varints require some specific logic for = parsing. To >>>>>>>>>>>> skip >>>>>>>>>>>> over any header, I have to read every single varint. As the = code >>>>>>>>>>>> sees Stream >>>>>>>>>>>> and ACK headers most frequently, that is my focus. The = Stream >>>>>>>>>>>> frame has a >>>>>>>>>>>> length in its third field. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> ACK parsing, however, needs 6 + 2*num_blocks reads to = identify >>>>>>>>>>>> length. There are two reads each for =E2=80=98largest = acknowledged=E2=80=99, =E2=80=98ACK >>>>>>>>>>>> delay=E2=80=99 and >>>>>>>>>>>> =E2=80=98ACK block count=E2=80=99. The pain point is the = total number of cycles >>>>>>>>>>>> parse an >>>>>>>>>>>> ACK. If I am processing 10M pps, where 10% - 30% of the = packets >>>>>>>>>>>> have a >>>>>>>>>>>> piggybacked ACK, these cycles becomes a significant = bottleneck. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>>=20 >>>>>>>>>>>> Manasi >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana >>>>>>>>>>>> Iyengar >>>>>>>>>>>> Sent: Monday, June 11, 2018 3:11 PM >>>>>>>>>>>> To: Deval, Manasi ; QUIC WG >>>>>>>>>>>> >>>>>>>>>>>> Subject: Re: Proposal to replace ACK block count with ACK = length >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> You're right that we no longer have the ability to skip an = ACK >>>>>>>>>>>> frame, >>>>>>>>>>>> and this crept in when we moved to varints. >>>>>>>>>>>>=20 >>>>>>>>>>>> I believe your problem though is generally true of most = frames >>>>>>>>>>>> not >>>>>>>>>>>> just ACKs, since ids, packet numbers, and numbers in all = frames >>>>>>>>>>>> are now all >>>>>>>>>>>> varints. To skip any frame, you'll need to parse the varint >>>>>>>>>>>> fields >>>>>>>>>>>> in those >>>>>>>>>>>> frames. If you have logic to process and skip varints, then >>>>>>>>>>>> skipping the ack >>>>>>>>>>>> block section is merely repeating this operation = (2*num_block+1) >>>>>>>>>>>> times. Do >>>>>>>>>>>> you see specific value in skipping ACK frames over the = other >>>>>>>>>>>> control frames? >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi = wrote: >>>>>>>>>>>>> - Moving the ACK length to the front of the ACK = allows >>>>>>>>>>>>> the >>>>>>>>>>>>> flexibility of either reading the entire ACK or >>>>>>>>>>>>> reading >>>>>>>>>>>>> the >>>>>>>>>>>>> first 16 bits and skipping over the length. This = is a >>>>>>>>>>>>> useful >>>>>>>>>>>>> feature for the case where ACK processing is split >>>>>>>>>>>>> into >>>>>>>>>>>>> multiple layers. Depending on the processor this = is >>>>>>>>>>>>> run >>>>>>>>>>>>> on, >>>>>>>>>>>>> there are different advantages - >>>>>>>>>>>>=20 >>>>>>>>>>>> Just a note. In my experience, the cost of parsing an ACK = frame >>>>>>>>>>>> is >>>>>>>>>>>> negligible compared to the cost of processing an ACK frame: = that >>>>>>>>>>>> is, >>>>>>>>>>>> poking at various memory locations to discard newly ACKed >>>>>>>>>>>> packets. >>>>>>>>>>>>=20 >>>>>>>>>>>> - Dmitri. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Kazuho Oku >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Kazuho Oku >>>=20 >>>=20 >>>=20 >>> -- >>> Kazuho Oku >=20 From nobody Thu Aug 9 13:15:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CEC130E77 for ; Thu, 9 Aug 2018 13:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 b7e_7q_kU-64 for ; Thu, 9 Aug 2018 13:15:05 -0700 (PDT) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BBC130E41 for ; Thu, 9 Aug 2018 13:15:05 -0700 (PDT) Received: by mail-yw1-xc31.google.com with SMTP id w76-v6so6373354ywg.4 for ; Thu, 09 Aug 2018 13:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lMzjSlFwv96cSIpc/4UzoAsnSe/FMoESvixw39g/dCg=; b=XCGWLPIUKWy9VCazLV9+TjPWipsF7/C6D0Jj+oyFQtepG9gJgpg/M2wUP0vO36Ey81 YoK/68iQBFjOBcEECKtFYFGrkrexqK1Nb3/ZGGUlgOBA6ZZTSSQRyI+uCz4jHa0RMm8P nHD8QoxU/eaNjsAlKBXI5LYztKYSWxGVPTcPMQ84HlotemStZ4DyJqg+eL2yXkIp12nc cNK1gb7vpdPvJvt7wIPLELyY+D0qjOIkDHnN2YFyA4eO+5ixmMwskuhAuWNgB+liOGUg l28WQT80CzPuCNeZeQ+OHQqoS0+LVZEz89wm363Z+9CZ3FnLKT1/NxE1ZIpBB1/e7MxJ 3v3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lMzjSlFwv96cSIpc/4UzoAsnSe/FMoESvixw39g/dCg=; b=PZw0Z+k3psRg3dfAetiA75XUsDLXDkdhZvuX2duHNn+GpEqpdlcXce/NB+CKXwQuzN DTEJpMpqvH8WFA5DK8GoRsL44GN2aA3YxlZMgFZyd3sIuoNvxVTcJ0kC+I212Ek6FCe2 CZwDBDos65AKn9PGMJ7f1DVEbEXgKJhAQSEdx/Rvaqtezur1SkCh2xI8l5upofnqZGD3 OpOjCt2vmKSS8AdvxFCSW3B7E3xbBft9eutYVQtIpwJrBiWWJIMZyc0b1cpsg8XH33Y0 iLjV8tSh0ucZmhpGH5gLIFJSWezWz1CKfvvFUW8jJ6sV5A3Tsya2pp96TJ9umbnqbdnK oyug== X-Gm-Message-State: AOUpUlHiWxEnOxtHch42OvZbCZaZpoJ5g0Y/wysRhr6kFRWEdKNXr07I XnTPOGRmyo0ni8jpXjiMocXo2ul7eVke5u22pvpCXA== X-Google-Smtp-Source: AA+uWPyg9tE4S7MRH85a5+EtHFsFxhkicDkFsjLR1C6IE0DeoGT8HlhiKJ+5/kyLBaWUt2fL1BahFRvDZ3s7w9SbB8Q= X-Received: by 2002:a81:2c0a:: with SMTP id s10-v6mr2072880yws.335.1533845703870; Thu, 09 Aug 2018 13:15:03 -0700 (PDT) MIME-Version: 1.0 References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> In-Reply-To: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> From: Ian Swett Date: Thu, 9 Aug 2018 16:14:31 -0400 Message-ID: Subject: Re: Unified ACK frame encoding To: Brian Trammell Cc: Jana Iyengar , Magnus Westerlund , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000527547057306486c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:15:09 -0000 --000000000000527547057306486c Content-Type: text/plain; charset="UTF-8" There are a few things I like about this proposal: 1) It makes ECN and ACK_ECN either the same(or more similar) 2) As Kazuho said, it provides more precise feedback about which packets were marked, which avoids some edge cases we've had to write up in the current text around ack loss and being unsure of exactly when recovery is exited. 3) It doesn't get more expensive as the connection goes on. This is an unfortunate property of the current design. I find Jana's variation on this particularly interesting, because if ECN isn't negotiated, I don't think there a reason to add any overhead. From personal experience, if you find a form of feedback valuable(whether it's ECN or timestamps for one-way-delay), then you're happy to consume a few extra bytes to get better feedback. If the extra information isn't useful for whatever reason, it's just wasted bytes. So overall this seems like an improvement we should do, but I'd prefer a variant that doesn't increase the ACK frame size when ECN is disabled or there are no ECN marks to report. FYI, if we need to steal a bit from the number of ack blocks, I'm ok with that since I expect more than 32 ack blocks to be very rare. On Thu, Aug 9, 2018 at 3:52 AM Brian Trammell (IETF) wrote: > hi Jana, all, > > Also fried, but I've had a quick look at this... > > > On 9 Aug 2018, at 08:36, Jana Iyengar wrote: > > > > Thanks for picking this one up, Martin. As I've said to you and to > Kazuho, I think if we can unify ACK and ACK_ECN frames "reasonably", I > think there's a lot of value in having a single frame format. The question > of course is if we can make this reasonable, so thanks for trying. > > > > I need to think some more when I'm not as fried as I am right now, but > I'm not convinced about the encoding yet. > > +1 to this -- if we find not-quite-varints in packet numbers > uncomfortable, I can't see us finding rolling five-in-four encoding in the > low bits of a different not-quite-varint less so. > > > A couple of more simplifying assumptions might help: > > 1. A receiver receives 3 types of packets: Non-ECT, ECT, CE. It only > reports packets it has received. > > 2. We can assume that a sender uses ECT(0) or ECT(1), not both. Let's > call this default-ECT. If a future mechanism wants to use both, they can > define a new ACK frame. (Magnus and I checked on this with David Black, and > he agrees on the use of a single default ECT value..) > > This also seems reasonable to me, and AFAICT lines up with all the current > proposals for using ECT0/1 signaling. > > > This means that you only need to report 3 types of ranges. > > > > Further, if you have a separate bit to communicate ECN/non-ECN, meaning > that the receiver has seen ECT/CE bits and will echo them back, or the > receiver has not seen ECT/CE bits and won't echo them back, then you have 1 > or 2 types of ranges. > > ECN bit = 0: every range is of packets received, there's no ECN echo. > This is exactly the same ACK format as what we have now. > > ECN bit = 1: ranges are of 2 types, default-ECT or CE. We need exactly 1 > bit here to distinguish between these two ranges. > > > > I'm aware that if we move this ECN bit to the frame type, then we end up > with two ACK frames again, but this is still far more unified than what we > have now. > > +1. I'm really not bothered by pushing some of the ACK signaling bits into > the frame type (especially if we describe these frames in a unified way, as > we do with STREAM frames), as long as the structure of the frames is > identical. > > Cheers, > > Brian > > > I'm also aware that we need a way for a receiver to say that it received > non-default ECT, but that can be separate, or an error even, and a receiver > could stop reporting ECN assuming that a network box is messing with the > bits. > > > > On Wed, Aug 8, 2018 at 8:54 PM Martin Thomson > wrote: > > (More long emails. Sorry, I'm trying to either close these issues or > > prepare us for the interim.) > > > > We decided to take ACK_ECN to address an immediate need, but > > recognized that the encoding was suboptimal. In the issue (see > > https://github.com/quicwg/base-drafts/issues/1439) we've > > beendiscussing an option for frame encoding that fixes a bunch of > > issues. That discussion covered a lot of ground, but here is my > > summary. > > > > This is what we have currently (using C/TLS style notation because I > > don't think ASCII art works in email): > > > > struct ACK { > > varint largest_acknowledged; > > varint delay; > > varint additional_block_count; > > varint first_block; > > struct { > > varint gap; > > varint block; > > } blocks[additional_block_count]; > > }; > > > > struct ACK_ECN { > > ACK ack; > > varint ect0_count; > > varint ect1_count; > > varint ecnce_count; > > }; > > > > The most obvious issues are: > > > > A. There are two inconsistent encodings for acknowledgments depending > > on whether ECN is enabled. > > B. ACK_ECN has more overhead than ACK. Ideally there are fewer > > disincentives to use ACK_ECN. > > C. The counting scheme is imprecise (you don't always know which > > packet was CE marked, and that could matter), which makes counting of > > ECN markings fragile in the presence of ACK loss. This can lead to > > ECN being disabled despite it being fully functional. > > D. ECN counters always increase, and so they take more space to encode > > over time. > > > > Kazuho suggested a scheme that adds some modest complexity, but I > > think that it works and reduces other complexities such that it's > > probably a net win on the complexity front. It also fixes these > > issues at the same time. > > > > The observation is that there are 5 things that you might want to say > > about any given packet number: > > > > 0. say nothing (i.e., I'm not acknowledging this packet; this is a gap) > > 1. packet received, no marking > > 2. packet received with an ECT(0) marking > > 3. packet received with an ECT(1) marking > > 4. packet received with an ECN-CE marking > > > > Now, the current system of describing ranges of packets is still > > pretty good. An expression of the form "the next N packets are of > > type X" gets us an encoding that is small and fits traffic patterns > > well. No point changing what is a fundamentally good encoding. > > > > So, we retain the maximum packet number and the idea of expressing > > ranges of packets. But each range is a tuple that expresses both the > > type of acknowledgement (or lack thereof) for that range and how many > > packets are in the range. > > > > That would produce an ACK frame in the following basic shape: > > > > struct ACK { > > varint largest_acknowledged; > > varint delay; > > varint range_count; > > struct { > > enum {gap,unmarked,ect0,ect1,ecnce} type; > > varint count; > > } ranges[range_count]; > > }; > > > > The problem now is that we lost efficiency in a big way because the > > enum takes up a ton of space, for just 5 values. > > > > If we observe that there are 5 types, but you don't need to repeat the > > same type, then we can express the type in two bits. That is, the > > type is interpreted as: > > > > type = last_type + 1 + encoded_type (mod 5) > > > > Kazuho suggested that we pack these bits into the low two bits of a > > varint. It's a little ugly, but I can't see a better option. For > > instance, defining a new varint type would be considerably worse. In > > addition to not being able to reuse varint code, my testing on > > encodings showed that a defining a new type with flags before the > > 2-bit length is surprisingly expensive. > > > > This produces a format like this: > > > > struct ACK { > > varint largest_acknowledged; > > varint delay; > > varint range_count; > > varint ranges[range_count]; > > }; > > > > As you can see, this is a considerable simplification. The only trick > > is that more data is packed into each range value. These values are > > encoded using something like: > > > > encoded_type = (type + 4 - last_type) % 5 > > // encoded_type = type - last_type - 1 (mod 5) > > range = encoded_type | (count << 2) > > > > The cost is that ranges take one more byte once they get above 16 > > packets rather than at 64 packets as before. It's also possible with > > this to encode a non-acknowledgment at the end of an ACK frame, which > > I think we can either prohibit or ignore. But it fixes all the above > > problems. > > > > Is this a change worth making? > > > > Cheers, > > Martin > > > > > > A side note: This works whether we encode a count (as here) or a total > > number of octets (as has been proposed). Similarly, we could count > > from the bottom rather than the top if we wanted to. Those decisions > > are orthogonal to this; I'm trying as much as possible to retain the > > current design. > > > > Another note: We already have an issue on file for an ACK frame > > example. That is still planned and that should help with interpreting > > the text. > > > > --000000000000527547057306486c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are a few things I like about this proposal:
1) It makes ECN and ACK_ECN either the same(or more similar)
<= div>2) As Kazuho said, it provides more precise feedback about which packet= s were marked, which avoids some edge cases we've had to write up in th= e current text around ack loss and being unsure of exactly when recovery is= exited.
3) It doesn't get more expensive as the connection g= oes on.=C2=A0 This is an unfortunate property of the current design.
<= div>
I find Jana's variation on this particularly interesting,= because if ECN isn't negotiated, I don't think there a reason to a= dd any overhead.=C2=A0 From personal experience, if you find a form of feed= back valuable(whether it's ECN or timestamps for one-way-delay), then y= ou're happy to consume a few extra bytes to get better feedback.=C2=A0 = If the extra information isn't useful for whatever reason, it's jus= t wasted bytes.

So overall this seems like an improvemen= t we should do, but I'd prefer a variant that doesn't increase the = ACK frame size when ECN is disabled or there are no ECN marks to report.=C2= =A0 FYI, if we need to steal a bit from the number of ack blocks, I'm o= k with that since I expect more than 32 ack blocks to be very rare.

On Thu, Aug 9, 2018 at = 3:52 AM Brian Trammell (IETF) <ietf@= trammell.ch> wrote:
hi Jana,= all,

Also fried, but I've had a quick look at this...

> On 9 Aug 2018, at 08:36, Jana Iyengar <jri.ietf@gmail.com> wrote:
>
> Thanks for picking this one up, Martin. As I've said to you and to= Kazuho, I think if we can unify ACK and ACK_ECN frames "reasonably&qu= ot;, I think there's a lot of value in having a single frame format. Th= e question of course is if we can make this reasonable, so thanks for tryin= g.
>
> I need to think some more when I'm not as fried as I am right now,= but I'm not convinced about the encoding yet.

+1 to this -- if we find not-quite-varints in packet numbers uncomfortable,= I can't see us finding rolling five-in-four encoding in the low bits o= f a different not-quite-varint less so.

> A couple of more simplifying assumptions might help:
> 1. A receiver receives 3 types of packets: Non-ECT, ECT, CE. It only r= eports packets it has received.
> 2. We can assume that a sender uses ECT(0) or ECT(1), not both. Let= 9;s call this default-ECT. If a future mechanism wants to use both, they ca= n define a new ACK frame. (Magnus and I checked on this with David Black, a= nd he agrees on the use of a single default ECT value..)

This also seems reasonable to me, and AFAICT lines up with all the current = proposals for using ECT0/1 signaling.

> This means that you only need to report 3 types of ranges.
>
> Further, if you have a separate bit to communicate ECN/non-ECN, meanin= g that the receiver has seen ECT/CE bits and will echo them back, or the re= ceiver has not seen ECT/CE bits and won't echo them back, then you have= 1 or 2 types of ranges.
> ECN bit =3D 0: every range is of packets received, there's no ECN = echo. This is exactly the same ACK format as what we have now.
> ECN bit =3D 1: ranges are of 2 types, default-ECT or CE. We need exact= ly 1 bit here to distinguish between these two ranges.
>
> I'm aware that if we move this ECN bit to the frame type, then we = end up with two ACK frames again, but this is still far more unified than w= hat we have now.

+1. I'm really not bothered by pushing some of the ACK signaling bits i= nto the frame type (especially if we describe these frames in a unified way= , as we do with STREAM frames), as long as the structure of the frames is i= dentical.

Cheers,

Brian

> I'm also aware that we need a way for a receiver to say that it re= ceived non-default ECT, but that can be separate, or an error even, and a r= eceiver could stop reporting ECN assuming that a network box is messing wit= h the bits.
>
> On Wed, Aug 8, 2018 at 8:54 PM Martin Thomson <martin.thomson@gmail.com> = wrote:
> (More long emails. Sorry, I'm trying to either close these issues = or
> prepare us for the interim.)
>
> We decided to take ACK_ECN to address an immediate need, but
> recognized that the encoding was suboptimal.=C2=A0 In the issue (see > https://github.com/quicwg/base-drafts/issues/1= 439) we've
> beendiscussing an option for frame encoding that fixes a bunch of
> issues. That discussion covered a lot of ground, but here is my
> summary.
>
> This is what we have currently (using C/TLS style notation because I > don't think ASCII art works in email):
>
>=C2=A0 =C2=A0 struct ACK {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint largest_acknowledged;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint delay;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint additional_block_count;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint first_block;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 varint gap;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 varint block;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0} blocks[additional_block_count];
>=C2=A0 =C2=A0 };
>
>=C2=A0 =C2=A0 struct ACK_ECN {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ACK ack;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint ect0_count;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint ect1_count;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint ecnce_count;
>=C2=A0 =C2=A0 };
>
> The most obvious issues are:
>
> A. There are two inconsistent encodings for acknowledgments depending<= br> > on whether ECN is enabled.
> B. ACK_ECN has more overhead than ACK.=C2=A0 Ideally there are fewer > disincentives to use ACK_ECN.
> C. The counting scheme is imprecise (you don't always know which > packet was CE marked, and that could matter), which makes counting of<= br> > ECN markings fragile in the presence of ACK loss.=C2=A0 This can lead = to
> ECN being disabled despite it being fully functional.
> D. ECN counters always increase, and so they take more space to encode=
> over time.
>
> Kazuho suggested a scheme that adds some modest complexity, but I
> think that it works and reduces other complexities such that it's<= br> > probably a net win on the complexity front.=C2=A0 It also fixes these<= br> > issues at the same time.
>
> The observation is that there are 5 things that you might want to say<= br> > about any given packet number:
>
> 0. say nothing (i.e., I'm not acknowledging this packet; this is a= gap)
> 1. packet received, no marking
> 2. packet received with an ECT(0) marking
> 3. packet received with an ECT(1) marking
> 4. packet received with an ECN-CE marking
>
> Now, the current system of describing ranges of packets is still
> pretty good.=C2=A0 An expression of the form "the next N packets = are of
> type X" gets us an encoding that is small and fits traffic patter= ns
> well.=C2=A0 No point changing what is a fundamentally good encoding. >
> So, we retain the maximum packet number and the idea of expressing
> ranges of packets. But each range is a tuple that expresses both the > type of acknowledgement (or lack thereof) for that range and how many<= br> > packets are in the range.
>
> That would produce an ACK frame in the following basic shape:
>
>=C2=A0 =C2=A0 struct ACK {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint largest_acknowledged;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint delay;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint range_count;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum {gap,unmarked,ect0,ect1,ecnce} = type;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 varint count;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0} ranges[range_count];
>=C2=A0 =C2=A0 };
>
> The problem now is that we lost efficiency in a big way because the > enum takes up a ton of space, for just 5 values.
>
> If we observe that there are 5 types, but you don't need to repeat= the
> same type, then we can express the type in two bits.=C2=A0 That is, th= e
> type is interpreted as:
>
>=C2=A0 =C2=A0 type =3D last_type + 1 + encoded_type (mod 5)
>
> Kazuho suggested that we pack these bits into the low two bits of a > varint.=C2=A0 It's a little ugly, but I can't see a better opt= ion.=C2=A0 For
> instance, defining a new varint type would be considerably worse.=C2= =A0 In
> addition to not being able to reuse varint code, my testing on
> encodings showed that a defining a new type with flags before the
> 2-bit length is surprisingly expensive.
>
> This produces a format like this:
>
>=C2=A0 =C2=A0 struct ACK {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint largest_acknowledged;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint delay;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint range_count;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0varint ranges[range_count];
>=C2=A0 =C2=A0 };
>
> As you can see, this is a considerable simplification.=C2=A0 The only = trick
> is that more data is packed into each range value.=C2=A0 These values = are
> encoded using something like:
>
>=C2=A0 =C2=A0 encoded_type =3D (type + 4 - last_type) % 5
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // encoded_type =3D type - last_type - 1 (m= od 5)
>=C2=A0 =C2=A0 range =3D encoded_type | (count << 2)
>
> The cost is that ranges take one more byte once they get above 16
> packets rather than at 64 packets as before.=C2=A0 It's also possi= ble with
> this to encode a non-acknowledgment at the end of an ACK frame, which<= br> > I think we can either prohibit or ignore.=C2=A0 But it fixes all the a= bove
> problems.
>
> Is this a change worth making?
>
> Cheers,
> Martin
>
>
> A side note: This works whether we encode a count (as here) or a total=
> number of octets (as has been proposed).=C2=A0 Similarly, we could cou= nt
> from the bottom rather than the top if we wanted to.=C2=A0 Those decis= ions
> are orthogonal to this; I'm trying as much as possible to retain t= he
> current design.
>
> Another note: We already have an issue on file for an ACK frame
> example.=C2=A0 That is still planned and that should help with interpr= eting
> the text.
>

--000000000000527547057306486c-- From nobody Thu Aug 9 13:37:34 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6A4130FC5 for ; Thu, 9 Aug 2018 13:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80jMSzF-up6z for ; Thu, 9 Aug 2018 13:37:21 -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 D78CB130FB2 for ; Thu, 9 Aug 2018 13:37:21 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by linode64.ducksong.com (Postfix) with ESMTPSA id 1FA683A019 for ; Thu, 9 Aug 2018 16:37:21 -0400 (EDT) Received: by mail-oi0-f44.google.com with SMTP id n21-v6so12172902oig.3 for ; Thu, 09 Aug 2018 13:37:21 -0700 (PDT) X-Gm-Message-State: AOUpUlFzA0l3oMlRna1pVkUMReJOtHyZHvcDxc4V2EDpPmZDNjOrmfmC TUOYSo8rMpjlZCrGjFR1GYqOUk0YMO776c/HYxk= X-Google-Smtp-Source: AA+uWPz7M9pf6MLLu60PIZfdFwZHW1enWU7GrN9Jra88x75NpmTK8RMmT2PB+XlLg7PQ735yeFQ5mTR+kUkRjeIrT3E= X-Received: by 2002:aca:e80c:: with SMTP id f12-v6mr4015092oih.38.1533847040852; Thu, 09 Aug 2018 13:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Thu, 9 Aug 2018 13:37:19 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Thu, 9 Aug 2018 16:37:19 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: PNE Test Vector To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="000000000000028bba05730698b3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:37:32 -0000 --000000000000028bba05730698b3 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 30, 2018 at 5:36 AM, Martin Thomson wrote: > I just implemented a hacky encrypt/decrypt routine for initial packets > and verified this message (not that that was necessary). > > https://gist.github.com/martinthomson/7f4b615070254644f4c5335014980cbc > > hacky or not, its super helpful. thanks. --000000000000028bba05730698b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Jul 30, 2018 at 5:36 AM, Martin Thomson <martin.thomson@gma= il.com> wrote:
I just imple= mented a hacky encrypt/decrypt routine for initial packets
and verified this message (not that that was necessary).

https://gist.github.com/m= artinthomson/7f4b615070254644f4c5335014980cbc


hacky or not, its super helpful. thank= s.

--000000000000028bba05730698b3-- From nobody Thu Aug 9 17:44:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2095A130DF5 for ; Thu, 9 Aug 2018 17:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 jqwD_YEYGP8U for ; Thu, 9 Aug 2018 17:44:41 -0700 (PDT) Received: from mail-yw1-xc30.google.com (mail-yw1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E75130FF2 for ; Thu, 9 Aug 2018 17:44:41 -0700 (PDT) Received: by mail-yw1-xc30.google.com with SMTP id q129-v6so7285561ywg.8 for ; Thu, 09 Aug 2018 17:44: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=xIoAqwmj5G0aIvWAGXd6o4J2xJtgSBDNWLFLTJVhgzA=; b=clm9Oqi9AuZcmkzj7Q5FBxn2ZJjLJRIi0u0rcnbdA/p/ZeO9eEmulE6/NAgyC390Ti Yy1W/lMhm48p0CLjhlJc5YraOE1Jaudh9F5FQSdyDw4IHHnPyNxMCw6w64ZeVFuXLagY 7NiPT/Ekx3AFBHQApw/ozareS3mfZ4cJ3wMp1PjQCJsoVFZFAgX5YV5rxyDGofNUASHw V6Jcb7aF7Lyc0KRa59bz5AWgqmNKYWVCyHpJrY7ajqktCm6C0JTxwU5cF0H0A0G1nTl9 503f88XR+wN7tgZ0lrSmHxHWK7OreB29ykAxr4dFCc9Xu52/O9PTTdMGKYVuFskD/3nf da2g== 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=xIoAqwmj5G0aIvWAGXd6o4J2xJtgSBDNWLFLTJVhgzA=; b=eGtHTnuSGFZj3ZrZjptowA4eGfofRb2wbbXLQ8Kq5zFamRn6mY1XKcDiOo7+CcretY gCDADo5rgxHePqNcZ3b/s5SUQUxVwzB4DZu3jZzlfCp8t8WvWgkwmbkdj/xj+03zqI4b 1kUeGdbnEWBxjWX+PFKGcpstSSH9WnQssWZRZKeSUIUUO6mr3LqWu6kfr3tF8xGBgEvY 9vkdCX4bWmM9hnS356MrgT+/P26AQ7vtTs1jOGaJ4BirO4aEjFHIzKSohnyN5KzZJYbs bxPKstPFoC7NAi4Td/k9kbfTQS9gYqfAr+a5tZ356Lg3uwH2qqOdZSyyMXl9nxIMw3WO PhXQ== X-Gm-Message-State: AOUpUlHAPzqnELWHgJDUVH1X0JTr6zUkL8XSS7BLnSJyZ7+I2BMArtib e2/hFGP/QkhyPkfQAC7DC3TdmL00HEyd6kw4R5nTOC0l X-Google-Smtp-Source: AA+uWPzpvzB7clmJFZFtHiW5mv3usX0ejPm3kIkT1m+LZ1RFTTIWvJwmuMmwmlnLyFHa6DVgdGmevMj7jrhJLFnptcY= X-Received: by 2002:a25:a263:: with SMTP id b90-v6mr2485033ybi.247.1533861880131; Thu, 09 Aug 2018 17:44:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:8b11:0:0:0:0:0 with HTTP; Thu, 9 Aug 2018 17:44:39 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 9 Aug 2018 17:44:39 -0700 Message-ID: Subject: Re: Reserved HTTP Frames To: Mike Bishop Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000080ac1c05730a0c55" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 00:44:45 -0000 --00000000000080ac1c05730a0c55 Content-Type: text/plain; charset="UTF-8" Great, thanks! Would you be interested in a PR to add the "(0..7)" comment to 4.2.1? On Thu, Aug 9, 2018 at 8:51 AM, Mike Bishop wrote: > No overflows. The IANA section is more exhaustive: > > > > Additionally, each code of the format 0xb + (0x1f * N) for values of N in > the range (0..7) (that is, 0xb, 0x2a, 0x49, 0x68, 0x87, 0xa6, 0xc5, and > 0xe4), the following values should be registered: > > > > *From:* Ryan Hamilton > *Sent:* Wednesday, August 8, 2018 2:13 PM > *To:* IETF QUIC WG ; Mike Bishop > *Subject:* Reserved HTTP Frames > > > > I've a question about this text from the HTTP mapping doc: > > > 4.2.1 . > Reserved Frame Types > > > > > > Frame types of the format "0xb + (0x1f * N)" are reserved to exercise > > the requirement that unknown types be ignored. > > > > For what values of "N" are we talking about? I assume [0,8)? Because, > unless I'm doing the math wrong, if N can be [0,256) (and we're doing > uint8_t math) then that covers all possible values. > > > > Cheers, > > > > Ryan > --00000000000080ac1c05730a0c55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great, thanks! Would you be interested in a PR to add the = "(0..7)" comment to 4.2.1?
=
On Thu, Aug 9, 2018 at 8:51 AM, Mike Bishop = <mbishop@evequefou.be> wrote:

No overflows.=C2=A0 The IANA section is more exhaust= ive:

=C2=A0

Additionally, each code of the format 0xb + (0x1f * N) for values of N in the range (0..7) (that is,= 0xb, 0x2a, 0x49, 0x68, = 0x87, 0xa6, 0xc5, and 0xe4), the following= values should be registered:

=C2=A0

From: Ryan Hamilton <rch@google.com>
Sent: Wednesday, August 8, 2018 2:13 PM
To: IETF QUIC WG <quic@ietf.org>; Mike Bishop <mbishop@evequefou.be>
Subject: Reserved HTTP Frames

=C2=A0

I've a question about this text from the HTTP mapping doc:<= u>

=C2=A0

4.2.1.=C2=A0 Reserved Frame Types

=C2=A0
=C2=A0
=C2=A0=C2=A0 Frame types of the format &qu=
ot;0xb + (0x1f * N)" are reserved to exercise

=C2=A0=C2=A0 the requirement that unknown =
types be ignored. 


=C2=A0

For what values of "N" are we talking about? I assume= [0,8)? Because, unless I'm doing the math wrong, if N can be [0,256) (= and we're doing uint8_t math) then that covers all possible values.

=C2=A0

Cheers,

=C2=A0

Ryan


--00000000000080ac1c05730a0c55-- From nobody Fri Aug 10 03:27:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738FB130F0A for ; Fri, 10 Aug 2018 03:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sps4AD5ag8hY for ; Fri, 10 Aug 2018 03:27:05 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C77130DE3 for ; Fri, 10 Aug 2018 03:27:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41n1Wr1q2pz15KJd; Fri, 10 Aug 2018 12:27:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffpNUegxU4nl; Fri, 10 Aug 2018 12:27:02 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.20] (nb-10688.ethz.ch [82.130.103.20]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 10 Aug 2018 12:27:02 +0200 (CEST) Subject: Re: Key updates To: Martin Thomson Cc: Ian Swett , QUIC WG References: <193166ED-C8C3-4A6B-9483-5546C34B5BDA@tik.ee.ethz.ch> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <8984a3c6-d506-54ec-6ce6-b5e95a18aee4@tik.ee.ethz.ch> Date: Fri, 10 Aug 2018 12:27:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------0AD8CA3712A08BE12929B923" Content-Language: en-US Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 10:27:08 -0000 This is a multi-part message in MIME format. --------------0AD8CA3712A08BE12929B923 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I was more thinking about things we know we want to do in future versions and where it would make implementation easier if we already design the current version with these changes in mind. I think that something that is independent of the invariants. On 07.08.2018 02:39, Martin Thomson wrote: > On Mon, Aug 6, 2018 at 11:06 PM Mirja Kühlewind > wrote: >> However, this brings us back to Martin’s other question: does it make sense to have a couple of reserved bits to make it easy to add a bit for the next version with minimal changes to the protocol machinery/wire image? > > I think that was Dirkjan who asked that question. > > The driving principle behind defining invariants was to avoid having > to come back to this question repeatedly. We have a version > negotiation mechanism that allows us to change an awful lot between > different protocol version. We don't need to reserve a few bits > because most of them are already reserved. > --------------0AD8CA3712A08BE12929B923 Content-Type: text/x-vcard; name="mirja_kuehlewind.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mirja_kuehlewind.vcf" bnVsbA== --------------0AD8CA3712A08BE12929B923-- From nobody Fri Aug 10 10:37:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46957130DF4 for ; Fri, 10 Aug 2018 10:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xIWhK7RP0W5 for ; Fri, 10 Aug 2018 10:37:34 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0127.outbound.protection.outlook.com [104.47.32.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDD71286E3 for ; Fri, 10 Aug 2018 10:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oiDxOJb2f2SDI6+KFFfGqHxOWKA5ILjxtrj5s4h82FE=; b=DavU6O2SxmBy/mu5fViT7fA0auxNCloptMAVznR/+DYMcLOLopZ7aXmVFCMl0wdB75o8dyioYgwJFsL6p7MvqGOeVp6vpR07b887OuUeqGW2n++iHyvjFYhisv7sAisuAvco8aZ6SeO9cbpB3ncsF5NMFkYgVamSdrHZoXYERao= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4502.namprd08.prod.outlook.com (52.135.203.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.20; Fri, 10 Aug 2018 17:37:29 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::913f:4f09:ae22:b6db]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::913f:4f09:ae22:b6db%5]) with mapi id 15.20.1038.019; Fri, 10 Aug 2018 17:37:29 +0000 From: Mike Bishop To: Ryan Hamilton CC: IETF QUIC WG Subject: RE: Reserved HTTP Frames Thread-Topic: Reserved HTTP Frames Thread-Index: AQHUL1yjkMEVY37LVkuUUxvpaUrG6KS3kriwgACVMYCAARky8A== Date: Fri, 10 Aug 2018 17:37:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4502; 6:Ba8puAXMlORlodWZW0O5KOEa+TuwD0YrWF3V9niQ1RhbuzG4L0rh4vouHTi8h9uSTZX1PSrZ3NjkWCShK08dJQ5kQSRgCCc/v91Tj6YFY111OIBZo9yDzTX4BwR5ny9mufQZ0Tw6hGvZ2kVBc4lAltJ/stl9xIOlBTnJL5/u/s7nOD2Tlv8N83SWth39fEW9PAFv0dWHiQWfsV16iwGCgHYfElGtYSoF+tQkTmiFF1wl2sRmIt+RyttfW35JIZous1Y8n+TO+REtU7XiYPLtfuWiB5D8JV9caFc0+oUiMnNtXcuS3t2OHLJY6Ec1b2w2UD/QriMI0GTBHJK+Q0c7bfpsJBWyIfvOUNFRaQJEcvaPmcOqrrhbYr2LeDCW4ooOVG5AsSVyx/0fJxFstC2Z0gWrRr+zwXeu3R7QBBWxt/IPD6bDNyUPC3KhlHqdFf8iMwrP+dAc5aC/hjMkpYklew==; 5:gPu5Cjztbfg1Xw53xbM2tUvSxFXXUzTqmOJoon9iRduJ14/x8Q89p3mdedPILIkljeTn4GPI8DGSgiUdREl6wFiK3SlDLAsijsNUydMa8tbWeWRDDuiHqG62Noj+Z/neZzw4vSC/HFTB2aWDlkBkt9UkH7/o1X7bR/Px+TovqPA=; 7:XdPvwGcPP0zFHIe0gM1RN246m6kLsDGbqECaQ8S9dn+zB5/titWd/q+TnWSgwm4mtk1x2BMVoew27qVttFB0GTM9+WQbsw6vUW2iFh/AqThcwEZy8x7EwIPqFzUqItYuEtLScjTblrG1dpwrUR8LwEdUdgqkdg3LooMJLROfu5QmagY46WtM5KdWJ9WJlZuriLx8QTWtOmGHN8Pgxew5s/MsRdLBmQ3lT7mdHcboyEBI3mRBgVKKu6+zTJxnUDgG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 88fc1e4f-367e-4bbf-8925-08d5fee7f1d9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4502; x-ms-traffictypediagnostic: BYAPR08MB4502: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(211936372134217)(153496737603132)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(2016111802025)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB4502; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4502; x-forefront-prvs: 07607ED19A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39830400003)(396003)(366004)(346002)(376002)(199004)(189003)(74316002)(25786009)(6116002)(55016002)(790700001)(9686003)(54896002)(3846002)(2906002)(5250100002)(6306002)(6436002)(97736004)(2900100001)(256004)(7736002)(86362001)(229853002)(8676002)(53936002)(3480700004)(106356001)(6916009)(105586002)(316002)(8936002)(102836004)(74482002)(19609705001)(14454004)(478600001)(7696005)(446003)(81166006)(76176011)(476003)(7116003)(5660300001)(11346002)(6246003)(81156014)(606006)(53546011)(486006)(99286004)(186003)(4326008)(33656002)(68736007)(6506007)(236005)(26005)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4502; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4OUt46lkqKQ1f5+g51GpCFJvG1Z2WurPERAZ+czS+HF5vWQAckh+LTbazXc29amNB/yqRAamO6BeCIVZ2K5CTPKTGaMljIOceaP7g3T3TPbKYPZQgOmrK93P9AmMKIfZyhZs2wy/m16+u7xToVFPkSoA5VCfI3mtS4yZJaWEW3IGfq9+hRCnoHl5iSHEie+ASa3JBHaGQkoX14Jtvdbt4bK+CzgHP/W18DycYDh4gyH2EEUSWc5z/LEv32p8L/ns2IOvRDoCQMoH21lqpsSUvr/yGvQ/8NFkXDzdv/YOAntvZL+aIvWiAGmOCCaLFTGg998fHCy0pFQ78JykeuTYI/BfzECeYCYswkoV8yW/ezQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB3944C01A8B6788794F5D22A5DA240BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 88fc1e4f-367e-4bbf-8925-08d5fee7f1d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2018 17:37:28.7508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4502 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 17:37:37 -0000 --_000_BYAPR08MB3944C01A8B6788794F5D22A5DA240BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBmb3Igc29tZSBjb250ZXh0OiAgQXMgeW91IGtub3csIHRoZSBwb2ludCBvZiBncmVhc2lu ZyBpcyB0byBjcmVhdGUgYSBmb3JjaW5nIGZ1bmN0aW9uIHRoYXQgbWFrZXMgaXQgZWFzaWVyIHRv IGRvIHRoZSByaWdodCB0aGluZyAoc2tpcCB1bmtub3duIHZhbHVlcykgdGhhbiB0aGUgd3Jvbmcg dGhpbmcgKGhhcmQtY29kZSB0aGUgbGlzdCBvZiBncmVhc2UgdmFsdWVzIGFuZCBpZ25vcmUgdGhv c2UpLiAgR2l2ZW4gdGhhdCB0aGVyZSBhcmUgb25seSBlaWdodCBvZiB0aGVtLCB0aGF04oCZcyBh bHJlYWR5IHF1ZXN0aW9uYWJsZS4gIFRvIHRoZSBsaW1pdGVkIGV4dGVudCBwb3NzaWJsZSwgSSB3 YW50IHRoZXNlIHRvIGJlIGVhc3kgdG8gZ2VuZXJhdGUgcHJvZ3JhbW1hdGljYWxseSAocGljayBh IHJhbmRvbSBudW1iZXIsIGRvIGEgc2ltcGxlIGNhbGN1bGF0aW9uIHdpdGggaXQpIGFuZCByZXF1 aXJlIGF0IGxlYXN0IGEgbGl0dGxlIHdvcmsgdG8gaGFyZC1jb2RlLg0KDQpJ4oCZZCByZWFsbHkg cHJlZmVyIG5vdCB0byBoYXZlIHRoZSBzcGVjaWZpYyBsaXN0IGluIHRoZSBkb2MgYXQgYWxsLCBi dXQgY2VydGFpbmx5IG5vdCBpbiB0aGUgbWFpbiB0ZXh0LiAgSG93ZXZlciwgSSBkb27igJl0IHRo aW5rIGNsYXJpZnlpbmcgdGhhdCB5b3UgZG9u4oCZdCBydW4gTiB0byBpbmZpbml0eSBhbmQgdHJ1 bmNhdGUgaXMgYSBwcm9ibGVtLg0KDQpGcm9tOiBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNv bT4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgOSwgMjAxOCA1OjQ1IFBNDQpUbzogTWlrZSBCaXNo b3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBSZXNlcnZlZCBIVFRQIEZyYW1lcw0KDQpHcmVhdCwgdGhhbmtzISBX b3VsZCB5b3UgYmUgaW50ZXJlc3RlZCBpbiBhIFBSIHRvIGFkZCB0aGUgIigwLi43KSIgY29tbWVu dCB0byA0LjIuMT8NCg0KT24gVGh1LCBBdWcgOSwgMjAxOCBhdCA4OjUxIEFNLCBNaWtlIEJpc2hv cCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj4gd3Jv dGU6DQpObyBvdmVyZmxvd3MuICBUaGUgSUFOQSBzZWN0aW9uIGlzIG1vcmUgZXhoYXVzdGl2ZToN Cg0KQWRkaXRpb25hbGx5LCBlYWNoIGNvZGUgb2YgdGhlIGZvcm1hdCAweGIgKyAoMHgxZiAqIE4p IGZvciB2YWx1ZXMgb2YgTiBpbiB0aGUgcmFuZ2UgKDAuLjcpICh0aGF0IGlzLCAweGIsIDB4MmEs IDB4NDksIDB4NjgsIDB4ODcsIDB4YTYsIDB4YzUsIGFuZCAweGU0KSwgdGhlIGZvbGxvd2luZyB2 YWx1ZXMgc2hvdWxkIGJlIHJlZ2lzdGVyZWQ6DQoNCkZyb206IFJ5YW4gSGFtaWx0b24gPHJjaEBn b29nbGUuY29tPG1haWx0bzpyY2hAZ29vZ2xlLmNvbT4+DQpTZW50OiBXZWRuZXNkYXksIEF1Z3Vz dCA4LCAyMDE4IDI6MTMgUE0NClRvOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRv OnF1aWNAaWV0Zi5vcmc+PjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0 bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+DQpTdWJqZWN0OiBSZXNlcnZlZCBIVFRQIEZyYW1lcw0K DQpJJ3ZlIGEgcXVlc3Rpb24gYWJvdXQgdGhpcyB0ZXh0IGZyb20gdGhlIEhUVFAgbWFwcGluZyBk b2M6DQoNCjQuMi4xPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXF1aWMt aHR0cC0xMyNzZWN0aW9uLTQuMi4xPi4gIFJlc2VydmVkIEZyYW1lIFR5cGVzDQoNCg0KDQoNCg0K ICAgRnJhbWUgdHlwZXMgb2YgdGhlIGZvcm1hdCAiMHhiICsgKDB4MWYgKiBOKSIgYXJlIHJlc2Vy dmVkIHRvIGV4ZXJjaXNlDQoNCiAgIHRoZSByZXF1aXJlbWVudCB0aGF0IHVua25vd24gdHlwZXMg YmUgaWdub3JlZC4NCg0KRm9yIHdoYXQgdmFsdWVzIG9mICJOIiBhcmUgd2UgdGFsa2luZyBhYm91 dD8gSSBhc3N1bWUgWzAsOCk/IEJlY2F1c2UsIHVubGVzcyBJJ20gZG9pbmcgdGhlIG1hdGggd3Jv bmcsIGlmIE4gY2FuIGJlIFswLDI1NikgKGFuZCB3ZSdyZSBkb2luZyB1aW50OF90IG1hdGgpIHRo ZW4gdGhhdCBjb3ZlcnMgYWxsIHBvc3NpYmxlIHZhbHVlcy4NCg0KQ2hlZXJzLA0KDQpSeWFuDQoN Cg== --_000_BYAPR08MB3944C01A8B6788794F5D22A5DA240BYAPR08MB3944namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KaDQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzYW1wDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5IZWFkaW5nNENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgNCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA0IjsNCglmb250LWZh bWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMkY1NDk2Ow0KCWZvbnQt c3R5bGU6aXRhbGljO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IGZvciBzb21lIGNvbnRleHQ6Jm5ic3A7IEFz IHlvdSBrbm93LCB0aGUgcG9pbnQgb2YgZ3JlYXNpbmcgaXMgdG8gY3JlYXRlIGEgZm9yY2luZyBm dW5jdGlvbiB0aGF0IG1ha2VzIGl0IGVhc2llciB0byBkbyB0aGUgcmlnaHQgdGhpbmcgKHNraXAg dW5rbm93biB2YWx1ZXMpIHRoYW4gdGhlIHdyb25nIHRoaW5nIChoYXJkLWNvZGUgdGhlIGxpc3Qg b2YgZ3JlYXNlIHZhbHVlcyBhbmQgaWdub3JlIHRob3NlKS4mbmJzcDsgR2l2ZW4NCiB0aGF0IHRo ZXJlIGFyZSBvbmx5IGVpZ2h0IG9mIHRoZW0sIHRoYXTigJlzIGFscmVhZHkgcXVlc3Rpb25hYmxl LiZuYnNwOyBUbyB0aGUgbGltaXRlZCBleHRlbnQgcG9zc2libGUsIEkgd2FudCB0aGVzZSB0byBi ZSBlYXN5IHRvIGdlbmVyYXRlIHByb2dyYW1tYXRpY2FsbHkgKHBpY2sgYSByYW5kb20gbnVtYmVy LCBkbyBhIHNpbXBsZSBjYWxjdWxhdGlvbiB3aXRoIGl0KSBhbmQgcmVxdWlyZSBhdCBsZWFzdCBh DQo8aT5saXR0bGU8L2k+IHdvcmsgdG8gaGFyZC1jb2RlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5J4oCZZCByZWFsbHkgcHJlZmVyIG5vdCB0byBoYXZlIHRoZSBzcGVjaWZpYyBsaXN0IGluIHRo ZSBkb2MgYXQgYWxsLCBidXQgY2VydGFpbmx5IG5vdCBpbiB0aGUgbWFpbiB0ZXh0LiZuYnNwOyBI b3dldmVyLCBJIGRvbuKAmXQgdGhpbmsgY2xhcmlmeWluZyB0aGF0IHlvdSBkb27igJl0IHJ1biBO IHRvIGluZmluaXR5IGFuZCB0cnVuY2F0ZSBpcyBhIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkZyb206PC9iPiBSeWFuIEhhbWlsdG9uICZsdDtyY2hAZ29vZ2xlLmNvbSZndDsg PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgOSwgMjAxOCA1OjQ1IFBNPGJyPg0K PGI+VG86PC9iPiBNaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBSZXNlcnZlZCBIVFRQIEZyYW1lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssc2Fucy1zZXJpZiI+R3JlYXQsIHRoYW5rcyEgV291bGQgeW91IGJlIGludGVyZXN0 ZWQgaW4gYSBQUiB0byBhZGQgdGhlICZxdW90OygwLi43KSZxdW90OyBjb21tZW50IHRvIDQuMi4x PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVGh1LCBBdWcgOSwgMjAxOCBhdCA4OjUxIEFNLCBNaWtlIEJpc2hvcCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hv cEBldmVxdWVmb3UuYmU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5vIG92ZXJmbG93cy4mbmJz cDsgVGhlIElBTkEgc2VjdGlvbiBpcyBtb3JlIGV4aGF1c3RpdmU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BZGRpdGlvbmFsbHksIGVhY2ggY29kZSBvZiB0aGUgZm9y bWF0IDxzYW1wPg0KMHhiICYjNDM7ICgweDFmICogTik8L3NhbXA+IGZvciB2YWx1ZXMgb2YgTiBp biB0aGUgcmFuZ2UgKDAuLjcpICh0aGF0IGlzLCA8c2FtcD4weGI8L3NhbXA+LA0KPHNhbXA+MHgy YTwvc2FtcD4sIDxzYW1wPjB4NDk8L3NhbXA+LCA8c2FtcD4weDY4PC9zYW1wPiwgPHNhbXA+MHg4 Nzwvc2FtcD4sIDxzYW1wPg0KMHhhNjwvc2FtcD4sIDxzYW1wPjB4YzU8L3NhbXA+LCBhbmQgPHNh bXA+MHhlNDwvc2FtcD4pLCB0aGUgZm9sbG93aW5nIHZhbHVlcyBzaG91bGQgYmUgcmVnaXN0ZXJl ZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUnlhbiBI YW1pbHRvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJjaEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+cmNoQGdvb2dsZS5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg QXVndXN0IDgsIDIwMTggMjoxMyBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBRVUlDIFdHICZsdDs8 YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5v cmc8L2E+Jmd0OzsgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1 ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmVzZXJ2ZWQgSFRUUCBGcmFtZXM8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkkndmUgYSBxdWVzdGlv biBhYm91dCB0aGlzIHRleHQgZnJvbSB0aGUgSFRUUCBtYXBwaW5nIGRvYzo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGg0PjxhIG5hbWU9Im1f LTUyODMzNDA4MTEzNjk2NTY0NTVfc2VjdGlvbi00LjIuMSI+PC9hPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXF1aWMtaHR0cC0xMyNzZWN0aW9uLTQuMi4x IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPjQuMi4xPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+LiZuYnNwOw0KIFJlc2Vy dmVkIEZyYW1lIFR5cGVzPC9zcGFuPjxvOnA+PC9vOnA+PC9oND4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgRnJhbWUgdHlwZXMgb2YgdGhl IGZvcm1hdCAmcXVvdDsweGIgJiM0MzsgKDB4MWYgKiBOKSZxdW90OyBhcmUgcmVzZXJ2ZWQgdG8g ZXhlcmNpc2U8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIHJlcXVpcmVtZW50IHRoYXQgdW5rbm93biB0eXBlcyBi ZSBpZ25vcmVkLiA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNo ZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIHdoYXQgdmFsdWVzIG9mICZxdW90O04mcXVvdDsg YXJlIHdlIHRhbGtpbmcgYWJvdXQ/IEkgYXNzdW1lIFswLDgpPyBCZWNhdXNlLCB1bmxlc3MgSSdt IGRvaW5nIHRoZSBtYXRoIHdyb25nLCBpZiBOIGNhbiBiZSBbMCwyNTYpIChhbmQNCiB3ZSdyZSBk b2luZyB1aW50OF90IG1hdGgpIHRoZW4gdGhhdCBjb3ZlcnMgYWxsIHBvc3NpYmxlIHZhbHVlcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYi PlJ5YW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_BYAPR08MB3944C01A8B6788794F5D22A5DA240BYAPR08MB3944namp_-- From nobody Fri Aug 10 11:05:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A595B130DE0 for ; Fri, 10 Aug 2018 11:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 zOVdCeGfayxG for ; Fri, 10 Aug 2018 11:05:32 -0700 (PDT) Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60F61292AD for ; Fri, 10 Aug 2018 11:05:32 -0700 (PDT) Received: by mail-yw1-xc2b.google.com with SMTP id 139-v6so9208532ywg.12 for ; Fri, 10 Aug 2018 11:05:32 -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=O9TscmnosFmhZY0kEseL7ut/ADiXGvLIBHLlntjIM1g=; b=DmUxo8P9HtzwCwW6+rbbo6JxBZDlzebhHvoa0tWsYbcVKALHuv5bZpiZv4+xkGqBX5 eGziBBe9Nnb2OTIqSdQtI91g87iR1kNtK6nEY3oIczR0YVu/7UiD/CelyVOaCIuCoPcK m6DhSU+5/j1bPS/0L8+yHcjlFe/RE3EFpgCtOsh1wOyatUiT4tRUXH0VUQLOQncG8SiH kWmLvzT6QJfXeQDmNn/M1G1kSVrngdAJUTA5jNKH5tI+ssvd4KCbpLpdlZ0s7Av2aeeH t5UT7tlwxcYlx8omhJ2pW/PCMlPnMdDfgDqRqQaj+tlmgLWYIkriX9UInAj0DwdQtwFU mLmg== 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=O9TscmnosFmhZY0kEseL7ut/ADiXGvLIBHLlntjIM1g=; b=s+pT+/i1zKIx42cfQiSgCOCsZDIYzdnIZPXl7JitbW9OXWpu2/LXB7bPXVa9Ao5FOS PQvdEorT8Bm+f1cDMaqHPl6r7VjtJva7NRy8G2s+Q102htW9v0nVY0Lq+qKYCCxAn4VZ w8AJKJUgoPBfCNfkRPe2kOrTChe2OSRph6RUCmkOsN4zAMYqj/lvyE0MiwVx3KNSsJ10 nZikEtzhZsumXimHnTAdR+g49cxV/6EHXHxFQN4e1RF0bf+8iavvBCv2q+Sd9lkC4w+k PVQIOVe2ZiLzGKu3qb5+aG20GH+qyo6PUvT3suLtPm6G7EEQaS9KqvME+rl1KGDZk66v yyGw== X-Gm-Message-State: AOUpUlFIyz4/z9cRbNaOm1ZfidZPSuMGdMeJWpxdKnFM2/9KhTkjxZZv ug6exldSTi4JsgvMU3LW0fNcU1zysTrTq8K8WoAlSDJS X-Google-Smtp-Source: AA+uWPzGNE9GiC+8knG/+R/Tpjp/NJ4hIYwRIK/rOQno/z7pRg8t/kXiJmonPC3ji+rEff4uek2YN77ooHa2rE1JwrI= X-Received: by 2002:a25:38f:: with SMTP id 137-v6mr4006947ybd.314.1533924331313; Fri, 10 Aug 2018 11:05:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:8b11:0:0:0:0:0 with HTTP; Fri, 10 Aug 2018 11:05:30 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Fri, 10 Aug 2018 11:05:30 -0700 Message-ID: Subject: Re: Reserved HTTP Frames To: Mike Bishop Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e20ebf0573189622" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 18:05:35 -0000 --000000000000e20ebf0573189622 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 10, 2018 at 10:37 AM, Mike Bishop wrote: > Just for some context: As you know, the point of greasing is to create a > forcing function that makes it easier to do the right thing (skip unknown > values) than the wrong thing (hard-code the list of grease values and > ignore those). Given that there are only eight of them, that=E2=80=99s a= lready > questionable. To the limited extent possible, I want these to be easy to > generate programmatically (pick a random number, do a simple calculation > with it) and require at least a *little* work to hard-code. > Oh, definitely agree. We want implementers to use a bit of elbow grease here. I also share your anxiety that perhaps 8 reserved values is not quite enough, though the particular values do at least cover every bit in the byte. > I=E2=80=99d really prefer not to have the specific list in the doc at all= , but > certainly not in the main text. However, I don=E2=80=99t think clarifyin= g that you > don=E2=80=99t run N to infinity and truncate is a problem. > Makes sense to me. --000000000000e20ebf0573189622 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 1= 0, 2018 at 10:37 AM, Mike Bishop <mbishop@evequefou.be> wrote:

Just for some context:=C2=A0 As you know, the point = of greasing is to create a forcing function that makes it easier to do the = right thing (skip unknown values) than the wrong thing (hard-code the list = of grease values and ignore those).=C2=A0 Given that there are only eight of them, that=E2=80=99s already questionable.=C2= =A0 To the limited extent possible, I want these to be easy to generate pro= grammatically (pick a random number, do a simple calculation with it) and r= equire at least a little work to hard-code.


Oh, definitely agree. We want implementers to use a bit of elb= ow grease here. I also share your anxiety that perhaps 8 reserved values is= not quite enough, though the particular values do at least cover every bit= in the byte.

I=E2=80=99d really prefer not to have the specific l= ist in the doc at all, but certainly not in the main text.=C2=A0 However, I= don=E2=80=99t think clarifying that you don=E2=80=99t run N to infinity an= d truncate is a problem.


Makes sense to me.

--000000000000e20ebf0573189622-- From nobody Fri Aug 10 11:07:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26567130E67 for ; Fri, 10 Aug 2018 11:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 HHXk87_yvmo0 for ; Fri, 10 Aug 2018 11:07:13 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B2F130DE0 for ; Fri, 10 Aug 2018 11:07:13 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id 139-v6so9212511ywg.12 for ; Fri, 10 Aug 2018 11:07:13 -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=NM2HD8mRrEDSA9OjHetHZ4nJqdcCLZU3MScKooIoL8M=; b=a5Tr79BCBspi3lwyxQ8Zzx8ri/X5IRejNe9Rf8A5rTWeTIia/9g9mx34gIjeLzic23 pSNd/EoRfC/MTkJSgEeGfQhKlKBbV2jtnElDiemzzUI4IvGHQi0VGfppp6zSbcLHlZt/ yY03ty6QGxVk4Z4bWJs2QM1OO4H5G3ZX3zKpsXuSqhvvBLuu0YQyY8wfeLp2CEYlTvlJ mgiJocjm9h/9RR3nNAfrpp6j0WueTNpj2Q9VYIezNQ4AMT3XJSq+b92KaiyR7C2+2Q0E l1hZWjh+qEYGgo4rkVYUk2hF8Ir4L6MQO/vo8BVHv76lDjdW5A9MOokkUMG8d3WtmZuH b1mQ== 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=NM2HD8mRrEDSA9OjHetHZ4nJqdcCLZU3MScKooIoL8M=; b=TxG4FISeYOqzS44b2DPgYp/oIHg26oiu3HDm4n/AhWIINUSAbTi5zJQeWJmq6uU+yI xahF5W0hUlC8fqTh/Xio2fsUXdd2U2SwD+wCX3gkjXeJChIw4x21XNaxQ5Cj5aWvlYGE N9UwCao5hkht6iZ0GJZLGSy3tq1s045uHLYbLciks1jR6Vjj+nFVWcED4sBEB2H54m6b ReHTBeeGIAMhxLlXWbqL/6Oo0cWwsxrZvHLRr7dUoYDMHyJy3cuVaZoF7LCi+AuYPBPn SBmYIYAVPoa6CPWT/+ERBoJ4wO9AVlzKFgW4y4AqcqGr6cJTSyv/ip8paU3F1d/GAgFG frJw== X-Gm-Message-State: AOUpUlGIFk9vTmJuIxTwCX0wZsLHTPH11jZ3Zz9A6YAIjD+9hleGy87M aZeHfvdM91jXPTk3uFx4l8akGuxbq+NWwbVpsjU3O8mxIKM= X-Google-Smtp-Source: AA+uWPznPakCLU12GN6RGG5u3f38iwkyGJjN5vts6oIElwGt28Bgs2TSMG70ewXMEcHNLBbitXeMBbrq09tSkQN22ao= X-Received: by 2002:a25:7a86:: with SMTP id v128-v6mr4067255ybc.5.1533924431971; Fri, 10 Aug 2018 11:07:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:8b11:0:0:0:0:0 with HTTP; Fri, 10 Aug 2018 11:07:11 -0700 (PDT) From: Ryan Hamilton Date: Fri, 10 Aug 2018 11:07:11 -0700 Message-ID: Subject: Can we simplify SETTINGS? To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e20b430573189cf0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 18:07:15 -0000 --000000000000e20b430573189cf0 Content-Type: text/plain; charset="UTF-8" Howdy, The SETTINGS frame format is extremely flexible. While the identifiers (keys) are uint16s (though not encoded as a varint even though most/all identifiers could be varint encoded as a single byte), the contents (values) are, on the wire, sequences of bytes of arbitrary length. (Is it legal/desirable to permit a peer to send a 1GB setting contents?) But more than that in some cases they are booleans (true if the content is empty, false if the identifier is missing?!). This is quite a general purpose representation. But curiously, there are only two defined SETTINGS and they are both integers. Since HTTP/QUIC only needs two numeric settings, it seems like we could just define the settings frame to be a sequence of pairs of varints (while still allowing greased identifiers, of course). It seems like that would be much simpler and would not really cost us anything. But perhaps this has been discussed previously and there's a use case I'm not thinking about, or perhaps we have a longer list of settings that we're planning to add to this list before we "finish" v1? I can well imaging abusing, sorry I mean using, a SETTINGS frame to carry all sorts of interesting data of various types. But such data could "just as easily"(tm) be carried in some application-specific frame type. Cheers, Ryan --000000000000e20b430573189cf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

The SETTINGS frame format is extre= mely flexible. While the identifiers (keys) are uint16s (though not encoded= as a varint even though most/all identifiers could be varint encoded as a = single byte), the contents (values) are, on the wire, sequences of bytes of= arbitrary length. (Is it legal/desirable to permit a peer to send a 1GB se= tting contents?) But more than that in some cases they are booleans (true i= f the content is empty, false if the identifier is missing?!). This is quit= e a general purpose representation.=C2=A0

But curiously, the= re are only two defined SETTINGS and they are both integers.

Since HTTP/QUIC only needs two num= eric settings, it seems like we could just define the settings frame to be = a sequence of pairs of varints (while still allowing greased identifiers, o= f course). It seems like that would be much simpler and would not really co= st us anything. But perhaps this has been discussed previously and there= 9;s a use case I'm not thinking about, or perhaps we have a longer list= of settings that we're planning to add to this list before we "fi= nish" v1?

I can wel= l imaging abusing, sorry I mean using, a SETTINGS frame to carry all sorts = of interesting data of various types. But such data could "just as eas= ily"(tm) be carried in some application-specific frame type.

=
Cheers,

Ryan
--000000000000e20b430573189cf0-- From nobody Fri Aug 10 11:27:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47874130E47 for ; Fri, 10 Aug 2018 11:27:05 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=GzN3GEsQ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ebDMPMyX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd1aY6D7noXC for ; Fri, 10 Aug 2018 11:27:02 -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 7472D130E7D for ; Fri, 10 Aug 2018 11:27:02 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w7AIPX6M008367; Fri, 10 Aug 2018 11:27:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=rQZnWGvJohC2EHA61vF6FS0Y8LQwwcdk4QUSSZVrKz0=; b=GzN3GEsQDdkLyOE/mTsee8199iwCFJ0tU6TT8pEDfCapH8WpQiN2Vpkl/O+GgmywaPIy ZR/x7koNeok+wDQhHk7OjsnEjXFJl1a7pIwB0mL+hschX2zUVKZsCKvmsqxEn5yp98Mn NIPyRYgB3g6lWh2w6U0DbGmBQTMc779iDgc= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2ksfhvr42v-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2018 11:27:00 -0700 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.17) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 10 Aug 2018 11:26:58 -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:X-MS-Exchange-SenderADCheck; bh=rQZnWGvJohC2EHA61vF6FS0Y8LQwwcdk4QUSSZVrKz0=; b=ebDMPMyXkZ2jWW19pbKj68UQ5qdNFmz9qGNA2xqvrARAzssAzsh/uUljUDmDCEYi0dGGf5VhNDnd+GApM6JvJ/c/WuFNEzQrgMTfIBDzclxRor05yfTAbkIKzHEZwi6CdwSq6WPuldCHxmgLcl6q02rjFtyyl8N0zEAKIKu7/+Y= Received: from BN4PR15MB0659.namprd15.prod.outlook.com (10.164.62.145) by BN4PR15MB0612.namprd15.prod.outlook.com (10.164.62.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.18; Fri, 10 Aug 2018 18:26:40 +0000 Received: from BN4PR15MB0659.namprd15.prod.outlook.com ([fe80::40a4:f346:33b:a959]) by BN4PR15MB0659.namprd15.prod.outlook.com ([fe80::40a4:f346:33b:a959%2]) with mapi id 15.20.1038.023; Fri, 10 Aug 2018 18:26:40 +0000 From: Luca Niccolini To: Ryan Hamilton , IETF QUIC WG Subject: Re: Can we simplify SETTINGS? Thread-Topic: Can we simplify SETTINGS? Thread-Index: AQHUMNUgnX/hMrcAtUWJO7JMvvK4daS42FiA Date: Fri, 10 Aug 2018 18:26:39 +0000 Message-ID: <1BB9EC7D-FDF2-40CD-B198-D4E8972C6629@fb.com> References: 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::7:cd6d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN4PR15MB0612; 20:EMPtiNNXKoPvKNLLU1868PY7dvbELNsrTBI/CekGI/kDq0CqQ1h++hJQtXdlCuOvcY+CEGTQoq4lA/dghGG+3GVS7omQ/YxWxriTuEq+4aMjiFdM0EzPA72xO/qG8axYpyFdvjIjK/6xZUgjvDNbAVQ9O4JH8j8WTWHiOvRxIrE= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c1cb0aec-aa69-43d9-7479-08d5feeed0bc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BN4PR15MB0612; x-ms-traffictypediagnostic: BN4PR15MB0612: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(11241501184)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BN4PR15MB0612; BCL:0; PCL:0; RULEID:; SRVR:BN4PR15MB0612; x-forefront-prvs: 07607ED19A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(396003)(39860400002)(366004)(199004)(189003)(105586002)(106356001)(5660300001)(46003)(5250100002)(81166006)(76176011)(81156014)(476003)(8676002)(6506007)(186003)(53546011)(102836004)(33656002)(6486002)(83716003)(229853002)(110136005)(486006)(316002)(99286004)(256004)(68736007)(3480700004)(25786009)(6436002)(6512007)(97736004)(236005)(2616005)(11346002)(6116002)(8936002)(6306002)(2906002)(54896002)(7736002)(86362001)(14454004)(446003)(82746002)(966005)(2900100001)(606006)(478600001)(6246003)(36756003)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN4PR15MB0612; H:BN4PR15MB0659.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1qWE6ItRFCmpDdLQ+57IhH9OTUdsBfxfvHWFekXD45MR7ffJJDuXpuNbgnocd17KFr0LFdJhr2IO0t0oVcXdqXLfDMVZw1yc+qXY/ixnHyrf4bt3yu7Mh1uAQRcZzrEdaCvsNqISmke9LATTfDBuenQDxwIuC3seP5AiHDpW3bIu74fA8UcoFRKj3bf3QCXFkoGRfgYS9NVNejeJEcWBNjCSpLm78nba03OkuS01ALJQ4IqUm7U/ZpRjXQ7pl4ui+YV5psFbe8ppWm/qktboPZZWniJCUafxMBMh6VI4UCeDZRk/Y3MsgpQbNZb+EK8ai9NPoPjLigCQdrZpRXcocA8GpTv3Vp9Rw2chV/flc/o= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_1BB9EC7DFDF240CDB198D4E8972C6629fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c1cb0aec-aa69-43d9-7479-08d5feeed0bc X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2018 18:26:39.9215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN4PR15MB0612 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-10_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 18:27:05 -0000 --_000_1BB9EC7DFDF240CDB198D4E8972C6629fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UnlhbiwNCg0KdGhlcmUgaXMgYW4gb3BlbiBpc3N1ZSBhYm91dCB0aGlzIGFuZCBkaXNjdXNzaW9u IG9uZ29pbmcgb24gR2l0aHViDQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRz L2lzc3Vlcy8xNTU2DQoNCkFsbG93aW5nIGFyYml0cmFyeSBkYXRhIHRvIGJlIGNhcnJpZWQgYnkg YW4gZXh0ZW5zaW9uIGZyYW1lcyBlbmFibGVkIHZpYSBzaW1wbGVyIHNldHRpbmdzIGlzIG9uZSBv ZiB0aGUgcHJvcG9zZWQgYWx0ZXJuYXRpdmVzLg0KDQpDaGVlcnMsDQpMdWNhDQoNCkZyb206IFFV SUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJ5YW4gSGFtaWx0b24gPHJj aD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBGcmlkYXksIEF1Z3VzdCAxMCwg MjAxOCBhdCAxMTowOCBBTQ0KVG86IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1Ympl Y3Q6IENhbiB3ZSBzaW1wbGlmeSBTRVRUSU5HUz8NCg0KSG93ZHksDQoNClRoZSBTRVRUSU5HUyBm cmFtZSBmb3JtYXQgaXMgZXh0cmVtZWx5IGZsZXhpYmxlLiBXaGlsZSB0aGUgaWRlbnRpZmllcnMg KGtleXMpIGFyZSB1aW50MTZzICh0aG91Z2ggbm90IGVuY29kZWQgYXMgYSB2YXJpbnQgZXZlbiB0 aG91Z2ggbW9zdC9hbGwgaWRlbnRpZmllcnMgY291bGQgYmUgdmFyaW50IGVuY29kZWQgYXMgYSBz aW5nbGUgYnl0ZSksIHRoZSBjb250ZW50cyAodmFsdWVzKSBhcmUsIG9uIHRoZSB3aXJlLCBzZXF1 ZW5jZXMgb2YgYnl0ZXMgb2YgYXJiaXRyYXJ5IGxlbmd0aC4gKElzIGl0IGxlZ2FsL2Rlc2lyYWJs ZSB0byBwZXJtaXQgYSBwZWVyIHRvIHNlbmQgYSAxR0Igc2V0dGluZyBjb250ZW50cz8pIEJ1dCBt b3JlIHRoYW4gdGhhdCBpbiBzb21lIGNhc2VzIHRoZXkgYXJlIGJvb2xlYW5zICh0cnVlIGlmIHRo ZSBjb250ZW50IGlzIGVtcHR5LCBmYWxzZSBpZiB0aGUgaWRlbnRpZmllciBpcyBtaXNzaW5nPyEp LiBUaGlzIGlzIHF1aXRlIGEgZ2VuZXJhbCBwdXJwb3NlIHJlcHJlc2VudGF0aW9uLg0KDQpCdXQg Y3VyaW91c2x5LCB0aGVyZSBhcmUgb25seSB0d28gZGVmaW5lZCBTRVRUSU5HUyBhbmQgdGhleSBh cmUgYm90aCBpbnRlZ2Vycy4NCg0KU2luY2UgSFRUUC9RVUlDIG9ubHkgbmVlZHMgdHdvIG51bWVy aWMgc2V0dGluZ3MsIGl0IHNlZW1zIGxpa2Ugd2UgY291bGQganVzdCBkZWZpbmUgdGhlIHNldHRp bmdzIGZyYW1lIHRvIGJlIGEgc2VxdWVuY2Ugb2YgcGFpcnMgb2YgdmFyaW50cyAod2hpbGUgc3Rp bGwgYWxsb3dpbmcgZ3JlYXNlZCBpZGVudGlmaWVycywgb2YgY291cnNlKS4gSXQgc2VlbXMgbGlr ZSB0aGF0IHdvdWxkIGJlIG11Y2ggc2ltcGxlciBhbmQgd291bGQgbm90IHJlYWxseSBjb3N0IHVz IGFueXRoaW5nLiBCdXQgcGVyaGFwcyB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBwcmV2aW91c2x5 IGFuZCB0aGVyZSdzIGEgdXNlIGNhc2UgSSdtIG5vdCB0aGlua2luZyBhYm91dCwgb3IgcGVyaGFw cyB3ZSBoYXZlIGEgbG9uZ2VyIGxpc3Qgb2Ygc2V0dGluZ3MgdGhhdCB3ZSdyZSBwbGFubmluZyB0 byBhZGQgdG8gdGhpcyBsaXN0IGJlZm9yZSB3ZSAiZmluaXNoIiB2MT8NCg0KSSBjYW4gd2VsbCBp bWFnaW5nIGFidXNpbmcsIHNvcnJ5IEkgbWVhbiB1c2luZywgYSBTRVRUSU5HUyBmcmFtZSB0byBj YXJyeSBhbGwgc29ydHMgb2YgaW50ZXJlc3RpbmcgZGF0YSBvZiB2YXJpb3VzIHR5cGVzLiBCdXQg c3VjaCBkYXRhIGNvdWxkICJqdXN0IGFzIGVhc2lseSIodG0pIGJlIGNhcnJpZWQgaW4gc29tZSBh cHBsaWNhdGlvbi1zcGVjaWZpYyBmcmFtZSB0eXBlLg0KDQpDaGVlcnMsDQoNClJ5YW4NCg== --_000_1BB9EC7DFDF240CDB198D4E8972C6629fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <23DCB27BDD4F834FBB8822E8C6105CD3@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJ0cmVidWNo ZXQgbXMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SeWFuLCA8YnI+DQo8YnI+DQp0 aGVyZSBpcyBhbiBvcGVuIGlzc3VlIGFib3V0IHRoaXMgYW5kIGRpc2N1c3Npb24gb25nb2luZyBv biBHaXRodWI8YnI+DQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJh ZnRzL2lzc3Vlcy8xNTU2Ij5odHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lz c3Vlcy8xNTU2PC9hPjxicj4NCjxicj4NCkFsbG93aW5nIGFyYml0cmFyeSBkYXRhIHRvIGJlIGNh cnJpZWQgYnkgYW4gZXh0ZW5zaW9uIGZyYW1lcyBlbmFibGVkIHZpYSBzaW1wbGVyIHNldHRpbmdz IGlzIG9uZSBvZiB0aGUgcHJvcG9zZWQgYWx0ZXJuYXRpdmVzLg0KPGJyPg0KPGJyPg0KQ2hlZXJz LDxicj4NCkx1Y2E8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206 IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFV SUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFJ5YW4gSGFtaWx0 b24gJmx0O3JjaD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPkZyaWRheSwgQXVndXN0IDEwLCAyMDE4IGF0IDExOjA4IEFNPGJyPg0KPGI+VG86IDwvYj5J RVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPkNh biB3ZSBzaW1wbGlmeSBTRVRUSU5HUz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7dHJlYnVjaGV0IG1zJnF1b3Q7LHNhbnMtc2VyaWYiPkhvd2R5LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDt0cmVidWNoZXQgbXMmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O3RyZWJ1Y2hldCBtcyZxdW90Oyxz YW5zLXNlcmlmIj5UaGUgU0VUVElOR1MgZnJhbWUgZm9ybWF0IGlzIGV4dHJlbWVseSBmbGV4aWJs ZS4gV2hpbGUgdGhlIGlkZW50aWZpZXJzIChrZXlzKSBhcmUgdWludDE2cyAodGhvdWdoIG5vdCBl bmNvZGVkIGFzIGEgdmFyaW50IGV2ZW4gdGhvdWdoIG1vc3QvYWxsIGlkZW50aWZpZXJzIGNvdWxk IGJlIHZhcmludCBlbmNvZGVkIGFzIGENCiBzaW5nbGUgYnl0ZSksIHRoZSBjb250ZW50cyAodmFs dWVzKSBhcmUsIG9uIHRoZSB3aXJlLCBzZXF1ZW5jZXMgb2YgYnl0ZXMgb2YgYXJiaXRyYXJ5IGxl bmd0aC4gKElzIGl0IGxlZ2FsL2Rlc2lyYWJsZSB0byBwZXJtaXQgYSBwZWVyIHRvIHNlbmQgYSAx R0Igc2V0dGluZyBjb250ZW50cz8pIEJ1dCBtb3JlIHRoYW4gdGhhdCBpbiBzb21lIGNhc2VzIHRo ZXkgYXJlIGJvb2xlYW5zICh0cnVlIGlmIHRoZSBjb250ZW50IGlzIGVtcHR5LCBmYWxzZSBpZg0K IHRoZSBpZGVudGlmaWVyIGlzIG1pc3Npbmc/ISkuIFRoaXMgaXMgcXVpdGUgYSBnZW5lcmFsIHB1 cnBvc2UgcmVwcmVzZW50YXRpb24uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O3RyZWJ1Y2hldCBtcyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7dHJlYnVjaGV0IG1zJnF1b3Q7LHNhbnMtc2VyaWYiPkJ1dCBjdXJp b3VzbHksIHRoZXJlIGFyZSBvbmx5IHR3byBkZWZpbmVkIFNFVFRJTkdTIGFuZCB0aGV5IGFyZSBi b3RoIGludGVnZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDt0cmVidWNoZXQg bXMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O3RyZWJ1Y2hldCBtcyZxdW90OyxzYW5zLXNlcmlm Ij5TaW5jZSBIVFRQL1FVSUMgb25seSBuZWVkcyB0d28gbnVtZXJpYyBzZXR0aW5ncywgaXQgc2Vl bXMgbGlrZSB3ZSBjb3VsZCBqdXN0IGRlZmluZSB0aGUgc2V0dGluZ3MgZnJhbWUgdG8gYmUgYSBz ZXF1ZW5jZSBvZiBwYWlycyBvZiB2YXJpbnRzICh3aGlsZSBzdGlsbCBhbGxvd2luZyBncmVhc2Vk DQogaWRlbnRpZmllcnMsIG9mIGNvdXJzZSkuIEl0IHNlZW1zIGxpa2UgdGhhdCB3b3VsZCBiZSBt dWNoIHNpbXBsZXIgYW5kIHdvdWxkIG5vdCByZWFsbHkgY29zdCB1cyBhbnl0aGluZy4gQnV0IHBl cmhhcHMgdGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgcHJldmlvdXNseSBhbmQgdGhlcmUncyBhIHVz ZSBjYXNlIEknbSBub3QgdGhpbmtpbmcgYWJvdXQsIG9yIHBlcmhhcHMgd2UgaGF2ZSBhIGxvbmdl ciBsaXN0IG9mIHNldHRpbmdzIHRoYXQgd2UncmUgcGxhbm5pbmcNCiB0byBhZGQgdG8gdGhpcyBs aXN0IGJlZm9yZSB3ZSAmcXVvdDtmaW5pc2gmcXVvdDsgdjE/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7dHJlYnVjaGV0IG1zJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkkgY2FuIHdlbGwgaW1h Z2luZyBhYnVzaW5nLCBzb3JyeSBJIG1lYW4gdXNpbmcsIGEgU0VUVElOR1MgZnJhbWUgdG8gY2Fy cnkgYWxsIHNvcnRzIG9mIGludGVyZXN0aW5nIGRhdGEgb2YgdmFyaW91cyB0eXBlcy4gQnV0IHN1 Y2ggZGF0YSBjb3VsZCAmcXVvdDtqdXN0IGFzIGVhc2lseSZxdW90Oyh0bSkgYmUgY2FycmllZCBp biBzb21lIGFwcGxpY2F0aW9uLXNwZWNpZmljIGZyYW1lIHR5cGUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O3RyZWJ1Y2hldCBtcyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7dHJlYnVjaGV0IG1zJnF1b3Q7LHNhbnMtc2Vy aWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7dHJlYnVjaGV0IG1z JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDt0cmVidWNoZXQgbXMmcXVvdDssc2Fucy1zZXJpZiI+UnlhbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1BB9EC7DFDF240CDB198D4E8972C6629fbcom_-- From nobody Fri Aug 10 13:58:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE0D130ED2 for ; Fri, 10 Aug 2018 13:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTGXl0Y-owVg for ; Fri, 10 Aug 2018 13:58:01 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4d::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19712130E41 for ; Fri, 10 Aug 2018 13:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oSQJbI/s9kExDarylHmp84qruxfE44yA890OXPr+qZg=; b=BWb6ZCnev6/TNHzgIyT+WEDPj/WeBosCFys2+uKnLUKPVM5m8lpLriblvojkTj3LZkHXZvH0hE8viGwcbA7Rx9wTFZK9taRCL1Oh+VoqjpOvefRTO2n1BT8rjZP+dI+8fV9d+lBqZjMUwxahpDNRt4hbj0Hiy6DdKJSDfq+boOw= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB5029.namprd08.prod.outlook.com (20.177.125.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.19; Fri, 10 Aug 2018 20:57:57 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::913f:4f09:ae22:b6db]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::913f:4f09:ae22:b6db%5]) with mapi id 15.20.1038.019; Fri, 10 Aug 2018 20:57:57 +0000 From: Mike Bishop To: Luca Niccolini , Ryan Hamilton , IETF QUIC WG Subject: RE: Can we simplify SETTINGS? Thread-Topic: Can we simplify SETTINGS? Thread-Index: AQHUMNUDeD/A/VJrFkuYqVi/TTATy6S5TbGAgAAn5QA= Date: Fri, 10 Aug 2018 20:57:57 +0000 Message-ID: References: <1BB9EC7D-FDF2-40CD-B198-D4E8972C6629@fb.com> In-Reply-To: <1BB9EC7D-FDF2-40CD-B198-D4E8972C6629@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB5029; 6:jT0wwP5oDwjF8Ue/3rjoA4v33RVl0+s180i/yUTWo+LweDmUn+o+LdxYZUpOb7Qui6BkRkE8RcxPXeIuebUlIxqx1uRZuIhzHXJSaecFOlLye6tiUOr8r0uivFZBb/2bcarvdNXpYFob5aigjA3+qEf97e9AXUyQA3kuq9M2/MPYdATj7f11AvdoeEV5MTyRnCQvEjOiKE9Ql+/twZOglWYx8bJs1thvBLeJ+xwpvS6x+txoa9XypLzN4ncqx7lY7x23rDJCCEiOojvzTukCdIfQvAPzgrIwSjv5Va8lmXz/HdCboGtnHM6+gfgfuck4IEYMZqIARPiQTSEkWZ1tBKZKclfex2R7oL82ioiJyzmPssdj3k/x68NuN4aJdw9cxfvXb9LGT7JrSrlBAfsJmOePUO6JuSTqRC5e6L55d8ecXbEq/TXG5jdlh+9e7IQZQfFWBB4Mnji6uYjllaJEow==; 5:kpmWSOl1D/UJ9yji7FRpYn6s6VKQDi062bw86lUePp/virR0nAtnebSNZ8WzzVi8E4HvJ4rEf/punr/VcQv2sTLQk4OqI2eDlkRYisC6K2Y17wDiixLroY7B/6L9By7FXJxjaovCY58x0O8SWblOFLE7wythi/PWMSnGC2ZiR6I=; 7:WlkVwk4ydjzDqXLlXkyRD9I9g1wPyZxDTO9ZxCH9Sy8Ha+VKrcoEBNjKMwAZ+rlYNzPV2h14adJXy4wn8VHYy+WC07JPNm0nW/dw6EykbnADbrSLAUkikl0rsoiSt50MbASI/G7a2o10GSTNzFczqgh68cJ3x/6tqqkMhKVG+9rDgWawL/T05v27beHms/is/AhFiCgiuvsB7uMA78EP7NQy8y0OR5mLZ3w3ivdyO7RunuXz3vaPe2djJWnQ1VkS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e7092820-ff48-4257-4129-08d5ff03f33e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600074)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB5029; x-ms-traffictypediagnostic: BYAPR08MB5029: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(166708455590820)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(2016111802025)(20161123562045)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB5029; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB5029; x-forefront-prvs: 07607ED19A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39830400003)(366004)(346002)(136003)(396003)(199004)(189003)(7696005)(6116002)(6306002)(76176011)(54896002)(6436002)(236005)(53936002)(33656002)(26005)(97736004)(561944003)(606006)(55016002)(229853002)(74316002)(5660300001)(316002)(110136005)(9686003)(7736002)(790700001)(2900100001)(3846002)(106356001)(25786009)(102836004)(99286004)(105586002)(53546011)(8676002)(81156014)(81166006)(6246003)(66066001)(74482002)(11346002)(6506007)(476003)(446003)(14454004)(2906002)(256004)(3480700004)(8936002)(486006)(186003)(68736007)(478600001)(86362001)(966005)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB5029; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: xRU0rn/3DkUGY6O00HFr0JdFS2WhgH4jkMNf0rVM+IvAJi8OgYUd6RP2fIUYnb8jC3Tyj1v/UYA41a6nJEZHJnXDwUm+IOVFbqyDwOmMvSLQqBuDS/DGrWbSk5w7N95qyhE2Fsp2tZZLjd/zjwvWDR91IDgVDBU5tjxdxiz1+bbU0kKRrOfUG/76HMx7cPqy1tLLgLTdP2ooF/OVGnSKw5tJAO/xiKAKiJhVBdFLQ0Ep/3POkYEGb9n9m8Ma/AYB+CLcEOHDz7ExUEjPAszHYCi/kLFmwJgRgYEh++nHWYLVZhno3j8iKD88SZ7LH27NYXcJ6TG61WbVYkEcFSHIGPyk8FuGLmpzMh68lCYZWzI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB39442EB1F04B4DE3039CBB67DA240BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: e7092820-ff48-4257-4129-08d5ff03f33e X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2018 20:57:57.2315 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB5029 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 20:58:04 -0000 --_000_BYAPR08MB39442EB1F04B4DE3039CBB67DA240BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNob3J0IGZvcm0gaXMgdGhhdCB0aGUgdmVyeSBmbGV4aWJsZSBmb3JtYXQgcHJvcG9zYWwg KG1pbmUsIGZ1bGwgZGlzY2xvc3VyZSkgY2FtZSBvdXQgb2YgdHdvIG9ic2VydmF0aW9uczoNCg0K ICAqICAgSDIgZXh0ZW5zaW9ucyB3aGljaCBtb2RpZnkgc2VtYW50aWNzIG5lZWQgYSBCb29sZWFu IG9uL29mZiBpbmRpY2F0b3IgZm9yIHN1cHBvcnQuICBUaGUgY29yZSBzcGVjIGRvZXNu4oCZdCBu ZWVkIHRoaXMsIGJ1dCBleHRlbnNpb25zIGFyZSBleHBlY3RlZCB0byB0eXBpY2FsbHkgYmUgMC8x Lg0KICAqICAgVGhlIG9yaWdpbmFsIGluY2FybmF0aW9uIG9mIFNlY29uZGFyeSBDZXJ0aWZpY2F0 ZXMgd2FzIHRyeWluZyB0byB0cmFuc2ZlciBzb21lIGZhaXJseSBjb21wbGV4IGluZm9ybWF0aW9u IGluIFNFVFRJTkdTLCBhbmQgdHJ5aW5nIHRvIGNvZXJjZSB0aGF0IGludG8gYSBmaXhlZCBpbnRl Z2VyIHdhcyBwcm9ibGVtYXRpYy4gIFRoZSBvcmlnaW5hbCBwbGFuIHdhcyB0byBoYXZlIGEgcmVn aXN0cnktY29udHJvbGxlZCBiaXRtYXAsIGluIHRoZSBhYnNlbmNlIG9mIHN0cnVjdHVyZWQgc2V0 dGluZ3MuICAoSWNrISkgIEluc3RlYWQsIHdl4oCZdmUgc2hvdmVkIHRoYXQgY29tcGxleGl0eSBp bnRvIFRMUyB2aWEgRXhwb3J0ZWQgQXV0aGVudGljYXRvcnMuDQoNCk5vdywgd2lsbCBib3RoIG9m IHRoZXNlIGJlIGFwcGxpY2FibGUgdG8gSFE/ICBJIGRvbuKAmXQga25vdy4gIE1vc3QgSDIgZXh0 ZW5zaW9ucywgYnV0IG5vdCBhbGwsIGhhdmUgbm90IGJlZW4gc2VtYW50aWNhbGx5IGJyZWFraW5n IGFuZCBzbyBkb27igJl0IG5lZWQgYW4gb24vb2ZmIHNldHRpbmcuICBObyBvbmUgaGFzIHlldCBi dWlsdCBhbiBleHRlbnNpb24gdGhhdCBjb3VsZG7igJl0IGJlIGRvbmUgd2l0aG91dCB0aGUgc3Ry dWN0dXJlZCBzZXR0aW5ncy4NCg0KVGhlcmXigJlzIGRlZmluaXRlbHkgdmFsdWUgaW4gaGF2aW5n IHRoZSBmbGV4aWJpbGl0eSDigJMgSSBqdXN0IGRvbuKAmXQgaGF2ZSBhIGdvb2QgZmVlbCBmb3Ig dGhlIHRyYWRlLW9mZiBiZXR3ZWVuIHRoZSBjb21wbGV4aXR5IGFuZCB0aGUgYXBwbGljYXRpb25z IHdlIGRvbuKAmXQga25vdyBhYm91dCB5ZXQuDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIEx1Y2EgTmljY29saW5pDQpTZW50OiBGcmlkYXksIEF1Z3Vz dCAxMCwgMjAxOCAxMToyNyBBTQ0KVG86IFJ5YW4gSGFtaWx0b24gPHJjaD00MGdvb2dsZS5jb21A ZG1hcmMuaWV0Zi5vcmc+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogQ2FuIHdlIHNpbXBsaWZ5IFNFVFRJTkdTPw0KDQpSeWFuLA0KDQp0aGVyZSBpcyBhbiBvcGVu IGlzc3VlIGFib3V0IHRoaXMgYW5kIGRpc2N1c3Npb24gb25nb2luZyBvbiBHaXRodWINCmh0dHBz Oi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzE1NTYNCg0KQWxsb3dpbmcg YXJiaXRyYXJ5IGRhdGEgdG8gYmUgY2FycmllZCBieSBhbiBleHRlbnNpb24gZnJhbWVzIGVuYWJs ZWQgdmlhIHNpbXBsZXIgc2V0dGluZ3MgaXMgb25lIG9mIHRoZSBwcm9wb3NlZCBhbHRlcm5hdGl2 ZXMuDQoNCkNoZWVycywNCkx1Y2ENCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgUnlhbiBIYW1pbHRv biA8cmNoPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cmNoPTQwZ29vZ2xlLmNv bUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBGcmlkYXksIEF1Z3VzdCAxMCwgMjAxOCBhdCAxMTow OCBBTQ0KVG86IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBDYW4gd2Ugc2ltcGxpZnkgU0VUVElOR1M/DQoNCkhvd2R5LA0KDQpUaGUg U0VUVElOR1MgZnJhbWUgZm9ybWF0IGlzIGV4dHJlbWVseSBmbGV4aWJsZS4gV2hpbGUgdGhlIGlk ZW50aWZpZXJzIChrZXlzKSBhcmUgdWludDE2cyAodGhvdWdoIG5vdCBlbmNvZGVkIGFzIGEgdmFy aW50IGV2ZW4gdGhvdWdoIG1vc3QvYWxsIGlkZW50aWZpZXJzIGNvdWxkIGJlIHZhcmludCBlbmNv ZGVkIGFzIGEgc2luZ2xlIGJ5dGUpLCB0aGUgY29udGVudHMgKHZhbHVlcykgYXJlLCBvbiB0aGUg d2lyZSwgc2VxdWVuY2VzIG9mIGJ5dGVzIG9mIGFyYml0cmFyeSBsZW5ndGguIChJcyBpdCBsZWdh bC9kZXNpcmFibGUgdG8gcGVybWl0IGEgcGVlciB0byBzZW5kIGEgMUdCIHNldHRpbmcgY29udGVu dHM/KSBCdXQgbW9yZSB0aGFuIHRoYXQgaW4gc29tZSBjYXNlcyB0aGV5IGFyZSBib29sZWFucyAo dHJ1ZSBpZiB0aGUgY29udGVudCBpcyBlbXB0eSwgZmFsc2UgaWYgdGhlIGlkZW50aWZpZXIgaXMg bWlzc2luZz8hKS4gVGhpcyBpcyBxdWl0ZSBhIGdlbmVyYWwgcHVycG9zZSByZXByZXNlbnRhdGlv bi4NCg0KQnV0IGN1cmlvdXNseSwgdGhlcmUgYXJlIG9ubHkgdHdvIGRlZmluZWQgU0VUVElOR1Mg YW5kIHRoZXkgYXJlIGJvdGggaW50ZWdlcnMuDQoNClNpbmNlIEhUVFAvUVVJQyBvbmx5IG5lZWRz IHR3byBudW1lcmljIHNldHRpbmdzLCBpdCBzZWVtcyBsaWtlIHdlIGNvdWxkIGp1c3QgZGVmaW5l IHRoZSBzZXR0aW5ncyBmcmFtZSB0byBiZSBhIHNlcXVlbmNlIG9mIHBhaXJzIG9mIHZhcmludHMg KHdoaWxlIHN0aWxsIGFsbG93aW5nIGdyZWFzZWQgaWRlbnRpZmllcnMsIG9mIGNvdXJzZSkuIEl0 IHNlZW1zIGxpa2UgdGhhdCB3b3VsZCBiZSBtdWNoIHNpbXBsZXIgYW5kIHdvdWxkIG5vdCByZWFs bHkgY29zdCB1cyBhbnl0aGluZy4gQnV0IHBlcmhhcHMgdGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQg cHJldmlvdXNseSBhbmQgdGhlcmUncyBhIHVzZSBjYXNlIEknbSBub3QgdGhpbmtpbmcgYWJvdXQs IG9yIHBlcmhhcHMgd2UgaGF2ZSBhIGxvbmdlciBsaXN0IG9mIHNldHRpbmdzIHRoYXQgd2UncmUg cGxhbm5pbmcgdG8gYWRkIHRvIHRoaXMgbGlzdCBiZWZvcmUgd2UgImZpbmlzaCIgdjE/DQoNCkkg Y2FuIHdlbGwgaW1hZ2luZyBhYnVzaW5nLCBzb3JyeSBJIG1lYW4gdXNpbmcsIGEgU0VUVElOR1Mg ZnJhbWUgdG8gY2FycnkgYWxsIHNvcnRzIG9mIGludGVyZXN0aW5nIGRhdGEgb2YgdmFyaW91cyB0 eXBlcy4gQnV0IHN1Y2ggZGF0YSBjb3VsZCAianVzdCBhcyBlYXNpbHkiKHRtKSBiZSBjYXJyaWVk IGluIHNvbWUgYXBwbGljYXRpb24tc3BlY2lmaWMgZnJhbWUgdHlwZS4NCg0KQ2hlZXJzLA0KDQpS eWFuDQo= --_000_BYAPR08MB39442EB1F04B4DE3039CBB67DA240BYAPR08MB3944namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2lu LWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4NDY5NDI5OTY7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00NjUxNzI4NjggNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgc2hvcnQgZm9ybSBpcyB0aGF0IHRoZSB2ZXJ5IGZsZXhpYmxlIGZvcm1hdCBwcm9wb3NhbCAo bWluZSwgZnVsbCBkaXNjbG9zdXJlKSBjYW1lIG91dCBvZiB0d28gb2JzZXJ2YXRpb25zOjxvOnA+ PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPkgyIGV4dGVuc2lvbnMgd2hpY2ggbW9kaWZ5IHNlbWFudGljcyBuZWVk IGEgQm9vbGVhbiBvbi9vZmYgaW5kaWNhdG9yIGZvciBzdXBwb3J0LiZuYnNwOyBUaGUgY29yZSBz cGVjIGRvZXNu4oCZdCBuZWVkIHRoaXMsIGJ1dCBleHRlbnNpb25zIGFyZSBleHBlY3RlZCB0byB0 eXBpY2FsbHkgYmUgMC8xLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlRoZSBv cmlnaW5hbCBpbmNhcm5hdGlvbiBvZiBTZWNvbmRhcnkgQ2VydGlmaWNhdGVzIHdhcyB0cnlpbmcg dG8gdHJhbnNmZXIgc29tZSBmYWlybHkgY29tcGxleCBpbmZvcm1hdGlvbiBpbiBTRVRUSU5HUywg YW5kIHRyeWluZyB0byBjb2VyY2UgdGhhdCBpbnRvIGEgZml4ZWQgaW50ZWdlciB3YXMgcHJvYmxl bWF0aWMuJm5ic3A7DQogVGhlIG9yaWdpbmFsIHBsYW4gd2FzIHRvIGhhdmUgYSByZWdpc3RyeS1j b250cm9sbGVkIGJpdG1hcCwgaW4gdGhlIGFic2VuY2Ugb2Ygc3RydWN0dXJlZCBzZXR0aW5ncy4m bmJzcDsgKEljayEpJm5ic3A7IEluc3RlYWQsIHdl4oCZdmUgc2hvdmVkIHRoYXQgY29tcGxleGl0 eSBpbnRvIFRMUyB2aWEgRXhwb3J0ZWQgQXV0aGVudGljYXRvcnMuPG86cD48L286cD48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk5vdywgd2lsbCBib3RoIG9mIHRoZXNlIGJlIGFwcGxpY2FibGUgdG8gSFE/ Jm5ic3A7IEkgZG9u4oCZdCBrbm93LiZuYnNwOyBNb3N0IEgyIGV4dGVuc2lvbnMsIGJ1dCBub3Qg YWxsLCBoYXZlIG5vdCBiZWVuIHNlbWFudGljYWxseSBicmVha2luZyBhbmQgc28gZG9u4oCZdCBu ZWVkIGFuIG9uL29mZiBzZXR0aW5nLiZuYnNwOyBObyBvbmUgaGFzIHlldCBidWlsdCBhbiBleHRl bnNpb24gdGhhdCBjb3VsZG7igJl0IGJlIGRvbmUgd2l0aG91dCB0aGUNCiBzdHJ1Y3R1cmVkIHNl dHRpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZeKAmXMgZGVmaW5pdGVseSB2YWx1 ZSBpbiBoYXZpbmcgdGhlIGZsZXhpYmlsaXR5IOKAkyBJIGp1c3QgZG9u4oCZdCBoYXZlIGEgZ29v ZCBmZWVsIGZvciB0aGUgdHJhZGUtb2ZmIGJldHdlZW4gdGhlIGNvbXBsZXhpdHkgYW5kIHRoZSBh cHBsaWNhdGlvbnMgd2UgZG9u4oCZdCBrbm93IGFib3V0IHlldC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlD ICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpMdWNh IE5pY2NvbGluaTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEF1Z3VzdCAxMCwgMjAxOCAxMToy NyBBTTxicj4NCjxiPlRvOjwvYj4gUnlhbiBIYW1pbHRvbiAmbHQ7cmNoPTQwZ29vZ2xlLmNvbUBk bWFyYy5pZXRmLm9yZyZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IENhbiB3ZSBzaW1wbGlmeSBTRVRUSU5HUz88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJ5YW4sIDxicj4NCjxicj4NCnRoZXJlIGlz IGFuIG9wZW4gaXNzdWUgYWJvdXQgdGhpcyBhbmQgZGlzY3Vzc2lvbiBvbmdvaW5nIG9uIEdpdGh1 Yjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNz dWVzLzE1NTYiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzE1 NTY8L2E+PGJyPg0KPGJyPg0KQWxsb3dpbmcgYXJiaXRyYXJ5IGRhdGEgdG8gYmUgY2FycmllZCBi eSBhbiBleHRlbnNpb24gZnJhbWVzIGVuYWJsZWQgdmlhIHNpbXBsZXIgc2V0dGluZ3MgaXMgb25l IG9mIHRoZSBwcm9wb3NlZCBhbHRlcm5hdGl2ZXMuDQo8YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0K THVjYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UVVJQyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGlldGYu b3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFJ5YW4gSGFtaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0 bzpyY2g9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIj5yY2g9NDBnb29nbGUuY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBBdWd1c3QgMTAsIDIw MTggYXQgMTE6MDggQU08YnI+DQo8Yj5UbzogPC9iPklFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6IDwvYj5DYW4gd2Ugc2ltcGxpZnkgU0VUVElOR1M/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5Ib3dkeSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssc2Fucy1zZXJpZiI+VGhlIFNFVFRJTkdTIGZyYW1lIGZvcm1hdCBpcyBleHRyZW1l bHkgZmxleGlibGUuIFdoaWxlIHRoZSBpZGVudGlmaWVycyAoa2V5cykgYXJlIHVpbnQxNnMgKHRo b3VnaCBub3QgZW5jb2RlZCBhcyBhIHZhcmludCBldmVuIHRob3VnaCBtb3N0L2FsbCBpZGVudGlm aWVycyBjb3VsZCBiZSB2YXJpbnQgZW5jb2RlZCBhcyBhDQogc2luZ2xlIGJ5dGUpLCB0aGUgY29u dGVudHMgKHZhbHVlcykgYXJlLCBvbiB0aGUgd2lyZSwgc2VxdWVuY2VzIG9mIGJ5dGVzIG9mIGFy Yml0cmFyeSBsZW5ndGguIChJcyBpdCBsZWdhbC9kZXNpcmFibGUgdG8gcGVybWl0IGEgcGVlciB0 byBzZW5kIGEgMUdCIHNldHRpbmcgY29udGVudHM/KSBCdXQgbW9yZSB0aGFuIHRoYXQgaW4gc29t ZSBjYXNlcyB0aGV5IGFyZSBib29sZWFucyAodHJ1ZSBpZiB0aGUgY29udGVudCBpcyBlbXB0eSwg ZmFsc2UgaWYNCiB0aGUgaWRlbnRpZmllciBpcyBtaXNzaW5nPyEpLiBUaGlzIGlzIHF1aXRlIGEg Z2VuZXJhbCBwdXJwb3NlIHJlcHJlc2VudGF0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlm Ij5CdXQgY3VyaW91c2x5LCB0aGVyZSBhcmUgb25seSB0d28gZGVmaW5lZCBTRVRUSU5HUyBhbmQg dGhleSBhcmUgYm90aCBpbnRlZ2Vycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDss c2Fucy1zZXJpZiI+U2luY2UgSFRUUC9RVUlDIG9ubHkgbmVlZHMgdHdvIG51bWVyaWMgc2V0dGlu Z3MsIGl0IHNlZW1zIGxpa2Ugd2UgY291bGQganVzdCBkZWZpbmUgdGhlIHNldHRpbmdzIGZyYW1l IHRvIGJlIGEgc2VxdWVuY2Ugb2YgcGFpcnMgb2YgdmFyaW50cyAod2hpbGUgc3RpbGwgYWxsb3dp bmcgZ3JlYXNlZA0KIGlkZW50aWZpZXJzLCBvZiBjb3Vyc2UpLiBJdCBzZWVtcyBsaWtlIHRoYXQg d291bGQgYmUgbXVjaCBzaW1wbGVyIGFuZCB3b3VsZCBub3QgcmVhbGx5IGNvc3QgdXMgYW55dGhp bmcuIEJ1dCBwZXJoYXBzIHRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIHByZXZpb3VzbHkgYW5kIHRo ZXJlJ3MgYSB1c2UgY2FzZSBJJ20gbm90IHRoaW5raW5nIGFib3V0LCBvciBwZXJoYXBzIHdlIGhh dmUgYSBsb25nZXIgbGlzdCBvZiBzZXR0aW5ncyB0aGF0IHdlJ3JlIHBsYW5uaW5nDQogdG8gYWRk IHRvIHRoaXMgbGlzdCBiZWZvcmUgd2UgJnF1b3Q7ZmluaXNoJnF1b3Q7IHYxPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpJIGNh biB3ZWxsIGltYWdpbmcgYWJ1c2luZywgc29ycnkgSSBtZWFuIHVzaW5nLCBhIFNFVFRJTkdTIGZy YW1lIHRvIGNhcnJ5IGFsbCBzb3J0cyBvZiBpbnRlcmVzdGluZyBkYXRhIG9mIHZhcmlvdXMgdHlw ZXMuIEJ1dCBzdWNoIGRhdGEgY291bGQgJnF1b3Q7anVzdCBhcyBlYXNpbHkmcXVvdDsodG0pIGJl IGNhcnJpZWQgaW4gc29tZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBmcmFtZSB0eXBlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90 OyxzYW5zLXNlcmlmIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Ry ZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPlJ5YW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BYAPR08MB39442EB1F04B4DE3039CBB67DA240BYAPR08MB3944namp_-- From nobody Sat Aug 11 17:45:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131AF130DC3 for ; Sat, 11 Aug 2018 17:45: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, 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=mnot.net header.b=R/vgkeEZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MhsyO/rx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COlti2DewsR7 for ; Sat, 11 Aug 2018 17:45:22 -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 4DDD71277CC for ; Sat, 11 Aug 2018 17:45:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 707F621144 for ; Sat, 11 Aug 2018 20:45:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 11 Aug 2018 20:45:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=kTEw4KsTzNrGzT9if yNRnCZpKVbBf1d7gOU0x2aGk8s=; b=R/vgkeEZsKVE9JPreShot1q+RAvO+ixL6 MNFCK9w0cE95X7H7Bc1SOEZ5z8Qx7QlZJT5tzPXzVKIUUSQGYV8jQYLtQD0405ci 04frMwnXTvUDR+kZKemjzxiey5OkEaSkCAVYklmnL4dSoj9TngxsS15pZWcGdphq ihHN7j8Rd+eXQ3mdPqweBwl+XqwrRcWL9Ui34XWp9C3LlFClN7wQhWJiyrNfei59 1rU5xGNkJ2ahnikggu4AKoHZyuUaD/NtaSlD2wk7pwH7PbeQl5ZR7Mx/zONJV61W nQscPVi9dyVGRo700PtZ94qnjkNWY6Me3a5TGp1WjGwGjXC8f2hsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=kTEw4KsTzNrGzT9ifyNRnCZpKVbBf1d7gOU0x2aGk8s=; b=MhsyO/rx b5MDLxv49GXV+YSW3DDDTtvCCgRt27uuQtYIZExvVmllD4gWWNviToL684xUobQW FzrFy4R2xJJJsxEzZFL4OwKohtg0/y9T6xnnjhrQs7lBlEpCEEGoP1OCgv5/xin+ qfpmfQKIQ5gT0Z8QV5U0vpnP2hOjIj2HvizslQTiaF2Nig5FlUKPV6ZtB4kC79gp o7Z151bpc6AxmXtHtQ3HTsAPabjyx++ofO9n/dBbMMEW46+ndiP6Z7b2JiKqHPVF priCGaNxPY0e05iHHm/VGriY6t4lX5lT9cvccasr2spddNGJCtSxGdUSs8TtEQ/U v5IQO+LFmdp0dw== X-ME-Proxy: X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 80B30E4621 for ; Sat, 11 Aug 2018 20:45:20 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id E8831C2601 for ; Sun, 12 Aug 2018 00:45:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============6140041566340378537==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180812004517.E8831C2601@cloud.mnot.net> Date: Sun, 12 Aug 2018 00:45:17 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 00:45:26 -0000 --===============6140041566340378537== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+6/-5/=F0=9F=92=AC53) 6 issues created: - Ordering of crypto stream packets (by huitema) https://github.com/quicwg/base-drafts/issues/1651 = - Subsequent Initial Packets with Token Field (by nibanks) https://github.com/quicwg/base-drafts/issues/1649 = - The server shouldn't use a token for much (by martinthomson) https://github.com/quicwg/base-drafts/issues/1647 [-transport] [design] = - HKDF for handshake secrets (by siyengar) https://github.com/quicwg/base-drafts/issues/1646 = - QPACK improvement: wrap absolute index values (by dtikhonov) https://github.com/quicwg/base-drafts/issues/1644 = - Dead path timeout (by janaiyengar) https://github.com/quicwg/base-drafts/issues/1638 [-transport] [design] = 10 issues received 53 new comments: - #1530 Initial size of dynamic table (15 by mirjak, dtikhonov, martintho= mson, kazuho, MikeBishop) https://github.com/quicwg/base-drafts/issues/1530 [-qpack] [design] = - #1644 QPACK improvement: wrap absolute index values (12 by martinthomso= n, dtikhonov, MikeBishop) https://github.com/quicwg/base-drafts/issues/1644 [-qpack] [design] = - #1570 Connection ID lengths 1, 2 and 3 bytes can't be encoded (11 by ka= zuho, janaiyengar, mikkelfj, MikeBishop, martinthomson, ianswett, ekr) https://github.com/quicwg/base-drafts/issues/1570 [-invariants] [design= ] = - #1638 Dead path timeout (6 by mirjak, martinthomson, janaiyengar, iansw= ett) https://github.com/quicwg/base-drafts/issues/1638 [-transport] [design] = - #1556 HTTP SETTINGS: define setting content encoding (3 by martinthomso= n, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/1556 [-http] [design] [edi= tor-ready] = - #1505 Stateless Reset from clients, bis (2 by martinthomson, MikeBishop) https://github.com/quicwg/base-drafts/issues/1505 [-transport] [design] = - #1600 Indicate support for PRIORITY (1 by rmarx) https://github.com/quicwg/base-drafts/issues/1600 [-http] [design] = - #1482 Extension poster-child (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1482 [-transport] [design]= [parked] = - #1647 The server shouldn't use a token for much (1 by mikkelfj) https://github.com/quicwg/base-drafts/issues/1647 [-transport] [design] = - #1620 CANCEL_PUSH, MAX_PUSH_ID and GOAWAY specify the length of the ID = twice (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1620 [-http] [design] = 5 issues closed: - HTTP SETTINGS and 0-RTT https://github.com/quicwg/base-drafts/issues/15= 41 [-http] [arch] [design] [has-proposal] = - Handling of duplicate packets https://github.com/quicwg/base-drafts/iss= ues/1405 [-transport] [design] = - HKDF for handshake secrets https://github.com/quicwg/base-drafts/issues= /1646 = - Detect adversarial ECN reporting https://github.com/quicwg/base-drafts/= issues/1426 [-transport] [design] = - Stateless Reset Eternal Ping Pong https://github.com/quicwg/base-drafts= /issues/1443 [-transport] [design] = Pull requests ------------- * quicwg/base-drafts (+9/-7/=F0=9F=92=AC13) 9 pull requests submitted: - Start indexing dynamic QPACK table beginning at zero (by dtikhonov) https://github.com/quicwg/base-drafts/pull/1650 = - Add another condition to idle timeout (by siyengar) https://github.com/quicwg/base-drafts/pull/1648 = - Specify behavior on incomplete requests (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1643 [-http] [design] = - Initial table size is the maximum permitted when table is first usable = (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1642 [-qpack] [design] = - Previous SETTINGS MUST be remembered, can't be reduced for 0-RTT (by Mi= keBishop) https://github.com/quicwg/base-drafts/pull/1641 [-http] [design] = - Discuss Application-Limited Sending (by ianswett) https://github.com/quicwg/base-drafts/pull/1637 = - Rules for discarding old keys (by martinthomson) https://github.com/quicwg/base-drafts/pull/1636 [-tls] = - Fix references to the Post-Base Indexing section (by dtikhonov) https://github.com/quicwg/base-drafts/pull/1635 = - Sender/Receiver (by ianswett) https://github.com/quicwg/base-drafts/pull/1634 = 8 pull requests received 13 new comments: - #1637 Discuss Application-Limited Sending (2 by mirjak, janaiyengar) https://github.com/quicwg/base-drafts/pull/1637 [-recovery] = - #1634 Sender/Receiver (2 by martinthomson, ianswett) https://github.com/quicwg/base-drafts/pull/1634 = - #1648 Add another condition to idle timeout (2 by siyengar, martinthoms= on) https://github.com/quicwg/base-drafts/pull/1648 [-transport] [design] = - #1624 Duplicates are dropped (2 by janaiyengar, MikeBishop) https://github.com/quicwg/base-drafts/pull/1624 [-transport] = - #1628 add code points for 1, 2 and 3 byte connection IDs (2 by ekr, ian= swett) https://github.com/quicwg/base-drafts/pull/1628 = - #1641 Previous SETTINGS MUST be remembered, can't be reduced for 0-RTT = (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/1641 [-http] [design] = - #1626 Consequences of bad ECN markings (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1626 [-recovery] = - #1631 Clarify use of the term "supports ECN" (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/1631 [-transport] = 7 pull requests merged: - Previous SETTINGS MUST be remembered, can't be reduced for 0-RTT https://github.com/quicwg/base-drafts/pull/1641 [-http] [design] = - Duplicates are dropped https://github.com/quicwg/base-drafts/pull/1624 [-transport] = - Fix references to the Post-Base Indexing section https://github.com/quicwg/base-drafts/pull/1635 = - Fix typos in HTTP draft and use the more common "incautious" https://github.com/quicwg/base-drafts/pull/1630 = - Sender/Receiver https://github.com/quicwg/base-drafts/pull/1634 = - Consequences of bad ECN markings https://github.com/quicwg/base-drafts/pull/1626 [-recovery] = - Defend against endless Stateless Reset ping-pong https://github.com/quicwg/base-drafts/pull/1627 [-transport] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============6140041566340378537== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday August 12, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+6/-5/=F0=9F=92=AC53)

6 issues created:

10 issues received 53 new comments:

5 issues closed:

Pull requests

quicwg/base-drafts (+9/-7/=F0=9F=92=AC13)

9 pull requests submitted:

8 pull requests received 13 new comments:

7 pull requests merged:

Repositories tracked by this digest:

--===============6140041566340378537==-- From nobody Sun Aug 12 20:29:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3955130E65 for ; Sun, 12 Aug 2018 20:29:44 -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=mnot.net header.b=pnuroZoa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VU25Lnkt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAwwHSfENtRv for ; Sun, 12 Aug 2018 20:29:42 -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 C7E77129385 for ; Sun, 12 Aug 2018 20:29:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6EE4A21B90 for ; Sun, 12 Aug 2018 23:29:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 12 Aug 2018 23:29:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= 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=fm3; bh=SYqnI/08OIXb0KpN9yIoD7Z/9s/oN EmcQuGVOxowx3I=; b=pnuroZoait++S1hu+xDWPIjB/zyNksHXfBuaOTbn1bLGQ 6urQ8WsrW/ZP2HoV0oBcXQCNOgBPT2RjfnOw6vyf75JvXKX6wu+Lo8dEd0ll2DLI n7nfcH9dn/WIf44mZT1Cze6SAWOTtz9BseARfmJxGK6HufgMIK31OMBl1hjFlkbg SCV5aMZn8Y6wmOssgLeL62GP19Aj9veBLWvGEC01eCMw+dObQRJmJcWxmTIAd8v8 j7Dn2/h4vh658JnIYo91jFlvZoE73Zx+t1zQ2F3akBDd6PcuBwpVWybGgmWzd/hx dMi8KVf8fc+MnkbM0m+DWDqBtz5S0JNvEGZIsQDFQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=SYqnI/ 08OIXb0KpN9yIoD7Z/9s/oNEmcQuGVOxowx3I=; b=VU25Lnktrq/ugicR5Fwozt ytAZtRvAFMm7qqz5glvUMcbU4hJo03zwcr087rcWDaF64vJIImoSZ4+u+zrQP434 +pT8YEqL092QQTp2SCYkUSyOTkO7PH2BfmbJ/FinpBGeUOp7iWe1hvpMjA8YpcKv AKY+5Kk0ZleiMIYMbkAKmcV0y9jZCEYA0PhBmG47W/R5mLu5HV3tJPSDDdJ5CbJ6 heg6CtfYfv7N7Dsg5wabAItOvaDoEtm+flQS48Yd/llnJxuxlESET9qmehlPxh4y Kzv6As3WKko6KMTGxq6b9mV2dS+HJkn21znL0DojuGScmOlLXgeD6yi0amc1xZiQ == X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id AFFC310286 for ; Sun, 12 Aug 2018 23:29:35 -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.5 \(3445.9.1\)) Subject: Re: Spin Bit Experimental Design Reviews at the New York Interim Date: Mon, 13 Aug 2018 13:29:32 +1000 References: <50AB6C0B-C9BC-4B96-84B9-578F0FBC2B37@mnot.net> To: IETF QUIC WG In-Reply-To: <50AB6C0B-C9BC-4B96-84B9-578F0FBC2B37@mnot.net> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 03:29:45 -0000 Reminder -- if you want your Spin Bit experiment reviewed by the Working = Group, please tell us ASAP. Cheers, > On 20 Jul 2018, at 12:25 am, Mark Nottingham wrote: >=20 > As you may remember, we decided to adopt the Spin Bit draft = , but = defer deciding whether it'll actually be published as part of QUIC until = we get some validation that it helps to operate networks.=20 >=20 > We've encouraged folks to gather data to guide that decision by = running experiments, with the aim of being able to make a decision in = our Bangkok meeting. >=20 > To help those experiments succeed in guiding our decision, we'll = reserve some time to review experiments that request it in our New York = interim meeting = .=20 >=20 > The goal of these presentations will be to guide the experimental = design with feedback from the working group; not to report or judge the = results of the experiments (which will happen in Bangkok). >=20 > Please note: >=20 > * Reviews (both individually and collectively) will be time-bounded; = plan on approximately 15 minutes (each) to present, with another 15 to = discuss (extended if there's WG interest). > * This is ONLY an experimental design review; expect feedback on the = utility of the design and its results. > * No other discussion or decisions about the Spin Bit will take place = in the NYC interim. >=20 > If you'd like to request a review, please contact the chairs.=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sun Aug 12 23:29:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B295130E7A for ; Sun, 12 Aug 2018 23:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WmrQWIywAVk for ; Sun, 12 Aug 2018 23:29:54 -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 EF716129385 for ; Sun, 12 Aug 2018 23:29:53 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w126-v6so25384544oie.7 for ; Sun, 12 Aug 2018 23:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=O/uSyyicYNuP4B1ebuYFOAZML6GnPVK9MgNr4ok1f5A=; b=u9PcWaqBAmOPjf7hAlwYttouZndISiQxRAjU0lfLWLcHh0g9lqqTw2Nbi4t/RvzTvw PWxGxm//pd040/3Cn+Jo3hkj69OR9znrsOhNlUECZ3sn+WAsdz7AeJGkuhYuHpRIk7y5 crbntEHXq4+0WVS086+HuNPnuR1N2pHp9D8WisAlZVn1AzF/48onU+nHlNTuCZ7A1xxL OSutvEevCK6Hhm7gBzOw8AJ9QHl2zGIyLwjpj4Raz5EEJgM39Fr16NXMjmSGQELl9/lD nbwqCieHR8UPSwdDstV6flu0MNWpDrskk9E/ErwUNTJGbwM0msNTutspJhis+twDn9y9 b89A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=O/uSyyicYNuP4B1ebuYFOAZML6GnPVK9MgNr4ok1f5A=; b=Ad2TK4F3mpqsglqKP3wAfgF280VhygPvfA7BDWjZzOGpt1iN839aXLTQ5nMWIEJPRd 2LkRMvZrH9k2no1A+jf45dx3bU8XHuaxad6OfDO8FU2S2HCw8eJYdtC85JNKnMWSFXAc 1CJxO8CaPU3tq5MpiNEcwpSz9iw4aB6iI46p3jYbFdS4EWXD8IzXq91vnLxXK5vpH1Om UcXOi3Ruj+YNeoy1LKyzLpIFqYJvRxiuVuL9e/7VzZ8nTEPxN53TAPFtC+ZtEwnECM+m Y6aZlFL0efoB3ADjpjBOvTPdBTHmW1gRzeWkS5cNuydvGbI7dzSaU363Wbm7GIN1cogB zkNw== X-Gm-Message-State: AOUpUlHX6eNvSz7I2JYv4vFrtQ4F1ZGcHf9UEbwMQ5XRULHsxD9N4v2Q mbb9rW64MrEKSFJ63PSJK9Vy+4Jf+A7WWHRWJZA= X-Google-Smtp-Source: AA+uWPzXzp1hqV2p4TXZOTfcb8N150mCWA+1jP7vhK0DL31ij5XFaJE3leVZpd+k09kfm7fxZDa73veiiM9tPMwW+gQ= X-Received: by 2002:aca:df42:: with SMTP id w63-v6mr15977352oig.295.1534141793225; Sun, 12 Aug 2018 23:29:53 -0700 (PDT) MIME-Version: 1.0 References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> In-Reply-To: From: Martin Thomson Date: Mon, 13 Aug 2018 16:29:43 +1000 Message-ID: Subject: Re: Unified ACK frame encoding To: Ian Swett Cc: Brian Trammell , Jana Iyengar , Magnus Westerlund , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 06:29:56 -0000 On Fri, Aug 10, 2018 at 6:15 AM Ian Swett wrote: > There are a few things I like about this proposal: > 1) It makes ECN and ACK_ECN either the same(or more similar) > 2) As Kazuho said, it provides more precise feedback about which packets = were marked, which avoids some edge cases we've had to write up in the curr= ent text around ack loss and being unsure of exactly when recovery is exite= d. > 3) It doesn't get more expensive as the connection goes on. This is an u= nfortunate property of the current design. > > I find Jana's variation on this particularly interesting, because if ECN = isn't negotiated, I don't think there a reason to add any overhead. From p= ersonal experience, if you find a form of feedback valuable(whether it's EC= N or timestamps for one-way-delay), then you're happy to consume a few extr= a bytes to get better feedback. If the extra information isn't useful for = whatever reason, it's just wasted bytes. OK, 4 values is definitely easier to reason about. Merging ECT(0) and ECT(1) into the same bucket is easy as long as we're OK with that. The simpler encoding is easier to describe and write code for, and we can just tolerate (or reject) two adjacent ranges of the same type, just as we might tolerate (or reject) a trailing gap. > So overall this seems like an improvement we should do, but I'd prefer a = variant that doesn't increase the ACK frame size when ECN is disabled or th= ere are no ECN marks to report. FYI, if we need to steal a bit from the nu= mber of ack blocks, I'm ok with that since I expect more than 32 ack blocks= to be very rare. This is very close to a variant I suggested on the issue, which we agreed pretty quickly wasn't great. You can create two ACK frames, one with the full expressiveness, and another that has the potential to encode the ECN information. Call the second one ACK_ECN... I'm not convinced that optimizing for the awkward space between 16 and 64 is worth the extra complexity of a variant encoding of the frame. There are other ways to optimize for the cost of that occasional octet that seem like they would be more fruitful (like truncating ACK frames more aggressively). From nobody Mon Aug 13 21:58:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF34130E41 for ; Mon, 13 Aug 2018 21:58:28 -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 5Ll8P_GDxbO6 for ; Mon, 13 Aug 2018 21:58:26 -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 2FCA6130E2D for ; Mon, 13 Aug 2018 21:58:25 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx114.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fpRPS-000bEr-KF for quic@ietf.org; Tue, 14 Aug 2018 06:58:23 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fpRPR-0004Sw-0t for quic@ietf.org; Tue, 14 Aug 2018 00:58:21 -0400 Received: (qmail 29475 invoked from network); 14 Aug 2018 04:58:16 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.52]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Aug 2018 04:58:15 -0000 To: Martin Thomson , Mike Bishop , Ian Swett , Jana Iyengar , Sean Turner , ckrasic@netflix.com, afrind@fb.com, "Brian Trammell (IETF)" , =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: IETF QUIC WG From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <56e58699-37ba-10fb-982d-6d52e16a9390@huitema.net> Date: Mon, 13 Aug 2018 21:58:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Is draft-14 coming soon? X-Originating-IP: 168.144.250.234 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.22) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5p0fu4twNffxvfpeviVZ5up602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVic7PpLclFtot0r3ihxl5eG87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB81OoFFeyN79z+gPkYXfWpU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2Drvl3AsHuisl/RSyh5DLe 1OidX4Ts4xdG+C13IyWeZaLQFv21teFX4xX+heWMZvqWF8FcHzzV3acxBudgYcInb9U3tCdnANy/ aTF673AfZBKZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZxaD1j8zstKyoNMHmOfd8LFwBl1z1+w2zS/h3e6UiVRe4GJRFHT89/p5k W5IeUioW34BDuMJJAZp6jZEoPcoo7GeqA47D/juB1cx4exzYk7xEVhTEUT6xtIipPd5Oayzq647l NwN4qOsSZg+fYhVZGz1kOnf1peAVDGMbv2JVybbVwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 04:58:28 -0000 The next interim is in a bit more than a month, and I am concerned that the spec is still a bit uncertain. Some alternatives like draft-tls-28 vs. RFC 8446 can be easily settled by the interop spec. But there is more. The current editor draft includes several PR's that were not there in July. For example, we are discussing a new ACK-ECN format. At the same time, interop tests do flush issues in the spec -- but they only do that when implementations are based on the same spec. Thus, it would be very nice if you folks could cut draft-14 a couple of weeks before the interop! -- Christian Huitema From nobody Tue Aug 14 00:15:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0CD130D7A for ; Tue, 14 Aug 2018 00:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGrPHcHS0bai for ; Tue, 14 Aug 2018 00:15:11 -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 B5C92126CB6 for ; Tue, 14 Aug 2018 00:15:11 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id j205-v6so31856133oib.4 for ; Tue, 14 Aug 2018 00:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GIj1jMuKpI1B/KqQsO2DeMuMVGdnOvlcyXUWQaqLTRk=; b=lfDf6QtFLXspO8s5xh81sXMG25+Urr4sdjsqBrHYMn+0axgDPO2YFcgzaYNskTMFzP 9c2DS8rwWyeNLjeSOI3axv/0Q/syRTDyawTA08aI+i9N1NoXIcUNW+NmWTJppiFlInGp PsVclP7U+WVPSUNs1PEfIM49roO7stUiC9KFP83hUgooJQ6m6q6HZ2tJea32QVh2CyCh aKdT5FDK6wtj8PZlI8vlljddTL20aZILuFIK23v77DrRyZozl5tuR0TezbQ2GU2Z77pw ohf8kNKll2mcmezwxUucSJGUWVmI9PKQ/xcpm38HkY+0M59W1aUOsZb+ZO/6//gxhoHn Z6ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GIj1jMuKpI1B/KqQsO2DeMuMVGdnOvlcyXUWQaqLTRk=; b=Hr8HSxMtpvhW68s6D3gavsHkrH5Bj99aUEQtb5b/qsuZuYXdWkuFCkWjF1NVrlxLqe 04giHDOUiIX+eBOpf/Ifv4OMBCchMxkYV8flvwQuXj8fnpaAXWfpAmPfTC/yzb6zfYJA iwgU/D3WybG5nK1CSQAofGhTyhNsW3pgt+5m7ebXw17vn6qjds35Pbz45Z6NddrJu+mC k7GEzuVJxSruiafHy4Hi27WtEBVmEA6U+yu16URWhQgoUdOG2KCo8ytUJR7ZxLKd4I5X l0VXu+he1uEnoMmpSX7FZ5J5PNBmqwLALZe4MXZkmjL2pEil7H/D/lOPdN1aczePvw9j ZsUA== X-Gm-Message-State: AOUpUlHMZce8xInm987q0g6YAEEEz0zJBWFOrMHjwgEpF66o9edYcN9x CyqFXT0LBUHAE3cmx01vLLsNxcitxpTlQPL7BPE= X-Google-Smtp-Source: AA+uWPwaPm5iL9D9W0TxntNalRksIpDS2Vm8fnPqJsOQBnSB0FUb3IGsVzpWoRQJxXEf8wv4nQEbPLrzzd7aM8IXBDU= X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr19665524oib.254.1534230910801; Tue, 14 Aug 2018 00:15:10 -0700 (PDT) MIME-Version: 1.0 References: <56e58699-37ba-10fb-982d-6d52e16a9390@huitema.net> In-Reply-To: <56e58699-37ba-10fb-982d-6d52e16a9390@huitema.net> From: Martin Thomson Date: Tue, 14 Aug 2018 17:14:58 +1000 Message-ID: Subject: Re: Is draft-14 coming soon? To: Christian Huitema Cc: Mike Bishop , Ian Swett , Jana Iyengar , Sean Turner , ckrasic@netflix.com, Alan Frindell , Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 07:15:14 -0000 Soon. Check https://github.com/quicwg/base-drafts/pull/1653 for a summary of what we believe has changed since -13. It includes little more than the fixes we all tacked on to that broken version. I'll open a PR for 8446 now. On Tue, Aug 14, 2018 at 2:58 PM Christian Huitema wrote: > > The next interim is in a bit more than a month, and I am concerned that > the spec is still a bit uncertain. Some alternatives like draft-tls-28 > vs. RFC 8446 can be easily settled by the interop spec. But there is > more. The current editor draft includes several PR's that were not there > in July. For example, we are discussing a new ACK-ECN format. At the > same time, interop tests do flush issues in the spec -- but they only do > that when implementations are based on the same spec. Thus, it would be > very nice if you folks could cut draft-14 a couple of weeks before the > interop! > > -- Christian Huitema > > From nobody Tue Aug 14 22:17:09 2018 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 321BE130DDD; Tue, 14 Aug 2018 22:17:02 -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-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <153431022215.27027.17903007261097326997@ietfa.amsl.com> Date: Tue, 14 Aug 2018 22:17:02 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 05:17:02 -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-14.txt Pages : 32 Date : 2018-08-14 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 14 22:17:19 2018 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 09CD4130F08; Tue, 14 Aug 2018 22:17:06 -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-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <153431022598.27160.9106022819215133095@ietfa.amsl.com> Date: Tue, 14 Aug 2018 22:17:06 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 05:17:12 -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-14.txt Pages : 129 Date : 2018-08-14 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 14 22:20:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5E0130DDD for ; Tue, 14 Aug 2018 22:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 GDvNW67AEqnK for ; Tue, 14 Aug 2018 22:20:12 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFA11271FF for ; Tue, 14 Aug 2018 22:20:12 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id q11-v6so155272oic.12 for ; Tue, 14 Aug 2018 22:20:12 -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=q8LsS79coqWxn0chWTxB8ELoH1HAD9vugmHAZhpGfeo=; b=BdZOFZAYsHxrrxs1tr1qaM/6J0BA26UIc0xK3a36UtebC1vIasBAP2izONEilPhkJV 0JhuchBrdn7/BBvKtYEwWzbvjz/QGVOVIDn6OzqSHrpGEdLAvZ5lXK7xeIKSYNxYj/eN 9RBZGTNRaw/FNWC/BHMv+h0jCyw6yCEXC/i3CxvExvAL17Gan7wiaFnVahxN1qhFlH3r zf12qZ9HJFJjIMw5ysXpobfsq2y7BLU8R8ImbMvFUHP1W8DkhiiE3OEMJSLe6LjZjKjR VAHQBbWq0uH3eXjOmSb4f++muWSeDMYqaRcJ3NbItDR/sDApIHvb+M3syGuCbIqoycXl wIVw== 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=q8LsS79coqWxn0chWTxB8ELoH1HAD9vugmHAZhpGfeo=; b=BPHUhMBE+T7mtJxQpj2fkiC67GyKBjY8BGLZgLmPiCnKDAMbHKuLW+f0NbOezHOPZ/ 3GbJNpSmM7wuPTbGjbNgOVql+w4C6VlUR5KzhDVpqhNFyvQ0TNsAXe0krIV6hFFt+2Dx QDnwAw0V++wti5TIp6ykS3RkTJg5EUzzR6hNp8+SMPDQgclCkv+pXWkPkKZxS2l5yTkD 66aC5FH1FfHzF5oTuHsjH1txhSjQvWCaqVxF93bZPB8jdVewo7zoZAM9jzYwUH0VgWud MhquPZ5f56IFxiW3wYAjNZjPxt2SograwkHBXR6DPvOsT8XmHW9kZpbcJXSf5xnR6d6F pDOA== X-Gm-Message-State: AOUpUlGlPQMOk+xOl9VPWtvLQT8QMeFOluARqistgreUeEKcP5IEos4Z vW/9NZmdDTgHa89ltdSaqCypHhWf6X/gH7Hln+ZYZQ== X-Google-Smtp-Source: AA+uWPzED8yqkSOHYA3LdzYMN8IyQf+/Hkge7jqoxuOVn7uoM3+IDQ+dw0hBliwPeUZmrOmDvhAWc4n+ofLJsfIBrCo= X-Received: by 2002:aca:305:: with SMTP id 5-v6mr26016379oid.84.1534310411676; Tue, 14 Aug 2018 22:20:11 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 15 Aug 2018 01:20:11 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 15 Aug 2018 01:20:11 -0400 Message-ID: Subject: Key Life To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000001032b70573727bbf" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 05:20:16 -0000 --0000000000001032b70573727bbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://github.com/quicwg/base-drafts/pull/1636 "Once this timer expires, an endpoint MUST NOT either accept or generate new packets using those packet protection keys. An endpoint can discard packet protection keys for that encryption level.=E2=80=9D I don=E2=80=99t understand this. If an older crypto stream was important be= fore timeout, why isn=E2=80=99t it important after timeout? If the peer is missing some packet, I would presume that it cannot proceed with the handshake and a deadlock would occur? I can see that packets can dropped later on, during key update. Why not have an explicit signal to indicate the end of life of a crypto stream and use that to discard keys? I can see that an explicit signal won=E2=80=99t be ideal post handshake bec= ause a peer can then force old keys forever, but during handshake that would seem reasonable to me. This probably ties in with the discussion of client finished signalling. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --0000000000001032b70573727bbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = https://github.com/quicwg/base-draf= ts/pull/1636

&quo= t;Once this timer expires, an endpoint MUST NOT either accept or generate n= ew =C2=A0packets using those packet protection keys.=C2=A0 An endpoint can = discard packet =C2=A0protection keys for that encryption level.=E2=80=9D

I don=E2=80=99t underst= and this. If an older crypto stream was important before timeout, why isn= =E2=80=99t it important after timeout?
If the peer is missing some packet, I would presu= me that it cannot proceed with the handshake and a deadlock would occur?

I can see that packets = can dropped later on, during key update.

Why not have an explicit signal to indicate the end of = life of a crypto stream and use that to discard keys?
I can see that an explicit signal = won=E2=80=99t be ideal post handshake because a peer can then force old key= s forever, but during handshake that would seem reasonable to me.

This probably ties in with the= discussion of client finished signalling.

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

--0000000000001032b70573727bbf-- From nobody Tue Aug 14 22:38:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FAB130DDE for ; Tue, 14 Aug 2018 22:38:02 -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, FREEMAIL_FROM=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 HKZjXCntOOc2 for ; Tue, 14 Aug 2018 22:38:00 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC303130DDD for ; Tue, 14 Aug 2018 22:37:59 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id y200-v6so96807lfd.7 for ; Tue, 14 Aug 2018 22:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nt1bVv4/0vArmHhQWsFOvpm5BapT7yNqdDUoK0UQSaQ=; b=m74mdO3hSjAEPAjx7qo3gzI0360HP8t4X2mp8Oc/2qyU/lURyFCWWQM9Dhr40l6HcZ YfEM2HgIbXnTLaWN7XWiAnP48/BO0bkxnv+l5u2rV4ZekE0Pc9iOgVSO5pfu4VTs2KVm M51K3GEFh7xCjpWEjYHt/+1id2WAjcsUnyfiOynyiPKcelOu96Q/mjKCqm4k1h0/7CM7 Iy/9MZCcIeGai4BDQqk/Oz4/Wg4T7X3M0ZO/Jc2zv9rH7tqzPJ60liezRPxgLZGaIpb4 38dlW/UVF7kYHQzdPFVyPXDEem56ixnBYBuDDvjmGpKO7hLiuoyuOEGxd3A5jxNVveKa lHzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nt1bVv4/0vArmHhQWsFOvpm5BapT7yNqdDUoK0UQSaQ=; b=LmmeoYTvjUuWPwOaByNvHtw3uUwNyFj7mpKu8ZkItU9dfm6cXINFvWRgNlR3xRKsLz pmkQSv4E+68rLr79ouReib0IYUFU0S6b/rpYGkermU/ada/iZXkfEXLKv+Kb6uL9ySLl SWhEnyMQL5q3Xd/akc9rbHj//KuKJWyjITB+sEkrNb8d6+lZ51/RT5kFzAtZsno+tuNX RMHjZ2IxJuh2BQ7tNN17KwvOyJgt/2tIR0arUNxtFmwljOC90Xrh28C/v3oYmrL3iz2o 8msIZQVIfbQugLRLAq9PtxOWVpQDys2+IalAEbK6h01+54jSvslN5FgqNCtKA8WW05I5 0aiA== X-Gm-Message-State: AOUpUlEno9QbgE8MZNAXPZP6tWEdhvLSFs9alMv00yQ0jCV5WkooKJnR VdQ5kMCNDdPScxTRn/7IPUNg/FT+uLskXLMPq7I= X-Google-Smtp-Source: AA+uWPwFXWs9Rhlv2BwurU877H8nHLtcaxdVrKISTFq1wYJ9uW1h7fSpSayi65KEz82jKfOPXtW7er4oAGF/IqZe6R0= X-Received: by 2002:a19:9a81:: with SMTP id c123-v6mr15623460lfe.106.1534311477982; Tue, 14 Aug 2018 22:37:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Wed, 15 Aug 2018 14:37:46 +0900 Message-ID: Subject: Re: Key Life To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 05:38:03 -0000 2018=E5=B9=B48=E6=9C=8815=E6=97=A5(=E6=B0=B4) 14:20 Mikkel Fahn=C3=B8e J=C3= =B8rgensen : > > https://github.com/quicwg/base-drafts/pull/1636 > > "Once this timer expires, an endpoint MUST NOT either accept or generate = new packets using those packet protection keys. An endpoint can discard p= acket protection keys for that encryption level.=E2=80=9D > > I don=E2=80=99t understand this. If an older crypto stream was important = before timeout, why isn=E2=80=99t it important after timeout? > If the peer is missing some packet, I would presume that it cannot procee= d with the handshake and a deadlock would occur? No. Because if the peer is still transmitting data, it will retransmit that before the timer expires. > I can see that packets can dropped later on, during key update. > > Why not have an explicit signal to indicate the end of life of a crypto s= tream and use that to discard keys? > I can see that an explicit signal won=E2=80=99t be ideal post handshake b= ecause a peer can then force old keys forever, but during handshake that wo= uld seem reasonable to me. That was discussed at the Interim in June and also at IETF 102. IIUC, some if not most of us are comfortable with using timers. Others who want an explicit signal can rely on that. An endpoint can deduct such signal from the receipt of packets at a higher encryption level. For the tail, the client can send a PING frame and use the receipt of ACK against the PING as a signal that the server has received all handshake packets. To summarize, current draft provides the freedom to implement either ways. > > This probably ties in with the discussion of client finished signalling. > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > --=20 Kazuho Oku From nobody Wed Aug 15 00:34:14 2018 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 67160130ED8; Wed, 15 Aug 2018 00:34:05 -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-recovery-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <153431844537.14313.5047414534527071821@ietfa.amsl.com> Date: Wed, 15 Aug 2018 00:34:05 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 07:34:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-14.txt Pages : 34 Date : 2018-08-14 Abstract: This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-recovery [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-14 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 15 06:21:54 2018 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 23740130E5A; Wed, 15 Aug 2018 06:21:47 -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-14.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <153433930710.14364.2855635238621769538@ietfa.amsl.com> Date: Wed, 15 Aug 2018 06:21:47 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 13:21:47 -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-14.txt Pages : 46 Date : 2018-08-14 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 15 06:22:13 2018 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 B22C2130E99; Wed, 15 Aug 2018 06:21: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-qpack-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: quic@ietf.org Message-ID: <153433931868.14433.5706781353318049945@ietfa.amsl.com> Date: Wed, 15 Aug 2018 06:21:58 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 13:22:06 -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 : QPACK: Header Compression for HTTP over QUIC Authors : Charles 'Buck' Krasic Mike Bishop Alan Frindell Filename : draft-ietf-quic-qpack-02.txt Pages : 26 Date : 2018-08-14 Abstract: This specification defines QPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP over QUIC. This is a variation of HPACK header compression that seeks to reduce head-of-line blocking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-qpack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-qpack-02 https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-qpack-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 15 23:17:42 2018 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 E4A72130E6F; Wed, 15 Aug 2018 23:17:39 -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: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: quic - New Meeting Session Request for IETF 103 X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153440025989.3036.10698183012703844733.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 23:17:39 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 06:17:40 -0000 A new meeting session request has just been submitted by Lars Eggert, a Chair of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm iccrg httpbis tls dispatch Second Priority: mptcp saag rtcweb Third Priority: irtfopen maprg People who must be present: Sean Turner Mark Nottingham Patrick R. McManus Jana Iyengar Martin Thomson Spencer Dawkins Brian Trammell Mirja Kuehlewind Lars Eggert Mike Bishop Ian Swett Alan Frindell Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: Two consecutive days early in the week, if possible. --------------------------------------------------------- From nobody Thu Aug 16 09:57:30 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3826F127AC2 for ; Thu, 16 Aug 2018 09:57:28 -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 jIr1NlH7vSaw for ; Thu, 16 Aug 2018 09:57:25 -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 CABCF1277BB for ; Thu, 16 Aug 2018 09:57:24 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx15.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fqLaL-0000al-41 for quic@ietf.org; Thu, 16 Aug 2018 18:57:22 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fqLaG-0005Tt-Rb for quic@ietf.org; Thu, 16 Aug 2018 12:57:17 -0400 Received: (qmail 20126 invoked from network); 16 Aug 2018 16:57:14 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.52]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Aug 2018 16:57:13 -0000 To: Martin Thomson , Sean Turner Cc: IETF QUIC WG From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <6dbdfa4e-b897-8765-2f64-ccaa7df007b7@huitema.net> Date: Thu, 16 Aug 2018 09:57:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Language: en-US Subject: Did the crypto change with draft-tls-14? X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5pHDT2eXyQ6gG1JvpDdgWh9602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViaftx1CKhgt5vmVVLovhrxs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB4BYXicIRbWrtVh3YscLvvx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXAOqm+6J4QXGS373vqtxtHd7a93mYLfhzgsBYekMM1H9gi8SgLoL2y DubsiXN4mleU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwRbLz+Z/8OylBaLzk09eGtkuggKW28pboyZCmKkHUYXakwrAx9H+G/ywEB rOQBb19QtyuKKdD7jSaryCB+Lex8hntB4/4Pbrz2QtFuyl+Sh6ctJJaoNQlm9OuZnd22I17dfqb5 R4VemuUI6bcEARsm0L3ImxSUHqpGB7nC++w7dpmNZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 16:57:28 -0000 TG9va2luZyBhdCB0aGUgY2hhbmdlcyBiZXR3ZWVuIGRyYWZ0LWlldGYtcXVpYy10bHMtMTMg YW5kDQpkcmFmdC1pZXRmLXF1aWMtdGxzLTE0LCBJIHNlZSB0aGF0IEhLREYtRXhwYW5kLUxh YmVsIHNwZWNpZmljYXRpb25zIGhhdmUNCmdyb3duIGFuIGV4dHJhIGVtcHR5IHN0cmluZyBw YXJhbWV0ZXIsIGUuZy4gY2hhbmdlIGZyb206DQoNCsKgwqAgY2xpZW50X2luaXRpYWxfc2Vj cmV0ID0gSEtERi1FeHBhbmQtTGFiZWwoaW5pdGlhbF9zZWNyZXQsICJjbGllbnQNCmluIiwg SGFzaC5sZW5ndGgpDQoNClRvOg0KDQrCoMKgIGNsaWVudF9pbml0aWFsX3NlY3JldCA9IEhL REYtRXhwYW5kLUxhYmVsKGluaXRpYWxfc2VjcmV0LA0KwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCAiY2xpZW50IGluIiwgIiIsDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIEhhc2gubGVuZ3RoKQ0KDQpUaGUgZW1wdHkgc3RyaW5nIGlzIGFsc28g cHJlc2VudCBpbiB0aGUgbGF0ZXN0IFRMUy0xMyBkcmFmdHMgYW5kIGluIFJGQw0KODQ0Niwg YW5kIHRoZSBzcGVjIGRpZCBzYXkgdGhhdCB0aGUga2V5cyAiYXJlIGNvbXB1dGVkIGluIHRo ZSBzYW1lDQpmYXNoaW9uIGFzIHRoZSBjb3JyZXNwb25kaW5nIFRMUyBrZXlzIi4gSSBhc3N1 bWUgdGhhdCB0aGUgY2hhbmdlIGluIHNwZWMNCnRoZXJlIGlzIHB1cmVseSBlZGl0b3JpYWws IGFuZCB0aGF0IHRoZSBleGlzdGluZyB0ZXN0IHZlY3RvciByZW1haW5zDQp2YWxpZCAoZXhj ZXB0IGZvciB0aGUgdmVyc2lvbiBudW1iZXIpLiBJcyB0aGF0IGNvcnJlY3Q/DQoNCi0tIENo cmlzdGlhbiBIdWl0ZW1hDQoNCg0K From nobody Thu Aug 16 10:20:51 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7046F130DC1 for ; Thu, 16 Aug 2018 10:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 y68MM-1DE3Ht for ; Thu, 16 Aug 2018 10:20:48 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90FC127AC2 for ; Thu, 16 Aug 2018 10:20:47 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id a4-v6so3969596lff.5 for ; Thu, 16 Aug 2018 10:20:47 -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=Ld++HZnhZTFXlmNpD+7udjVCyCtv2VL3WUp2eFu3Au4=; b=fyflvHzvjuYZ+YMprCQYP8zavmNSAvs9JPap+XmEUx9QUcW8Ohr4yb0LuNjfrcDcgh gVDNdQzmxGpdlEYJdf2KL2tFak5HH5XcqkzoQhXgsnaXLqhKu84zKfpGQ5RiOvhpxPM3 gfIEZ0oCLzY7+9dF+5vlov7Co8sjcHrmZPZTeq9WaxFqMpSGFibV0bHnrmOb7oOFi124 SdE8z1lXXn94DVju9cCKGlv8aQObJkk7YzuPTRL41DOozeg8SxF+cDYR/5SC9sTsAXjX ReWZvQybupWWoewItc4CDkgMMSSCHMCs0zM+OlXi3N7KtMJwlJvrpxtKWPHCrrYUjZlk drkA== 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=Ld++HZnhZTFXlmNpD+7udjVCyCtv2VL3WUp2eFu3Au4=; b=JyO5ihBBk8Ffz9PuTAurgx7gQLehb8q7UbS5IonxD5CTMXaebDEqN2o4MyQZQoHREn sEFbPR8WpPrW+HkrmPXSsS9bQVB6SoWPv3ybg4DrbdwwueEMF0NO/EmF+G4L5c5I2FVW mrvBUvvQxqiq23sNKzfShrwMJUKNp8LGijIh4sknSVS4cVQPFHnPjnD8LVkJCb9uZy3P 3owLCuvpqay5PzO85gM+1C9KHxOlAodyI+l5vJCl4IyM/T4mXHXligNWC6+LMEWnokEi nsd3ZWNGyX0A7lkPq5Y8nvXLs8MkdSCEjWOpGVfWH7EHOFnK8EgP98hz97P10rAlHJRZ 0PJw== X-Gm-Message-State: AOUpUlER/DxpHwufKxD77OWMg1nlGXMsvndN8XPRfXYyBiF3Xvey/5CQ up+3X5EMEMKM4FOezpyaWHzq+M89I5lNBQnXbf3NYA== X-Google-Smtp-Source: AA+uWPzlnGzMVaW+mDYe/41P7xwho83DC8io+3f9jeANMyvHbCVRWknMfKCPIJV1rhRSF+cCk635/vqC+hE+wReOero= X-Received: by 2002:a19:e307:: with SMTP id a7-v6mr19602916lfh.125.1534440046078; Thu, 16 Aug 2018 10:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Thu, 16 Aug 2018 10:20:05 -0700 (PDT) In-Reply-To: <6dbdfa4e-b897-8765-2f64-ccaa7df007b7@huitema.net> References: <6dbdfa4e-b897-8765-2f64-ccaa7df007b7@huitema.net> From: Eric Rescorla Date: Thu, 16 Aug 2018 10:20:05 -0700 Message-ID: Subject: Re: Did the crypto change with draft-tls-14? To: Christian Huitema Cc: Martin Thomson , Sean Turner , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000e03fbc057390a9b9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2018 17:20:50 -0000 --000000000000e03fbc057390a9b9 Content-Type: text/plain; charset="UTF-8" What happened here is that the text in -13 was just wrong, because HKDF-Expand-Label() takes 4 arguments. And when I changed it from QHKDF-Expand, I just forgot. So, it's an editorial change in that -13 and -14 should have the same crypto. A technical change in that -13 couldn't be implemented w/o this correction. -Ekr On Thu, Aug 16, 2018 at 9:57 AM, Christian Huitema wrote: > Looking at the changes between draft-ietf-quic-tls-13 and > draft-ietf-quic-tls-14, I see that HKDF-Expand-Label specifications have > grown an extra empty string parameter, e.g. change from: > > client_initial_secret = HKDF-Expand-Label(initial_secret, "client > in", Hash.length) > > To: > > client_initial_secret = HKDF-Expand-Label(initial_secret, > "client in", "", > Hash.length) > > The empty string is also present in the latest TLS-13 drafts and in RFC > 8446, and the spec did say that the keys "are computed in the same > fashion as the corresponding TLS keys". I assume that the change in spec > there is purely editorial, and that the existing test vector remains > valid (except for the version number). Is that correct? > > -- Christian Huitema > > > --000000000000e03fbc057390a9b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What happened here is that the text in -13 was just w= rong, because HKDF-Expand-Label()=C2=A0 takes 4 arguments.

And when I changed it from QHKDF-Expand, I just forgot. So, it'= ;s an editorial change in that -13 and -14 should have the same crypto. A t= echnical change in that -13 couldn't be implemented w/o this correction= .

-Ekr


On Thu, Aug 16, 2018 at 9:57 A= M, Christian Huitema <huitema@huitema.net> wrote:
Looking at the changes between draft-ietf-quic-tl= s-13 and
draft-ietf-quic-tls-14, I see that HKDF-Expand-Label specifications have grown an extra empty string parameter, e.g. change from:

=C2=A0=C2=A0 client_initial_secret =3D HKDF-Expand-Label(initial_secre= t, "client
in", Hash.length)

To:

=C2=A0=C2=A0 client_initial_secret =3D HKDF-Expand-Label(initial_secre= t,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "client in", "= ",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hash.length)

The empty string is also present in the latest TLS-13 drafts and in RFC
8446, and the spec did say that the keys "are computed in the same
fashion as the corresponding TLS keys". I assume that the change in sp= ec
there is purely editorial, and that the existing test vector remains
valid (except for the version number). Is that correct?

-- Christian Huitema



--000000000000e03fbc057390a9b9-- From changzhi2@lenovo.com Thu Aug 16 23:35:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870A8130DDE for ; Thu, 16 Aug 2018 23:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZjYgGy0mLOu for ; Thu, 16 Aug 2018 23:35:28 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FE2130DC8 for ; Thu, 16 Aug 2018 23:35:28 -0700 (PDT) Received: from [67.219.251.54] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-c.us-west-2.aws.symcld.net id F5/5A-22772-AAC667B5; Fri, 17 Aug 2018 06:35:22 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRWlGSWpSXmKPExsWS8eIhk+6qnLJ og6Z37BatK94zOjB6PHr2hjmAMYo1My8pvyKBNWPpibNMBe8FKjZufMbUwHiEv4uRi0NI4Dmj xMq539ggnHmMEmcm/GXuYuTkYBPQltg38x8jiC0ioC9x+8ctFhBbWMBIYsWdR6wQcXOJEwu6m CBsPYkLT26C1bMIqEpc3nwXLM4r4CNxY/J3sF5GAVmJaY/ug8WZBcQl5k6bBTZHQkBAYsme88 wQtqjEy8f/gOIcQLa8xJZZghDleRIn925ihxgpKHFy5hOWCYwCs5BMmoWkbBaSMoi4jsSC3Z/ YIGxtiWULXzPD2GcOPGZCFl/AyL6K0TypKDM9oyQ3MTNH19DAQNfQ0EjX0NhM19RCL7FKN1mv tFi3PLW4RNdIL7G8WK+4Mjc5J0UvL7VkEyMwOhiAYAfj/0MphxglOZiURHktwsqihfiS8lMqM xKLM+KLSnNSiw8xynBwKEnw2mYD5QSLUtNTK9Iyc4BxCpOW4OBREuGtBEnzFhck5hZnpkOkTj Hac6y7N2USM8cRMHkBTP55P3USsxBLXn5eqpQ4byFImwBIW0ZpHtxQWFq5xCgrJczLCHSmEE9 BalFuZgmq/CtGcQ5GJWHeQJApPJl5JXC7XwGdxQR01jSBUpCzShIRUlINjMorm5jlWi33SLQF Bu1+f8ZnVsCVtqe+P0Qavu5Y1JJ0t1no9OV6E5k/zw9M9FjItOfu/pLVgfIX/dI2/PBuylqwI KkmVGbfrYef7sYsebBa1yF5zhLxwuXSf6+yTVA4vWeymJxltMKcmd+zfaZ/rLfm2xOj+6mZf9 nj2bxVPd5/FA95PZzWy6fEUpyRaKjFXFScCAB3SaX1JgMAAA== X-Env-Sender: changzhi2@lenovo.com X-Msg-Ref: server-31.tower-366.messagelabs.com!1534487720!2190509!1 X-Originating-IP: [104.232.225.2] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27822 invoked from network); 17 Aug 2018 06:35:21 -0000 Received: from unknown (HELO maesmtp01.lenovo.com) (104.232.225.2) by server-31.tower-366.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 17 Aug 2018 06:35:21 -0000 Received: from CNMAILEX02.lenovo.com (unknown [10.96.80.2]) by maesmtp01.lenovo.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 155b_6f16_cc68c2da_f35f_4ff0_a10a_176b658ce582; Fri, 17 Aug 2018 06:35:19 +0000 Received: from CNMAILEX03.lenovo.com ([169.254.11.183]) by CNMAILEX02.lenovo.com ([10.96.80.2]) with mapi id 14.03.0389.001; Fri, 17 Aug 2018 14:33:40 +0800 From: Zhi Zhi2 Chang To: "quic@ietfa.amsl.com" Subject: Same packet number in a QUIC connection ? Thread-Topic: Same packet number in a QUIC connection ? Thread-Index: AdQ19DPcZrzOeqm3R6SZpqdlxcdaWA== Date: Fri, 17 Aug 2018 06:33:40 +0000 Message-ID: <7335E3E9AC2DE240988251CF62CAE90A0A236086@CNMAILEX03.lenovo.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.19.89] Content-Type: multipart/alternative; boundary="_000_7335E3E9AC2DE240988251CF62CAE90A0A236086CNMAILEX03lenov_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 06:38:15 -0000 --_000_7335E3E9AC2DE240988251CF62CAE90A0A236086CNMAILEX03lenov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable reply --_000_7335E3E9AC2DE240988251CF62CAE90A0A236086CNMAILEX03lenov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

reply

--_000_7335E3E9AC2DE240988251CF62CAE90A0A236086CNMAILEX03lenov_-- From nobody Fri Aug 17 07:19:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06CD130DE8 for ; Fri, 17 Aug 2018 07:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.519 X-Spam-Level: X-Spam-Status: No, score=-9.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=Y4YE0IxO; dkim=pass (1024-bit key) header.d=chromium.org header.b=CG7pni/S Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifZ_gUrjwSqW for ; Fri, 17 Aug 2018 07:19:00 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D68127332 for ; Fri, 17 Aug 2018 07:19:00 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id m13-v6so5788395uaq.7 for ; Fri, 17 Aug 2018 07:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=JeMO0cdy8N6nybiDjj9Vsk68LhoD0yYtSgVbJz5xSD0=; b=Y4YE0IxOdXGpGlwF7snsuLAzeq0OsWsQ7dum+j3huIRC+kTUWReiSp2Uqm2uIzBm7B byA9qm7rvc2WcZTJ+m1XOGB2gHVtHj6zn7K07OiZnDoBeDeWy2uv14tckQQi4wvZZc6O eAV0u5WoxXngaLVf44rOzoUA6NVAOsGglvLo9nt2I7twXWzXezeqspoczg9Gw6Az4A6M 245ZDhb2KaHu1A0N2E/Dzrg7CqoASa+8YYVrSVnDVOcD6h9QlXmDBBLdprfwP+Phy/zd p/5nH9g/fHS4z4oF3QFi8ja40yc3ezoD8Gxq7xGfEcHIpuk1RWGU0oZIu9veka9Qxxrd PcpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:from:date:message-id:subject:to; bh=JeMO0cdy8N6nybiDjj9Vsk68LhoD0yYtSgVbJz5xSD0=; b=CG7pni/Swq2r6twnvU1hStlpdvQXcirw7SGIPMeTWSMHck+TX4/3n5XJ5drWUnBCOY dsrpRHVQgnQekCdizsrZ+mm/ByO7IT6YwAHxknfw3UO1o3gGxb7uYjaTjE0Wa9ycvPfc n5l+EUQJVGiC4l+F4jejrRSJ4+cdfD6k0/BtQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=JeMO0cdy8N6nybiDjj9Vsk68LhoD0yYtSgVbJz5xSD0=; b=CUV0DHEFMJLV/WV5TOtIsIpqfZDN45IjhIbeyLJ+NkM0XXfR/ny3TFfktsoXcGigqJ 7ANaI7x+7LHp7SwJIbv+GgQZE7lVge+5JgKsI1HQv8NaG8EDf237I/QLr7Vhw89TeUhr hW9q/gNQmINARJgZh0OH4rRZ8OOc/g3R2ghyKeuc+XMP2Hd6iOEhgH8OBjLuBK62cgis kSXGfpDgC39vuOxsCluetuKOlOb+DET6jky6zMVUy7T7dJzx2GK4OzthspSLNi38lPDQ rcQY4WykPPiBnAtrLx52L8UAv8fRw45EnBOznTldx/RzAybw3rfO1KLZPy1AU+LeSQ6L R7fA== X-Gm-Message-State: AOUpUlHuxjN6LtjgAYwJrp3xeIccrW8Uj87L4LzJ2qfulwssh7GjdoIt zwfceZaRhAhtk9ENxTxdVVgtf4t4Mcy1BdMeEf7ct/+Netk= X-Google-Smtp-Source: AA+uWPzhF47GOSdMYVlQq7vf1+e1Z6kr9O+O8CmFkWTjVRSGicN3uFVeVXSPO+/2GLEmBRWRMOkr6aNRWbXqvMKh9PI= X-Received: by 2002:ab0:a25:: with SMTP id q37-v6mr23091500uah.22.1534515538715; Fri, 17 Aug 2018 07:18:58 -0700 (PDT) MIME-Version: 1.0 Sender: bnc@google.com Received: by 2002:a67:3593:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 07:18:38 -0700 (PDT) From: =?UTF-8?Q?Bence_B=C3=A9ky?= Date: Fri, 17 Aug 2018 10:18:38 -0400 X-Google-Sender-Auth: V8TgmJGuTm9vvrBJ38FxrKU4wI0 Message-ID: Subject: QPACK ordering guarantee? To: quic@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 14:19:01 -0000 Hi, HPACK Section 1.3 defines a "Header List" as "an ordered collection of header fields...". QPACK uses the term "Header Set" instead and does not require it to be ordered. HPACK has a whole section, 2.1, on ordering, whereas QPACK does not spell out this guarantee. However, since frames on a given stream are guaranteed to be ordered by the underlying transport, my impression is that QPACK as specified already guarantees to preserve order of header fields within a header list. (Also in my experience things can break in colorful ways if you start reordering headers in your application.) Sorry if this has been discussed before. I see that definitions were added at https://github.com/quicwg/base-drafts/commit/4a4cdc24043f165b1a85949ba56c832ddd27f6ca but I do not see any discussion or reference to GitHub issue. I propose to add language on the requirement to preserve order, and to use the expression "header list" instead of "header set" throughout. The clause "header list ... can contain duplicate header fields" should probably also be included. Cheers, Bence From nobody Fri Aug 17 07:32:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E30F130EB4 for ; Fri, 17 Aug 2018 07:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 0cKZfNqHBZBK for ; Fri, 17 Aug 2018 07:32:28 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87600130E8A for ; Fri, 17 Aug 2018 07:32:28 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id w26-v6so1895796qkf.4 for ; Fri, 17 Aug 2018 07:32:28 -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:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ZHlJbKvw4n7lSpUZTx7AyUi/Rw6UoTjZwQdDGc+3n4M=; b=jl7iHv10fEEIuq2MTWPKsFWKVtQMmCEFRNGPuyZzpmnrff7cs2etJjcx5h4v/ve9gt HwV0Qe4XgIJA9WFPv3kuMfW4k72xK8pBdvnxi8qvYOP8YR6mnsxBcXgnGqQzirF4ugs6 fHbcF8uhEIuat1kAlJoN1k0NstrEu4BiwjlncO57jiOJAdYJmUi116eE0jMJ2Eou+Q61 qtffYhCQmbCthwjPnOZigsQpyrKtFKFMS1AU2RXnjtdjWWyQ0+QJ+0TuysdxaPf6S48M kho+1OKv0hg5EFfaFxnzGqeyZallkYLLllSIxP4GxQobMpyL2FeDW//dfE/iKbHZxapy YQWA== 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 :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ZHlJbKvw4n7lSpUZTx7AyUi/Rw6UoTjZwQdDGc+3n4M=; b=JoObwCAnRz3P3P2yuRjCfS+hSRkJQjqMSN8glehmJGpeY65WdPCljVzW9KYRe0KBk4 JSnn1+YtnWX9FW9c4B/ZEzAGOf+MKnayugpXgnQzxNFc9novlnUF1aYw2jprsPtdgjfN BV6XaiDfLYXzitvBoSzxRKxKQJwaWrJubA79pPKDYZO5uyvloMcOK8rvVsfqR2K+5Oh9 zvL61G/lLSz0j+pcYgUCT+5dJFTRGl8136zIEU24+wlW5qXibdoesQqIgkX/WbGhCH9v keFxBnLimaCJKgoOMk3mJF713IePInHebTnqjM7FkDn4Ep1Yae1jv2IGMwzWovO4ANEF Ne7Q== X-Gm-Message-State: AOUpUlFQU6QotUqiDWv9xK5bIro65/aMeUlHWo7Rhu9AMTTQjcwWAdqA MRhEXx5lwzaaJFt0fcakgVT0qg== X-Google-Smtp-Source: AA+uWPw8qzY/Y/O3gDXPhPmzvRRKGO+0OWLXko13PFL5xisxWCv9NRMi7BNY2oQ65hWpqSB+4oreOQ== X-Received: by 2002:a37:e216:: with SMTP id g22-v6mr7494006qki.61.1534516347634; Fri, 17 Aug 2018 07:32:27 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id v71-v6sm1416713qkl.42.2018.08.17.07.32.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 07:32:27 -0700 (PDT) Date: Fri, 17 Aug 2018 10:32:22 -0400 From: Dmitri Tikhonov To: Bence =?iso-8859-1?Q?B=E9ky?= Cc: quic@ietf.org Subject: Re: QPACK ordering guarantee? Message-ID: <20180817143204.GA9133@ubuntu-dmitri> Mail-Followup-To: Bence =?iso-8859-1?Q?B=E9ky?= , quic@ietf.org References: 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.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 14:32:30 -0000 On Fri, Aug 17, 2018 at 10:18:38AM -0400, Bence Béky wrote: > I propose to add language on the requirement to preserve order, and to > use the expression "header list" instead of "header set" throughout. > The clause "header list ... can contain duplicate header fields" > should probably also be included. I support this change. In addition, the "full collection" aspect is not quite correct: Header set: The full collection of headers associated with an HTTP message. Header block: The compressed representation of a header set. Since there may be more than one header block associated with an HTTP message, a single "header set" does not always contain the full collection of headers. - Dmitri. From nobody Fri Aug 17 07:47:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FA0130FB1 for ; Fri, 17 Aug 2018 07:47:38 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=K/GGRnyM; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=OVBqDyqU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrayIEFwb46c for ; Fri, 17 Aug 2018 07:47:36 -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 3E412130F88 for ; Fri, 17 Aug 2018 07:47:36 -0700 (PDT) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7HEgl9a018641; Fri, 17 Aug 2018 07:47:33 -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=Y35VA16xij8EgZ5RL3VtccVIEh8rbyZByDdSDKNU1r4=; b=K/GGRnyM+CQ3KbFYSwY+akzY08wqHTqj2udcaedsdyoSDJJKOew93+aOKvY7xlPlCciM T2jGGg3L+O7acqb+DX88Jnf6M92TTSsnFUNvFz7GWZh2XSq48ibLbX8iy0Yl/q/34GVQ sO2LzarlfUbGFVYmh6Opd+dhjdX3+u7hOfM= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2kwueugq8j-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Aug 2018 07:47:33 -0700 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 17 Aug 2018 07:47:32 -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:X-MS-Exchange-SenderADCheck; bh=Y35VA16xij8EgZ5RL3VtccVIEh8rbyZByDdSDKNU1r4=; b=OVBqDyqU7RLfHvLPhlkwEFYC3WzcnSojXitZZmw62e942zPhgTDzysmlSgKclzWLh3fVcx0S/VYp/rKBfE1UZ+CVT3VIHX1K9+1GU8bF7tNeuK1oU1HoAMT6yDaQlQCqwq+i7CqDdaTP9mWBqn+Cj4PBJ7NiccZczs1ngOVYFoU= Received: from BYAPR15MB2312.namprd15.prod.outlook.com (52.135.197.146) by BYAPR15MB2485.namprd15.prod.outlook.com (52.135.194.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.23; Fri, 17 Aug 2018 14:47:31 +0000 Received: from BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::9cb7:21b7:1e7e:b7c1]) by BYAPR15MB2312.namprd15.prod.outlook.com ([fe80::9cb7:21b7:1e7e:b7c1%4]) with mapi id 15.20.1038.025; Fri, 17 Aug 2018 14:47:31 +0000 From: Roberto Peon To: Dmitri Tikhonov , =?utf-8?B?QmVuY2UgQsOpa3k=?= CC: "quic@ietf.org" Subject: Re: QPACK ordering guarantee? Thread-Topic: QPACK ordering guarantee? Thread-Index: AQHUNjVW2zU3aeaIW0WkX1S5WK3PH6TEAc0A//+O4QA= Date: Fri, 17 Aug 2018 14:47:31 +0000 Message-ID: <9DDEFF9E-1478-488D-AB02-7DA5A2BDEEEF@fb.com> References: <20180817143204.GA9133@ubuntu-dmitri> In-Reply-To: <20180817143204.GA9133@ubuntu-dmitri> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-originating-ip: [2620:10d:c090:200::7:398] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR15MB2485; 20:wHlvPwliiibCSjRFGdlzPxWtgvSfWL+/vTpIVKdC1dNCaf15v8cB/mwt2xlatZ94/B+WOrCfRYwVACEqjlOmMGzr49yWmGYnngthh2HkZ6KBD2c1T6yyfGdYHMqSv0VjBcPiR+rXGmY2aLiKs5clj9ghUyxIS9YP2E4H4qfI9YU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 33eb55f7-2222-4fc1-960e-08d604505c4f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB2485; x-ms-traffictypediagnostic: BYAPR15MB2485: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231311)(11241501184)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699016); SRVR:BYAPR15MB2485; BCL:0; PCL:0; RULEID:; SRVR:BYAPR15MB2485; x-forefront-prvs: 076777155F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(396003)(346002)(136003)(366004)(376002)(199004)(189003)(97736004)(256004)(8676002)(316002)(58126008)(110136005)(105586002)(7736002)(68736007)(14444005)(14454004)(86362001)(81156014)(4326008)(25786009)(305945005)(81166006)(106356001)(486006)(446003)(11346002)(476003)(6116002)(6246003)(3480700004)(2616005)(8936002)(186003)(46003)(99286004)(102836004)(6512007)(478600001)(6486002)(5250100002)(36756003)(53936002)(6506007)(76176011)(82746002)(6436002)(2906002)(33656002)(7116003)(2900100001)(229853002)(83716003)(5660300001)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR15MB2485; H:BYAPR15MB2312.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: JwvV5oEvpL2cvieLCM5E5cuMtHdNoAtcadXwua/F8aVw8vH6pFhdDtA5XKoDreL5H9eUdkukNCOTXiaHnO4iXeiofTiZbJHd6h+oHU8FB07qnnreMJkbw3DZQ453oGawwnt3f1JhvReMazEVi7aLxWJi/O5Ol4xL6CWe5cOgxMKVj9384AizdsyRFyQD01I5rmXmomvfW5XcYPxjFPhOQpiscJLKr5kknSHWPCC5qWdEoY9aS1Y3hYpKPmhd8MpAKo9m3cD3LFKdWfAc8CanGk+QtM8MPOGBhfWl/QSxMFVSHXCUKyAfT/0TOKe79DcerR89IukCwAk7lQ2ZwoJ98HoYX/ZffbYF861w6+u2fqw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <214150803EFD3A45B061B946FA4EB3F5@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 33eb55f7-2222-4fc1-960e-08d604505c4f X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2018 14:47:31.0555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2485 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-17_04:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 14:47:45 -0000 R3JlYXQgY2F0Y2ghDQoNCkkgc3VzcGVjdCB3ZSBzaG91bGQgYmUgc2F5aW5nIHNvbWV0aGluZyBh bG9uZyB0aGUgbGluZXMgb2Y6DQogIFRoZSBvcmRlcmluZyB3aXRoaW4gYSBoZWFkZXIgbGlzdCBN VVNUIGJlIG1haW50YWluZWQsIHdoaWxlIHRoZSBvcmRlcmluZyBiZXR3ZWVuIGhlYWRlcnMgbGlz dHMgYW5kIGhlYWRlciBibG9ja3MgTUFZIE5PVCBiZS4NCg0KLT1SDQoNCu+7v09uIDgvMTcvMTgs IDc6MzMgQU0sICJRVUlDIG9uIGJlaGFsZiBvZiBEbWl0cmkgVGlraG9ub3YiIDxxdWljLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbT4gd3Jv dGU6DQoNCiAgICBPbiBGcmksIEF1ZyAxNywgMjAxOCBhdCAxMDoxODozOEFNIC0wNDAwLCBCZW5j ZSBCw6lreSB3cm90ZToNCiAgICA+IEkgcHJvcG9zZSB0byBhZGQgbGFuZ3VhZ2Ugb24gdGhlIHJl cXVpcmVtZW50IHRvIHByZXNlcnZlIG9yZGVyLCBhbmQgdG8NCiAgICA+IHVzZSB0aGUgZXhwcmVz c2lvbiAiaGVhZGVyIGxpc3QiIGluc3RlYWQgb2YgImhlYWRlciBzZXQiIHRocm91Z2hvdXQuDQog ICAgPiBUaGUgY2xhdXNlICJoZWFkZXIgbGlzdCAuLi4gY2FuIGNvbnRhaW4gZHVwbGljYXRlIGhl YWRlciBmaWVsZHMiDQogICAgPiBzaG91bGQgcHJvYmFibHkgYWxzbyBiZSBpbmNsdWRlZC4NCiAg ICANCiAgICBJIHN1cHBvcnQgdGhpcyBjaGFuZ2UuDQogICAgDQogICAgSW4gYWRkaXRpb24sIHRo ZSAiZnVsbCBjb2xsZWN0aW9uIiBhc3BlY3QgaXMgbm90IHF1aXRlIGNvcnJlY3Q6DQogICAgDQog ICAgICAgSGVhZGVyIHNldDogIFRoZSBmdWxsIGNvbGxlY3Rpb24gb2YgaGVhZGVycyBhc3NvY2lh dGVkIHdpdGggYW4gSFRUUA0KICAgICAgICAgIG1lc3NhZ2UuDQogICAgDQogICAgICAgSGVhZGVy IGJsb2NrOiAgVGhlIGNvbXByZXNzZWQgcmVwcmVzZW50YXRpb24gb2YgYSBoZWFkZXIgc2V0Lg0K ICAgIA0KICAgIFNpbmNlIHRoZXJlIG1heSBiZSBtb3JlIHRoYW4gb25lIGhlYWRlciBibG9jayBh c3NvY2lhdGVkIHdpdGgNCiAgICBhbiBIVFRQIG1lc3NhZ2UsIGEgc2luZ2xlICJoZWFkZXIgc2V0 IiBkb2VzIG5vdCBhbHdheXMgY29udGFpbg0KICAgIHRoZSBmdWxsIGNvbGxlY3Rpb24gb2YgaGVh ZGVycy4NCiAgICANCiAgICAgIC0gRG1pdHJpLg0KICAgIA0KICAgIA0KDQo= From nobody Fri Aug 17 08:14:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439E7130E4D for ; Fri, 17 Aug 2018 08:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.52 X-Spam-Level: X-Spam-Status: No, score=-9.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=srXIaySO; dkim=pass (1024-bit key) header.d=chromium.org header.b=nVpHsySo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5-7_Y2p32eM for ; Fri, 17 Aug 2018 08:14:19 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73841130F4F for ; Fri, 17 Aug 2018 08:14:19 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id r15-v6so5914458uao.1 for ; Fri, 17 Aug 2018 08:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=mX9ySUBr/v3JpaYALj+5i3c6ucrRXeqwmJ4BugQVukg=; b=srXIaySOmHRN6PqaYAuDXBvSBJGHtNo+H/MobwbcHT+TPzPC91ItsCzWtSNtgjgcxc SBlSNcMIyZZoGpMWsCmpuvr/fJ926kUYgy34qOWZMTedaoVT7DfiYxrZqpaapsMFGt1f SNbEA+DjTSH1Kumcuelsck98E1lZMZ/yWqQbvutxvOW/2uWcSurXUGPLO+50t+Mi8jl8 Vt+Ht3jcFCwEmbOdvae8ahfGjcu37ZMyMtgU2tNaAkVc68x2jgGxoWK3FZxh7gHLkFz1 sxNjuRXA7dPx+/3CqTCi4sz1jCTPLeSNpDPEZNsvOcxr20L/kUCOK193aNfvu9W/Pfqc hg1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:from:date:message-id:subject:to; bh=mX9ySUBr/v3JpaYALj+5i3c6ucrRXeqwmJ4BugQVukg=; b=nVpHsySok8Ef3udG+0khJGN7AbGYCPFnu0OW9xo37yHib1vZTTDj61q7TxbUBIJZOD Sg0LrjdqAFLyKHRwhqZL2Q/z/2VWkzICw2b8k5dntME5r9Bk7tKK3BOPS6PIidM0HqGo +ZRrEqHBSuoXF5LLcZ7li4993WuaACZmY96FU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=mX9ySUBr/v3JpaYALj+5i3c6ucrRXeqwmJ4BugQVukg=; b=AarA+EX8PWqjer8jKauCHarXKSpdVQdQ+k62/1cAhM3WVWQVABfGVVTtyRn4G4V3Hg zuLdVG7XyFsTpkY4CZ6IlWIBoSKE0ToDCUU2iwyvi+Wy/LYgD4YcLSn2HBKbX/Q5uMwK xKSVOmFOlzV7CfgUy0bYnXzCAMUbrrTaWlzCHMc9+Bh+rr9A2HI0A74IJxqxsi/WOPcO YMsDS1zIrlfyzhvC94wJi9h4PE9/rrpD7BVrc7yA7QFXmns+G6r9cuUOHJpq/NjlFsrh nJoMG0YOq9Ry1O89XjFgX8lHLtulYXnttuAVrvQieuOEiHcZPZXar+RfGv/IZlvuZKnF vGdA== X-Gm-Message-State: AOUpUlENU4jh6TehcpFI5Yc2SXvAgCAF6PjrutWGPTA9NXIcDrdufurq I76ZVwQTYiZE7vagr3xDr1SB/Oo9dubj4tDK8fhdiFdb2G0= X-Google-Smtp-Source: AA+uWPxrSLQgX+7n0ByY3/3TUQ06ZEzT8Qj3bpdaXoStpos8cD7mCun91IvOP6HM3/188uJl2ObIKs2fC8hnClWgJBw= X-Received: by 2002:ab0:240b:: with SMTP id f11-v6mr22629407uan.137.1534518857952; Fri, 17 Aug 2018 08:14:17 -0700 (PDT) MIME-Version: 1.0 Sender: bnc@google.com Received: by 2002:a67:3593:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 08:13:57 -0700 (PDT) From: =?UTF-8?Q?Bence_B=C3=A9ky?= Date: Fri, 17 Aug 2018 11:13:57 -0400 X-Google-Sender-Auth: LfxDCLLaNhvwtL4rrtUIdCaw-e0 Message-ID: Subject: QPACK: how to handle bogus data on encoder or decoder stream To: quic@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 15:14:22 -0000 Hi, It is possible for a peer to receive invalid data on the encoder or decoder stream. For example, on the encoder stream, a Duplicate instruction might address an already evicted entry. Or on the decoder stream, a Table State Synchronize might contain an Insert Count exceeding the total number of applicable inserts and duplications, or the Header Acknowledgement might contain a Stream ID for which there are no unacknowledged header blocks. As far as I can tell, the spec currently gives no direction on what should happen in such cases. I propose that these should be treated as connection errors. HTTP_QPACK_DECOMPRESSION_FAILED seems like a relevant error code, but it does not really match any of these cases (strictly speaking, these errors do not happen during decompression), especially incorrect data on the decoder stream (because it is the encoder, not the decoder, that detects the error). Should there be one error code covering all these cases, something like HTTP_QPACK_ERROR? Or should there be multiple, like HTTP_QPACK_DECOMPRESSION_FAILED for errors on HEADERS and PUSH_PROMISE frames, and self-explanatory HTTP_QPACK_ENCODER_STREAM_ERROR and HTTP_QPACK_DECODER_STREAM_ERROR? Bence From nobody Fri Aug 17 11:07:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97255130F9A for ; Fri, 17 Aug 2018 11:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CEkLccvMlwk for ; Fri, 17 Aug 2018 11:06:53 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 97AA913103B for ; Fri, 17 Aug 2018 11:06:51 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w7HI6g4L003916; Fri, 17 Aug 2018 11:06:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=3Dcet5pyJ+YPaV7mu5+Vu0j640PvqBSmA7g1F5/QobY=; b=VRTDJD8bfa76Z14dFJTLjwWER5KrUsYxs5qGHZx5mafcdGBsq/QFKbFRKonVwmqboqBc NOoVeaecVSJObfL99+zJ5ksRZBrC6UqsiNMqYFRTt6Oo2OGED+8mY4xax81ahnL7tjAI f8ejymj6TJkNNTPZVSwSy4HcLt62ax+UTVHuxE9uv9SXE50ZwewT35UIB/yqOY8jn3eY LYIcZyFR4OeEk5YnhJl9Fhud/cL7MVqxz34tkziGfn8Vk6VOCRg3y855QU7so8NzeSFX DgSl2VPSMGrIXkBmGjvAaBW47tb6JvhHu5rVtdx3miNHLKx+h/2yHM2OU8U88UTAIRD7 eg== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2ksxt0myf6-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 17 Aug 2018 11:06:44 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_iU/JAQrU54yMMGDWd1ybtw)" Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PDM005NAAB2TB60@mr2-mtap-s02.rno.apple.com>; Fri, 17 Aug 2018 11:06:38 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PDM00200A30ZK00@nwk-mmpp-sz09.apple.com>; Fri, 17 Aug 2018 11:06:38 -0700 (PDT) X-Va-A: X-Va-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-Va-E-CD: 62c1f1059e3efb7b3cd09beda357c933 X-Va-R-CD: 5924d7c314759fcfb8af58b16a7d074b X-Va-CD: 0 X-Va-ID: f55504c6-b28c-46d2-9711-01a5be833af3 X-V-A: X-V-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-V-E-CD: 62c1f1059e3efb7b3cd09beda357c933 X-V-R-CD: 5924d7c314759fcfb8af58b16a7d074b X-V-CD: 0 X-V-ID: d79a0344-8a8d-48fa-8b3c-f07a6d396e41 Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PDM00200A2KWK00@nwk-mmpp-sz09.apple.com>; Fri, 17 Aug 2018 11:06:37 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-17_05:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from [17.230.163.133] (unknown [17.230.163.133]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PDM00H84AB15840@nwk-mmpp-sz09.apple.com>; Fri, 17 Aug 2018 11:06:37 -0700 (PDT) Sender: rpaulo@apple.com Subject: Re: Did the crypto change with draft-tls-14? From: Rui Paulo X-Mailer: iPhone Mail (16A357) In-reply-to: Date: Fri, 17 Aug 2018 11:06:36 -0700 Cc: Christian Huitema , IETF QUIC WG , Martin Thomson , Sean Turner Message-id: <5926294B-E0BF-4C7A-AC82-218074B41ED7@apple.com> References: <6dbdfa4e-b897-8765-2f64-ccaa7df007b7@huitema.net> To: Eric Rescorla X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-17_05:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 18:07:02 -0000 --Boundary_(ID_iU/JAQrU54yMMGDWd1ybtw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Thanks for the explanation! I was having a hard time figuring this one out := -) =E2=80=94 Rui Paulo > On Aug 16, 2018, at 10:20, Eric Rescorla wrote: >=20 > What happened here is that the text in -13 was just wrong, because HKDF-Ex= pand-Label() takes 4 arguments. >=20 > And when I changed it from QHKDF-Expand, I just forgot. So, it's an editor= ial change in that -13 and -14 should have the same crypto. A technical chan= ge in that -13 couldn't be implemented w/o this correction.. >=20 > -Ekr >=20 >=20 >> On Thu, Aug 16, 2018 at 9:57 AM, Christian Huitema w= rote: >> Looking at the changes between draft-ietf-quic-tls-13 and >> draft-ietf-quic-tls-14, I see that HKDF-Expand-Label specifications have >> grown an extra empty string parameter, e.g. change from: >>=20 >> client_initial_secret =3D HKDF-Expand-Label(initial_secret, "client >> in", Hash.length) >>=20 >> To: >>=20 >> client_initial_secret =3D HKDF-Expand-Label(initial_secret, >> "client in", "", >> Hash.length) >>=20 >> The empty string is also present in the latest TLS-13 drafts and in RFC >> 8446, and the spec did say that the keys "are computed in the same >> fashion as the corresponding TLS keys". I assume that the change in spec >> there is purely editorial, and that the existing test vector remains >> valid (except for the version number). Is that correct? >>=20 >> -- Christian Huitema >>=20 >>=20 >=20 --Boundary_(ID_iU/JAQrU54yMMGDWd1ybtw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Thanks for the explanation! I was having a h= ard time figuring this one out :-)

=E2=80=94
Rui Paulo

On Aug 16, 2= 018, at 10:20, Eric Rescorla <ekr@rtfm.co= m> wrote:

What happened here is that the text in -13 was just wrong= , because HKDF-Expand-Label()  takes 4 arguments.

<= div>And when I changed it from QHKDF-Expand, I just forgot. So, it's an edit= orial change in that -13 and -14 should have the same crypto. A technical ch= ange in that -13 couldn't be implemented w/o this correction..

-Ekr

On Thu, Aug 16, 2018 at 9:57 AM, Christian Huit= ema <huitema@huitema.net> wrote:
Looking at the changes between draft-ietf-quic-tls-13 and
draft-ietf-quic-tls-14, I see that HKDF-Expand-Label specifications have
= grown an extra empty string parameter, e.g. change from:

   client_initial_secret =3D HKDF-Expand-Label(initial_secret= , "client
in", Hash.length)

To:

   client_initial_secret =3D HKDF-Expand-Label(initial_secret= ,
            &nbs= p;            &n= bsp;           &= nbsp;       "client in", "",
            &nbs= p;            &n= bsp;           &= nbsp;       Hash.length)

The empty string is also present in the latest TLS-13 drafts and in RFC
8446, and the spec did say that the keys "are computed in the same
fashion as the corresponding TLS keys". I assume that the change in spec
= there is purely editorial, and that the existing test vector remains
valid (except for the version number). Is that correct?

-- Christian Huitema



= --Boundary_(ID_iU/JAQrU54yMMGDWd1ybtw)-- From nobody Fri Aug 17 16:14:55 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E105C130FB5 for ; Fri, 17 Aug 2018 16:14:52 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=hnYcd7dB; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=TgqZDPZ8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvPgOCWZkwau for ; Fri, 17 Aug 2018 16:14:51 -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 30E18130E02 for ; Fri, 17 Aug 2018 16:14:51 -0700 (PDT) Received: from pps.filterd (m0148460.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7HNEelj006709; Fri, 17 Aug 2018 16:14:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=adGSARfUUpPQhsB+sVKjHnDwIm5mcTXT25i0wP4hNN8=; b=hnYcd7dBMx1JzUY8/BO/Uh1M9n1K5ogQHHVGo8b6PJODzKwbeiE4VVtMHWFxAIM3wg3B TaPFV+yqwpDodyj4jpQme35YAjTqEA7nYE1ISazm1xt4k6C2vI4NarQ0lQB4AQqnhRQZ ID74OGKp55ahqD1tpqrrodmt9Ok5jjsaaok= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2kx5m6rb9f-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Aug 2018 16:14:46 -0700 Received: from NAM04-SN1-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; Fri, 17 Aug 2018 19:14:44 -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:X-MS-Exchange-SenderADCheck; bh=adGSARfUUpPQhsB+sVKjHnDwIm5mcTXT25i0wP4hNN8=; b=TgqZDPZ8IqdSO/nPXtqkwMJUmLK3bTQAsnMmBawgJ+94/aoB9lFIWOZQcplWDLh7RQWJb2ULOJ0TDQUG29l4tVshBD9Re6WEZ/PhxE31geA4zfjakum6Jpw+Akm5/CmcLi3H6nRQxxI/ChluYdxhu6muSvgKIj1wCiRIQqDDuw8= Received: from MWHPR15MB1181.namprd15.prod.outlook.com (10.175.2.135) by MWHPR15MB1582.namprd15.prod.outlook.com (10.173.235.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.25; Fri, 17 Aug 2018 23:14:43 +0000 Received: from MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::7079:d902:8876:1e8]) by MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::7079:d902:8876:1e8%9]) with mapi id 15.20.1059.021; Fri, 17 Aug 2018 23:14:43 +0000 From: Alan Frindell To: =?utf-8?B?QmVuY2UgQsOpa3k=?= , "quic@ietf.org" Subject: Re: QPACK: how to handle bogus data on encoder or decoder stream Thread-Topic: QPACK: how to handle bogus data on encoder or decoder stream Thread-Index: AQHUNj0N243A4+Hzn0CBq1w8uJDUi6TEHlUA Date: Fri, 17 Aug 2018 23:14:43 +0000 Message-ID: <67AEE8C2-00DD-44A5-B7C5-84520B2F7F0F@fb.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/10.f.0.180709 x-originating-ip: [2620:10d:c090:200::4:7e69] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1582; 20:FhwQr0XOUkrIAzAKz2pMrvaATZed/j+TwAYw99prip6EFtJRXzx2wK7VJkNrZ+cZcaisC5PDz4MkHOxHf39PmMDcBqayyut3a4IjV3EP9+kQKF5hae4d8cSBRIaYT10yTAhrvdqHXAoPu4YprfsH8rZFfes8FV9zNOVjX/45CT8= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8ac7daa4-3c0a-41b8-3e6a-08d60497374e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1582; x-ms-traffictypediagnostic: MWHPR15MB1582: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231311)(11241501184)(944501410)(52105095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699016); SRVR:MWHPR15MB1582; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1582; x-forefront-prvs: 076777155F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(39860400002)(346002)(376002)(189003)(199004)(14454004)(33656002)(6486002)(2906002)(68736007)(8936002)(478600001)(5660300001)(83716003)(6116002)(229853002)(2900100001)(11346002)(2616005)(46003)(446003)(476003)(6246003)(486006)(97736004)(305945005)(7736002)(8676002)(25786009)(105586002)(106356001)(53936002)(6512007)(86362001)(82746002)(36756003)(6436002)(81166006)(256004)(6506007)(81156014)(102836004)(110136005)(5250100002)(99286004)(76176011)(2501003)(186003)(58126008)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1582; H:MWHPR15MB1181.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9skffQJLk6gthVtrOUH+vgF+QcsVyG3R9bV/tr7q0pxxLfCA3hOA74Zts6ITLMXq38CGbCtbigL8dlY6bJ50UdCcaJw6S404ioJbnlUfXI4Xvy3zZXgDTFz8sURn/PeFZeg6ZcY8nHJXlYql18XRf0U/J/0h+w/39kzNA26PnWKLTdhx/YeBoXgUO8zKciyU2fT4sqV0A4E51TllSfAQniVGczZ1F1FkQ86MIupRarsU9dYVfY1INCAZmCD3M+g2O1JYo04ddIzyfafDvdcICwIzqs5gtdK/jy0gXTGMFxUaF6AlvUEGy7x+DeqgOW6G41ZF9RSI5gBjG5R6UpoTaW9Cxtxf+Whlx/6Mt/pFVdc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8ac7daa4-3c0a-41b8-3e6a-08d60497374e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2018 23:14:43.1829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1582 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-17_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 23:14:53 -0000 SSBiZWxpZXZlIHRoZSBpbnRlbnQgaXMgZm9yIHRob3NlIGVycm9ycyB0byBiZSBjb25uZWN0aW9u IGVycm9ycy4gIEFzIGZvciBlcnJvciBjb2RlcywgSSBrbm93IHRoZXJlJ3MgYmVlbiBzb21lIGJh Y2sgYW5kIGZvcnRoIGluIFFVSUMgYWJvdXQgd2hldGhlciBtb3JlIGVycm9yIGNvZGVzIGFyZSBy ZWFsbHkgdXNlZnVsLCBidXQgaW4gdGhpcyBjYXNlIEkgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIGRp c3Rpbmd1aXNoIGNvbnRyb2wgc3RyZWFtIGVycm9ycyBmcm9tIGRlY29kaW5nIGVycm9ycy4gIEkg b3BlbmVkIGlzc3VlICMxNjgzIHRvIHRyYWNrLg0KDQotQWxhbg0KDQrvu79PbiA4LzE3LzE4LCA4 OjE0IEFNLCAiUVVJQyBvbiBiZWhhbGYgb2YgQmVuY2UgQsOpa3kiIDxxdWljLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGJuY0BjaHJvbWl1bS5vcmc+IHdyb3RlOg0KDQogICAgSGksDQog ICAgDQogICAgSXQgaXMgcG9zc2libGUgZm9yIGEgcGVlciB0byByZWNlaXZlIGludmFsaWQgZGF0 YSBvbiB0aGUgZW5jb2RlciBvcg0KICAgIGRlY29kZXIgc3RyZWFtLiAgRm9yIGV4YW1wbGUsIG9u IHRoZSBlbmNvZGVyIHN0cmVhbSwgYSBEdXBsaWNhdGUNCiAgICBpbnN0cnVjdGlvbiBtaWdodCBh ZGRyZXNzIGFuIGFscmVhZHkgZXZpY3RlZCBlbnRyeS4gIE9yIG9uIHRoZSBkZWNvZGVyDQogICAg c3RyZWFtLCBhIFRhYmxlIFN0YXRlIFN5bmNocm9uaXplIG1pZ2h0IGNvbnRhaW4gYW4gSW5zZXJ0 IENvdW50DQogICAgZXhjZWVkaW5nIHRoZSB0b3RhbCBudW1iZXIgb2YgYXBwbGljYWJsZSBpbnNl cnRzIGFuZCBkdXBsaWNhdGlvbnMsIG9yDQogICAgdGhlIEhlYWRlciBBY2tub3dsZWRnZW1lbnQg bWlnaHQgY29udGFpbiBhIFN0cmVhbSBJRCBmb3Igd2hpY2ggdGhlcmUNCiAgICBhcmUgbm8gdW5h Y2tub3dsZWRnZWQgaGVhZGVyIGJsb2Nrcy4gIEFzIGZhciBhcyBJIGNhbiB0ZWxsLCB0aGUgc3Bl Yw0KICAgIGN1cnJlbnRseSBnaXZlcyBubyBkaXJlY3Rpb24gb24gd2hhdCBzaG91bGQgaGFwcGVu IGluIHN1Y2ggY2FzZXMuDQogICAgDQogICAgSSBwcm9wb3NlIHRoYXQgdGhlc2Ugc2hvdWxkIGJl IHRyZWF0ZWQgYXMgY29ubmVjdGlvbiBlcnJvcnMuDQogICAgDQogICAgSFRUUF9RUEFDS19ERUNP TVBSRVNTSU9OX0ZBSUxFRCBzZWVtcyBsaWtlIGEgcmVsZXZhbnQgZXJyb3IgY29kZSwgYnV0DQog ICAgaXQgZG9lcyBub3QgcmVhbGx5IG1hdGNoIGFueSBvZiB0aGVzZSBjYXNlcyAoc3RyaWN0bHkg c3BlYWtpbmcsIHRoZXNlDQogICAgZXJyb3JzIGRvIG5vdCBoYXBwZW4gZHVyaW5nIGRlY29tcHJl c3Npb24pLCBlc3BlY2lhbGx5IGluY29ycmVjdCBkYXRhDQogICAgb24gdGhlIGRlY29kZXIgc3Ry ZWFtIChiZWNhdXNlIGl0IGlzIHRoZSBlbmNvZGVyLCBub3QgdGhlIGRlY29kZXIsDQogICAgdGhh dCBkZXRlY3RzIHRoZSBlcnJvcikuICBTaG91bGQgdGhlcmUgYmUgb25lIGVycm9yIGNvZGUgY292 ZXJpbmcgYWxsDQogICAgdGhlc2UgY2FzZXMsIHNvbWV0aGluZyBsaWtlIEhUVFBfUVBBQ0tfRVJS T1I/ICBPciBzaG91bGQgdGhlcmUgYmUNCiAgICBtdWx0aXBsZSwgbGlrZSBIVFRQX1FQQUNLX0RF Q09NUFJFU1NJT05fRkFJTEVEIGZvciBlcnJvcnMgb24gSEVBREVSUw0KICAgIGFuZCBQVVNIX1BS T01JU0UgZnJhbWVzLCBhbmQgc2VsZi1leHBsYW5hdG9yeQ0KICAgIEhUVFBfUVBBQ0tfRU5DT0RF Ul9TVFJFQU1fRVJST1IgYW5kIEhUVFBfUVBBQ0tfREVDT0RFUl9TVFJFQU1fRVJST1I/DQogICAg DQogICAgQmVuY2UNCiAgICANCiAgICANCg0K From nobody Fri Aug 17 16:17:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED1E130E08 for ; Fri, 17 Aug 2018 16:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_02=0.437, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uazEMxwXYfJj for ; Fri, 17 Aug 2018 16:17:19 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E531130E02 for ; Fri, 17 Aug 2018 16:17:19 -0700 (PDT) Received: from [67.219.250.102] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-a.us-west-2.aws.symcld.net id 58/C9-25586-E77577B5; Fri, 17 Aug 2018 23:17:18 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRWlGSWpSXmKPExsWS8eIhk25deHm 0wfQTohatK94zOjB6PHr2hjmAMYo1My8pvyKBNWPWlf+MBS13eCs2bpvA2MB4eD9vFyMXh5DA S0aJpxN+MkE40xklTp6ZztzFyMnBJqAtsW/mP0YQW0RAX+L2j1ssILawgJHEijuPWCHi5hInF nQxQdhGEv+WbwGrZxFQlXix/QeYzStgK9H/aSIbiC0k4CNxbM5kdhCbU8BXYvXBx2C9jAKyEt Me3QezmQXEJeZOmwU2X0JAROLhxdNsELaoxMvH/1ghaqIkrh2EuIFXQFDi5MwnLBMYBWchaZ+ FpGwWkjKIeIJE+4IfbBC2jsSC3Z+gbG2JZQtfM8PYZw48ZsIU15H4/a0Lql5R4vbVqUDzuYDs lYwSc3fuYoJJTOl+yL6AkWcVo3lSUWZ6RkluYmaOrqGBga6hoZGuoZGFrrG5XmKVbqJeabFue Wpxia6RXmJ5sV5xZW5yTopeXmrJJkZg1DIAwQ7GTy9SDjFKcjApifKmh5VHC/El5adUZiQWZ8 QXleakFh9ilOHgUJLglQfJCRalpqdWpGXmANMHTFqCg0dJhJcLmEKEeIsLEnOLM9MhUqcYLTm O3JsyiZnjApj8837qJGYhlrz8vFQpcd7/IPMEQBoySvPgxsFS3CVGWSlhXkagA4V4ClKLcjNL UOVfMYpzMCoJ864DmcKTmVcCt/UV0EFMQAdNEygFOagkESEl1cC49/0SSZ+1jwVNvlUa856X1 3hUEXvxaWVRou0DhoWrr101KXdaNut1qnWbhf+Eoz8/JT/693SCbvLvR6bnpl1ps3n8iune98 hvGzR3RCRX5zfYS/ya2bp/066zsfevvZ11a4ppc+jFUL3lt3gEBHWcrlYJG1RLvtuZk9+unNz e2332wcWFq6w3KLEUZyQaajEXFScCAKKuQfFsAwAA X-Env-Sender: changzhi2@lenovo.com X-Msg-Ref: server-2.tower-326.messagelabs.com!1534547835!2457147!1 X-Originating-IP: [104.232.225.2] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 732 invoked from network); 17 Aug 2018 23:17:17 -0000 Received: from unknown (HELO maesmtp01.lenovo.com) (104.232.225.2) by server-2.tower-326.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 17 Aug 2018 23:17:17 -0000 Received: from CNMAILCH02.lenovo.com (unknown [10.96.97.130]) by maesmtp01.lenovo.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4d4c_d5dc_d6834401_caf0_48dc_aaad_0ff3ef9192b9; Fri, 17 Aug 2018 23:17:09 +0000 Received: from CNMAILEX03.lenovo.com ([169.254.11.183]) by CNMAILCH02.lenovo.com ([::1]) with mapi id 14.03.0389.001; Sat, 18 Aug 2018 07:16:45 +0800 From: Zhi Zhi2 Chang To: "quic@ietfa.amsl.com" Subject: Same packet number in a QUIC connection ? Thread-Topic: Same packet number in a QUIC connection ? Thread-Index: AdQ19DPcZrzOeqm3R6SZpqdlxcdaWAAjCmCP Date: Fri, 17 Aug 2018 23:16:45 +0000 Message-ID: <5DFAC0AB-2135-4792-A3A3-54D7D35B942A@lenovo.com> References: <7335E3E9AC2DE240988251CF62CAE90A0A236086@CNMAILEX03.lenovo.com> In-Reply-To: <7335E3E9AC2DE240988251CF62CAE90A0A236086@CNMAILEX03.lenovo.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_004_5DFAC0AB21354792A3A354D7D35B942Alenovocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 23:17:21 -0000 --_004_5DFAC0AB21354792A3A354D7D35B942Alenovocom_ Content-Type: multipart/alternative; boundary="_000_5DFAC0AB21354792A3A354D7D35B942Alenovocom_" --_000_5DFAC0AB21354792A3A354D7D35B942Alenovocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a question about " packet number ". I set up an environment about QUIC and I capture some QUIC packets by wires= hark. I find an insteresting phenomenon by watching these packets. Please w= atch this picture: [cid:image001.png@01D43635.2CFF1C30] In my environment, the server is 10.121.222.230 and the client is 10.116.47= .192. Why there are two identical packet which the PKN ( packet number ) is= the same ? Just like two " PKN: 2 " packets, two " PKN: 3 " packets. After my consideration, I find that the packet which client to server has "= CID " and the packet which server to client has no " CID ", for example "= PKN: 2 ". This is a pair of packets which client to server( PKN: 2 ) and server to cl= ient ( PKN: 2 ), isn't right? And the packet client to server has CID and t= he server to client packet has no CID ? Am I right ? Hope for reply. Thanks Zhi Chang --_000_5DFAC0AB21354792A3A354D7D35B942Alenovocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, I have a question about " packet number &qu= ot;.

 

I set up an environment about QUIC and I capture som= e QUIC packets by wireshark. I find an insteresting phenomenon by watching these packets. Please watch this picture:

3D"cid:image001.png@01D43635.2CFF1C30"

 

In my environment, the server is 10.121.222.230 and = the client is 10.116.47.192. Why there are two identical packet which the PKN ( packet number ) is the same ? Just like t= wo " PKN: 2 " packets, two " PKN: 3 " packets.

 

After my consideration, I find that the packet which= client to server has " CID " and the packet which server to client has no " CID ", for example  " = PKN: 2 ".

 

This is a pair of packets which client to server( PK= N: 2 ) and server to client ( PKN: 2 ), isn't right? And the packet client to server has CID and the server to client pa= cket has no CID ?

 

Am I right ?

 

 

Hope for reply.

 

 

Thanks

Zhi Chang

 


--_000_5DFAC0AB21354792A3A354D7D35B942Alenovocom_-- --_004_5DFAC0AB21354792A3A354D7D35B942Alenovocom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=160281; creation-date="Fri, 17 Aug 2018 23:16:45 GMT"; modification-date="Fri, 17 Aug 2018 23:16:45 GMT" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABjAAAAMnCAIAAAAf7owtAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAA/7VJREFUeF7snQlgFdW9/+feBNz3XSBEEsVQ3OpOIogFlwDFbmB5VLHlaZH3 opQ/LbXYPiVt7ePx0PQh1dIaLaVAaysFEYXKYkDrVlFrRBMIca8rrkCSe/+/c87M3DPLme3Ovbk3 fMdruJmc+c3vfM6ZM2d+8/v9TuL6m36XTifSWleatlQqrXWmutL3HzRUwwYCIAACIAACIAACIAAC IAACIAACIAACIAAC2RE4YcufE6Wl6URSSyZKNPonwbbrf/S7VEIjY5SW7kqRQSrd0dWV/ushF745 6+TsToejQQAEQAAEQAAEQAAEQAAEQAAEQAAEQAAE9moCx9W/1P/ZPyZLeqWTSa0kWUrWqDSzRyW7 Ep3pVJeWTmlaQtOSGnlL0a/YQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQCBrAmlyfUp1JtOdCeYP xSxP5BWVTJAZij7MRypFTlIscI/9FRsIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIZEsgRSmiyOSk kSGKfWH/pcgglSJfKfqaZlYptgcGqWxB43gQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAFBgIxQKY0y llOmKGaboi/kJJVkvlL8z2nmHpUi4xRllAIyEAABEAABEAABEAABEAABEAABEAABEAABEMieAHOP IgcoFpwn3KBYlF6SWaBoY35TtHXxvdmfCxJAAARAAARAAARAAARAAARAAARAAARAAARAgPk9MXMT 2aTIUYonkUrRWnsshRT9RmYpMkTRF/49G1q0Vt8Hn3ZufXv349s/f+9T5EfPhiWOBQEQAAEQAAEQ AAEQAAEQAAEQAAEQAIEiJ8CMTixLFNmhREpz+ilC9tgP7jSVSlLEHrNWhd7o6Dd37rnj0Y9rGt47 of7dwb94//xb3//zls9CC8IBIAACIAACIAACIAACIAACIAACIAACIAACPYWAsEaRRxQP16P/WBpz MkCxrFEp+ppI0q+URIrvD7f96+OOn635eNj/fVj3p51PtX6+69Pd2u7dxx/W9a2z9g8nCKVBAARA AARAAARAAARAAARAAARAAARAAAR6EgFKFMWMTbSqHtWK/mfWqaTwjhI76E9iKb5QtV738mf/9ruP GtZ93PbmZ7069/Tq2pPcs6fzk90/HLH/vr1LQolCYRAAARAAARAAARAAARAAARAAARAAARDYqwiw 1N7qLZ8oSIunn37aeUbaydKPR97I7qRbpFiuKLbsHoXokRWKf1iGc5ZfSjhQBd7+8PQnsx749Jlt n3744a7Szo7Enj3a7j3p3buTnbsvP/1AhZiW26uvfZD/7cFrEwn9K/uV/pCovr3FOMz4lf0rlTKl sv3WP/A9sghxDklmRiV2brG5/jkwAhQEARAAARAAARAAARAAARAAARAAARAAgSwIGOvP2f/NQmSU Q5966qnzq2tsNin6lXbSn6JI5Mek0l0Us0f/kh8U/7CdSZbjnLyiuBWKO0mFyCC18vlPG/++a9ub n3/80e6Szg5tz540++zu/Hz3sQekjjm0l4uuzAx01bLB2v3c9HTZ5ddoL7xsWKBaHli2Wdu87AHj 91de3Dxk3KhKVY2puDZkyF33C9uWuV1zzeAbrspYtRRHP3ht/aBXREOvGnzDiW72rsikcSAIgAAI gAAIgAAIgAAIgAAIgAAIgAAIFBuBM88887FNTbJNSlijaCf9KXptmPFF+EaxlfREFvMkWaDYh7tL pTUyWZG7FMso5btte2f37Rs/f+OdXe99sKu0q0OYojT67N7d9fmuQUcnS0vI/cqxXXZn+pVx2l13 abPSm66v1E4cNCRjgSID1DXXXLP5xVfEUS0vv+Bnjxp3z6xrHBapy2fcpvmapC67k52eb1armG/F UQAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEeiQB2SYVjzWKJYhiH26MYh+WKypFicwpk5RwjuJfxMd3 6+pK3bjyk88/62h58/OSrs50B7lHMQ8pitdjflK7dh1/cFIRXvjgtSe+OCu9SqvlTkmVo8YNMSxQ D95/1zWXzxhk+Dwxf6nBJ3n6R5H7FFmT7qq3+UNVXn8PmaQCez3ReTWPE/nCQAEQAAEQAAEQAAEQ AAEQAAEQAAEQAAEQ6CEETJtUDL5RLkjYknq0vp7+D08jxb8nNLYQn9+2dutnr73fSdaoFNmhKFiP DFIdzBSldexO79ml7fq8NL1HIYNcpO68TBM/dYuU8HHi9qjLmIVKBPExf6nLeRm37cE5N2g8nI8s UlKUn16UmaSG3CVsXt4bZZ2qveuaVUIZbCAAAiAAAiAAAiAAAiAAAiAAAiAAAnsLgcLJJt6ziRuc WWZzkUCK/qFV9sSHG6TSSeY85WeQ6uxK3fHo55/v6vjgoz3JVJfW2ckMUp0d6Q6K2tul7flc6/js 448/C0jTsECxAL1BJ3KfKY2lkSL7FP/dfWN/1dNLuVqktCAmKZYC/cRl417RbWMBFUYxEAABEAAB EAABEAABEAABEAABEACBHkBAlUpcz3LUA2oYqQpmpJ4tn1QkYdaDhGmKOUWlkpTPvCstPin+SXT5 pZB67vXd73yceuO9PVoXt0aRhxSL2mPuUVrHrnTHLq1r17b29/mSfQG2ypMGU9Aey1AuLEz6754J pFiU3eYbThQVqWXf5zicoQyT1P0Kk9a1CRY7yDNZYQMBEAABEAABEAABEAABEAABEAABEAABEJDz RjlznEflw2LyEokS5ghFblDMUYp8oyhKjyxTPMFUOunnHMXP/Octu3bv6dr5SUeC7Fed7MNsUuQh 1bkn1bk7RR5Snbu273hnz57OYIqyNFD3z3lRt0fxIDzL704pzB51zaqMJXPVNZojtTkzbfHAPUqg 7txabq9HoF6w5kEpEAABEAABEAABEAABEAABEAABEACBvYGAM4t5LDYp7hOVok+SltYjQxSzPyUo Ro/tY6mjOFpft7RdHV2btne8s7Pj891dyXSKkqLTz67Ozs6OPV3kIdW5Z9+SrmMOKaGf734QNGqP WaDuuiuTV9z+O1Psrloj5LD69tuZPUpOL8XWyXOzSAmTlFufoQRVkkgSHSDd1N7Q91BHEAABEAAB EAABEAABEAABEAABEACBfBNQZbPKsx5nnXUWhemREUo+r7BJ0Z+yUYavs0e15HmjeNRe4tqZvxFG qBStnMcsS3u6OjseOX7Mm7NOdj1T6zsdoxa8Q2vq9T84fdR+Wi9yi9q1Z+fOzz775LOu3bt6Jzp3 7/p839L0Afsmf/Cdc847vW826uJYEAABEAABEAABEAABEAABEAABEAABEACB4iVwXP1LfZ66pyTZ K1lSmighY1QpW1iPvunOUZl0Tyx+z6Oej7zwr9Mrjx435LgzKo8+7ujD+hxz+En9jzpj4LFnfeH4 C88uP+MLfc4Y1Leq8rjjjj5849Nvfvjhh8WLDJqDAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAhkSUBk jSIhiTR92Fp6FKdH2aTYunos/zgL3hNFvAxSx3a0fO2Ip49+9+FjPlzT55NHjvho3f7vrz9692Pl Jf84susf/fd5aeBhbRWHtp/e91+HlbR9AINUlo2Gw0EABEAABEAABEAABEAABEAABEAABECgqAnw iMQkpY9iacyF3SmR+PcZv6V4PS2dopg9itrrSndRyN7fjq9VhewVNQEoDwIgAAIgAAIgAAIgAAIg AAIgAAIgAAIgkDcCFLLX9+lFpSxkryShldBPFqSXSFLwnsgrpWsi5TfPm244EQiAAAiAAAiAAAiA AAiAAAiAAAiAAAiAQM8kQAvqMZ8oZohKUQ5zVsmElhR1FRF72EAABEAABEAABEAABEAABEAABEAA BEAABEAgTgIscZQwSnGPKBHBR7mkWDopZp1KUChfWiO7lW6livPckAUCIAACIAACIAACIAACIAAC IAACIAACILD3ESCfqFRC62IGKG56SrAc5oaHlAjV88pmvvcBQ41BAARAAARAAARAAARAAARAAARA AARAAASyI8AtUMwmlU4mUomSBPsYBilTMmU8p092J8LRIAACIAACIAACIAACIAACIAACIAACIAAC IMAI2MxMwiMqE50njFWpRIo+AAYCIAACIAACIAACIAACIAACIAACIAACIAACOSKQMUjxlFIiuzly SOWINsSCAAiAAAiAAAiAAAiAAAiAAAiAAAiAwN5MQPeCytieKJk5belEkvyksIEACIAACIAACIAA CIAACIAACIAACIAACIBA9gTI9kQfWkdP3jIGqTQZoxCrlz1mSAABEAABEAABEAABEAABEAABEAAB EAABEHAjwOPzKDYvzfyiLB+WWgrMQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQCAnBJhJSl94T88e RcYo9h82EAABEAABEAABEAABEAABEAABEAABEAABEIiDgJ4cirtGsdg98UVL6zaohMYK2GL64jgv ZIAACIAACIAACIAACIAACIAACIAACIAACOy9BNhKesIuJX7qOaS4TUp4RtF+ZDXfezsIag4CIAAC IAACIAACIAACIAACIAACIAACsRMgqxPzjTJsTyzNuWmHSrMEUmSwCm6Qarm9OnHtgwolH7y2+vaW zN8evFZdNPZq2k5Gv1p0EeczFGS1sG7KOsWoKJ3VOA2pZ92Esk69LKVcahSjeoaojG5CWwHN1rYS TOM4Uj4/Csp1dqjFd0ikJe0ybeysTA44uok0eqn7peG6V/SJvJG16uAE2XL7tfI1rl9WebzQLVgV Q4ybktLVlQ+YjitcupIzHdFyzYhf8tzeEk4vlRNmCyvHqHxQlcYojxHboqI8iOXpKsdpQAAEQAAE QAAEQAAEQAAEGIF0ioXnWTZhkDI/9Lfg1igqXHn9plVarfuzx4P3vzBuVKWLqUJSwDBoWR9rqm// jasBKXgr0rlvm3EZmU30577au7TNN5yo/2KagQwFSe6Q215JG9srtw3JnMldQ/485m7lCqxk5fWz tHrjaV4+f3rVNaaQa1ZxrZhK+lddSxclWW2tz2VM+exhct3ofC/U201Msk1Ngsm1f+VFTTS/S3OL XXKj63pniVTBvvL6ewbV8zOYHeLEGzbfVWsYBWrvcnYOq6lVejg35GT9wE1nqNVW3XkZqXXZjNte qFU/UsugTnxxFvWATdcbZK168pKSoCx5ttxez68jY6scNe4F69Veef3lL54YxHwr6ek0cWZhYLOY Tegyz7Qqta6umKmkZZgRJF1g2q6jWC6iy+6UhxfL1Z7mXYBfEA8sGzzLbFmxj0ZYi4risrn2QVcl TfN/HDpLKvPLX6G0ZhuYRD2lIcy41IXODst/Vl1Ul5hpd8tJMpeoNIyqx2d5qLd0aeMPWaka+L6A giAAAiAAAiAAAiAAAiDQIwlQ+nLnRgapNM8mxSP26CvbPGxSzhfiFlsPe9wwvHvqDXuU3VRhatFy +1XLxr1iPI9lDC6brv/Ona+MW3aVw/ciYLu03H7/oHv0BzurGcd4UuIPMoYdonrOi5K5KpEgY4Vx IpWG/CHysuhKCoxcAcmwofLUefBappL0qG01hhhKXnb5Ndpd90v+avSAu/maWVnCzDAfPG6cdsOc +zM7HpyzbJxh9ssYda69PVM58fipP93JMBkA0yJAXe7y+3mdskUqtKiuNj3edLWE/an69hMNuwA9 YGd6xqprMg/bojfKqrK+QpYjw6DANc1CT4GP6n+i1Pfthl29f/I2r779Fdlgapov7HoyqQ8s04YM kfpAdno+OOcGbiDJGBJYPzSNd6IXXnbnqoxdVXWBZniSLBPmK8JMmJ2SskGEzCCZVpVNtnSKQfff 3iKsO7qF95rLM5Y2vU3EcETmwSF3maZigqDddk9sFxE/0+CTbJZavS1fnHXnZVYvtAdMG45+zcsX +wsvGxYodqVrm5c9YPz+youbh4wbld0oGnCw1aw2wMwbgMzxps761Sc1E9GOPoqyrmOYv/R251cH +84saA6DOFeJX88ZE7QxllqHetfKZ6VqYJwoCAIgAAIgAAIgAAIgAAI9lQBZnYTFiRmfROje1T/4 7dUzfnPVjF9fOf3XE6+/85v/MX/cd287dnaz+ULf9Yvled54J273MhLPCLZ35RytKCk9lzg9gCx/ 9lbG/tdV17AzM+nXZFyNpCY19LK+8nc7h4+G1jqEU9J4LOZPT7pFxDCMGP8yyrfp7lqGsoarQsZl QVKSsbY+kRu/WR7VQ2maaT+SxX9hqpCKQySnLUd/cDmfP0zTucJuRQyssGxa0h9Vra1sYrMrSL9n SiqRyopERsotJW6dj9HN7M9cEw73FEMNmwqinEvNIvHU29RUw+0adW0YJ5jMHlVVIsO0HGg3SHk4 FVqGeA7d1j/1hpD7RWQlLZhcxk4xTnJt2T9OD0lTgIVkprPog51RX4lyPDo7PaQMjZS1cb2aFFd4 dCVtdxcxRF2zivVVUwGLMylHJA+emXaW6Fm9vuSeH13VwIMYCoIACIAACIAACIAACIBAjyNAJqYv fuXGs77+k7PHzx4y7uc1E+bUTJxbc+U8Pal52KX1WOyO7ItD750tflDkViC8jHjQj4iGk6byPOKo 5eUXhgw6UW37O3HQkIwLQAgT4YP338UcS+oHvXLn5a7xJOwtOumlzRr1AI9Bc02Wwv7gpyEpFVVJ 8ar+xBsGi5gt9XaS7tRxj3YVdz4gt6JMvBYnLGG0+Ehx/yjDCyQbPYfctor7E5Gm5JFgPgKOu8cM Nmp54MVxM04UObEM5y+7R5ekJ3PkkSPBrLXPRlVdUsaPzx6NRz4ys15ksZv3X25qzzMPUc3oD8KX S1KVOtMQhapR9WR+Za9IQXeZ2jN/D6Ydd9rgTi/crYu5vWRiCnUXFJf+ybCSUwh1gox/T/Quyi5h dh2JPkpEr9L0Bs9kOjI4kzLSRWQJnLPpWXnS4M03zHFmnYsKk8GTYy+lXwxHR13J6ts10z+KmyQk axW7ouTriKJpr+H+RjRM3EU+hro/U1QlrW6llmhR0ZqMnxi1qF8ypyFzwLR5cUlK0hA8ZPOL5DzH RpL777rm8hmDDN841nUMJ6yoOocYcC1Rkk4PqZyOogKV2ZrGYMpc4diIaUTeOUP2BB/STVQ0gJKi YB54hkCPoiAAAiAAAiAAAiAAAiBQNAQSWpIlLCf3KEpdbmidNE1R7EsipX98K8UsUmZUi7A7ZQIk 2G/XXMMSMbllRTFkU1iJJXTFfK7RgyjYs6v+wOWrjlyAAivY06ZutqHER/a8JSxVMD2y3VVLj4bs Qb9+0G1yqI94vGGHKzXMpOmJqiSz29CDOz0/+yTgeVlPuM7MAXy7/H7+CEthhmKzKMmjjYSl0GKP 0iLrSTaoTddnzIYPXsu0ZhuPjRNBlWRiGWSmi2LPgnZHJRtMUtlssMzDugEiuqqmWgTHdHzQv5hu EvTwTuUc8Vq0jx5uxQOtvd3du19UPRnQV5zZdHTDBHvCZriIqcZd0Ga9eFWmOhmrrrN/stgyfg2S RUqK3ora9EwR4Uly52U8ZtS0iYnvrLl4CJwgK2UcsjiR2PWkCL9r+JVu7fdRYbKmkWMvXUL2uJI2 TxqXFrU2Ol1IFJ56u9VyGlXJTKQgt8s7neMIEsf9yiuZhFJCxfszHYUBk5VkFilxrXN71GXsd2HB p1Jm/46qc4gh183/TuId4GqKqqQxeGRsfNW3v2xQkyKvDTOlvMuooLgHqYd69hIgE8Md9WoKgRNF QQAEQAAEQAAEQAAEQKBHEuBhemxLa0n9e4psVIkE+59W1uP/JfknQP0pUbSZ5YmeV5eNM5I2sdm9 Nu6eGYOYEHoUU3kAOd5Jm881hgdQxJfRlAxE+HZUX3v/C0MGD2bPqDwehj8Kisdn8YioR25suv4k SyIU07XC7sKVefLKVCqiksxNRvgdsZxE7CGKP1duvsGeOEt4SL1Cj8d6TnaRgWeT4Ot4tW8+pVrt UdHf7BsLl3Gg1dX3DzIyvrPHauFTRC3JjBXGUyHlFWYVMVLI67YHlQuC/rAuGwyiIeUPp7Xkz0Te RwRHV8D0kOKNysqQaxT1BPIhetBYW1H26AnoGMfRR9OTH2o6dkjGCTmyiDvwzRosirLquGUdsiJl vly6TdhmkYqqJ13WujseV1e3M+n/UP6noGndbU3Phb1CWdwtVqmoSgYYquQiThOGkfPOdrEzJ6m7 bhA5tMwteyV1y73bcoCE+0TpomGdWbvrhUHmYgs05lhJGhYoYy/9rjG3LtYTMq6n2evsh9jbQyqQ 71FEJQ1bo3EVGaPI5UaqOFt+QuMSowUXrL656puR7oAVZx/w44m/gwAIgAAIgAAIgAAIgEBPJMD9 azRaaC+V0LpYGnNmnkqKZfboZ1JLJ7UUfRJUJshmRj+x6DhLGNll1xtPcXI0nO253/+teIBX6256 mv4Imy7XNg8eNIi9Hq9l8TDcOCG/7aYTCD8fMghJr/mNxxZ/Den0EZXM+B2xb2QQ4/YolpfJdZN8 LF6ZYQlztCupW6Ts9qioepraMIPeYG3cjJNkvzbhU6QrZ8TNmCFHepymCHmT9bQZTOw1jobU5gjj 6iHFytypXZuo167RXjQiuCz5Zlg/DqpqND2l2rotRCj+TCZdaXE72aNMOtzS9Mzxy7QC8oUGzMC4 iHoyicLWYFie5AhbQmkNHVUPGW7Xkd5aGQfBiEqys/qE7NkVszgomVZAp5Is/tXmSJeFkkILI028 ExYLDrSvV0f2FW6INFcotCkpftUjNUmk/juZ1qR03lnr7Hsv8PaQyuUoyslIq2qwEf4Gc6VFpe8p mZ9sBt5ASuqXps2x1xcPCoAACIAACIAACIAACIAACHACFKxHdij6yTykxEYGKd0rSveN4rnOQ27q yDp56XA5kseIpzOXiXI5o5nfI6Q2/MGPR7qQv8wgsvU4PaR2COeY+hf4WuYqDykmyC+LVTZKZupF RqmT5tRSthrTKUb2y8hY9XiYVKVjhS6LktwiVX+VLUtTHHqSlqMeoJw6cl4b0u2Ka0VQpOEhVc19 j/TkXBZbpaknD4iS1xeUmzgOVc2kS1YPKd4vyEVq052XDzaU4b5q45bZ8hqpVTWXQsxWT2uYq9W0 mTHpss7MI7LcrwKzFmQ9kg0DdLEZi+1F1VO/dslkw69v0sLyFG9dDY5bTTyiTw097aUMG1dUJRkV Rcge2UPv1POaCXav3F6diXR1w5nji10sMOj0GOVMuIWO/sZ6qMGRZQNjFkG2HKV5mKwkK3A/BXQa 9if771TJbMD6DLzc28wlI5YYerl1VDdl5gysiA82e4AUDmmL0RSRz1zZ6mvnLBvscj35KSlo5JBn hPscDgEBEAABEAABEAABEACBoiFAqaPYRomk+JbiHlMsh5T4hNp0GwkLf5LyGomMQkE35ifjlSNK zoQSVCYrpxsd2IMKeQq4Zk3vL9Ib3zMuI9e6JCA9tlBl7BpKsSmG00hUJS0V4u/5Kfe79KxqmD3Y KY2sTa5xhQ4lNZ7teLP5kCrOlJWeL/OMWxQCee1VN1izkbNQl/NncJhmZmFKOTXqnlWD6XmUDIIZ Vw0LTPYg+cq4ZZkIJaq+4RKUlaomV/ccUszIwnPa68mMiXz9oHuuv+z6TZSay7SnOFTltdG3+y/X ralZ6Umd1BrmqnzS5Xm13e1RGT2ZN5OlkJTePrKeIryN5zInw47dliK7bfGIzRdnqaJzJZ4U6Tuo 3kBJIg0vq8hKmom/3IYI5jxkxGZtvqGW4oozwZxCiYzDpN9wlN1FxC9xCrZ1Q6QHkAncbEjlhXTn H25v40nl3UYkZoG6SzIU2n/P8sL3HnYznpGsnC1XmxhPWfPmFqxTxczLCD728/xndy0zUvBR8PNd L5juh2bsXgAlYxhIw9zGUBYEQAAEQAAEQAAEQAAEehYBcoFiSc21EvKT4mmiWOIobfLMxsnf/+13 Ziz89vRff3var66q+79/m/K/tCafsDQ5Nj3ExXUdef1v4snEuRy4c8Fs5XL24nhn8l+FUq679bfl sh76W3NTeXEO+V26sSi4y/rpChpZKClUY6eXNTI6He1TLKlumH+MU/uj8i/h2dxmi7oomqm/U1ve ITJdJZAWgQopGpyhc1nWnXJ1ZZ6Yjda+5hrinlkaXg8vNNT118K/hLKzMhXc1qS3dyVjAXub55P8 q78W/iUUepqXqyWkkQqb14uuiOO6dl7ofldzZCXtujtyl2fMJEJb+5nk3320iK6k5RIXKlsVFcOA dSk4e16kTE1CDDnZ6ex9/7tmlRjw3dXhFQymc3Qlnc3vx8YYpAz+luHL7+AY7kph7mAoCwIgAAIg AAIgAAIgAAI9hgCZmM76yqyzvv5fZ4//2bkTfnHexLnV35pXc+W8xDUzG6mSqVRXOkUJprq6ujq7 OjvWHnfpm7NOzoM9jl78k2cFZYGxnYueF+yJqfKgjX4KUmrOSUYydpWGVLZblbTg8FCyiPQsIlXR 9GEvx2K/joqlxeV2KQqdi0JJQbVwVA179aE8CIAACIAACIAACIAACHQvgePqX+r7zO8TvXonSnon k7SuXkkJpTEnp6lrf3hPKkXheykySmlkl+rq7OzYkzeDVPdCwdlBAARAAARAAARAAARAAARAAARA AARAAARyR4AZpP6xOFlKBqleCWaRKk0mKJsU/U8JpPhpRRop5icVMp9U7pSGZBAAARAAARAAARAA ARAAARAAARAAARAAgeImkKaYPPKCInsTN0HxJOdJ/k1Yo+h3vgpfcdcS2oMACIAACIAACIAACIAA CIAACIAACIAACBQOAXJ+4jYp+skMUOz/ZEmCvKTERv/qXwtHZWgCAiAAAiAAAiAAAiAAAiAAAiAA AiAAAiBQvAREJB7zf6Is5mSNSpNlKpX4jxt/18WzmrMf6XTX7s+7ujoeOvaSl6/vU7xVheYgAAIg AAIgAAIgAAIgAAIgAAIgAAIgAALdTuCk21/v88zvS0p6lSR7p0rIE4rnkKIkUv/xI7bKnm6Qopzm Hbspr/mDR1+Wn1X2up0LFAABEAABEAABEAABEAABEAABEAABEAABEMgRAb7K3h+SJb2SSUpqntBD 9Shn1H/O+i15S/F19shTipbY6+jq7Fh19KiX/vO4HKkCsSAAAiAAAiAAAiAAAiAAAiAAAiAAAiAA AnsDgZN/+Wbfp5eQQSqRLC0pSZJBKs0dpIRBKpFKd5FRKpXq7Nyzp6uza9UxtTBI7Q3dAnUEgZwS aHypd/byJ528J3shkAACIAACIAACIAACIAACIAACINAtBAyDVGkiWVJSUioMUpRRKpnWkl2UWIrZ pNiHEk1hmb1uaSGcFAR6JIHTj+zK5tMjmaBSIAACIAACIAACIAACIAACILCXEUiJlfVEdnOxJVOp JKU270olWZpzMkiRbWovo4LqggAIgAAIgAAIgAAIgAAIgAAIgAAIgAAI5IgAW1vPsSWm/PBevuge pTXvpDRSXandnZ1dDx99aaiQvU8++eRf//rXRx991NnZuWvXrsMPP3zQoEE5qoa32N27d3/88cek A8UfdnR07L///scd55MMi8q3t7e///77pDwJLy0tJf3LysoOOuggj3O9+uqr/fr1cy2Q3PEtfR1D +jNDy7kbXxjsXv1KT/iFh/Bf3TVf9ddevUovvbi2Tx/3U8tHFYIQD0rd0j3ydtIPPnj/0EMPS1BU bODt36/9TsCyv77zNwFLdksxudEpZI/co7JR49l3S0TI3l7Yl7q6usif1aRHAxSNTtnAxLEgAAIg AAIgAAIgAAIgAAIgkH8CFLLX56nfsxxSJZRDqlc6yVbao5C9xJQf/Y5ZTLpYAimW2LxrDyU2D26Q IlPUSy+91KtXr/Ly8k7t0H332Wd7y1OVlZX77ruvayW3bNnibegRR5GR6LTTTguFiUxRb731Fj2w HXnkkfQU17t379dff52+k24ecl5++eU333zz5JNP7tu3L1mvqORnn3322muvNTc3H3/88SeddJLq WI/H40TbxIP7jOeeaCkyR7GfzByV+fnejhWlA//goRXZkh458crdXdrulLZH/ORf9qTSx+zednXn U18afknfvj42qVwI+fzjTzp777dHKwmoia8RYedHHy354582bX4smUyeUN7/WxMmDDihPFS7F2Dh F/75/JNP/X2fffapqR5a1q9/NA3f/+D9jRvXJ5OJYUOHH3LIoRGE/O2RNa+0vGweWFU1aNgFw4PI GTri4iDFqMzGtQ87S3aLQerNt95avmLlxqZNH3388aGHHFI95PzxX//a4YcdFrAiolghCJHhf+Mr tcsfWLNnT4dQb8K4sYuXLTdr5Ao/VH1RGARAAARAAARAAARAAARAAATyQEAySFESqX0yBqnrfvQ7 WmGPLbOX6kqlaYm9zlRnx+oAHlL09v65554jA1D/AYOX/23nU//86I23d//yxye//9bzHu5R27Zt I+vP22+/7VHnY445hoxcAwYMCMiFbGlkeyIj1LHHHtvW1kYGpk8//fSiiy569913aY+HkKampqOP PvrMM8+kL4899lhLSwsVJmva+eefX1NT8+STT5IE+uIqwcsgtX3iwX3HqaxRtP+9tgdKT/YxSD12 8pW7yBTFjVBkjdqdStD3DmaZ2v34iI6/LH/wogtH9O1b5lE7Mkgtf+7Njk8/2v/yGZ37HWIT8uBZ 737v+zf3L+s/9xe3eguRNfnwH8/t2r4jOXBQ14DKIJp4G6Teevvt731/5hdPP62m+vxPPvmU7IlL 7/vzLTfddMbp4WyRpv4ffbTz4IMPCdhtPIqFlUPXwojLRpkCR35p6LcnXX3A/gf86b5lW1u2/f3J f1CBUHYE6sD3/WXZBTXD6MAnnnz8K2O/vt9++4WtF3WA//e9HwgXm917dv/y/27/9+9cG0QI2aaD FKMyyaSLw46HQaruii8FlNyw5G+iZBAPqRdefHHWT26+eOSXRl40/KijjnznnXf/unLVIxs2/uKn swcHdtUsECEEv6MzRa51pSXJxnvvnnDFhN699xEo7lp45zWTr+2kcTqt9SolEy68pQL2JhQDARAA ARAAARAAARAAARDoTgK6QaqUkpqTh1RvbpBiD5SJqTcygxStspcigxR9usgktWfN0Zd4h+yx5+Qn nhg8ePCWV/ZZ+MfXPv6Mwv20gw8qvX3mkbt37SIrj6quZJA67LDD7rvvPg8YX/va1z744IOABimy RpERqk+fPuSr9fzzz+/Zw6J7yD/r3HPPpe8e3ljkG0WuYWQdu/3228n2RB5eZ5999m9+8xvyk6KN /LOuv/76F198kZ7nXf2kvEwt2yce0vfrrr5R3EqVenfHg738DFL/+AIzSJE16uj9k+ceu/+jb+z6 5/ude1KJjlTqidpdb7317tp1j1884rLjjjteRZLsEX/Z/OLnr71SemSfk/99ds2Jx5tCOj95/+SH ftL+6hvHHH1kw9z/8RZiatL7/Xfa1/39g/d2Ulhj8rDDE2ec8cTEA7w18TZI3XTz7PL+/Si+8sGH 1x5/3LE/nDH9/Q8+uOWnt/7pD7/39mtzVvn1N17b+OiGzz799PzzqwdVfSGbS+3F5n8+9tim/Q84 YOgFw/oc39dXFDkitW5rIfOAWZKstN+aOCm972cHJo9atXoldeaRI0YeeMCBooCvHYG69PIVfzl5 4Mknnsq8q155bkdLa8vo2i+HCgCkA6kD/GDGjTduPJu+3zLksdt/+b+Tv93NBqlTD9/ty1MUeO59 3Qrja5CiPvOtb0/+0Q/+33nnsJqa2+NPPPnfc29b8Mvbj/O0SovyhSOEDFJTbt9Ebf3Tb5+5/M+L bQapb1wx6Ue/fZoGrgXXV/t2pICoUQwEQAAEQAAEQAAEQAAEQAAEckqADFLHP7OYgvXYU0xJMpEo oXA92miVPbHpyW5cE03ZNKPcTGSNOvOss3/zl93/e3fbhx/TK33yrUqfOvCgtu3bjzjiiJzWRBZO djGyRpHpqrW19emnnxbWKNrIIkbOTQcccIBKEwoJJEeqs846S1ij3njjjfPOO+9b3/rWD3/4wx/8 4Afz5s176qmn6CeZqMj3igqHqxFbqtAlUk9Yo0Q2KV+B+5Uk9itJ9z+odPyJh0w55dBPO1L7lnTt W5LunUyeu2r/y57q9+f9z1754ApvOZUTf7jPkX063339X/f+1zeO7xJC9tn1wX5/vpmsUanD+uy6 bKqvEKFJxwsvPHffw8waxfoKLdGYJttmcE2cepIT0JNPP31SZeXfn3zqD/f85le/vK1/Wb8zTjuV fj7x1NO+fMwC1GMf//vmvz2yduSIS2prR7/xxuvBj3UtSRJIDkkjmSTZ94qgsLjp074/5T+uNT// /t3v7HtgyW+em3LPS/859OLzBn/hC39d/oc97/zHwR3foY+vek89/eTBBx086IwTf/v8FPrQF4r+ +/sTj/keGEsBMoc99Y8nAn6ocCwnzUbI0j/dd9GwoaY16sKLa4U02kM+U39d+UAQ4TYh5iF5FiLg v/XeJ9ve+Pi7/7txT2fqH889Y7ZFVzpBO+lPVIB2FgL8IGxRBgRAAARAAARAAARAAARAAAR4GqNU KpFi9hJjLT1y60jQ4noafZhNKlAOZjL9nHnWWXf+8cNH/v4eM0VRkB//ec6ph1AiJzkLb66hUzLy E044geL7KOuTfC4K+qMEwLLTik0TOpB8oyhSj+pSX19PHlvf+MY3fv3rX3/44YckkCxZVICC+DZu 3EjFduzYEaoi3IRhzxuVsUZpLOLGdztsH+2IfbVBh/e+rJwyW6X6HZg8ct/kkfukj9pPO3K/xFH7 lXQc3Jec2bzlHH3Eoad/9+ZDj+33r9fbJ3936jHpnYd1flTyx58k3n8teUTf3t+c3XVsla8Q0kR7 9+3Wx7aQa92Q08r2P+Sg44acVf7lkcf0PSK4Jk49KXvUwQcddM45Zy1omCebDvv26UMuRb58RIHP P/985aq/fvTxR9+eNPmIPgccecSRO9rbFv72TvPz69/cueHRdR7S6K9URv6QBJJD0kgmSSb5dBZv fain/demC2yfdz/f0fLB43f841v9Bx1TU3Pxw48FSvP/4YcfkIvWJRdfdt/WW975rI0+9KX20tEv v/IyeYEFxCIX66RlClJB/ZLoQKrLWWecE/DjcYk5VU3s2Z2oviDoZ09QnSkB2ZdH60Yo20kpgm/D o01BoMUrhIxi8ocUCKiJgL+niwbp9Ocd2gvvHnrGqV802+Kf7x1KO+lPVIB2hoIfBALKgAAIgAAI gAAIgAAIgAAIgECOCAhjEzM+cQ8dMpvQP0nDOBLUGkUeQ2Tu+eu6Xas3vtvRQY5RwhqVpu8DByg9 knJRJTIeHXzwwbS0H+UvP+WUUyhG7wtf0GO1DjnEJ5EQralHWczJ5ETeXpS6iCL7Lr300v/6r//6 3ve+95WvfIVCrn7xi1+QzM2bN9NSesHtI1I1LVnMZWtUEPcokjPo8F6nHrXPmUf35rat1ICDS889 dp/zj9u3+tjeFxzX64Ljep91tHvaeBk1CTlrwDEzb51L+cK3t7W9+KsffbzoJ53vvX7gMf2G3vCz oZXHBBTy7pat1E/qvnn+rddfPOmGr10yfFBYTZwd4Mgjjvj0M4qx+9SWHemV1lbqYEE6zM6dH/5l +Z8qKyovGXPR4pbv/d8zE4888qgb6qZf/5/fMz//+R/XNze/6CGN/kplbqj7nvSZTnJI2h9av0eS ST6dhc7lrRK38lo+u7o+/bzrE/JI3K/0wD0dHSUlgRab2/RYU/WQmo7Sj1//pJkOpw99oV9rLxtN MYlBsNjKCCERDoz9kHTvfdKbHg36MRIn+arx4c6dlDeKigkbkPyF9lOOc18JVMAmxDQn0Z8iCFn/ 8Cr5E0oIFe7qYhbrXXu6duy0JA5r//gA2mkWCFIvlAEBEAABEAABEAABEAABEACBQiBAtifuD6Xr ItyiWOIbYZ0SPlPeeWrIfENZgQ45cmDjn18nC1RnF7NDcSepLvpQPvS8RZFQsB7ZiSg88L333jv9 9NMHDhxIliNzTXSmh2cwEflPUaIoymJOmaf+9a9/kZ8UuVkJMGSfWrBgwcUXX/zFL36R1tqjaCkq HK79GFDJQ8qM1DMX3QvgIjX51EOuOeXAIcfrBqnvffGgH59z0C3nHfKzIYf+d/Vh8y445LYL9JxE HroJIZd94diFv2oo69f343+98ck7b9CX5ff83+2XDggu5MO33qOzfH3EoH7HHDTjnENNTWYM6h1Q iFNJMiNeOPSChvm/kmPiVjzw4O7de8484/QgwDdsXHfO2eedeGrZf/99zBNv/WXHR8/9+0NHX7vm 2Cl/O9787BPArkFl5ENIAskhaX9/8y8kmeTTWehcHiqRY+DPa54xP78Y+uycC587Yt9+Zxx92fVf XLLlyeYnn3pySM2VH/X6DX085Hz88Uevv/7agQceqH2+z6zz1+7q/IQ+9KXz45KOjj1kvaNs60HI /PPFF1Y/vErk4RJCyJuGLu21f3uY3K98JTyz5ckgIXtUzFdUHgqQnx1lMacTCRuQ/IX204p7QXSw CTHNSXRsBCFOD6ngQohqrxL28mCf0sSZx3wgh+x98aj3aSf9iQoUCPwgbFEGBEAABEAABEAABEAA BEAABLhbFP8YGxmnzBxSuqnKO2MOJWyqqKj474XbP9+dYtaozlRHRxdZqTr2dHR20OrkFE0SIBot jqYgOxQlivrHP/5BRiVydxIiyd2mqqqK3J2C28UogfrEiRNtq/4deeSR69evv+2226JVhx9leEg5 rFHpVAez/nX6Oq107dnz+VtvvfHmm2/s3PnBe++R3ewtskh8/PHO1157lfzUPvkkiOuHLuTtt98y mdCXTz75KJQQweFf/3pb1uSV7a+fM/FXF3/3t8E0cWn166de9+677029YfqKVQ+ueWTdj2+pn3/n r79X958BY5FoZUiKDyXdKHcYmYRct4B9TXU4SSb5dBY6l0rUFwYN/uX8229r+F/pM/f9D96fcc7y r5X99L4l9z/08EONi5aN/cY3TRcelaiDDjq4esgFW5579reNC6mM0Ira695Fjf/85wuUrz3IGoJk 1dq0+dHTTj2dQg5NIYT0yomTvvCFwZSv3deq9cXTzg4SskfFAuI1i43+0UMX/2C174eKBZc87IIa 6jyu5Wmtveoh5wcRFa8Qp4dUcE2I6gH79epVmrjg1OPKDt0jh+wdf+BntJP+RAUiwA/CAWVAAARA AARAAARAAARAAARAIBcEUkmti8frJcgPinLFcG8oY2kw03HK88xkFCnZt8/jz35IXlHMBkXmqK7O rq6ONK0Tn6ZfAwUlxVI38myixEPvvPMOhXcdfvjhlMKcxJL5gFylzMA9jxORL9Vnn31WWVn5yiuv /PWvfx0/fjxZskT5448/fvjw4SST5FM+KTJymY5XITQXHlJO3ygtvfOtLSWl+3a0/4+vtKamJ5Yt u3/HDjIDti1a9CcyQu3evWvlytX337+CEm9/tDOQswwJabxnyfe+f9Nrr79BbiBHH30kffn2NXWL /7AsuJC+RzBfm98/8IysyZxfP0g7D9o3EVATZ33JSarhf//nim9848XmrY89/uTb/3qHVty7+Wc/ ++CDD33hUIGhQy98tGlDy/Ov3lj94OmHjzqqtPLeL++0fciTzlcUlXEeSNJIJkkm+XQWOpdKzgU1 w/79O9d+5+rvmJ9+ffuSGfEfTz5/9z2/Jce9793wvYdW/EV2uvFQicxbl15cS1cWlen4PE0fMkiR UWzEly4OuHogWbX69OlLF0hqn8+nrzpTCKEvyQM6evXqTasHBrFq+UKLVmDlTy95+BeX+n6oWHD5 Xx496uE1f6M19cQhwkmKNtqzes2as888M4gomxDzkPwLoVNfePpxE7904vfHn+rUnHbSn6hAkEqh DAiAAAiAAAiAAAiAAAiAAAgUCIE0WaDo/zSzRpFNSmhVctbQr7KvzGmHrQHHnn3TXdsOqPyPcw+y 6U05m8iE9fDj2lPPf8AtUFS2S0tTvhP2k34dft7Rpdr7ZNDxqDDF2VHOIAqF8ygzaNAgMkwcdthh qjIiyTRZo8hPih74yVVqw4YNO3fuJLMUuUdRHB8lliLXkkMPPVQlgR7X6ZmfTrFq1SoySA0bNuzK K6+kpFGnnnoqLa5HMXpkjXrooYfIf0p469ApbKLoFKpMVan37tvvkJNcrVFE6aN3mw/vc85n7/2j 9OhvqNSjddbIR+W++x6oqOj/3HP/HDLkiy+88HJZ2XE7d378+utv7dq1m1IaHXvskS9tbT3rzHO8 hSz6/X3rmx771zvv9ut7/JeG1Xxz/Ogtz2+lX1997Y1DDj6wrN+xQYQ8sXnzK//Smnd8dPDBB+z+ +P3DjjjiDw9tXfn3f9GpRw7udfKAo1VCPCgJtalHlffvf0H1EArfO/ywwzc2bfr8811t7e0jLhru e9lQR6qsOOnvTz7+Rvvb42u+d/4JX9nzadcdv/o/yrVELkLis/mxTSdWnjTghAqVNOo2Kx/4q1me vjzx5ONVJw+qqfj6eceOW/vQ315/4/Uxo8YecrBP5FeamSD1jaJX16x9uLSk9OIRI/uXldvCYGlp S9+qUQeoqb5g6ZM/S3VoXz9tJi2x98UzzvI9yixw9FFHkwLnnF79z7cefe3dV0jIiUecO6TP+GV/ WjL8wotoCT9vUU8/+/fX33z9jbcyn7tWvXLnqlcWrW295+GW3/+t9U8bty3ftO2fr7w6/MwBTlFy oz/7bsmx+2ecy47Zz98+KAS+/Xmp+PLWZ8nTj2RHqfrSQQceOHjwF358y0/ffvtfRx91FJmPyeS6 7L6/3Pnr3+7avftv69bTJXzaKad4V7lwhBD84w7afcR+nxH/N998K6V1vfX2m6It6Nd0IkV/Ov7g 3W/9643jj+sXvEugJAiAAAiAAAiAAAiAAAiAAAh0F4H/e+KTA998IZEsTSZLNEonkyyhx2TmJDX1 h7/j6c3TGgXhpSgPFG17Hj72kpf+0/4S/rnnnjvzzLNrr3nmnfd28RxJPECPGaR0Y9aVX6v40pmf kUGKrEKqem7bto3MQLSqnQcIMgOR3WrAAJdnXXEU+QqR79LatWvJbkW5yc8777xnn32WYvfI44Zy P5HrEy26R9YKMhjtu6975u+PP/74qaee+vKXv/zTn/6UUpvPnj2bnlpbW1u//vWvb9q06brrrjvq qKMoh9Qtt9xCFqtzzjnHWSPKpUW2MNdadG395uH9R+lppMy8UUYQ39vbHjlmwEX0c99Tlqkg/Oqu +d+5+t/++teHhw07e+nSlTfeeN3dd//p3HMHv/vux3v2dH766Sfbt7ePGX3Rn/7y0Hevmeoh5CuX j7p26vff/+BD8o36yx/vXPHXv5GQbdvfvH3+b8kmdcjBB//vf9/4t0ce8xYiNNnx2WG/W90iR2SS YfOSLx468PCPPTTxoORUmxzcvnbFBFp9j1ptzs9/6mtEEBLIgYjMN5QaiXKBU/YlincjD6NsLjPK vkTxbmSy3LS5iZySzjrz7CAhhENHXBzwpBvXPuxbkjrAD2bc+NW72HW07Nsf3P7L/5387Wt9j5IL PPHk3yl2b/ilNTcuH0H7fzZ27dpVG8gUdd65Q3zlpMjcbN3+45ePtbz+kbw8JI0hlX0OvuP6C5zS 5EZvfKm3MCeJ7aEfzukM4EdZ2qvkkp/PEIeQSWvSyXvoi3dfev+DD5b+6T5aLI/Sk1NvH1pTfcbp p9/445+Q3ZnSwE26cuK/jR/vW/FCECLDb7z37glXTOht5EG7a+Gd10zOdAPKl+9bIxQAARAAARAA ARAAARAAARAAgW4ncPIv3zzumcXJkl4l9BRTQlapUpbkmAxS/3HjogR5d7CNcpLrBqmHHAYp+jMl bCo96NQpN/2DbFfCo0p84X5S9HvXoIpD5s6sIFtPeXm5qsLZG6ToVO3t7eQGRUvg0VnIWHDRRReR MxRlkqJF9+hXMjCRoWrw4MFkmaJiKk1efvllitUibyxyifr73/9O38kFjPJJkVnq+eefP/PMM2+4 4QbSlp5mTzqJ3J3sm8fjcefWbx5RdpkRsscD98yUUunU29vWHzPgQvq576leBqkfzJh6111LyD3r yCMP+cIXKleu3HDYYQfV1g5btuwhchX50peG9C87/p5Ff/a2JTW/3PKPZ/952KGHTp407txzTjOF NN5z/4oH11A+qpNPGvDF00/xFmJq8mHHPk9t63y+5T3qOWecfPTx+354SOkn3pqEMkgR4ofX/u1/ b2/47PPP+/Q5fnHj3d4p9uUm+fDDD2h9OsoITjmYKOotm+uNMoKTnxRFvVWfX3PooUo3PdspnEYc lQ5B7AjZG6Togl2+4i8nDzz5hCrmsbi9+Y2W1pbRtV8OgtRZl7c/+HzK7Zs+/bxTODuRT+UB+5Uu uL76uCNcTM8eBqlTD98dsGmee38fUTKgQcpV7O//sKRx0e/JWZJMnNd8++qvf/UrAc8uF8uzEBik IrQRDgEBEAABEAABEAABEAABEChkAmSQOl4YpBKlWqnuJ0X2qJKzLvgKC9UjmxSL10t18p/bDrSH 7FE0HFmCNv6j89kX3xeRetxDigL3utivLGov9d6Hn333W6fvaGs97jhlihNyfSJzVVlZGVmCVBul haLTqUL2yHWFQFOkFcXr0RfSihIbkRWMrFFvvPEG+T2RZUoYpCjjlSqqjg4kW9XWrVtJ2je/+U1y syJLFj3Dk2sVnf2KK6749re//c9//pPOcsYZZ7i2q1fI3rv37X9oJQ/Zs1ujSN9PPthx4GH96Wev Y7xC9mqqzx48eEB5+fFnnjmIlkurGNCvvP/xffocc/LJA84+e/Dxxx9VWlLy5NPPe4fskZVt//3J 2+iHFw0/VxZyyiknXTKyhuLsjjj8UHIn8RZiajLywlMvPq/fN4b3n3DxgKu/dua5Z1T4auIbsmdj WzFgwN/Wr//ww53UgpeOHHnggQcEvKj23Xe/k04cSJ++fbONY6J4N5Iz+AunksyAZ+f9MBOy531U wJC9888b8s2zfzT+zBspV9vfn/j7mV8MEbLHbEaJRFm//msfefjwg4/Z+d6nTz/z5KjLxoh193w3 Z10O3K/XuScftemf/+pKpUqSiUMO2GfONef0PeoA17rkOWTPozqnnjKYEtI//8I/ySb17HPPf2vC N4PY42wC8yxEhv/slmdPGXxKSYnuCfX0M0/L3SBIR/JtaxQAARAAARAAARAAARAAARAAgVwToJC9 g998oSTJnKOSFKtHrjeJZJq8pK65cRFzcuLuUak0Zb8hL6mOR4652BayR8m/yVLTvKNX+xufMvMV 96kiLylhx2IP5PRfKv21URUvPNt09tnKKKctW7Z4BPSZFMjAdNppp7lCEWYmesKkdOO2AvLiev37 9yedyfjl/QhKflJkhKKM5mSTEvF9JJb2vPTSS2Q1c/WNEif18P3peOmbR/a/2NUaRVaqt1ofPbbi Avq532neHlLf1dIss7W+keEvlU6UlIj8X1TTPbs7b/+/3/k5N3WzkLAeUgzsa6/96Cf/1ee44396 y38FiZXL9ZUTUH68IXt/e2TNKy0vm6euqho07AL/pFpOVWmxv40bKYlSYtjQ4Ycccmi2dSndp7Sc XP+0zrYHtU7m6+QafujhIVV3xZcC6tCw5G+iZDYeUkLCffcv//Vvfjv0gpobv6+HAQbUQS6WNyFy R/rGV2qXP7CGli8VmkwYN3bxsuWmVkFiPyPUFIeAAAiAAAiAAAiAAAiAAAiAQLwEyEOqzzN/IA+p RAn5R1ECqZJ0CTdIffeHi1jEHZmjuvYwmxQL23MxSJEhiVKJk7sBqcXi8xyb2EnWH3JQong3ysEU bwVMaWQtorwwsplJ1kfeTyF7ZFSivELempDxi2IASW3KnkUlKSkyLbFHB3obzrwMUs1X6IR4bi6d GLPYCbsdW+Ywndxv/1PuUSlGEVsB6XkbpLpdSASDVECdC61YvCF7kWv379d+J+Cxv77zNwFLhi1W OCF7YTVHeRAAARAAARAAARAAARAAARAAgdgJkEGq7zO/T+gGKTJJlbLV9sh8c+2NfyAnJ+7w1MGs Ul0dnV0d6462e0jFrhAEggAI9HgCtqTmEeprekhFOBaHgAAIgAAIgAAIgAAIgAAIgAAIdDsBMkiV kUGKeUeVirX2Eskk2aQS1/xoaYrCwbooXq+DVtlLdTKD1HoYpLq9xaAACBQ/ATJIZV8JscoeNhAA ARAAARAAARAAARAAARAAgWIkQAap/sxDihuk6GeylAW3Ucjet2ctpriyRBdl4O4ks1Rn524esneJ LYdUMdYZOoMACIAACIAACIAACIAACIAACIAACIAACHQjAWGQovWahDVKS5akWV5zLWnqRBmOKLmR ppHfVGZnN2qMU4MACIAACIAACIAACIAACIAACIAACIAACPQYAhSpx01PLIUU85Bi68GxbOYdacoh RevssZC9Efec095jKoyKgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAI5J/AVU+U9f8HeUixVfZoIblE soSZo+j/7/zo92zhNzOpeSdbZW/9MV96c9bJ+dcSZwQBEAABEAABEAABEAABEAABEAABEAABEOgx BI6rf6n/s79P6gapXpTUnFUtkUx850YySLGNPKR4UvMUeUhtOPpLyCHVY9oeFQEBEAABEAABEAAB EAABEAABEAABEACBbiHAVtnbslgYpFgaqQTzkKKEUbTUnpZg6aPof7altRR9ukVFnBQEQAAEQAAE QAAEQAAEQAAEQAAEQAAEQKCHEaB19MSHMkgx+xOlkiKj1L//8PfcPSqV0jpTqa7dXR2pzj2PHq2v svfRRx+tWLHihRde6GEsUB0QAAEQAAEQAAEQAAEQAAEQAAEQAAEQiEzg/PPP79OnzymnnNK7d+/I QvaGA8lDqu8WFrKXLCktSfTiOaSSLKn5d5hBihykUql0Zyrdtadjd6qrwzRILVq0aP/997/66qtD MbruuusuvuPiUIegMAiAAAiAAAiAAAiAAAiAAAiAAAiAwF5L4HLt8uKq+6OPPvrggw/27dv33/7t 34pL8zxrSwapfs+ypOb0SVPIXrKEWaPIQ2rSjYvIQ4oC9YSHVEfH7nRn56PH6B5SP/zhD++44w5T 13vWt731wa4USznFE0+xUL/08Yfv950vDZDrA4NUnlsXpwMBEAABEAABEAABEAABEAABEACBoiYg DFLb27Zt3tz0+eef03eyOVA0FznQiP/YV/7zgAP2/9JFFw84QTdEvPfee62trR0dHd7V5zaMzMbi xIyNXJxOPPHEI444IgJAMoD8/Oc/j3BgwR7y6quv9uvXL0b1hIdUabJXSalukOI5pBJJCuFLJ7RU IpVKpFOJLh7KpzzvG+9/3sWi+5g/VVc63UU/U1r7O5/FqChEgQAIgAAIgAAIgAAIgAAIgAAIgAAI 7J0ENj/GrFFkmiDjQ1dXJ/1PWyf/KTbavXPnzjVrVpt8tm3b5m2N4gu5ZaxRzKohWaNIzp49e15+ +eU8AD/00ENdz+LcryopHy7KBCmZh6r5niKVTNgSlie1NH2EqxNrHuY2pd64BUr/6GYp6guUBt1v +0riK35Fgv6dRNmkOfcElYVyhUEALVgY7QAtQAAEQAAEQAAEQAAEQAAEQKCbCXz2GfODOfWUU888 4yynKeqcs88dcn4N7f9w54emomROUinta4qiA4V9avfu3d1Y8w8//DCyXSmbY/NYZQrRS6YSSTI7 CRMS/WS/MJsUrbeX1pLpJP1F/6ObXl1dGYNUZxdPOsU/eayD9pf0X2ync+7JkT6uhjBfW1uQo4II sVltxK/ygc49Tg5BjgoihyQ7dfathapd8taCOeoYQqw3kIBUc6ohhIMACIAACIAACIAACIAACIBA gRMQXlHk8XTWWWeffda5plcUfTn3nPOqh1zQ2dkZpAqupqjBgwefccYZ++23n5DgdJUKIjlsGbI0 mRsda/vVlEZ2pbCSYzk28kkn8C3U4YYHFHOEIncoMkWxfxLpZFIroZ8srRTf6boZYXrMCMXiOHnI XhCDVA+wODjtSlQp8fEwxAQ5yteOQwVs5wqyx9mCQY5ylnHtCaKYzRzmjSJUN81RYV/Ukc/ra40K 0lsinx0HggAIgAAIgAAIgAAIgAAIgEDPICC8op75x9OPNm0gf6jzzxvC9nR20heyRjVtenTT5ke9 a+rhFXX44YcfdNBBZ5555tFHH22L2ssdPbI0mRudxfar7byupisqI5uxVGVyV4XsJfMs5ulEJnCS eUclyWcqzeL4RCifLaDPflIzXo98owwPqUAhe9lrH5cE01HF44vruaLZ1IIcFaRMXNW3yenGU+eo RtmIjdw3fE8Kzr6IUAAEQAAEQAAEQAAEQAAEQAAEiICZK+rJp57YtLmJvKLOO3cIhekFsUaRKYp8 oGqs21BpE4STyeTJJ588cOBA+iL2eLhKvfvuu7/475/P/ukt5od+pZ2hGsvbhCT/1dV0ReeSzViq MkKOUEz1PZTaMRZmOcz5x9wS6QQF6pERikXrMbMUd5CiBfRUZzVD9kQCKZ7i3l9DVWSZr7uK7UA6 k/ce86/OYqaWpqOKxxf/KkUtYRomhIdRQDHOo4LscQpXnV3gCq6PkGw6SZnt6Nwj66BqHbmxZJOQ Co6qjFOOrcMIPXPRN5z0XHlG4xywk6AYCIAACIAACIAACIAACIAACPQAAiJtufCKatq0ccPGdTXV F9DH2zfK9Io65JBDAkI47rjjTjvtNN+ovSOPPPLSS2tfeqn5+eefo09z84sjRlxMOwOeRRRTmZDk v4YS2I2FRaSeGaxn+9VbMZG1nP3PTUlkgmJfxcY81piJSW2Q0lfWY/F6ASxRuiY2S4f4NUiwm62M GU1m1tC2R0h2FpOJ5M4LJniHiGD9Metlq4uNbRDJzjK+bWGrmk2CiNSTNXG1bZk75b+6tqC3Pq79 x5QjrE6uPUE+0LWxovWNgNaoIH0+eBdCSRAAARAAARAAARAAARAAARDokQSEKYp+CqtDaWmpqKb5 xVnrMPaJKMxOO/W078+Y2atXL9Jh+vdmnPnFM4NLsYXa0YHOPU5pVMaZqtz3QGH2EtJU34NrHm/J JHk/URLzdKJU/MMtU850UV6GpoAuUbHoLcwcpvdNcJnenj7d6yFFtQhiM3JWNojVI4jkIGWCoy7w kmF9viL3Ddn5SzBx7ilwVlAPBEAABEAABEAABEAABEAABAqBgGmKImXIMUpE6pGf1Hnnnj9s6HAP DYWvU/DU4G+++eazzz4rBPr6SZFNasb/+/73Z/wglDWKJDsTSDl3qipls0mZNibZ2JT/JltsbOLU tl9V+jDXJ8ONjdbSE8WSLLOUtAX3e8p1tb0dnXJ99hzJj2YPyp01KoK9zyRjOkaZQpx7coSxoMSa ZizSSnbCMr/T/mw4F1RloQwIgAAIgAAIgAAIgAAIgAAI5IeAaY2iLOaP//0xD5uUbE567rnnNvJt vdsmNKfyL1EMXnMzDw9kW5AanX7aGfQJUtK1jHB6sv3JTPkk75dLOv2k5JLef42sai4ONG1NlMVc D9ojS9SkWb8T0Xppyk6e6urs6KAFFpuOvuSl/zyOlPjhD394xx13mNpMb3yWfydRYpU+MnGx3+dO Ol3W+Lrrrrv4jovNPbLBQux03eP0Z5Ef480gLFOsc4/tT/FCjFYL21E2w4StCh45nuS6CLuP7x7B 2RYfZztK1RaimIeHkRkZZ57CuceVv2+bBukbzjJmRVRIVR0vrk7i2z1cdY7r7JADAiAAAiAAAiAA AiAAAiAAAsVO4HLtcqrCL+b8jH7K1iizXsJJShinaOcPZtwo/kTmJ7nurgYmsfOMM84oKSkhU9Sn n37qLDZixIgIDMkA8vOf/9z7QGF4Mg1SZkSebKJy3UlH2SxZrr+6Wrsi1EUc8uqrr/br18/3cJFG ijykfEue/Ms3+21ZkiztVZIsTZSUJpIlWoI+ycRVP7pXNkixYM3Ojk3HeBuktDMrDqNTPt36gTix t0HKqVw0RyHfSqJADyAQpG8EKdMDUKAKIAACIAACIAACIAACIAACILD3EJANUhSpRxUn3yhb9eX9 ToOUhylKlqNyicqFQco0RdnsTZHtSrJTlbBn2axd2XeYgAap4Ccig1RfbpBKJnsluUEqQdaoZAmt rsci+YxgPq+M5ubJKo89cHx1GX3oS3ANzJLCVQRBTBHQ9fhDgvSNIGV6PChUEARAAARAAARAAARA AARAAAR6JIGDDjpImKKc1ih5/8EHHWxWv3fv3q6Rd86dHgF6++67by54yvmenLF4wpZk7hcheM5N lBGbLSkV/Sl42qxcVDCETLaCHnOIMg9xJjW3SDvvvPMefTRjkjzhmAPKjtp/0kUnlCQT9KEv9Cvt DKGBsb5e2ITToU6BwkVKQM7HpKpCkDJFWn2oDQIgAAIgAAIgAAIgAAIgAAJ7OYFLLq4VNimPjaxR l1xymVmgsrJyn332kcuHMkXRgWSNqqqqikCeogXPPffcIAc6M5HLScpNCbK9yfxOf5W/O09XBDYp PY85pYCi3E96GqnElT9cxExUrLlYDqlUqpPySDUdM1LkkHr66afXrl3705/+VKzJF3Cz5ZAKeBSK gQAIgAAIgAAIgAAIgAAIgAAIgAAI7J0ERMheEW1kjfrTn/40fvz4wYMHF5Ha+VeVhew9t4yC9ZLJ 0mQJBe6VaElaYS9JBqnfywYpymhOBqlNx+oGqT179vzxj3984YUX8q8xzggCIAACIAACIAACIAAC IAACIAACIAAChUmAfKMqKipOOeWUwlSvcLRiSc3JIMVySLGk5swgRdYoX4NU4VQAmoAACIAACIAA CIAACIAACIAACIAACIAACBQXAatBKmkapHxySBVXJaEtCIAACIAACIAACIAACIAACIAACIAACIBA QRGQ0kCRGUr/2EP2OlMdqQ4WsnfPOe0FpT2UAQEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQKC4CVz1R Vvb8H1n2qJJSLcFzSLGQvUTiWzN5UnPKat7Fkpp3pVlS883HjLyu9KHiqiG0BQEQAAEQAAEQAAEQ AAEQAAEQAAEQAAEQKCgCd3Re4m6Q+jfnKntdHY8dzQxSN828vqDqEKMyb7zxxvHHHx+jwCIStTfX vYiaqbtURffoLvK5OG+xtGax6Bm8jXpejYLXHSVBAARAAARAAARAAAQKisADDzxw0pBRsaj08uYH Ro0atXPnzlDSGhY0WgxSyRJlDqk0d5cKJR2FQQAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQMCPQErT 9E8yoaWS3ABFZij6JLVEAvYoP374OwiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAQBAC6RQzNTH/p3RC OEElkyy3eUI+GO5RQVCiDAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAQFAC6YTGTFH0k31Jp8kkRd8s G/1q2xNUOMqBAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAgJNAmlmjkmlmhiLvKP6/tMEaZcWRgG0O FxEIxEaAlvWMRVZccmJRBkICEmCruvItYPlcFOt2BYJUqiiUDFIRlAEBEAABEAABEAABEAABmQCP 1BOPAwkWwZfKGKT4XtOByoHNnCIXwkNF7I1qVmrvfBKQqx87WwgsagLoG0XdfDblu7c12XoZwVbM yN1dJqACsTd68FsMlRSgutdyFzsBCAQBEAABEAABEAABEOjZBG644YZgFdQNUsz+lE7IHlLsD8x1 yh7Ex01VxoOE+NJd0/pgNYxSyrVePa+aTjTm88/eUNkoPWPvPsa8LiI8ITufqKP1sbjk7N0tmRnG o9k78mkfifcuk0/NVX3MNMYFt8pFu1jQyUEABEAABEAABEAABEAg/wSENcrbJkU5owzFhOmJmZWE QSpjo/JOIFUIM/tcwJWn/nvzY8DeXPdc9CvIBAEQAAEQAAEQAAEQAAEQAAEQAIEeTEC2Q3napDK5 O0zLAyU1Z3YpkeWcZZdKpETe84BbD45xs1VNFe1S7ASE54vT1CjvtAVsMhOmcYiKktl/ip1PwAth byvme3WIHuXaiwSrgBeUrxxZmrfkva2NVPUV5MU9wPtClq9iW2s6f5XbNEeXv7M7OYcXW79y9h9X zfPfN1z7f8Fqm38+OCMIgAAIgAAIgAAIgEBREDAtULfddptQ2NsmJSLujGl8IpnWkpRJKkV5zunZ hDJL0Ued5sMWtiOeaiLE8hQFWScHM5DENN/0DALORrTVyxawyXqQ8TQrR6CYR8mPoz24hxRFN86F kq7dXjS0ras495j6mFeTPIA4JcvFxLHOC9O1u6LjqZre2Si2KzdIKzjL5PryD9LKsg5mzxF9Ru42 hdA3XPu/s7f3jFtMLkYhyAQBEAABEAABEAABECgcAsIaZdqkXBXT05bzf7hBin1JppIafUTaqJSY uBdOtYpBE+cr+mLQ2kXHCIZFVWeR9/cYPkXarDlS29asovOYhtrIJ41LTmQF9s4D4x3145Umt4hv HzP7T+502Dt7CGoNAiAAAiAAAiAAAiAAAioCsh3K0yaVJgcoaaNHSC3ZpaU7NVpuj33IHKV/UcPG RN/GRncLKVo7XvZGBGdnkWUWOx+MO64EnM0ai9eJ08sG/IuOQOxDiinQdzBB/ym63gKFQQAEQAAE QAAEQAAEipqA0wLl7SfFK0t2KfKGYhuL1zN/0qJ7FMFHv6pMDLYnDefr6NgfRfLWNkJzWX/nHqcy JoHirbiotdhMa6OzZWXXFdNPwbc/9Aw+eeuEBXgi8ypw7R5mBzC7kK0KskuL7YJy/dXWzUxpHnLY eGb4Z4kO7Cq5ANnmX6WAo5zKz0huBY8hQjWMyOOG94Ap9zrZGiV3M+/+Y5NvG7LkfpufVnDW3eNy 8OacH4VxFhAAARAAARAAARAAARCImQA5SGXSmuuyKVpP38hVKqV7SLmcV341LTtJif3mAcXrP6Xy +JAfrsSjr/lT1Nr3pX3MrRi3OFN/W9vZWlauqeoQs4ysY7HziZt3kcnz7h7y1RHkCpI7lW1I8RBl k+zao4JILjL0OVDXt43kkdx1QPAY/D0uf9tQ6RxbbHWVe513y5oDsvgizKZiky1ZphBVr8sBbItI W41sNw6net6cc60t5IMACIAACIAACIAACIBA7ASENYr7AWW8oJgzlBnIRwvsaUmHzSp2RSAQBEAA BEAABOImIOxQYrMZ1OI+FeSBAAiAAAiAAAiAAAiAAAiEIkC2Jt1JSsSnMdOUnFaKTFYpSiQVSiYK gwAIgAAIgEBhEIBLZmG0A7QAARAAARAAARAAARAAAQcBskGZYXvcKEUOUSUJ7jYl7FCJFFtqD+RA AARAAARAAARAAARAAARAAARAAARAAARAQCbQGmYzD6SM5WxZPeYXZe5LsxxSFNsgdsq5VEEcBEAA BEAABEAABEAABEAABEAABEAABEAABLIkQMF5Ceb8RNYnPWCPjFO0rB7LZU77aa8I30MSqSxB43AQ AAEQAAEQAAEQAAEQAAEQAAEQAAEQAAFBQHaNYr5QYufXvv+HdLpLX14vlerq3JPq2PNUn5HXlT50 xbXXgx0IgAAIgAAIgAAIgAAIgAAIgAAIgAAIgEAxEnh58wMnDRkVi+YkatSoUc8880xwaRUVFQ0L Gu/ovKR8yx8TvXonkr2Spb2SSVpej4xSycRXZi4hgxS5SWldXWSPSnfsSXV2PA2DVHDAKAkCIAAC IAACIAACIAACIAACIAACIAAChUeArEijmypi0WtlTWtkg1T/5/5EpihukCpNJFkqc2aQ+uoPl6Rp bT2yRnV10s90V0eqc88zx18MD6lYGgxCQAAEQAAEQAAEQAAEQAAEQAAEQAAEQKBbCBSIh1QZN0gl hUEqUcIzmAtHKTN1VIrSSVFCKWwgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgEAMBtpQeTyTFUphT bnP6pCmpOYXpsaTm9GtCK2FpzjVaeq9wt7bFk0477/xZmywabqg/n3aKzxWL2+W/uZZ3rZ4oyT5X L2rzAtDeeHXmdPoh9U3siPZFVxhqnHbe7A2SkIzwzH6VHLV8TfOoaTZt5k5p02yD6qRGC1TlqVS0 vfcHYJ45oxBltLIXKw8grvq4tRGTITG3tGk2wIvr2Jx2Dw+8wS9ej2ZSyQ/brO7l1Ze8Fv7yyUuv kC4ZeaDLaGuOrqykPNIyAnygk64UMRLK44NCfl7qFuokLr0r3AAednBwIyOd0XZTMzk794eqZpjC Li1uu5/apan096xXGJXcy9p6oInI7KL8sKZZ1DlZjxXkzdGb/epTL08VQ41Lakku/UFxZVlvcz7z E3+6YcdzR/noUxTr7VtXNa7bcdh6mZdYpjOoRgCPcZ5Xwlmv0NMJxf3C+z7lytO/B6AECIAACIAA CHQXgTRzhWJGKbI9pcR6e2R7onTmwikqxY1SKUp2XrDL7LH55UxtxBgrQbol17VOXf74Y1vos2yq 1vBjw3riXt6VP931x64ZoQu5e2K5VyOVTbqbn0v/LJ1WpVUNKGNHlE1cYuxvGL2qTlip+GTFFL68 rrVOn1Cq5Cjlq2uaTZ9SUKLp0fTWactYNZfXafPG+dpiVLSVrRCGuVHB9kUzG7SqKrO+6rZQIlH2 Irc2Ym1Xp80Rbc3aNOuHgWyaqjuOzW33UOMNcfGKS8y1mcLuVxFW6qm45Jk1Ktzlk5e2ZY9V4+dV 6P15y83aQmG+l7TdMrd2xXS7xd+mXPmERnZFzK3VtNoGdmk0TuLjHzcBWOSvt745yEslg5xE0bvC DeChBgcFGf2Mc2w3tSB1CFqGNXrQNwpBZWYGYHHLc+ifh3qNNrqxe48lo8mMFVRmVo1QtqqqdYH1 ZVXoyuo93GUSEl6Ue39QX1namLn6lKOhYv5Y6+uuMGcPO567lo86RbHfvsWI4T6pC3k7Dlsvzsyp j2o8V+0X6B1yFFM+9YihuF/4TD9ceIbpCygLAiAAAiAAAt1AIKF7PnFTFHeW0sgfijYWp8f8p0Ts XqGG7G2on6HNfWzJhHIbuh3btmoV5fresvJKbWvLq6yIqrwL+U2z61bWNvjYoRQttumeec21Uybo D2Rmof4DBmqtbW18trJ+zdYxk3UjV/mEyWOa5y90Pqcp5GjSflVNs+lLKkob1q2qqrtFPGcynbVV 3rN5pRxFq9EzcATmG+6dr9XdMkWVkE3FUAKk0FPZRuwJwXikGTa8Vmteuz6Ys1g2jVI4x+a6e6jw hrh4OSyVnLD7VeSDdAPpktfCXj75aXG6fJqlR3QyoNezgau9cWHmYteqb2oYra1YpxvTQynWtnjh iqqpy43rheRPqg4lIE+Fg/SuIAN4kF4hqhSNjDBP1Bckwzw1VZDTVF9F74RsPbZt8Y/naVJXJDkj R1Su2cjvyNG3ID0niPRo/UFIHjaL3oH53I5VOoQdzwPVN/AUxXn7jut2HLZego/3dEIez2Wezv0O OaGnE6r7hfcI4zMdCtIRUQYEQAAEQAAE8kwgkeKRetwOxaL2uOEpSYmkWHZz+lno27BZ7lPzYVdO rVo5Qzhd07yEnogm8xm8qryznm07WrXRw4dFAcCe5dyOZTOSqpFDy5nM9pZmWXRZZZXWssNm1VDK keWrahpFceMYBaWmNSu1yv66lY3NnjWteZuXJUbZOopWi8Kc27Cctj+jKiqGFjwKPYO0UTaYi/XY XHcPFZfgF2/BkJUv+dCXT15qwbQaM1x3GMmcsX3j6ubMxU772RPXynVyxHEw9WQCwY7oplIBelfY Ady7JuHJeIS8uYX2sMid+iYzukcPQRJCxs1v1rbOG+ce0h6iBWIKQZWj0nIVjcg9R6bdbPN0Hjqy wv11AucWyIksQM8JQjR8f7BILTuhQmuWjGtZ668crwLU13Lb9ZqiuN2+47odR7lP+U0npCmcTN/R di5ywk4nIt0vfPQP0g9RBgRAAARAAATyToCC81JaqouW1DNOzXJI8fTmJRr91OhnIWePUgJj3tRz KhvGUzYTFrYT3tGJPI+qBmhmZqgQ2SXYs9zAaVdKz3j6rH08vZ69VXebqhlJHgcL9bxU7M2txT7F q+WUI2pr2591TcN0uoGV/ZgGhGXstsnL6waGOda/bHjmbOI7Zu5NSruhiqG/LlQiQBuRuXPdKq1q xIV2Z7hAJ+hxheLvHnHhVckJu1/VZHY5Lpc8HRo/n2y7UHtbi66VU5LQVt/K+0dbE5Y9hplW7Gy1 7a7jow3gPoNDeDKqkDcW2qPxMEkKmayYN04yo6ycsWDAUhFK2Szi1oWQZVOrtIEi+Jo+SxzOvDbS FLBpJmSsW2n80eO8YVqKhTI1VOj6L5va4hccGkg289CR78JtjT+ZXznXDCPNyBg2vGJ1UyE4uIbv D1YQzGQc8xZ1vAo6RfG7fVuqE+PtWFUvtT7u4zmPa2b58uSpHZ8guUxLIujvz9963wnFM+a+AnEg AAIgAAIgkAUBkbxcrKTHN5KVsUBxN6nC95NyqT97DzyjpY7m4nPGrJzhl5LcKaB9e6vW3LBQu9nM QjU+4JtbHgIz2cifwiVX3yTm/ctHrjUTPTAfe43yPrCJ/kxtMsUX2DYXObyEfX+2NQ3ZeV5lGWdW j1xqxqyFPN6jeGjmIgRD+L65biqGAXX2bSOWzYEcTIzQy4Bie3KxWLtHXHhVcsLuVzWcixy3S54d HiufeDuSxZXm1e1OC3m8pysmaZEG8Lh6ry8oHtpzlW6UZ6FqWzMWltFzdGNT9fBsMlKZuYp41jxd I6/z+iqdKcBDmcyXCmUTp0QNDmUi6V4vlhBhydok89PK+S6vfIQO1cMrG+5xuv6Rf42UBy1EfQqk aDz6RxqvAk5RfG/fNpJx3o7d6uWlj2o8d9uvkhNFf0/+thEmLM8C6ahQAwRAAARAAARYkJ4wQsmb ZJCiNFLceSqIUerRNX/986IFrp+8kxaJUfhcvKaebFLN82eGy13KHODNfEn0VjnoLLl90YKVVvco qe4i79IaPVdUJgnokgma3Y9AJcexP+uahmqbrfOmr710mf5GnaWvinMLy7xpoUsIhqSQZ1sEU9yz jTbNHtuwtapuKfK5GDBj7R5x4VXJCbtf1WM89bRe8rHyCdaDA5TS8+vxJ1jD3NDvhCoj756QwMJp q07oH0Ccs4gjGDmSlAI4KMQAHqz3xkFG2PGZL7DurJEnU2Jc57WFMvHg0MibmdQ8k1Ofy6L9zPfK NQSvZnJdq3FTjnzieA7Mpj/EfTumGkUar4JOUfxu3y5E47odu9YrkD7WESCjorTfQ05Y/T3520eY QPrH000hBQRAAARAAATiJWAun2d6SNEXWmWPm6l0S1UiqWc89zn1O2+//tWJU1w/8SrtL43NlfVF 7lhhlqEpwmZLkCQJVApj5iGfAC5LIIwuaNO6FVrtSMnTRyXHsT+emgaDwzFmnL/YqV2yzwSTpSoV gjmDlkmDQp5K/Kks88gRoC3C6GprI3JMm06OCUt9o13CnKOoy8baPeLCq5ITdr+qZQLpKS75WPnE 1VPKhl7qyP3Mh0xaCELOasfcWMxlIqTHZtv441SLBarIqW3iUrz75AQYwAP1ijjJ0EAkrfHqH4IX F71cnDcHhhVe3bKJtypWhi2vGdGybmNcTKLKybI/sJRDRobKqCpYjos4XgWdovjdvn3qEP12rKhX CH3cRgCmLt8fUI6//p78nSNMwPPG0jUgBARAAARAAARiJiCC8qxheWSAYsvrJfgie1o6qaWS7GcR bTzBp+mHz9JJhM5jwjNxLmRJN2hjqSIHXlpjJgpiSZTodbQjiI9nCFYHcPH06o58QywThy0RkkqO c38MNQ3crmWTJtdqBhOe90o2oqmYBBZPKedDMTe85cWTGAWS8KejzGLziraIpKetjWg6OI6W9oM1 Sm7c+LpHFLxuzaqSE3Y/q2UY+RIV6ZL35hPiMom1qNBKX/9BkkxuIwP1rENsADQz8pRdOHJgxsDE 90sDo4tq7KJunj+23lihr31Ro3M50VirlDthgQbwwL03JjK8RdyCzrw48JVns8udFOm8Ljrx3DrT Z+tBc/xWK2dgFJGkAePlvZuelidrGL2q7mo9dWOmMJllW9euth4cPCm490mD659Ff6DRia3cYmSo ZBplrX+08SrwFMXn9u0JNavbsaJewfRxHwH0lXP41C6InED6q/m7jjBBzpu7kRGSQQAEQAAEQCAr AjxcT6yyp2/kNHX59//AfqHMUqku+i/dsaera88/+n7putKHrrj2etX5KFiP3KOy0ib0wTwfqiVw zHRaoQmZmX6VUmCIuCqP8i7n5vMGvp/yv8r5UGn+N56MXKZYcSw7Y+vU5dYE6pYzysurZ4TXNjxu ScvtKkclX99vJJq1qRQaKD/Ag5L0J5vaLkxUcrxaISRzs4IEjdL3mv5KKobcsmBvO6U+ijaSu5au gNyy0aAXz1G57h4qvJ4Xr0uzquSE3c9bJoR85SVvubLsV313tj9/wjEjvdyGUMsAKAHM7He0jnSI LL/KPkJ2Z8WlcwcarAIM4OEGBzcygTThmpstZT1EJ892bptsJPtrmnXewkr5LpYZ3DJy3NqC9fyW yZnVbOWRVnlet5tysJu17VZr3IwCDLDW+maqwlqEFjaZJZYZIQ7MdrP87qHrr2bJEPVbBqche7zy drQr49pXvScV+l8D6M+HGelKNK4UxZWlj0iqG1As+rve7n3a0TEFCjJFUXcqqZ+HvB1Huk/pOJX6 SO3oMc67T0tC6m+diWXuF0FGGNt0qEDGWKgBAiAAAiBQcARe3vzASUNGxaIWiRo1atQzzzwTXFpF RUXDgsY7Oi/pu+VPWq/SREkpW1gvSWvrJZO0yB4zSLGgPUp1nkp3pro6d6e69jzbZ0ThGaSCVxkl QQAEQAAEwhFgT8jbp1gt5uEkoDQIZEMgsMdZNifJ4bHFrn8O0UA0CIAACIAACIBAtxIoWIMUs0mx ED4eyMeSR4m4vW6FhZODAAiAAAjknwCL7Vq1gK8IQR4BsURO5b8SOGPxEmhrWtus+YSFFnLtil3/ QmYL3UAABEAABEAABHoCgTTLHsUC9sjuZAbuFVW6qJ7QCqgDCIAACBQkgZr6ZVM1vojb2IYKeeGF gtQWSvUkAhRex3pdg23JvKKpYrHrXzSgoSgIgAAIgAAIgEAxE2DL7JFRKsl/6htbZY+H7PGfFLeX JlcpOc1UMVcYuoMACIAACAQmUDZxCV83YAsC9wIzQ8E4CNTUF3evK3b942hDyAABEAABEAABEAAB bwJmKB53lNJX3GMGKbGlKK85M0uRBxVIggAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgECcBJJkjTKM TvSdfZhXVIJcp7CBAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAQGwERN5yJo65SLGNviYTLKOURj/Z F2wgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgEB8B097EjFLGL0nKam66S8V3LkgCARAAARAAARAA ARAAARAAARAAARAAARAAAUZAeEWZaaNYhnMtxexTZJbCenvoIyAAAiAAAiAAAiAAAiAAAiAAAiAA AiAAAnETYN5QwiZlGqeYGUr2kOJZzbGBAAiAAAiAAAiAgI3Ahvrzr1jc3uOxUDVnberxtUQFQQAE QAAEQAAEQKA7CIgF9sSZM35RKUMVttZe4W5tiyeddp59pkhzR9opPvJcWdo/e4NfnYRk9rl6UZtX 4fbGqzOn0w+pb5KPEKJss3ZXzcVRruVV+z3k+FVR+Xd3mZtmG1QnNQZ7AFHp5r0/APOM5lZW/m3h WmdXfTId4DxLbwnViyI3QSEfmNPu4YE3VFdXyQm7X9UQ7nLaF11hjDynWbuNFv7yyUsfkC4ZeaDL aGuOrqyk/EzOCPCBTrpSxEgojw8K+XmpW7Yn8WhNo9ZOI0WQXmojFt3SIWkYXYgNE5MZYoSva516 64QyXYaFmK0nZNsa+T7eymHYlVNbpmdrk1K1u3kp8To2zaKLiF1Z4tox7z7s18i2v/huWy5XtGIE sN6OfeZR/s0b9r7jKO81PVBNGj2mZHFNG8LWy2UqqBqpPEcw1yll6GmP4r7m3d9UU1z/ToASIAAC IAACPZQAmZtYrF6CLa9XYgnUK/S05mzeNlMbMcbaMHSroyny8scf20KfZVO1hh8L6wnbr81hOx9/ rGH0qjrP6RHdTceuGaELuXtiuVfbl026m59L/yydVqVVDTAm6HRg+6KZDVpVlSzCXXNzTu8oz/8S Vk7E/qrQjaYd01unLWPVXF6nzRvna9FT1VFZ9zDMjbrZmfi1hQsTZS8yO8Dyulazt4TqRRFboKAP y233UOP1vGQcxFRywu5XNYVSz7KJS4yhgA0ypmE69OWTl07AHlfGz6vQR8UtN2sLhauLpO2WubUr /J7Dyyc0stFvbq2m1Taw6jdO0sc/ajWL/PXF5WOiak1uMnDeeoQpwW2/W2uONrAHIKzsDbqGc2w3 wbz0Hv2WNO1m2/1R9AHxMXtCnjRyOU0Y+5rnfX7irXUDV0z3vfH51dSn3cloMmMFlZlVIwRVVbUu yNoBLb7blvsVrR4BtDFz9c7QUDF/rM1G74dK+nvY+45reeX0QDVpVE/J4po2hK2XYiqoGqmUI5i7 HOIQbtqjuK/59DeXqWyIroCiIAACIAACPYuA6RVFpihjY1F8Ui0LeaG9DfUztLmPLZlQbmuVHdu2 ahXl+t6y8kpta8urrAibMxmTvGHDa7XmtetVbj6bZtetrG3wsUMpOsOme+Y1104x3xhr2oZ752t1 t0ypyJRXaS5KOMur9nvLidZZVTI3rFtVVXeLeM4snzB5jLbKe5aslKNoNXoGjsBcxUqvu6MtnEwU eravX7N1zGT9QYvVt3n+Qv4sHaIXRWuAwj4q191DhTdsV1fJCbtf1RpBukH/AQO11rY2cVGHvHzy 0wvo8mmWHn21son1bOBqb1yYudi16psaRmsr1llcPgOq17Z44YqqqcuNUZfkT6oOeGjBFbO0pmIQ C9tL9UpWX0XvMKIR7lZM7Y0/Ybc2w/jYrbrk5eTlE26ZVuVz4wuhiFu7ty3+8TxNumRI3MgRlWs2 imEk8hZkvAoiPJsretgselcXkV7Y+06gK1GaHqgmjYJJ4Clc6GlD2Hqp9JHbTh6pvPc76hVef8V9 zbu/+UzbgnRElAEBEAABEOhZBDIJpETUXjKdTqYpi1Q6kU7QF5bcnL4UZJ2HzXqs3u3xhlzrq1bO EJ7tdL+nJ6LJIZ+C2na0aqOHD4tSa/YsZzmW21lk+xRJVWnOTuhWXrXfS04U5dkxCplNa1Zqlf11 twc2K9W05m1eYXvK1lG0WhTmKlZ63R1t4cZEoWd7S7NcuqyySmvZESxMMSr5ojgu191DBSEXXT3H wNnkvmrk0HJ2mtCXT451E+KZVmOG644YmTO2b1zdnLnYaT97wlm5zjfG2aGzTCAvFcrhSSx1CTu4 hdPLGSzJ427swZJ+AVByFJUlms8lGJMraO4fN98y+Km0Z/1k4KU1ki+wup5MmfomM4rHGncmB1IZ oYKsyuSLxIPXzKh5NQebfBFJSj7FLH6WVWfrvHGOEH5VCK0Xh7ILRw5szto8pOTEPUccHmdDR1a4 vzzjPIMGV4brhO6ls7yiy06o0GR6wfUPe98JcL+wTA+8Jo0hpnChpw1h6yWuU+eUUmouVRs59rvI Cat/pPuaj/5x9FPIAAEQAAEQKCICFKTHc0eVaBSax6Pz6LdkKkHL7KVTWor9SKcojI/sUsW1MS/l OZUN42kiy2L03BydyGFBqxpxoWIuTa/LqgZoZmaoEFkb+Bx92pXmMx6b9IyZe1Ng25aqfFg5uWiw gZX92ByfsIzdNnl53cB4zxGeuR8Te1uE0rdmJHmFLNRzh7G31m6PaN69KNT5ir9w/N0jLrwqOWH3 q9rILkd/oB1Png6Z3Dpa/Hyy7TPtbS26Vk5JQlt9K+8vuXeGOCt7vDGt2CGOK6ii7q0Zq4rMU8O4 a5ANZd1wPd6NhfJxc0PZxCkWJzV6DhzoMFtYVGKhNw0VeujcMin5kat8/pR72nTNLG+JL1fV9dXt ze730FV1rmnUVs5YMGCpCO1sNuLoeZCjFNRpCfEjOQsrWZD40mna/Jn0hsmbw8oZekj+MvZGitng RLwS/aoNFMHm9FkinJfl+s6tmDfOMOv4cSivGVHVvH1HLO0vtzsT2EYeZ5VzXYIchw2vWN0U2+uQ LMbVbK9oZtqOeYs6rtqmB8pJo980w1KdGKcNqnqp9VGNVO77XeVE0N+fv7W/heIZc1+BOBAAARAA gaIhQAapRIrZp4TrFHeaKhrldUXZe9EZLXU0950zZuUMZ0pyFt9OrgFGQJajeu3bW7XmhoXazWYW qvEB88XyEJjJZgiDcL8P7p+lKh9WTq4a7FWWcWb1yKVm5GN8JwrN3JeJrS3CqsriCzTKecHeq8/U JlNMjW3z60VhT1j85WPtHnHhVckJu1/VPC5yqm8Sj77LR6615EyJlU+83cXiukKGhnilF7U0VWtm Xym6NwnDDcvNZ5gh6MHYjHCsHm5mhmIx5oaTGg+bUr5N4Xrx0BvzRYhsx3GXL4I0rwr84oSdg/m0 um9yDinpZczoOboxSKqXtmndCso7ZlbZKnCMbp3hnjXcIdeLgxl8yuvr7dDKQ2iN+rLQua3c4hOQ Q+v2bKxDru1OdVs53/W1B0NSPbyy4R6niyL514TN0hXXuJp992etGV5/l/NGGlft0wPFpNF3mmHT J85pg1u9vPRRjVRu+1Vyoujvyd/W38LyjKWbQQgIgAAIgEDxEUhqafqQHYp9Ifeo4qsBC/inxCh8 7ltTTzapZv5y1dw2zR7bsLWqbqlruB8vxaa/Zr4kx1tZNZH2RQvoxXXGPappoYv7vQdQVfmwcnLU ZlvnTV976TL9DTPLuRDnFpa5HxN7W0TQNZMAdckEze7r4d+LIpyxqA+JtXvEhVclJ+x+Vct46ilS ra3R03jHyie2nqLn1+NPhrTUA5fb74QqI++eOA8zPVSd0D/SSXtMoKu1NSOxsB1kJre2uAXJ8Wsz KDJa35jRRPQlS54XhR620BsedKlvCvla9/iyeUZq1440Yu1Z/xRGq8AcPCPKxfsP5kPNP+NlS1DO ffrc213TaD/zZXMNwauZXNdqjCRZ9L04xtVsrui4pw2EItK46pgeKCaNftMMl6aIa9rgWq9A+qhG Kmm/h5yw+nvyt/e3QPpn0b9xKAiAAAiAQBES0CP2SHMRusd/JskExb6yMD32g4XvFZdVis01pUXu WPafzEbvwabTq9Gl+qtadavZprOWVfMUR7E5jfzimr37zaSuIJ8sPgNWZ3xQlf9LSDk56YocY8b5 i0F2yT6T3alDMPdja2+L7BQTr/HNpyOWmiRYL8rytMVzeKzdIy68Kjlh96uaIZCeIqIhVj5xdYuy oZe65tJmC0HIDibMAmIuEyE9jtpGWqdaLAAkhwl34uIQQo4lkjHEcYGLbqhnkZ766q70NiVzIMte xIKIKdQojNetEGAaAtTyuy9HnpH4PxikIBx8eyY7FU0DpLVxjVA+S89XaVRxQqDEWcEqJJcqo4X8 3FewpVDBlnUbw0uMMvlRnyXLK5qlHDLS6mVVFePgiOOqY3qgmDT6TTN86hB92qCoVwh9VCMV3x9Q jr/+nvyd98eA542la0AICIAACIBAcREQuczNLUn5zMkMxXykEukuLd1JP7l1qmg27t5v+rezNA3G u1+6QY6jVYH8rVE8w+VClryDNpaCUU7dqr9hdgTx8QzBchig4SktZr3kfcBnwOplsFXlv6JHAAWV k5OWKps0mWJGdCY8p5JkoOGJpehVc8DARlcFwzH3YetoC/2UkfRkWUWkRGCBe1FO2qFAhcbXPaLg dWtWlZyw+xnwMPKlBuIrKojQKm8+3dWoQit9/QdJCXLHGJjJ8pPJdGPN6Mz3e+e0Zhd18/yxIsM0 A7moUfcX664qRz+v1JrRhYQ6kp1ROoCv9bl24b1rNT1TvocwngtmOiUFz9zCJNdd/UBJvpxtumlW sKTmPJuSeqXaYFXlQqwuzH4H+nOwLa7KV9q15mDiPdklCM6fQ1vT2maHt6CIeM3m9mdWmpYnaxi9 qs6ZsZ7Mx61rV1vhBE8Kzl6iqCc/wfXP4oqmUZStMCOl1aM1Z7JMyh5tXHVODxSTxrBTOLl1spo2 KOoVTB/VSJXZH0ROIP3V/F37W5Dz+l3++DsIgAAIgECPJaA7SHEXKcp0zlKca4lUKplKldBPnuC8 EDdjFSE2a18xnc0IRfZxcu9nUzo9PQeZEvTF+NhrMVobLuOof76+Fo+zcpRogyU6dST4UGMItZyf SvOwlOOSI59XKbP6puXs5S1jwtPl+mRqV8lRyg/PXIUrnrYw11riuX7NAM8QvShscxZD+Vx3DxXe sF1dJSfsfmUfUwwm8tJmlhUVQl4+eeoL9ISwbKpmDInkxSk2/lRseHdKGY7Y/go9sZqc+Uiv9fRV miYGXsMPlC5qnmFaj436iXZhyAVP88RBcRpVa4Ye3AJXQ3/g5zevBQOmSh5SJILMTFtXrKyQ12wN dhPM5KhSyZdyx1AecdkzS60687DbOu9ew9qYKSgnNfdbA473ELMHBlszzoUDO3kmNxON2PLtqaae pVHXA/TEJIF68vK6Vin5uq6nHwf3JcxEROSKdU4UgRteKjhsFsszMNZuk6KH/4rmqNndvG9bIfRX XNHKEcCYm7G4yAr3FWaCMAp73/G4X7hOD1STRpVuSvkhpw1h6+WnDxs35PuO8n6kEhRSf01xX9vL p0lBujTKgAAIgAAIuBLQ/aQSl89YQlF6XfRJdaa6urroa+eeF/p86brSh6649noVvD8vWvDViVOA FgRAAARAoGcQYG+5t0/xMz33jLoWRS3Io4Q9bSpSgHdDFZgbhZSRPV8aODmwVQW3Tc41GXaWNSOW O9ftjeLXmS9YQc5T7PoHqSPKgAAIgAAIgAAIyARe3vzASUNGxcKERI0aNeqZZ54JLq2ioqJhQeMd nZf0/+fyZEmvZGkvraQkmSzRyDsqyfKYk3sUSRNBe+mSogrXC04BJUEABEAABDwIsFinVQu4Rwk9 iscSkQTe0Qnw4HFn5F10gdkfqftHGLGB2QsMIqG7OLQvmqlYpYTF8Wk+4atBatZdZYpd/+7ihvOC AAiAAAiAAAjEQcCaQIokJhtvvOxu+vzwsl9N+9L/fOe8KcPLBh4cx5kgAwRAAARAoIgI1NQb4VQU pZtJ6l9ENegZqoo4mu7wRfLlJ3IeCatlzrdu5UBRSJVznSkgm2bpMezq7JA555LNCYpd/2zqjmNB AARAAARAAAS6mwBfSI9/pC3x4YcfptNpitXr7Ozs6OjYs2fP559+PGL5PgjZ6+72wvlBAARAAARA AARAAARAAARAAARAAARAIDqBAgnZK/vn8pJevRIl9CmVQvac9UqWRq8rjgQBEAABEAABEAABEAAB EAABEAABEAABEAABgwCtqedMEJUEHxAAARAAARAAARAAARAAARAAARAAARAAARDIEYE0t0elrSYo GKRyRBtiQQAEQAAEQAAEQAAEQAAEQAAEQAAEQKBHEaCF84Jvcs1TfD09WlCPvoifyd8sarr6p2u+ //sXV7786Wc9ihIqAwIgAAIgAAIgAAIgAAIgAAIgAAIgAAIg0O0EHGvs0Sp763fsTqWT77a/+dc/ P/6LjR/AJtXtrQQFQAAEQAAEQAAEQAAEQAAEQAAEQAAEQKDHEKAcUol0IpFiqaSSaU38ZCF7FMlH C+2Ru9Q7f3/m/rbdPabCqAgIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgEDBEaCQPTJFpckexc1SXYnE pn98/H7BqWkqtKH+/NPOE5/ZG6xqti2eRPtnbbIrr9rvrKQoyT5XL2rzYtDeeLWphvGlvokd0b7o Cl09uxxJ8/OvWNwui3c/76bZRk0nNZrFLfLtBLJpNndKrjp4nsZVToRWcz2JSk7Y/aoauMvxYB6e TzZt1I3H5rR7UL28L94Al2SGjRBlXGLqSzV8N85cp9bBx6N7d2OTqU8tMZEHukxnNkdRVlIeUVlN +UAnoRADoDRGaQr5hcfCpdepL/YsW99KTMblx4W3i/O+5ndYoL8HvzkGEhegkK3nmPUyuxaX0TSL OhXraaIvmXc69qvt7hngnPbBIWuYLj1ccUVYxx+feYV/VcKOw47yXuOhxxTFvORdpy42nhGulLD1 ctFHdeX6TZms9wvWBKH1V0wDvO8LzvP6Nz9KgAAIgAAIgEBPIEBeUbwaLHKPuUvRvwnykOIOUtwm lSKb1I4P3t1VmJWlW3idNmfL44/Rp2H0qrrM9I7NX2dqI8bY9Vbtd6kfzR7GrhmxnAvfcvfEci8E ZZPu5sX0z9JpVVrVgDLjiNoG80+GHKZ561Rd+LKpWsOPTRuT+3lpijO9ddoydorlddq8ccaMvGzi EkM4IyCsYNluCkoqHZSnc5cTvtXcT6CSE3a/Sn2lnirmoflk207ddHxuu4d4+HS7eLUwl6TBpn3R zAatqspE5X2puhJVdmNzfFhe12oOPuru3U3N5X1a9ng2fl6FPopuuVlbKIzjUmfeMrd2xXQfC0j5 hEY2+s2t1TQx3DVO0sc/omeRv97xhqAwuCh6neJip1aOofWr9FuAZUjPAw7W6GFMYLlWabTR/dx7 GhlNZqygMrNqhCJVVa0LrK9wIikYYjLgKd+9h6uvCG3MXH2q0FAxf6zjRVrguoQdh13LK8dDjykK 09A+rtKuuMbJsPXiwJz6qG7T3lMmh5zQV7piGuBzX3DhGbgjoCAIgAAIgAAIFDsBskDxpfYyW1J4 R7H/WZLzRDr9+nsFmkeKzfmMSeqw4bVa89r1/GFqQ/0Mbe5jSyaU21pHtd+lETfNrltZ2+Bjh1I0 /qZ75jXXTplgGqRciu3YtlWrKNf1Kyuv1La2vMqLKc67Yd2qqrpbxDNe+YTJY7RVzhl5/wEDtda2 tqx7pJJeAB3kk6vkhG01VYVUcsLuDytfLi8zD9JGWTdO9wvIdfdQXqSRLskN987X6m6ZUhH9UlXo 075+zdYxk3U7Nbskm+cv5KYWVffr/pZz04D4NEuP+lrZxHo2cLU3LswMOFr1TQ2jtRXrohi72xYv XEFmF2OUJvmTqguRRJBbg3Sxx9z65TUjqrTW7RY3WTWl6pvI9lefG4zCjJIj4f4NX30Vvcux9bS2 xT+ep0ldiKSMHFG5ZmOWd7ogLe6vMHOfid7Dh82id1cut/Ig5w07DgeqrzR1UU5RuHLOcTWucTJs vQQr73FeNTVy7nfICX2lq6YB3vcFn/tUkA6BMiAAAiAAAiBQrAT4ynrCP8r8JBfddPHvZl18740j 7/7+l34zffid0y48//DiquCwWe5TatV+Z+3adrRqo4cPi1Jt9izne+ywK6dWrZwh3N1pBkbPbJP5 A4bivE1rVmqV/XULF5sBa1rzNtvjC5s5VY0cWh5FZ8sxCkpBdAgiR6lf8NbJuopxCZCZh+YTlxJ5 lpPr7qHqBlEuSW7DUpuGg12q7oNJe0uzDL6sskpr2RHQopDnFvM4Heu0Y4brjieZcu0bVzdnBhza z57cVq6zxUQHqEZsg1KAc2VVJMDgI9cl5tZnZsGqERearzDcQn5UoW2s2spIYTkgi7tEiXilcfOb ta3zxunR5XrUlRTKpA65yjjKMX3qm8wopGzi5rxajnuOTLvZ5qE8dGSF/vLJdizXJ5DzV4AWD9Kj suzhZSdUaM2ScS1r/ZW3oQD1tYyHqimK6G/OcVUhP/SVEuX+4jfOK6ZGjrZzkRNW/0jTAB/9g/RD lAEBEAABEACBYicgwvaMjSU1L8KNXkxp8pw+uyrQ68GqAZqZGSrEbJs9yw2cdqX8jLeqTk8jJU2U md/4nMqG8ZQNhEUdGq5Y6vMOrOxHVWIPGGO3TV5eNzBTP/1pZDy9Rr7V0y0rOyR0tFqHqKLjajWV nLD7VfWwy3FnHj+fqFy75bjcVj/8Jcmer8bMvUlpVna5VINzqxlJTkML9dRyzInDYp/S5cTVvYOr Fa5ke1uLflE7jxOtqW/l/VU+Zt4nZI9zpiU9nG6FU9rlYo+p9ZspYotZhVj4tumNy0J+ND3Ke27F vHH6XUMPAWPhkHMsoeiK8jyESgqWFEGUIl5p2dQqbaAIAKfPEnHX0EOZrMJ5Ap2xDRW6PsumtsjB mytnLBiwVIRqNktR59GbjnnoyHfPtsafzK+ca4Z/ZgQPG16xuqkQ7L/Z9nBm6o15izoO28ZDxRRF uE96jauW6sR0pTCZqnqp9VFNjdz3u8qJoL8/f+t9IRTPmPsKxIEACIAACIBAgRIoRoMUi8+nV/1G BE3WZNu3t2rNDQu1m/mUneV4Gh8w7ykPgZls5E8xZ/kiyxW9lDZsUux19IyWOprNzxmzcoaRNN3z vK+ybC+rRy41oxT1avIIDpZbauTaLBJSBGOm0iHY0bZScbWaSk7Y/apKuMhRMY+VTySo3XpQDqsf +pIUkT7C8dB1s1+qIcmxcBtNNyjM1CZTqFGOundIvSIWt7i6vLrdzbwWUXLRH+Z2scfT+jyHlOXt AjnMssjoq3QrKgth2+pteVGW37RuBeXzMoMlIzYDD1kyrbplE6fIwZuj5+jGrOrhjnSNYc5Hd0Dx zoblSZTMTyvnu9p5mejq4ZUN9zhd9si/RspfFkaHwigbj/6RxmH7eOg+RSEDpc+4agMZz5UihLrV y0sf1W3abb9KThT9PfnbphNheRZGP4UWIAACIAACIBArAZ7HPJFmP3nOKE0rPoPUptljG7ZW1S2N L/MFc6Q3czbRq2PLLNyDf/uiBStt7lGZ0sNm0ctnPVeUSN3CZ/M19WSTap4/k4XveZx367zpay9d pr/NZvkdHJvILbUmhzmD/XUI0TfjajWVnLD7Vap76mllHiufECgLpGhOqx/2kmxa6BLpI4HyvFSD Ac3kA14yQbO7AsXVvYOpkkUpfUTiT8JkNOeS+p1QZWa14ztYvGTVCf0jnaYIIxnd62m92GNrfZ6A zAxAE4ZX5jnLP+OVFhldR2X5KCGuLvW2hSzx4M3YNzOpeSYXPj8H7Wc+Wa4heDWT61pzebMLUcls erjrrTzEuV2KRhqHHeOhYoriN6666BPXleJar0D6qKZG0n4POWH19+Rvvy8E0j+7/oCjQQAEQAAE QKCwCbAEUuZGBin+Pfmt2WuunP3wpJ+u+c7P//bv//3IdXPX3/DLjQVbEXqPN51eKS/VX9XGp6ct SZO0ap7yHPZUILaCLEBGbOwpQhLIEtCYm9t5eYGM4xU73CXzCxNhCbSJDwZJCq5DgNPG1WoqOWH3 q1QOpKdgHiufAAgLrEg+qh/ikmTuIZksOeQ+yR/yM0+2PpdqWLjcG2Wk6Y0VqNuEPUcOypcNvdSR Q5qdhi2zIKfEYm4y5iIM0uO3bRxzasgCXuQUOTmoQ55Fug2w2bY+2Va0efdmcsbT7Uxas9UIqVNX VFk+jjUubKfNgQHFswXLJt4qryorlaVM8C3run1ikmUPZymHYsn8aICJOA47xkPFFMVvXPW5GqNf KYp6hdBHNTXi+wPK8dffk7/zvhDwvHke5HA6EAABEAABEMgzgZTIay5tSdplbtY/5Vk3/9PRDX4c raIVvzWKZ/RcyLLA0sZSTg68tMZMOatninUE8fEMwcqwwXZKh9GsJy/nqUzNiAOWOEPPtKI4b9mk ybWaoQ9PWCM9/RqYeHJ0KTOuP75QJbx1UDFxO0WUVnOTr5ITdj/TMYx8qU4S80BtFIp4URWOr3so qh3ukjSCMsSDPTn+8Id2MxpIdamG6camniyJj5RUJUr37q6mFq2mr64gKUEmkoGZrECZzD5lF44c mDEw8f3SwOhSC9ZqlCmp3rC2tC9qzKELZ24xug+wcbQ+W2VPH945YbdgNEXdlOWZTN3x1nEoX9c1 WA4mnkNn+mw9OI7fCq0ZEt31EhGgAePcvZuNkmc1jF5Vd7Wery1TmMyprWtXWw8OnhTc+6TB9c+i h9Now9YzkTM/Zq1/tNuQczxUTFF8xlVPqFldKYp6BdNHNTXK7A8iJ5D+av6u94Ug583tqAbpIAAC IAACIFAABMgrSjhGmVuidsZ9yVSnlkqlU7R1pro6u7p2v9B3+HWlD11x7fUqnf+8aMFXJ07Jb41o 9ka+D5aNL2HO87BagtqEC5Vqv7vWfP7B/0T5X+W8qjSPZJEUY+Za1vJjysi5aYXQjBAegCBl9JCV t4hSnFdSvrbhcT1Vs6VGVvmRm8KDkqsO/EQuTFRywraaSr5KTtj9YeV7MFfzidwaBXdgrruH10Ua 8pI02VGXoOzLphOl+6UashtLl3bmeiQZqu5XcA1pKsSflMykUaa3qVQRywDout/RatIhsnzKmmRm 7y4kIoFuGfIAm+mKEVufnXHNCIMGHz81HY5VGdvdh6hRtvIZmnT3UZa3tKxVjnRj8r05Klt822Tj jkYqLayU7pK6SgFuSaxkRk6mT7CT0nIf+h2TVZlsN8vvHrr+apZIUb+WeS1k/2iuqpOYS1fzngwE 158PG9IVZPRwxRWh3yh1hRx8YtHff6rAT2+50p1TF+tQZpvtCP3lcVXJM+SVEun+ouNU6iNxDjJl stwvQupPqrjyD3JfsN2nCmmAhC4gAAIgAAI9kcDLmx84acioWGpGokaNGrVz585Q0hoWNN7ReUnZ 1hXJ0t7JktJEsoR+pimbVCKZuGzGfYl0Kp3uSnR1kTWKfwrTIBWqyigMAiAAAiAQggB70t4+xTB/ hzgQRXNIwG6QyuGpIosuJj9Bt0oWu/6RGw4HggAIgAAIgAAI7CUECsQg1f+lFSWlvRMlpVpJxiCV pBC+LhbIl0wntXQycdKoc2+bWrOXNAyqCQIgAAIgIAiw2K5VC9h6C+y1fywRWEAbjcCGxXrMWtvi hZaEZdHE5fiotqa1zZpPOGeOVchKfLHrn1XlcTAIgAAIgAAIgAAI5I0AyxCV1kpoaT1pS2pJcpSi hffIJpVIHzZg7ID9tGTxLb2XN4g4EQiAAAj0TAI19cumanzRt7ENFZms7T2zsgVdq2E12ky+9N5Y Wj5ymR6yXZAakwMX6y0NtiXzClJXN6WKXf+iAQ1FQQAEQAAEQAAEQEAjM1OS4vQYiUwiqcTdSx55 5B/vv3PwIUMHHTvilEOPSOz5/PPPR/ylpPBySKEJQQAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEghIo kJC9ipcoh1QvLVnSVVqaTJZqlEAqkUx+5dIvNsz80qJrz/j2+Ucdt0/QKqEcCIAACIAACIAACIAA CIAACIAACIAACIAACPgSSCfSaS1NwXnyhug8X24oAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgEJFA SktQ/ihukKL/9Q8MUhFp4jAQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAFfAsw/irJI0VJ6lMhc5JKi rFK+h6EACIAACIAACIAACIAACIAACIAACIAACIAACEQlkKCc5ulEiXCPIrOU1SCVSnXs3vPG6+9t 2Pxc1BPgOBAAARAAARAAARAAARAAARAAARAAARAAARCwEtCX1xPxerQlklfcuvabP1/zb79Ye+Xc ddfM3/TjP76w7JkPgQ0EQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEYiFA9qg0S2uuJ5CiL0nymjI3 +s5D+qx5z2M5czxCNtSff9p54jN7g1Vk2+JJtH/WJpcTiT9dsbjdWwlRjH2uXtTmVbS98WpTDeNL fRM7on3RFbp6djkZ4Q7N6ThXDV318ZYTmbI7vU2zDdqTGn3g6WdWtYL3/gDMMzWzslK3hScLV31U bD16XWTgxXVgTrtHtIvaCVAlJ+x+VdO4y7Fc8tZBKfzlk5deIV0y8kCX0dYcRVlJeURlBPhAJ10p YgCUxweF/LzULdRJXHq1ujXjGBzcyEhndN68PG5qoWoauLBLi/vcN1X6e9YrsD7KgrYeaKIzuyg/ smkWdU7WYwV58/Jkv/rOB9zP7XG9h66VS39QXFnW25zP/MRfj7DjuaO8121XGiddIHtMdWz9P8IV F7ZeLlMvVfv6tbuzXqH1V9wvvKcfASe3/n0CJUAABEAABEAgPwRYCqlEKqF1pbTONPt0pbUUhe1Z zE/MZJUfdUKfhW69ddqcLY8/Rp+G0avqMtMyNu+cqY0Y4yqyfdHMBq2qyud0dNcfu2bEci58y90T y72Kl026mxfTP0unVWlVA8qMI2obzD8ZckhzU/jyulZJc36Qm4au+vjICU1UHKCgR9Oj6a3TlrFq Lq/T5o2zWwAdZ1O1grJ1wjA3zmZn5d0WrkTc9VGxVfe6iLiL7bDcdo+IF7UDokpO2P2q1lHqWTZx iXG9s0FJGKZpC3355KVfsMeq8fMq9FF0y83aQmGml7TdMrd2xXR3y76pYvmERjb6za3VNDHcNU7S xz/qLRb5693eEOSlqt4nUfRqRWvGMTgoyOhnnON+84qFFGv0oG8UQp9QpX8e6jXa6MbuPZaMJjNW UJlZNaJSVVWtC/xeSvlXX3W9+x9pK+HeH9RXljZmrj7laKiYP9bttVYwFcKO567llbddNk62TtXn Ucumag0/trzKcpnqxHU7DlsvTsupj6p9vdvdISf0iKG4X/hMP4JNboN1DJQCARAAARAAgbwQkAxN ZJtK8PX2EnaDVF40iXYSNlczJpfDhtdqzWvX84epDfUztLmPLZlQ7ip2w73ztbpbplR4nnPT7LqV tQ0+diiFhE33zGuunTLBNEg5i7WvX7N1zGTdyFU+YfKY5vkLpec0Fw3d9fGRE42qit6Gdauq6m4R z5lMZ22V92xeKUfVOpGY+7Smf1uoeouSrarXRaNddEfluntEu6idGFVywu5XNVCQbtB/wECtta2N iwh7+eSnY9Dl0yw9omtlE+vZwNXeuDBzsWvVNzWM1lasMyxrYTRrW7xwRdXU5cYoTfInVYc5Pl9l vW8ZQgupNWMYHKKREeaJ+oJkmK+2CnCe6qvonZCtx7Yt/vE8TeqKJGbkiMo1G8XlGcsmX+9hBUbr D+Isw2bROzCf27FKn7DjeZArRZNuuzu2bdUqysvF6cvKK7WtLa9mdHHevhXyQ19xYesldPKeTqja 17nfISe8/orplvd9J9DkNmzXRHkQAAEQAAEQyDEBMkIl9Q87ExmjkmKVvcxae4UbrqdkM2yWesrO rR6e1iImtm1HqzZ6+LAo9NmznN+x7S3NsuiyyiqtZYcRAuemoUIfTzlRlBezW1d6TWtWapX9dSsb mz1rWvM2r7A9VSuo9kdh7tOaQdpCVd+csI3aJgV0XK67h6qqXhd1AeGRVWEPIVUjh5azfaEvn7zU iWk1ZrjuMJI5Y/vG1c2Zi532syeuletsMdEBNJQJBCjefUUC9C65LtkPDuHJeIS8uYX2sMid+iYz ukePRxNCxs1v1rbOG6dHl0cMVaPGiikEVY5Kcw2xj6FfcM+RaTfbPJ2HjqzQX2LZTsG5hXUiC9+m 0iUnjRURqlt2QoXWLBnXgusfdjwPcqXIU6BhV06tWjlD9DEyEpF5erJpTnW7fSvkh77iwtaLQfeb TijayNHuLnLC6h/pfhFschuhe+EQEAABEAABEMgHgSSZpQwblGmKytik8qFCtucgBwStasSFHm5J 7AzMQjFm7k2+liZ6rVc1QDMzQ4WYsrNnuYHTrpSf8VbV6WmkzAluzUjyOFio56Vib24z9il3DRX6 eMjJlqfb8QMr+3GGV58/dtvk5XUD4z1HeOZ+renSFsFVDsQ2WK8LftKiLhl/94gLr0pO2P2q5rHL 0R/Ux5NHxq0ZT8n4+WTbXdrbWjShlXOz7C/v7+1QqlKEPYaZVuxste2u411aM/vBITwZVcgbC+3R 9KjwuRXzxklmlJUzFgxYKkIpm0WolBCybGqVNlAEX9NniZczL4NOAZtG6sDz61YazeBx3jAtxUKZ Gip0/ZdNbfELDg0km3noyHfhtsafzK+ca4aRZmQMG16xuilYNkSPE7tf74E0NQqF7w9W8cxkHPMW dbyy3XZZl5tT2TCeuhBLsJDxOve7fVuqk/0VZ4pT1Uutj6p93fe7yomgvz9/630nFM+Y+wrEgQAI gAAIgEA2BER8XpJnkqLsUSmN55Ayt4yZKpuT5P5YFldPr/qNIDjVCYXTfuYFnVKx9u2tWnPDQu1m PmVniQ/GB3xzy0NgJhv5U4wHAD3LFb2U1p8WmI+9Rnkf2ER/pjaZ4gvEptBQqY9KTq6Qv8oyzqwe udSMlIzvRKGZ+7amvS1C6urLNmCvC3naYi4ea/eIC69KTtj96lHFMfhU3yQe9ZePXGvJ7RIrn3g7 isWV5tXtFg/OeM9UdNLcWrNwBgceCnqV/oqFhaptzVhYRs/RjU3Vw7PJSGXmKuK5GvX28zpviCbm oUzmK6KyiVOiBoeyc66coRvOWK5Dyfy0cr70yseqXPXwyoZ7nK5/5F8j5UHzq4/qevc7Lnd/D6e/ So9I45X9tsuc8ma01JFhdM4YaiAj0afv7dumVJxXnFu9vPRRta/bfpWcKPp78rfdv8LyzF3fg2QQ AAEQAAEQyJaAHrNXoiXEh0xVJLJg19gT1d00e2zD1qq6pX6ZNZoWujjtuxJjDvBmviR6qxx0lty+ aMFKm3tURv6wWZSn1kygkEkCumSCZvgRqDT00MdVTrbdQHH81nnT1166TH+jznJDxLmFZe7Xmp5t EUxxT7ZBe12wU/WEUrF2j7jwquSE3a9qIE89Raq1NXp6uFj5xNZh9BGJP8Ea5oZ+J1RZU72wcNqq E/pHOmkmGDnS4YVzkLU1Yxgc4iAj7PjM/YR/xistLzFzjOu8tlAmHhwaeTOTmmdy6nNZtJ/5XrmG 4NVMrms1rtDIJ9YPtPaQ0NKy6Q9x345J+UjjleO2K7LUccNoTT3ZpJrnz2The363bxd4MVxxXKpr vQLpo2pfab+HnLD6e/K333cC6R+6R+IAEAABEAABEMgrASOTVEIrsUfqCQ+qvGoT5mT0/m06vSJe 6ht3oG1at0JKnEEeVXwer8wTYUuQJK2ap1SPzb08wgZZgIzbxhSrHUmJFTw19NfHlBOGX+CyLNGV lnH+Yg8kLtlnAotzLehfR/Mwv9b0aYuwetrYBu91YU9UrOVj7R5x4VXJCbtf1SiB9BSRF7HyiauT lA291JH7mclmuYelrHYac2MxMxNLj81sEPAcGFmgipzaJi7Fu0+OW4RjlMEhTjJ0+5PWePUPwYuL Xi7OmwPDCq9u2cRbFSvDlteMaFm3MS4mmjIG1vsMWfYHlnLISFcXS1UijleO265tiOBiafO7ffvU IcoVJ0Qq6hVCH88Y54By/PX35O+87wQ8byxdA0JAAARAAARAIGcEmNkpzT6JJFtqT/rQKVOatB5f zlSIIJhuzONoybwA1igSbvhXi7k7hR7w+bRLXgkqyzNxLtTXJ2apIgdeWmOmp2JJlOh1tCOIj2cI VoYNtlMai2Y5o6eoL8vEYaS1UmvoqY9DTgSS/oeUTZpcqxlMeN4rbkTTNxUTf7lmiXDMfVpT1RaR 9JTbiNQN1etCACjqovF1jyh43ZpVJSfsftYsYeRLzciT+IrEdt58uqvphVZ6ymFJCXIbGahnHWJj lJmRp+zCkQMzBia+XxoYXWrBLurm+WPrjRX62hc1SsuJdle1o51Xak1JQNTBISYyvEXcgs686sgX O8sud1Kk87roxHPrTJ+tB83xW62cgVFEkgaMl/duVlqerGH0qjojZCxTmMyyrWtXWw8OnhRcPs7Z Q4Lrn0V/oNGJJQuX0tVR+vAISdnlqkQbr5y3XZ5t3eyfbMTgSeXCTMbszRr1iuNyFPUKpo/7CKAn a+fjfBA5gfRX83e9fwU5b7RRD0eBAAiAAAiAQB4IpNmmpdIa/UN2p850OjHqB39mv6VT6VRXqqur s2tXV+eel46/8LrSh6649nqVTn9etOCrE6fkQWPL856UY1Xs50uY8zyploAypwsVzdgo4auXXxWf N3ChlP9VtlvR/I9FRlBmDTlIkATWtU5dnsnZyQ/NCNF109XP7K9teNw9ybpdQ1d9AsgJ2yYe9KQ/ 2dR2YaKS49U6IZmbVbOxcm8LVjqEnlLbWSrLhJuZfaVeF5ZzkZbPdfdQ4fW8qF2aVSUn7H7eTCHk W/Tkw5HZ0OrLp1v7An/CMZNGmUOlBMoyALrud7SOdIgsv8oxQnZr1d2aRt8nOChbUzHwhhsc3MhE GDath+jk2c5tk43u1zTrvIWV8l1MujF5+heznt8yOXOnk0da5Xndbr4e16+qp1FL6EdZryPXLmOt b6YIE065tPXLkDgw283yu4euv5olQ9QnAJyGzIGrZLvvu/dUj+s9lP58mJGuRONKUVxZ+oik6+Tg E1F/Ls7k4Dpe+bSjcwrE7DWZO6Zt1iT0V3cqSZ+QV1yk+5SOU6mPxNm73Z31ijCdcOUfZITxn9wW xqgLLUAABEAABLqZwMubHzhpyKhYlCBRo0aN2rlzZyhpDQsa7+i8pO9Lq5IlpYlk70Rpr0SyREsm E+QgVTwGqVBVRmEQAAEQAIEQBNgT8vYpCot5CDkoCgLRCETxl4x2ptwcVez654YKpIIACIAACIAA CHQ/gcIxSCVKetFHI4MUWabIGpVIJrnHFPlHMY+pAg3V6/4WhAYgAAIg0MMJsNiuVQtYEmLmqxJL 5FQPJ4bqxUqgrWlts+YTFhrrCWMWVuz6x4wD4kAABEAABEAABEDASYAboWgxvUzaqGSKJ41KJ1ji KLJNgRoIgAAIgMDeSKCmftlUjS/iNrahQsoZtzeyQJ3zS4DC61iva1DkecyvMhHOVuz6R6gyDgEB EAABEAABEACBCAR4JnP6lKR4SnP2nftFiZ/iX/YfNhAAARAAgb2MQNnEJXwViC0I3NvLWr67q1tT X9y9rtj17+72x/lBAARAAARAAAT2DgIJ8owiXyixkTWKNjJLcd8o5iHF/aSMP+8dRFBLEAABEAAB EAABEAABEAABEAABEAABEACB3BIgc1OKjFLc7iRMT0n6yT7CLpVK6F9yqwakgwAIgAAIgAAIgAAI gAAIgAAIgAAIgAAI7BUEusjwxML0yPBEaaQSZJein5RPyozXExSoFNuJDQRAAARAAARAAARAAARA AARAAARAAARAAASyJFBCRihKGsWlMPco4SElhFLuKHPjvlLYQAAEQAAEQAAEQAAEQAAEQAAEQAAE QAAEQCBbAmSNoiX2ZClkltKTmpt7eXJz5JHKljWOBwEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQyJiZ DJtUiqeRSpKNyvCN0mP3jBX3AA0EQAAEQAAEQAAETAIb6s+/YnF7jwdC1Zy1qcfXEhUEARAAARAA ARAAgTwSEIF4tmX0WMge2aRsrlN51CrUqWiOeNp54jN7g/XItsWTaL9lBtm+6Aq9MD/k6kVtnicT EgKUbG+82lTD+FLfxGSrz5gRLmvuXl4t39BfSIvxqcCFHp1r02yD9qTGYA8g7nI0zXt/AOaZlrPW 3Z+Va5u76uPeRprm0etC9d7iLZzT7hHuolZDVMkJu191Bnc5lkvYOiiFv3zy0kOkS0YeEjPamqMo KymPqIwAH+ikK0UMgPL4oJCfl7ple5JwrRli8LERi27pkDSMLsSGickMMcLXtU69dUKZLsN2Cwss J9uWysXxVg7DrpzaMj1bm5Sq3c1LidejaRZdROzKEj3KHEbYr1ne5eOYKrhc0YoRwHpF+M24fNsw 7H3HUd7rCpXGcxfIrtzimjaErZc55GY6g2qk8hjBOG5nvUJPexT3Ne9pUhz90Le/oAAIgAAIgECR EGCL6/GgPHPL5C9nWc6tEX0FVim6pdVpc7Y8/hh9GkavqstMd9h8bqY2YoyLwrUNvDz73D2x3PNp duyaEcsDlNS0skl3GzJZ+aXTqrSqAcYEXXM5I2luCl9e1yppTgo5y3vLZ2avmQ1aVVVczaOgR9OO 6a3TlrGaLq/T5o2zWwAdp1e1grJ1aAYTmLlxNnvd/Vi5QHLXR9VG6l4XF/8Cl5Pb7hHponYhppIT dr+qMZR6lk1cYowwbFAShmnaQl8+eekG7HFl/LwKfRTdcrO2ULi6SNpumVu7wu85vHxCIxtR59Ya w1fjJH38o95ikb++uHxMwrVmyMFntIE9AGFlb9A1nON2s8t9F+LD77SbbXdS6Rb2uNkTcq+M6gxh 7GteWpZNvLVu4Irpvjc+v5r6tDsZTWasoDKzaoSgqqrWBXE5oMUwVXC/otUjgDZmrj47aqiYP9bx 4tAPlvn3sPcd1/LKK5SN561T9fnesqlaw48tr9xcuMU1bQhbLw7EqY9qpFLtF1wdckJPexT3NZ9p Ugz9MHDHQUEQAAEQAIEiIJBKUyYpeePL7ZlJo9jXgvWWYnMgY9I2bHit1rx2PX+Y2lA/Q5v72JIJ 5dH5b5pdt7K2wdNipRS+6Z55zbVTzDfGLuXa16/ZOmayPokvnzB5TPP8hcGf0xzyN9w7X6u7ZUpF 9OrKR6robVi3qqruFvGcyXTWVnnPkpVyVK0TiblP3f3bQtVblG2k6nXx0C94KbnuHnFd1Co5Yfer GiRIN+g/YKDW2tbGRYS9fPLTEejyaZYefbWyifVs4GpvXJi52LXqmxpGayvWGZa1MJq1LV64omrq cmOUJvmTqsMcX0hlQ7dmgMFHr1/1VfQOIxrhbiXU3vgTdusxjI/dqkteTl4+4ZZpVT43vhCKuLV7 2+Ifz9OkS4bEjRxRuWajGEay3LKfKmRzRQ+bRe/qItILe98JNAmUrtAd27ZqFeX6lLGsvFLb2vJq BraTm0J+6GlD2HoJnbzbUR6p5A7j3O+QE15/xbTQ+/6YfT/M8kLA4SAAAiAAAgVEIC3C9QwPqSTl OKdF92ivyCaVTlJGKbZpiYzbVAGpr1Rl2KzH6rN77Gnb0aqNHj4sSmXZs5zfse0tzbLossoqrWVH sBA4/qxokc/tOJ72r3DVUNBrWrNSq+yvuz2wWammNW/z0lnVCqr9UZj71D1IW2gKfbJpo3DAi6t0 rruHikb2F3XeObPJfdXIofwhJ/TlkxdtmVZjhuuOGJkztm9c3Zy52Gk/e5JZuc4WEx1AQ5lAgOIF XSRsawYafNxr7AyW5HE39mBJvwAoOYrKEs3nEozJFTH3j5tvuUGp2oX1k4GX1pi+wF7tx5SpbzKj eKxxZ3IglREqyKpMvkg8eM2Mr1dzsMkXkaR6yDyrztZ54/Ro+sypVSG0XhzKLhw5sDkm85ALL3eP s6EjK/SXbbZDOM+gwZXUvllPFbK8ostOqNBkesH1D3vfCXC/sFyhFI9ZtXKG6BtkJCIz+mRzDunG La5pQ9h6ievUsx1VbeTY7yIn7LQn0n0thn5Y0LcKKAcCIAACIBCaANmgmLkpwVKZc78o+oXbpcgi xRbho39JpjWoL/RJ8nEAOSBoVSMu9J8br6rT00h5TePodVnVAM3MDBUiawOfo0+7Un7Gc56xZiR5 HCzUM1ixN6KW6b+nhnb5bFI1Zu5NkWxnYdtlYGU/NscnLGO3TV5eNzDs8d7lwzP3q7tLWwRX2buN dDmBe13w8xZvyfi7R1x4VXLC7le1jV2O/kA7njwdMrl1tPj5ZNtX2ttadK2ckoS2+lbeP5r7JXu8 Ma3Y2WrbXcdHa81Qgw/z1DDuGmRzWTdcDypnoXz8PlU2cYrFSY2eAwc6AuUsgFjoTUOFHp++TEp+ 5CqfP+WeNl0zyweK/351e7P7Pde8hVlzO66csWDAUhHa2ZwJibKGgFlC/EjOwkoWJL50mjZ/JhkL vDmsnKGH8C9jxgVmgxPxSvSrNlAEm9NniXBelus7t2LeOGM+4MehvGZEVfP2HbH0RrndmcA28jir nOsS5DhseMXqpoCvrFSa+d0uA9Uo2yuambZj3qKOq7YrlHWVOZUN48n6yXpRxjs+FLcYpw2qeqn1 cR+pTEOz7X7kKieC/v78rffHUDxj7isQBwIgAAIgUOAE2Lp6zPCUTpN1ioxQ9F86xX7Q7nSKW6UK eGPx6vSq3wiCU2pqCaenV6Yqm1T79latuWGhdjOfwrKEAuMD5ovlITCTMyEMijMy33WN8imwd7Yz tckUr6Fvfhra5Av3/syrvFy30ass48zqkUvNSMn4ThiauW/d7W0RUldlGxlygva6kOct4uKxdo+4 8KrkhN2vahcXOdU3iUff5SPXWnKmxMon3n5icV0hQ0O80otaWqTWDDT4rJyhrxHBcvMZZgi6BZgR jtXDzcxQLCbdcFLjYVPeb1946I35okK247jLF0GaV4V6scF8Wt03OYeU9LJk9BzdGCTVS9u0bgWl TTSrbBU4RrfOcM8a7pDrxcEMPuX19XY65iG0Rn1Z6NxWbvEJyKF1ezbWIdd2p7qtnG99NSWxqB5e 2XCP00WR/Gu2BMvS5Xu77JZrNLj+XupFGlftVyhzvpvRUkcG0zljqIEM98Ow3OKcNrjVy0sf1Ujl tl8lJ4r+nvxt98ewPLulW+KkIAACIAACeSbAIvbYxl2ghE0qyeL1xNp7LOF5gj55Virs6TbNHtuw tapuaagwvWGzKAusJU2AdFo2/TXzJTneyqr1a1+0gF5cW9yjMoWtZ8wk11wyQXP1I3DR0C6/aaFL Qtmw+IKX3zpv+tpLl+lvmFnOhTi3sMz96u7ZFsEU92yjSL0u2HmLtFSs3SMuvCo5Yfer2sRTT5Fq bY2eHi5WPrH1EX0M5E+GtDQEl9vvhCrr2MhMD1Un9I900sDByJGk5/GgEK0ZcPAxk1tbbApy/NoM iozWN2Y0EX3JkudFAcAWesODLvVNIV/rHl82z0jt2pFG2BTrn8JoFZiDZ0S5eP/B3GH4Z7xsCcq5 T597u2sa7We+bK7vyWom17UaI0mETu93uwwjMpsrOu5pA+kdaVx1XKEimx43mNbUk02qmXvkaRG4 xTVtcK1XIH2sI1WmaaX9HnLC6u/J335/DKR/mM6IsiAAAiAAAj2DAM8WxUxP+pcE5ZCSNm6MKmT/ KHqvNZ1edS7VX70GbxQWruK12aaz0qp5yqPYnMbjxbXqjPwVsTnzzkh3lLfLZwdmUmOQjxifYQfO KBGcFSvJEl1pGecvNqF3yT4TTqa9dAjmfnX3aYuwetraKHKvC3veoikfa/eIC69KTtj9qlYIpKeI aIiVT1y9omzopa65tFlOX9nBhFlAzIy/0uMoGwQ8B0YWAJLDhDtxcQghJ1BrZjP4bKhnkTX6al/0 YJzRjWUvYoHeFGoU3ivWNASo5QfPYxiCV6CiRuL/QIW1IBx8eyY7FU0b9NBIOZTP0vNVGlWc4J8c IFhtbKXYQn7uK9hSqGDLuo2RhFLQVlxThSyvaJZyyEirF7Eq1sMijquOK9TWYbhY2rLkFn3aoKhX CH0sMdcSNL4/oBx//T35O++PAc8bS9eAEBAAARAAgSIkQFnLRTIpyibF7U8sgZT5MRfdK7Ca0Q1v HK3yE94aRZ75PyHjkTLYjWe4XKiv+8tSMMqpW/U3zI4gPp4hWBk2qDgjy1jhmgTKWd4h3/DEFrNq 8m7gM+wcLbNdNmkyxYzoTHjeK9mIpmISosOEY+5Td1VbRNLT1kbRe10IGsVWNL7uEQWvW7Oq5ITd z1oijHyp5XhyXBFa5c2nu1pbaKWn8pWUIHeMgZksP5lMN9aMzny/d05rdlE3zx8rMkwzkIsagy8n 2l1UFOcN3JreN4IQtWJnlIrz9VjXLrx3raZnyvcQxXPBTKek4HzjtzCn664kX8423TQrWFJznk3J Pdl28EpyIcIbJejmz8G2viFfNM2ag4n3ZJcgOH8ObU1rmx3egiLiNWBcv3c9aXmyhtGr6pwZ68l8 3Lp2tfXgoEnB/aYKwfXP4oqmUZQlC5fS6lH68DBJ2V3ARRtXnVcob3ezP7D+wx0G/bh5NWVW0wZF vYLpI41UFgUz+4PICaS/mr/rfTbIeYMOAygHAiAAAiDQkwjw6LwUT2MuYvXIIEVxeqyK5B2V5KnN 6WdBVpm95qK13jKO9+eLtXWM1YXYbH7FdDZT1LOSZ1bVGT+vQs5b6ageJdpgiU65P7+c4EPNwb4y i/EkkAkKkM9oasLzyGaCDdUausvPQbso6VXftJy9vGVMeLpcn0zqKjlK+eGZq2ofipV/b7G2karX 5aApClFkrrtH6ItaAUklJ+x+ZR/zGXzYZWJJjhvy8slT29MTAs+RJ4Yp8rIUG38qNrwvpQGQ7a/Q k9/JA6PeK6av0jSR0Nrw06SLmmeY1ofBn2gXZrf+aZ6wGKeRF6oL2JqhBh9ndfQHft4cCwZMlTyk qCyZmbauWFkhr6mquh4pxo3ZNURImtSCKvlS7hjKIy57ZqmRMw+7rfPuNayNmYJyUnM/j13eQ8we GMzD14UDO3kmNxPdVeXbU009S6Oud3IxGaCevLyu1VjhJNNj/Ti4L2EmIiJXrHOiiNJhWbQ+mXHt Nil6+K9ozk12txD6K65o5QhgzMFYXKT3pMsTVdj7jrK8cxE9fl7r9ULvCH1Wao5r2hC2XipIqpFK OYKpBCmmpsppj+K+tpdPk6Jc9jgGBEAABPZuAixgj+xPXWSQSmuUvjxxyf979pYZ/StKujo7P3rk jsfvem9PqmvPy30uuK70oSuuvV4F68+LFnx14pS9GyVqDwIgAAI9hwB7y719ip/puefUt+BrQh4l zC6mSAHeDeozNwopI3u+NHByYKsKbpucazLsLGtGLM8swWZUOIpfZ75gBTlPsesfpI4oAwIgAAIg AAIgIBN4efMDJw0ZFQsTEjVq1KidO3eGktawoPGOzkv6vfxwoqSXVlqaSJZqJaUUs0cbhe21vvyB kLZ//zNEqnNsIAACIAACexcBFuu0agH3KKFH8VgikvYugPHWVhF5F+9JwknT/SOM2MBwB0ct3V0c 2hfNVKwiwuL4NJ/w1ai1zcdxxa5/PhjhHCAAAiAAAiAAArkiQFYoEk1GJ93uxJOar27/SJzvuOPL KVyP/KZydXrIBQEQAAEQKEwCNfVGOBVF6bosvFCYWvc8rUQcTXf4IvmyFDmPhNUy51u3cqAopMq5 zhSNTbP0GPYcZW/MNdRi1z/XfCAfBEAABEAABEAgxwTI/4lsUTxzFI/do/xRI79/X/rQgf9zzbHH dnZ2fPLOvf/75KquPa19hyFkL8dtAfEgAAIgAAIgAAIgAAIgAAIgAAIgAAIgkEMCBRKy13frQ4nS XgkK2Uv0TiRLyCylJZO03p6W+vDt10UM4D77DxqUQxAQDQIgAAIgAAIgAAIgAAIgAAIgAAIgAAIg sDcSMJJEiQRSzCCVSH+4+o1dnEXvI/vtR3/YG7mgziAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAnET EJmh6GeKEkeRISqZTlDk3sjv/zlFa+594Qvzaw85oKNjz2vbJ92z9ZU+NRSyd8rXlKvsbV29YOCl WGUv7iaCPBAAARAAARAAARAAARAAARAAARAAARCIiUCvlwtilb0+FLLXq1eypDRNPxOlJYkk+Ugl yULF0kk9v/P13by6hx78ZSQ1j6nhIQYEQAAEQAAEQAAEQAAEQAAEQAAEQAAE9nICaUplTu5RGnOM ojA9ymxOQJKpVDKVTqS09mff6mSAeu874NTUXk4K1QcBEAABEAABEAABEAABEAABEAABEAABEIiF QCqdoiX22Cp7qYSwSmksjZS+JVa+9lkH+97ruH5Hx3I+CAEBEAABEAABEOhBBDbcPeaKh17vQRVy rwpVc9aWHl9LVBAEQAAEQAAEQAAE8k2AvKKSaZ7XXFinTIOUpj360RvcNergI47It1ZBz0dzxNO+ Iz7zNjgOanvoBvqTc66s2m8TIIqxz+z72rw0er1xtqmG8eXuJzRNtZ/J8tBcnNd17uvU3JtAUI4K dHYdtswzaN/Q+HYg2a51iVZ35/lUcsLuV9XEXc7b912hdzlHrwvPJxDEwivk3kXDV1/V1b33B7gk M8isl4zXJemB2VWfzPhgHXxydEnmrBdITOSBLtOa5ljESspjAqspG+g0CYUYAOXxQSE/Z/WJLNil ldUXe5atbyMW3dIhaRhdiA0ZkxlihK97bdKtl/TRZViI2XpC5JbppgOtHIbVTmppyNYmpWp381Li VX1iFl1EmSmEObdhl1Jk21+xjUvd1Og4LQiAAAiAAAiAQH4JMMcoLV2STifIFEUGKYrVozxS+qal W//5Ltfn4P3zq1bAs9Hcrk67actvVtCnoeaROpvZ6O37Zi7TqsodwlT7rQVp9jb2iQuWc+Fbbvqa U4xUvM+km3gx/fOraeVa1fE0QVftZ89vCs3ZTHSmdsEYVwQOzX0IBORoL6bQgR5QG3ZM+xmr5vJx 2rwbXSyAVknuciLW3VEXlZyw+1WQlHoe87UlRluzXscfyNkWmk/E5unuw3LbPcTDmOslEOaSNCDZ LxnlJammquzG5viwfNwOc/DJzSWZszZnj9zfnddXH0W3XKMtFK4uUmfeUnfRCr/n8PJLbmOjX91F mnZRA7s6bpt0jNCZ6Fnkry9QHxNFr1Nc7NTKMbR+jYE9AGFlD9A1vMn9lpGzjqML5tfXtGts90fR B8TH7Am5VkUtP4x9zUvLY75267iKFQ2+Nz6/mvq0O1mdZq+gMlefIwRVle9YkLUDWpGNS34I8XcQ AAEQAAEQAIGeQoCsUTyBuZYmJ6kEN0jxRFIspRTPbb727c94XfcpyBqzpyBj0jbsixdpbY+ul9x2 Nqxq1MbNmNLXrrpqv6Xclnl1TRc1+NihFFC2LJvXdtEU842xWUrar9J8w92ztboVSy7p5yraqbk3 gWiNptJhwzOPVI2bIZ4zyy+ZMEZ7xHuWrJITre7OuqjkhN2vohSEbf/jK7TXXm3jIsLyidY63X5U rruH8hKIdEn6XOyqS1WirNDn9fVPtI75sv4czi6HtsaF3NQSpNt0eyOaChCfZunRVzvma/Vs4Hq9 8a+Zi107bVpDjbbiGcPwGkb7tocWryiftNwYpUn+pNPCHJ+vst4Dr9BCutjjbv3TxtE7jGiE80XI 9TyvN97FbrKG8bFbdcnLycsvmTGt3OfGF0IRt3Zve2jOPE26ZEjcORdUPvG4uMtE3oprXIpcTRwI AiAAAiAAAiBQjARYInNugmJL6VEuKTJIiSTnzCb17kufvMP+LMXxFUkd+eOrm1VIsd9arba3dmg1 1cOi1JU9y7kdq9pvOcewq1fUqx7YVDWKoqTXMQodnljTpFUeq8dlsOdMTWt+wytviFdd3M4ftnzc 9Y4gjz2XVp1zXjk7NDSfCOcrhENy3T1U3SDKJelzyWRzSb7e0ia3Rp/Kcq3lraJLo8M67Zgv6o4Y mfq8/fjqtszFTvuZLaZpkzMm2q9DyheIX9lu/XuAwUeuS45b3xksyePg7MGSPoHkljhKSzSfSzAm p2/uv7GxOUhzsH5ScenpRrCe5yEsVO3uJ8yoMWvcmRxIa4QKsiqTLxIPXjOj5tUcbPJFJKkm4gdZ dVrn3ahH02dOrQox9uLQ58JzKpqzNg8pUbl7nJ03sq/lZZt5OOcZNLgySJOiDAiAAAiAAAiAAAjk n4CwRPGN26aSzBTF3KTILKVp299s35l/nSKckfxTtPILLtTjRNij5pi6aQ6Lkmq//YQ73mitOl4z M0OFyNrA5+jTal2f8dz2c88aSXNV1f01DyYnAlrzkIrKY+k7e3gY+8aE5eMqspEljo1LZ5WcsPtV NbLL0Z9YvkuvsjPJU7T4+WRPOI8Sclv98Jek3yWjulQDITtnJDkN/VVPLcecGtpcDourewfSKEKh t19t0Tut82DRmvpWfmz/COJprCCznWnFjiShAA5yudjjbn3mqWfcHciG8ky1Hu/GQvm4ueGYr02x OKmRJbHCEShnYcWCCpf110PnfiYlP3KVT4eyIE3NLF8VBPxb7c2Ze658wCN1rln2mmYvOP5XIrSz edkcIwuhNajTEuJHchZXsiDxX03TGmdS2Jo3h6bZeiD8zyZVNc1mNjgRz0i/ahUi2Jw+S4Tzslzf uv7zbjTMOn4cyk+/oKqtfUcQPr5l5HZnhV8lj7PKOpcgx2Ff7L/62djs3YU+LvlyQwEQAAEQAAEQ AIEeRIDZnbQEz1zONzJNkTMUi93jYXu05t5HT7+7u+ArzPIj0Kt+I4JGOL1PdrgaqfY76vf69te0 5mWLtWv4FPZnk7Rl3w2YL5aHwExwhjCo9ts0V5H21TygnGxb8i2WcWb1Ob8yIyWzERiXzio5Yfer 4Vt6Fyt22jTxbLP8nEfHygmtY+WTDdvuOTaH1Q99SfpeMqpLMiC6YVezh+Sx/MF7pjaBQq5sW1zd O6A+WRazuK6QoSFLcT3pcLeLPZ7Wb5qtrxHBcvMZZgiyoZgRjqdVm5mhWEy64aTGAyHNty+urHlQ oflKRrbjuMsXQZrjQjkFM6dF903OISW9Fqq5STcGSfXStmxaQXnHzCpbBY7RrTN9TuirO+R6cTCD T3l9vT0WeYS1UV8WOtfKLT4BOezYHmxND3c8ru1ORZsaXe3a/I5TXblsmdNFkTz7wmbpKq5xqScN JKgLCIAACIAACICAGwEyOpFDVIkI0kvST7JGJVmac2aZYg5S5Cn199c+/7yw6W2ZN3ZZa9W4XxnB bk8sdEmzSlVQ7XfWjk1/zXxJjreyahpv37eAXly7uEcp9ts1V0n20zyonCzbsXVew6OX/kx/w0we K1mJi0tnlZyw+1WV8dRT5NJao+dpjpVPVnC75eCcVj/sJel3yagu1RDkMvnRl1yi2V2B4ureIfSJ VrS15S12IH+ypaUhuJBjy6o0fb8QykwP5WXRvKSKMJLRnaT1Yo+j9c3k1ha3IDl+bTZFRusbM5qI ocaSwUrR6ragQh50qW8K+Vr3+LJ5huJeNNJ4q8T6pzBaBebgGVEuDNzfNRaN/a5sCcq5T597u2sa 7We+bK4heOdMHrfDuNFEu9L5UUUzLmVRRxwKAiAAAiAAAiBQZARodT36j5mkUsw5iuWQSvLNXGzv 2X/+v/mPFWytKAChgV51/kp/9cqmXPTGNZMwgjyn+LzzhsYNiv2KV5226SxfNc9nYz4Xbi+u3fc7 NVeJV9VIaB5cjp/+nn9nWXK0jPMXm9C7ZJ8JeIq4dFbJCbtfpXYgPUVwU6x8AmIsoGL5qH6IS9L7 kqFYUcWlGpEo9/IwH57zdUlGVDZz2DHnXeqaS/uYfpWa7GDCLCBa3340ANAmGZjYIOA5MLLQthwm 3MkaQHgBlkhG/fBYW3/D3SwQWF/d9Tfy2nksexGLEqVQUzf/X++6mO8P1PK7LwmasS5EsOYIwsG3 Z7JT0bRBWhvXCOWz9HCVRv1P0JMDBFM5eCm2kJ/7CrYUKtjyzOPBJbmUDHQ7y+oMOBgEQAAEQAAE QAAEQhJgqcyTaZbJnMXnpRO01F6aTFHMGMXi9Vg2KfYLmadCCs5TcZpg3Uir/EjWKDqxEWEh5pr0 zp/PO2+bNEwPs7Lvd5tZDqulJBSL9SQXLDWynLpVf8PsCOLjGYKNsEGJgNt+V81V1FQ1Is1Dycmq VfpM+jLFjOhMeNIc6QmcJ5ait82BAhuj6OwmXyUn7H6GJYx8CSMtzmXEznjzyQp9MRwcX/dQ1Dbc JelxyTD5qks1TDc29WRJZ6SMdVG6d3e1sGi12Y4ceeSOUZHJ8pPJdGPN6Mz3e+e0Zq3W1jhWZJim 7e37GnV3wu6qcvTzShe7JCSXrc/OKJ2KL+b46MJVj2r6QgoedeFZrhooKTjf+C3M6boryecxcXqu 7idmBUtqzrMpuSfbDk6ZC+H5oQJv/hxsq2cyA6uIyDM33pNdguD8ObQ9+2izw1tQRLwGuv35VZOW w2uoeaTOmbGezMevPbraeniIpObFNC75McLfQQAEQAAEQAAEegwBcozqTKS7WHQe38gqRZ/aH61I 05ZKpVMdqVSn1kk/9vzzmPOuK33olK9dr6r81tULBl46Jb9oaDZGDlCWTV7CnP+BylAi1Yz/lFFa tT8jjT9p8F8pH6qcZ5SeWpmH/5g6y4p4TJnXJi2/SV8J3pTjul+lOc9EawmFszh/OWoUhEDYNvHQ QfoTZQmRc8a7MFHJiVR3F/kqOWH3cz4h5FvqZe1vaj5hG6Fwy+e6e3hdAiEvSfkalAcB1aXq2g2U +mSUsVwLubgkc9sb+JOqmTTKHHCkilgGQNf9DkrSIbL8cpcRMre1CyZd1crKiz3r1meS35jgkoxP wlU1blLlskcrpbsPh2/pbx7Xi3sLKuXrYyC/301ouZGyibtk17bi5If0vclSC2t3Mu+e1vpSInNJ vuUQo+ewne1TLHeZzMn9ONhuTyKFubibsxdUYj5gRWf2WG8O7K+URdE2o9BFOaYfzt6nandWI80k SXzoVQddLOetl0/HayFPCTgH2/zEvccX37gU7MpFKRAAARAAARAAgYgEer38wElDRkU82HrYy5sf GDVq1M6d4dbCa1jQeEfnJce+8nCiZB+tpHdJSa9kspQSSTGvqNGzmEEqlepKp5gtKtHZ1dW554Wj zy88g1QsACEEBEAABEDAhYCnUQDE8k/AarbI//kdZ2QmEikje740cnJQGvhiVYmd5YkLnK+d8uiq HGt9IAwEQAAEQAAEQGCvJVAgBqnjt65NkDUq2Usr7a0lS1mCcwrPI5sU/V+SpGTnlOScrFQUuYcN BEAABEBg7yLAYp0eWcDDqehRPJaIpL0LYLy1VUTexXuScNJOm7ZckfMonJxQpbuLw9v3zXRfL0Vj cXyaT/hqqCqiMAiAAAiAAAiAAAjsFQRSFLMnltJjac1TVOeUlqacUWwn5ZOivWSi2itIoJIgAAIg AAI2AufU/2ySxhcjG7usfyZrOzjlmQA5In1nTLf4IvlWVOQ8ElbLnG/dyoFWQqisc4YxUngduzoa LEsl5pwETgACIAACIAACIAACPYEAeT/Rp4uW2DM2qlVizKy/0g76pNJdqa5OCtzr6tjz/JEFmEOq J7QB6gACIAACIAACIAACIAACIAACIAACIAAC+SFQICF7x7z8t5LS3omSXiUUnkc5pGgxPeeCemwl PmwgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgEAcBZmtKU7CeluJGpyRfZS8pJLPd2EAABEAABEAA BEAABEAABEAABEAABEAABEAgfgKJRIoljWJBe1w4rbLHQ/ZYzB4ttEdRex1myN4V116vUuDPixZ8 deKU+NWDRBAAARAAARAAARAAARAAARAAARAAARAAgTgIvLz5gZOGjIpDkkaiRo0atXPnzlDSGhY0 3tF5ybFb/5Ys6Z1gq+yVJJOlCdqSJeQnRVYp7h8lfmIDARAAARAAARAAARAAARAAARAAARAAARAA gbgIkGMUxesl0rTAHktwzpfUM0L2jHMwX6m4zgc5IAACIAACIAACIAACIAACIAACIAACIAACezcB MjTREntdtNAefWFheswmpRukBBnymdq7EaH2IAACIAACIAACKgIb6s+/YnF7j+dD1Zy1qcfXEhUE ARAAARAAARAAgbwSSFDuckohxXJIMfMT+z+ZEEF79H9KS6V4aqnCdZGiOeJp54nP7A0OdG2LJ9Gf MnPl9kVX6IX5IVcvavOkLQ4PULK98WpTDeNLfZOmqfazs7ppHra8rr3QM965srvMTbMN2pMagz2A qHTz3h+AeablrK3sxdCjtV31yXQAa+/y7nV5vYK76WQ57R4eeEN1dZWcsPs9nsNdBh/LIGMdlMJf PnlpXumSkYfEjLbm2MJKyuMMI8kGOk26UsQAKI8PCvl5qVtuThJxoJaVsRGLPnpL/S26EBsmJjPE CF/XOvXWCWW6DNtNNrCc3LRUdlKtHIZdObVlerb3WVW7m5cS17hpFl1EmSmEOYywjhfR9hdy8uMJ zuWKVowA1ivFb8bl21ph7zuO8gGvXBfI9skk1zWuaUPYepmnVkxupfuOx/1IqoLcqUJPexT3tXCT c9+2RwEQAAEQAIGeSoBnM0+UssRRySSF7FHsXjKV1NKGkxRfhY9XvjAtUnTjrNPmbHn8Mfo0jF5V Z5vutC+a2aBVVdlar7aBl2efuyeWq5uW7qZj14xYHqCkppVNutuQycovnValVQ2gCbpqP5vHuGke trw+c52pjRgTZx9ls2EXmTTtmN46bRmr6fI6bd44FwugVQuFHD7bdtU5DHPjVPZWVjJUE3LXh9rI 7ADL61rN3uXT6+JsiMKUldvuocar7DaumFRywu5XtYFSz7KJS4wRhg1K3F7DttCXT15anz2ujJ9X oY+iW27WFgpXF0nbLXNrV/g9h5dPaGQj6txaTRMDbOMk3UBBrWaRv74n+JhEGKjdWnO0gT0AYWVv 0PvbnFhvAYH7Hh9+p91su5NKN9lMTwgsM/aCYexrXicvm3hr3cAV031vfH4V8Gl3MprMWEFlZtUI QVVVrQvicUALOvnxrID7Fa0eAbQxc/XZUUPF/LFuLw79eIm/h73vuJb3vHJbp+rzvWVTtYYfW165 uUwm45o2hK0Xh+HUR3XfUe0XUB1yQk97FPe1SJPzYB0BpUAABEAABHokAe4gxX6k+eJ6SbbeHtvI OaorTaF8BWqNorZgcyBj0jZseK3WvHa95Laz4d75Wt0tUyoiNdqm2XUraxs8LVZKuZvumddcO8V8 Y2yWk/Z7a64fEaD8hvoZ2tzHlkwoj1RJ94NUMjesW1VVd4t4ziyfMHmMtsp7lqyUo9I5EnOfVla1 hVR1hZ7t69dsHTNZf9Bi9W2ev5A/Swdquxjbo8BE5bp7qPCG7eoqOWH3q/AH6Qb9BwzUWtvauIiw l09+mp0un2bp0Vcrm1jPBq72xoWZi12rvqlhtLZinWFZC6NZ2+KFK6qmLjdGaZI/qTrM8UVRNsBA 7VOP6qvoHUY0wt1KqL3xJ+wmaxgfu1WXvJy8fMIt06p8bnwhFHFr97bFP56nSZcMiRs5onLNRjGM dPuWzRU9bBa9q4tIL+x9J9D9Qrpyd2zbqlWU6xOpsvJKbWvLqxnYzmlGXNOGsPUSOnlPe+T7jtxh nPsdckJPe1T3tRxOzrv9GoACIAACIAAC8RJgKaP0JFGU1jwlvifJUUpLpNjPYt64dcPFKhSsTm07 WrXRw4cFK2wtxZ7l3I5V7VedI1D5YbMeq4/7AU8hs2nNSq2yv+72wGalmta8zStsT6Wban8U5j6t nA3D9pZmuWnKKqu0lh3BwhSjdJuiOSbX3UMFIhddPcfQ2eS+auRQ/pAT+vLJsW5CPNNqzHDdESNz xvaNq5szFzvtZ08yK9c5Y6L9lJQJ+JUt1r8HGmTCVc4ZLMnjbuzBkn4BUHIUlSWazyUYkyto7h83 3zL4Ke9R1E8GXlpjBOt5VpIpU99kRvFY487kQCojVJBVmXyRePCaGV+v5mCTLyJJyQGEBemz6myd N06Pps+cWhVC68Wh7MKRA5tzZx5y9zgbOrLC8rLNJM15Bg2uDNcJ3UtneUWXnVChyfSC6x/2vhPg fmG5cikes2rlDNE3yEhEZvTJ5szKbZqhkB962hC2XuI69ZzcqtrIsd9FTlj9I93Xspucx9GNIQME QAAEQKCQCHADFDNFUdYoCtMjExT/QiF76RL+6UUf8ppijlOFvtGLGq1qxIX63JhNNcbMvcnNorSq Tk8j5TWNo9dlVQM0MzNUiKwN7Flu4LQrXZ/x3PZz1wlJc4OzSo6qfD7aZ2BlPzbHJyxjt01eXjcw 3nOGZ+7Rylw1NcMAmteMJK+QhXqWMfbW2u0Rzb3tAkjviUXi7x5x4VXJCbtf1Wp2OfoD7XjydMjk 1tHi55NtL2pva9G1ckoS2upbef9ojqbs8ca0YmerbWEeH8tAzTw1jLsD2VDWDdeDylkoH79PlU2c YnFSo+fAgY5AOQsgFnrTUKHHpy+Tkh+5yudPuadN18zy9kh3V/ivbm/O3HPlEuZN1prbceWMBQOW itDO5kxIlDUEzBLiR3IWVrIg8aXTtPkzyVjgzWHlDD0QfhkzLjAbnIhXol+1gSLYnD5LhPOyXN+5 FfPGGfMBPw7lNSOqmrfviKU3yu3OBLaRx1nlXDPcNXOOYcMrVjdl/zok0OTHs2bZXtHMtB3zFnVc tV25rKvMqWwYT9ZP1osy3vF+0wxLdWKcNqjqpdbH/b5jGppt9yNXORH09+cfeHIec8+AOBAAARAA gaIhwBOYs41H7bGN9pSk06XpFH1K6EN7RIrzAt5YvDq96jcCrITTe+YFl6m5JZyeXpmqbFLt21u1 5oaF2s18CssSCowPmC+Wh8BMdoYwqPbbNDc1DVs+T43zKss4s3rkUjNSMr7zhmaubGVDJxXDgDqz +AKNcl6w9+oztckUU2PbVG0XUH4PLBZr94gLr0pO2P2q9nKRU32TePRdPnKtJWdKrHzi7T8W1xUy NMQrvedKy2qgXjlDT4rPcvMZZgi6SZkRjtXDzcxQLCbdcFLjYVPm2xdXuDz0xnwlI9tx3OWLIM2r QjkFM59W903OISW9Fho9RzcGSfXSNq1bQXnHzCpbBY7RrTPcs4Y75HpxMINPeX29HVp5qJFRXxY6 t5VbfAJyaN2ejXXItd2pbivnu772YEiqh1c23ON0UST/Gilfm+dlFnTyk9drNYT+HnpFGlftVy5z ppvRUkcG0zljqIEM90PfaYZNrzinDW718tJHdd9x26+SE0V/T/5BJ+d57Xc4GQiAAAiAQCEREOF6 cmweRe2R+Yk+wk5F3lOUSyqRprX4CnjbNHtsw9aquqVG8FrTQpc0q3b9h82iLLCWNAFSCTb9NfMl Od7KqlG0L1pAL65d3KMU++2aG5JVclTl89Q4W+dNX3vpMv0NM8u5EOcWlrlfK6sYhtA5kwB1yQTN 7uvRzW0Rohr5Khpr94gLr0pO2P0qiJ56ilRra/Q03rHyia1R9TGQPxnS0hBcbr8TqqxjIzM9VJ3Q P9JJe3Kga5YDtZnc2uIWJMevzaDIaH1jRhPRlyx5XhRtYgu94UGX+qaQr3WPL5tnpHbtSCNsivVP YbQKzMEzoly8/2DuMPwzXrYE5dynz73dNY32M1821/dkNZPrWo2RJNJ1KB3kOfnxF57NFR33tIG0 jTSuOq5ckU2PG0xr6skm1cw98jS/aYYLrbimDa71CqSP9b6TUVHa7yEnrP6e/CNNzv27IEqAAAiA AAj0MAJ6Dilyi0qQ9Ylt3BrFcpyntCR9ugrcO4rea02nV51L9VevVAH2xjWTMII8p/i80zHJY+Eq XpttOstXzfPZ2JzG7cW1+36n5ob4sOX99Irl7yyJkpZx/mITepfsM9mdKgRzv1ZWtUVEBflrfPPp iKUmsfW6iHJ7zGGxdo+48KrkhN2vaqVAeoqIhlj5xNVryoZe6ppLm+X0lR1MmAXEzPgrPY6yQcBz YGQBIDlMuBMXh6hycjFQb6hnkTX6al/0YJzRjWUvYkHEFGrk6v/rWQvTEKCW33058ozE/8HaIQgH 357JTkXTBj00Ug7ls/R8lUYVJ/hPB4LVxlaKLeTnvoIthQq2rNsYSajjIL/Jj/osWV7RLOWQkVYv lqpEHFcdV66tw3CxwSeTqqpEnzYo6uU37ZEUscRc2/cHlOOvvyf/yJPzWLoGhIAACIAACBQXAcP7 iWxTPKl5Ik3/JpMJ+o9ynpNxak8i0VGYVaIb3jha5UeyRpGehn+ymGvSO38+77TlZWDLAzXLeSut FeQZLhfq6/6yFIxy6lb9DbMjiI9nCDbCBiV5bvtdNdePCVs+P21TNmkyxYzoTHhOJclAwxNL0avm gIGNrhqHY+7Tyqq2iKQnyyoipSTzarv8tEUBniW+7hEFr1uzquSE3c9gh5EvNQ5PjitCq7z5dFeD Cq30VL6SEuSOMTCT5SeT6caa0Znv985pzS7q5vljRYZpBnJRo+4v1l1VjvG8OR+oWf+R9OVrfa5d eO9aTc+U71EXngtmOiUF5xu/hTlddyX5crbpplnBkprzbEruybaDU+ZChDdK0M2fg21xVb5omjUH E+/JLkFw/hzamtY2O7wFRcRrNrc/s/K0PFnD6FV1zoz1ZD5uXbvaCil4UnDpOJfJT3D9s7iiaRRl ycKltHqUPjzLpOzRxlXnlcvb3ewPrP9wh8FAk0lFv81q2qCoVzB9pPuORbfM/iByAumv5h99ch50 HEA5EAABEACBHkWAm52SZIMig1SK/uGVS7NE5txTisf0FWbIHnvNRWu9ZRzvz9fX1lG1T2ZVnfHz KuS8lY4DKOECS3TK/fnlBB/qlrevzGKUdN3voXmo8sY6Suy5ZcV0pm2I/OuKuihlVt+0nL28ZWfh 6XJdc8ZnhKrkKOWHZ65qDVVbuJZX6mP2Fp7r11zNMHSv61GjhZbr7qHCG7arq+SE3a/sY4rBR17a zJIcN+Tlk6deQ08mPEeeiF0if1Kx8adiw89UGgDZ/go9sZo8MOq1nr5K00TiZMMjlS5qnmFaj436 iXZh3KuC5gmU4zShBurgSuoP/Lw5FgyYKnlIkQwyM21dsbJCXj1WdV1QjBuza4iQNKkFVfKl3DGU R1z2zFLrzjzsts6717A2ZgrKSc391oDjPcTsgcHWjHPhwE6eyc1EI7Z8e6qpZ2nU9U4ubpHUk5fX tRornGR6rB8H9yXMRETkinVOFMFbPlOShdSRGdduk6KH/4rmyNndPCc/IfRXXNHKEcCYmbC4SO9J lyeqsPcdj/uF65VrvV7o/ZPP+sVxTRvC1ksFSXXfUd6PfCfJAac9ivvaXj5NinLZ4xgQAAEQ2MsJ mAmiyOpUQran2h89qKVT7JPqSKU7Ozp2048Xjz7/utKHrrj2ehWsPy9a8NWJU/ZylKg+CIAACPQY Auwt9/YpfqbnHlPdwq8IeZQwK6ciBXg36M/cKKSM7PnSwMmBrSq4bXKuybCzrBmxPLMEm1HhKH6d +YIV5DzFrn+QOqIMCIAACIAACICATODlzQ+cNGRULExI1KhRo3bu3BlKWsOCxjs6Lzm2ZV2ypHey pFeipDSZKE0kyVmK/ucZzen/FHlMMakswVQo6SgMAiAAAiBQ7ARYrNOqBdyjhB7FY4lIKnYk3am/ IvKuO1XS/SOM2MD8qNJdHNoXzVSsl8Li+DSf8NX8sIl2lmLXP1qtcRQIgAAIgAAIgEAhEGDJy5m5 Kc0SR3WxkD22yh79yhbYS6XJLEW/ktuUiOPDBgIgAAIgsNcQqKk3wqkoSjeT1H+vqX+hVFTEW3WH L5IvAZHzSFgtc751KweKQqqca0tGSTVumqXHsDv/lHMecZyg2PWPgwFkgAAIgAAIgAAIdCMBMj2x ZFHMJMU+XeQjdemsVSyFVIo+nelUV1dnZ1fnnq1Hn4WQvW5sJ5waBEAABEAABEAABEAABEAABEAA BEAABLIkUDAhe+u1kn1YvF5JiZYs1UqSaQrZ6+JOU/Q/+42ynCNeL8vWxuEgAAIgAAIgAAIgAAIg AAIgAAIgAAIgAAIZAmIVPZ40igfvsRi9JPeWEh5TlNucF8AGAiAAAiAAAiAAAiAAAiAAAiAAAiAA AiAAArEQSDEfqESaAvXIJ4pySGnJRNI0PzEDFTYQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQyAEB skkxs5T+MwcngEgQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQIAIUk6dviVRSSyXTqd4aeUvZNzhK obeAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAjESYBnjErrWaNSkkGKEpoLk1Va64rzhJAFAiAAAiAA AiDQEwhsqD//isXtPaEmnnWgas7a1ONriQqCAAiAAAiAAAiAQH4JGBanZEqjZObsZ5KnNs98tEQq vyqFOhvNEU87T3xmb3Ac2bZ4Ev3JNlcWO9nn6kVtnicLXLK98WpTDeNLfZOmqfazs6o0l/ZLmrcv ukKvpovmgfUMgVbItM+/N802aE9qDPYA4irHo9Xcz6tQPABDS6/w7i3Ok7iXt7SFtdeF5xOiSQqp aE67B1VU1Q0idHXrIOB1SXoAdtUno4x18Anbzbq7YSUm8pCY6czmOMBKymMCqykb6PT2MgYHGqPk 8UEhv7urncX5owzsttNJnYcN6dEtHdJwFF2ITTkmM8QIX9c69dYJZboM260qsJwsmiNnh1o5DLty asv0LFqKq6lqd/NS4qWaZtHtPjOFMO8yrONFtP153LZyxg+CQQAEQAAEQAAEQMCHQIJvVCiRLE0k S7RkSVeyxBmyV7AcaW5Xp83Z8vhj9GkYvarOZmBqXzSzQauqsqhP076xa0Ys54dsuXtiubpuwUtq Wtmku7lA/bN0WpVWNYAm6Kr9bFbqqjnb3zpVV2/ZVK3hx5Ldp7bBPIWkeRg9A7Ykmw3P1EaMsRWn B9TprdOWsWour9PmjXOxAFqPcJejbjXFeRVaezF06xU+vcVxFmX5solLjIZgvY4/kLMtNJ+AzVFo xXLbPcTDmEv34zbcgBdvBpl9EFBekmrKym5sKrO8rtUcfMJ2s25uXfaYOn5ehT6KbrlZWyhcXaTO vGVu7Qq/5/DyCY1s9Jtbq2limGqcpBsoiJ5F/vqe4GMSemB3b+XRBvYAhJX9RB+O5tiH6/x0LH59 TbvZdieVblWZnpAfhdzOEsa+5qVl2cRb6waumO574/OrqU+7k9VpxgoqM6tGCKqqal2QvQOa6rbl pyz+DgIgAAIgAAIgAAI5J0A2qZSW0hLpFPt00bJ79Jv4sF0UzJdzFSKegD0FGZO2YcNrtea16yW3 nQ33ztfqbplSIQnfNLtuZW2Dpx1KLx28pFP3TffMa66dYr4xNgtI+1Wa79i2VasoLxeHlJVXaltb XvWEk42eCsEb6mdocx9bMkHXwiy1Yd2qqrpbxHNm+YTJY7RV3rNklRxV3VXlVfVXyQm7P6x8uXz/ AQO11rY2vissn4idvrsPy3X3UHaDSF3dZRCQAaouVamMQp/29Wu2jpmsP4ezy6F5/kJuavEelLq7 9eznJz7N0qOvVjaxng1c7Y0LMxe7Vn1Tw2htxTrD8BqmDm2LF66omrrcGKVJ/qTqMMcXRdkAA7tP PaqvoncY0Qh3K6H2xp+wm6xhfOxWXfJy8vIJt0yr8rnxhVDErd3bFv94niZdMiRu5IjKNRvFXSaW Tb5txSIQQkAABEAABEAABEAgKwI8Po/lkGIfyiFFMXsUvZdIdZE9iqxSaZc051mdLz8H88dXm1Wo bUerNnr4sAAKBC/pEMae5dzOotpvEUBBAVUrZwiffHoSpme5yZ7Pb1noqaQwbNZj9S4nbVqzUqvs r7s9sOdMTWve5hW2p5AT9rwBWqvbijCrRNXIoeVMgdB8uk3r7E6c6+6h6jZRurrbICDVPtgl6X45 tLc0yxzLKqu0lh3Boliz4x/r0azTjhmuO2JkJLdvXN2cudhpP3uCXbnOGRPtp4x8gfiVLda/B+pF 4SrnDJbk8Vb2YMngIee2kECXYEyuoLl/3HxL71Zpz/rJwEtrjGA9z0qyULX6JjOa1Rp3JodAGqGC rMrki8SD18z4ejUHm3wRSaqJODVWna3zxunR9JlTqyKsvTiUXThyYHOs5iELNnePs6EjKywv28xD OM+gwZXGUXvDVRnugkNpEAABEAABEACB7iaQTpdoFLmXoJ+9EsweRYYpTUuyYD76JcEMVuZyfN2t q/L85J+iVY24UJ8bs4eEMXNvstmeyP+oaoBm5nvyyMUQvKRdIT5Hn3al6zOe237uWZPRnPnVz6ls GE9TcBbTZ3HmWlWnp5HKTECj6xmlIQdW9mNzfAI4dtvk5XUDo8iwHmNttejyVHLC7ldpYJejP7GM p1fZmeQpWvx8ohPphiNzW/3wXd19EMiAUV2qgdDVjCSnoYV6Ejrm1OD2BB9X9w6kUYRC7W0teqd1 HixaU9/K+8uOpsHPxMx2phU7+GHFVFLdi0K0PvOxMu4OZENZN1yP/mahfHy0L5s4xeKkRpbEgY5A OQs2MtCMbajQo7yXScmPXOXToSxIUzPLWyPdFQ3y6vbmzD1XLmPeqqy5HVfOWDBgqQjtbM5Eo1uD Oi0hfiRnYSULEl86TZs/k97TeHNYOUMPhF/G3usw+52IU6NftYEi2Jw+S4TzslzfuRXzxhl3VT8O 5TUjqpq374ilj8rtzgS2kcdZ5Vwz3DVzjmHDK1Y3ZW3vdr9txVITCAEBEAABEAABEACBaAR4Ailz I9MTfZLpZDrNv/IEUzzFlLVctHPl8iiWt4Ve9RsRNMLp3eFb1L69VWtuWKjdzCemLEPTeEUW2OAl 7bXiITCTnSEMqv02zfkb3RktdTRrnzNm5YxM2nVLAgh62Stmz9H1jNgar7KMM6tHLjUjJSPK4YfZ 6x5VlkpO2P2q87vIqb5JPNssH7l2rJzQOlY+UXl033E5rH7orq4YBDJwVJdkQHzDZrGH5LHcRjxT m0whV7Ytru4dUJ8si1lcV8jQkKW4vebwoAO7KxAa4cU7BpabzzBD0FBvRjhWDzczQ7GYdMNJjQdC mm9fXEXzkFLzlYxsx3GXL4I0rwriPmyejzktum9yDinptdDoOboxSKqXtmndCso7ZlbZKnCMbp0p O6FCd8j14mAGn/L6enss8ghro74sdG4rt/gE5NC6PRvrkGu7U8VXzne1azMk1cMrG+5xuiiSP6mU r83vqlPdtvyOw99BAARAAARAAARAIIcEyOLEzU7c8sQNT0lmlRK/8j0Fb42iV51jG7ZW1S01As2a FrqkWSWGbFJrZkFyvGuVIQcvaW2a9kUL6MW1i3uUYr9dc02kdOGz9pp6skk189fC1m3YLMpfK3JL RdUzYofaOm/62kuX6W+YWbqrbDZH3SMKU8kJu191ek89RS6tNXqe5lj5RMTRjYfltPphu7pqEDD4 qC7VEPwyma2XTNDsrkBxde8Q+kQrqmep40+2tDQEF9LvhCpr9jpmeqg6oX+kMxRhJGPgeqp6UcDW N5NbW9yC5Pi1GRQZrW/MaCKGGkv+MoWutpBSHnSpbwr5Wvf4snmG4taONILHWf8URqvAHDwjyoWB m3ki88942RKUc58+93bXNNrPfNlcQ/BqJte1GjeawP1TUdB628pWGo4HARAAARAAARAAgWwJUGwe OUOR7YmSRZH1Kcli9DJbwWY0N2bXi66YTq86l+qvXmkve+OaSRhBnlN83qlP8myTVL4WnvsWvKR5 PDMnub24dt9PzlA2zbnHk6QSS0zjsrFAm8wWQc9IPYYrk3H+Yqq6ZJ8JKNql7gGPtBZTyQm7X3Xy QHqK4KZY+USC0a0H5aP6Ibq65yBAoFSXakSG3MvDfHhmfo72Szui4NweVjb0Utdc2mw5BdnBhFlA zMUWJAOTbbxyKssCG3OYcCe3dPylBx7Y/UVlbiL1LBBYX2iV3klkDmXZi1iUKAUJuvj/+pzCfH+w QSm/+5KgGetCBMMUhINvz2SnommDtDauEcpn6fkqjSpOCJQ4K1iF5FJsIT/3FWwpVLBl3cbwElVH WGJy4xMLSSAAAiAAAiAAAiAQlgAP2iN7FKWJEtF5ZJBiy+6xNOe0xB6zTlktVGFPkMvy9OA3jlb5 kaxRdDbDL13MNemdP593soAInjJ8IQ92Yykk6lYqE7J6ltTfMDvC/XiGYCNsUKq2235XzbnHU7Pp mc8STDjfWrOFjZqNZOfBa5R1M5RNmkwxIzo9njRHegLniaXoVbMiBNJ6cve6eyvoJl8lJ+x+duYw 8iVNeeJ5ETvjzSdr/IUuIL7uoahpuEtSPQhw8apLNUw3NvVkSWekjHVRund3ta5oNX0VBUkJcscY mMnyk8l0Y83ozPd757RmrdY8f6zIMM2us0WNujthd1U5xvMGH9gjnpQNL9KhfDHHtQvvXavpCyl4 iOU5zqZTUvDMzc7puivJ57cePVd306xgSc15NiX3ZNvBK8yFuDgCe0jw52BbPZOvV2vNwcR7sksQ nD+Htqa1zQ5vQRHxGuj254eGlulsGL2qzpmxnszHrWtXWw+PlNRcrJfiHfLppyX+DgIgAAIgAAIg AALxECAjFA/PE5F69GEGKTJFJXm8Hm2Gf1RhJjVnL6hprbeM4/35+to6KjqUPoOlL3Wk7XCWD17S OFa1KJ7rfpXmFJjAJqN6YhF6yjUWvMusBzR+XoWU7Dy8nr49hy1XxBRgz0IrpjNWevb36puWs5e3 bA9Pl2vPGW+TrJKjqrvyvAqNVXLC7lcB8dOTcbAkng/Jx7chCrNArruHUn58XT3I+pUmfKU+5iXJ U0GbC1OGHpS6t5nJcsez6YnYJfInFRt/Kjb8TKUMR2x/hZ45S858pFOavkrTxPBlhB1Rq/EM03ps 1E+0Cz2XDe1eGKHOHmpgDy5ZN+Hx5lgwYKrkIUUyyMy0dcXKCnn1WFX/tN5KMjmqVPKlnGiUR1z2 zFLrzjzsts6717A2ZgrKSc391oDjPcTsgcHWjHPhwE6eyc1El6R8e6qpZ2nU9U4ubmfUk5fXtRrr hGR6rB8H9yXqRETkinVOFMFbPlOSReWTGddukyLzcUVz1OxuRj9x3LaiKIhjQAAEQAAEQAAEQCA+ AixFFEtkrpUYZqjEpbNW0Tp7aa0rnepKdXWmO9JdnbteOvrs60ofuuLa61Wn/vOiBV+dOCU+xSAJ BEAABECgOwkwb6/tU/xMz92p4V52bvKIYUZwRQrwboDB3AOljOz50sDJga0quG1yrsmws6wZsdyy +i2vczH5RearkXAeEAABEAABEACBQibw8uYHThoyKhYNSdSoUaN27twZSlrDgsY7Oi85tm1DSUnv kpJe9EmUlLJl9ZIlzDuKHKOYSUr4SbFYvsL0kApVZRQGARAAARAIQYDFOq1awD1K6FE8loikEGdH URsBHmbusmhGN4LS3UKN2MD8aNJdHNoXzXRfL0VjcXyaT/hqftjgLCAAAiAAAiAAAiBQTAREcigz bTkzQ7HYPX1Lkk2KEklpiVSa5ZTCBgIgAAIgsDcRqKk3wqkoSjeTtX1vQlAQdRXxod3hi+RbfZHz SFgtc751KweKxq2cy5JRWremWXoMu/NPOeeBE4AACIAACIAACIBATyDAvZ/IDKVbohKX/ogSgaTT qVQ61cmi9lJ7ujp2v3TUeQjZ6wmtjTqAAAiAAAiAAAiAAAiAAAiAAAiAAAjsrQQKJGTv+LaNydLe JcleyZLeFLKXouTmSUpqnvGZ2lvbB/UGARAAARAAARAAARAAARAAARAAARAAARDIGQFKZy5F6dF3 ttYezyGVMD7pRJp+wQYCIAACIAACIAACIAACIAACIAACIAACIAACMRDIROqluM2JftAuyhjFPuQw RVYpLZ0kx6kYzgURIAACIAACIAACIAACIAACIAACIAACIAACIGAQENYosTHbEy23Rwvu8V+5SYqv uIcNBEAABEAABEAABEAABEAABEAABEAABEAABLInIFbWMzfhIUUWKPrCPrTGnviBDQRAAARAAARA AARAAARAAARAAARAAARAAARiIUChecwgRT5QhhuUHqAnfueGKZvRKpbzQggIgAAIgAAIgECxE9hQ f/4Vi9uLvRa++lM1Z23yLYUCIAACIAACIAACIAACgQkwaxMlimJeUewf8o1iP8knSnhEpXisHove Cywx7wVpjnjaeeIze4N59vZFV+g7+Z+uXtQm/mTZL5VXqN22eJIu3JTgXrK98WpTDeNLfROdL6b9 7KwZZeSacn3En+KdK7vL3DTboD2pMdgDiKsc91YLXxeVnLD7Vd02QO+y9qLwfPJ+xcRzwpx2D48u HfiSzFRTHGI8MKsuSR8srvVVXZIe3Tse+jFLkZjIA12mM5tjCyspjzOspmygk0cnMQDK44NCfsy1 yKc4r14UsPWlzsOIRR+9pZtadCE2eExmiBG+rnXqrRPKdBm2m29gOflsv6DnsnIYduXUlulZtJR0 gzNuoxlp5qXESzXNoosoM4Uw7zKs42Vp+7OOh0FJoBwIgAAIgAAIgAAI5ISASBQlDFDcJsUsVGSQ 4iF6aVpsjyWQ0lIFm0CKplZ12pwtjz9Gn4bRq+osZqPaBr6ffe6eWC74lU1cYuxk5fmjlGqjCeLY NSOW2yS4ly6bdLdxLlZ+6bQqrWoATdDj2s+e90xllte1SjVlM9eZ2ogxcXYQhUx6QJ3eOm0Zq+ny Om3eOF+LnrscdauFq4tKTtj9KnJKPVW9KDSfONssj7Jy2z3Ew5hrlw5zSRo82hfNbNCqqkw8qkvS g5+yG7tekp6DUh5bKeCp2CP3+HkV+ii65WZtoXB1kTrzlrm1K/yew8snNLKRdm6tpomBt3GSbqAg ehb563uCj4myF4Vr/dEG9gCEle2pD0dzYr0FBOw97B0PXV/TbjbusPpx0s030xMCy4y9YBj7mtfJ yybeWjdwxXTfG59fBXzanaxOM1ZQmVk1QlBVVeuCuBzQ7OOhn6r4OwiAAAiAAAiAAAjklECSZ4dK UkyecJES3lJmCnMySHEbVcFu7CnImLQNG16rNa9dH8xth2rUf8BArbWtTVW3TbPrVtY2mJasUAg2 3TOvuXaK+cbYPDb6/vb1a7aOmaxP+ssnTB7TPH8hf67bUD9Dm/vYkgnloRT0LqySuWHdqqq6W8Rz JtNBW+U9S1bJUbVa2Lqo5ITdr6IRpHfJvSgsnxibLJ+ict09lN0g0iW54d75Wt0tUyoUhFSXpFRc oY/ykgzSbfLZXj4X+73zm6VHXzLZ17OBq71xYeZi16pvahitrVjnZb5XnaVt8cIVVVOXG6M0yZ9U XTi1j0kTqRdFbP3qq+gdRjTCMdUhmpj2xp+w68swPkYTUkxHlU+4ZVqVz40vRH3c2r1t8Y/nadIl Q+JGjqhcs1E5VwlxPs1nPAwjCmVBAARAAARAAARAICYC3D+KrE5sLT3uEEVWqjQ5RQlDFPtDj1xj jz1PVo0cWq6g2LajVRs9fFgUxuxZzu3YbPa3tzTLqpRVVmktO5jtbdisx+rjfsBTyGxas1Kr7K+7 PbDnTE1r3uZl/wurW9jyURon5mPkXhSaT8y65EtcrruHqhtEuSS5DcvFNKyzUl2SFpQKfZSXZL7a IZbzsE47ZrjuiJGR2L5xdXPmYqf9zPC6cl0mJjroyX2G2aBiCrpcoF70/9n7/+A6jivPF8y69wKk LHfLPR53j3tGIEhgjHcds+FZ/+G1TIYoxhJjLX8Eox1hUsHgynQEdrtpxsLmcDGPjiXtkIQIK4LB Rw/eo9kRiw1BenwakX7hXgxhPrrJGYoa0PJ4etyP26+NBw9BQlB02z3dbpu2RRLA/bHnZP24Wfdm VlXWrfsD0Ldcosm6WSczP/mjsk6dc9KuBo3OktIPrt5ZMsaRPORHGfLm0zhjygIG1/efCz1wTKXn fjL07DbfWS+ykuwpNj4b+DOG/c5UF0jfVZCrTLZI0nkt8Ls3c6iT73qSek76XJ35s/s9b/pa1iYP 6ygOfc8MD81lpB7SANNbnD09PKD/2CZ5JnWupPaNnA/tOilSgwAIgAAIgAAIgEAGBFgD5VTLDjvl sW+ew6drNsWH67vHcc272k7KLSzZp4jizmdqa+Mro14YqfByzVtrHqCPkLWwFw0s37k7X9wigghQ FlEb5Br92PPad7zU17cNk4XCpBcJi7+gJnpdyKCHhEUMDT7Ja3zCsu/uyPToUPMZNLRaSpEmObbX TdnXy9H3ouz5pMTRmdtaW337Icmagr1nThnVyqahmoheoiGZVfdOVKIUiZYW7wi31RqP0PX+TSYb s+hcWW0XaLFTFHAN3GLuRRatzzZW/tOBdC43dnjO5uzKJ59ffYeOhIzUSJM41OAoF6LFXt4TA57f +iUl+JFWPt3KTpoiSF9zco1og3fvzYWeuUHS4OEbju04M3Z+y0XXtXNu4mt+FMKwU2fIxY/kTA6y k/jFY+LcCXJbi+YwM+a58F86WpwZYx2c689I/xRDrrM5nW+4xstqfc8MnN3vrxPiOPRv21mcu/dO Jl1TbXcWuEgWZ4NnAnfXWh7bdwxcnU1s/q0vW9x8mEmNIAQEQAAEQAAEQAAErAiQrok0UKSTkpop vpX+dINJOaydyvGffK1ro0h51eXIHfSp33dqC8eKok+jik5q6yl3VTo9fH1fQ3Rwn97SvQUxNzEp XpBL2EtHxcSBhPFiySR+bs9IowtDk9e3n+QV+T6pYjshRsi/ozPHuxxx5urwxcBTspli1LdaWlkm ObbXTflr5Jh6UaZ80vLo3H0trL71kHQ9X0bM9oOmIZkQX+yQzKp7JyxPk8lCpiukaGhS3PvmdlMv StT6M2NecGuOzeerIUiHEng4bt0RRIZin3TfSE06QqpfXxpxS5fSQBur6nH08l0nzS9YGQWz0aL+ UGNIKRrhPac9ZZBSL3HrxmWKOxZUOSxwr6ed6ds84BnkRnEInE9lfV0jYtMhPaz9+rLr3LzU+CTk sHCvGe2Qtt2poDPnjJ+atu4YnHi10USR7DeVeG1Roy52PnzfDFlUFARAAARAAARAoJsIlCtsFkU6 qIpUSrFzXoUUUmwiVaVo5zlRptNxSqSe6qZi15fl1kv7JuaLoxe1zmvbT1K01/k779bf5EZBuqaP sMvL3yBeUsNXWTOLpQvn6cO1xjyq+eu1MLpvHBQdsjuYP3v8+rOXvC/MZLHSVKeIbDULySY5ttdN WUaWM9yLMuVjgaBLkra0+rZDcnZSE2tZAWUaqhYsI4dkVt3bojzpknpzo3yzpa0hpJAnNxfDcyar HoqbN6XKIVovkEpk19xk6kUJWz8Ibh0yC1L918bIM9o7WGniPrBC8csMLOpcSqXTpXcY5IvO2LJF uuLuGvYVytw/XaVVYg6RHuWugvuAv9vdAVUT1HKbPn27C0HX2ZZN64K3bWR0wbBcSTIc4ubDJDKQ BgRAAARAAARAAAQyJ0D6poqrf2JTKIec9fIcQ4qCnHvue6ywKueqlS5WSJEDwnH61HnR+/TayIjd UkyHyV2F09ctZ+WueTEHfy3XfbjO6rqXvfykHKzU4wqV1e8cuErUjL94Qa+JPpMwt9hWa1KOSb5t vonSu70oUz4Jq99FydpRfYshyWOkFjWGzCfly2ftTc80JFMSrRuSibpNyqyyvK3v6We1sbT7+geF amDCGhAx0N8v81YUTDwJRE6M7NjYwoA7WbJII0vfi5pr/Zvj7E7u7e76A3XvPI5exI7b5CQYafqn rUnw/cAsP8akKA2ghPdE7C6ikZCEQ2zPZLm0bPBcI1VXvlAPN1VgYHP8ciBh5cPJeCM//Q625Cp4 58ZbqYSSf2LMfJhSLG4DARAAARAAARAAgSYJuG56cns9qZOSR64iqiVRLXNo86oMcO6UuzWGFC39 99MuP2ZtFFngf52URBrPHdo8K8LrYfvzFIRi0gtywaFA1dCt3hfmBic+GSE4cBustU1W16VEjnAR GRmnyT5hvL3v8Aj5jHhMZBwrVSlmYqITF99qjXfp5Jvk2F7n3GzkK6VTelE0n1a1StfIza57GKpk NyR9n0r3hZMMf+TLZxCcxTQkbbpxUM66IZmme3eqGd1WG2uIkUfmGEO1KD+1SDfhiM7yenRMa261 uXP73AjTPM4uTOmNUjtFoJl8db0o09bn6UUpoNxf9frka9eFeTsOP7mMcXacgoJ7Tw16hDWa7iry pU+cF6t79mSyoOYympLFzrZa1lKIjA+V+IjnULd7JitYXY+84JA9WeMEF89hcfb6XIO1oOvxmtCv P7qitFHjxJ4ro40R60l9vHD9avjmpEHNY+bDxOiREARAAARAAARAAASyJUD2UHmyj5KnDB3FIaNy HDyKIkdV6BB00sExprrx4A/UZMpUM7x/yttbp7Z7zoGzA6dvv3KoXxafN+LxIp0/xdFP/euaulGg DQ50KvflUQN8mDFI3YRJ89X09aBGMu5s4Jzo14jfWy4f59JaxF831MUoc+upaf54y7nIcLnmcNEh 2vVlM7WabV1Mcmyvm5o0rpzMIdSLLPl044hKUKZWdw+jfPshaWxZw1DVpjeWxzAkjZNSArYdSEJv qjJGnjsxkimZe8i3Yt/ETJkA+fqAF8xOnRg9SsevCOEGtPaN0ajVZIRpb+L9ungm611BOwBNZqmd 8JtvfU+FJ5vj/JajQQwpmSepmeYvzwyoG0ea+if5uLFew33eKS1okq/ERKM44qpllhkwW9jNn33N 1zbWEqpBzeP2gJM9JOiByfaM03DgzGuxmegpqT6eto1zGHWvk7uPSOrJ06ML/s4ntR4bx0G/caTr EXn5RiOKNN2T4wyQGrdeJ0Xq44E5RHdLQxT3gAAIgAAIgAAIdCsB0kaRLiqIaM7mUaSW+r/8vy6T bVSlzP9Vyqvl6kqltPJffvczXyp877k//LKpLt+5cP5zh450a01RLhAAARAAATsCbO9z70ic6tlO JlI3QYAsYlgJbggB3oTgtLeyeaASkT2tGNv7GjnwroJ3R1pNhnO5tnO68VNWppZxtjSQHgRAAARA AARAAASsCfzk+9/92Gd2W9+mu4FE7d69+/79+1bSJs5Pfav02X/87qwo9ObyPblcPuf05PKFnMiR dRTFkcp5/nv0S5XUVHwRBwiAAAiAwPuHAPs6XTkvLUroVTwTj6T3D7zsayqdxzWbZmSfU2KJnlmo 7xuY+L6mEnaKw9KFE4atEtiPT8S4rzZVZdwMAiAAAiAAAiAAAuuSABlByTBRtLeeDG0uD4ohlXND nHunDDC1LuuPSoEACIAACBgJbBv33anIS7ftGymgYXwCrn9oJ2yRYtvAjXnkai1bfnSUA/ljDp4J 4tAFdZ096fmwN/7Uch7IAARAAARAAARAAATWPAEyfeJN9aqeCVSVtE///Xf+M4cyJ5+9cqlE58rq yuryub8ZgMvemm9tVAAEQAAEQAAEQAAEQAAEQAAEQAAEQOB9TKBLXPY+uvQf8uSyl+vJFzaIXMHJ 5Rzy3dv7yd/d88nf3fV//L3P/vPf++wnfm/4Ex/5P/+zf/g+bixUHQRAAARAAARAAARAAARAAARA AARAAARAIDMCeRkoivzxyEaKDncvPYSLyowvBIEACIAACIAACIAACIAACIAACIAACIAACNQRcMhD j9RRFLTcPyqB8x5ggQAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgEALCJBNFCmkPDspll+FhVQLMEMk CIAACIAACIAACIAACIAACIAACIAACICAS4B89DigOf+F1VJyrz0opNA7QAAEQAAEQAAEQAAEQAAE QAAEQAAEQAAEWkaANFBlUa3S6VTLjqg4/E/EkGoZbwgGARAAARAAgXVF4Ob4U8+9vrSuqqSrDFXz 5K11X0tUEARAAARAAARAAATaSIAiRpGRVJnUUjn+C/2znFtjFlK0RvzEp93zpZsBuqULz3kX5U9f vLDo/mS6bmC++PphT3ggQZ9yaeqLQTH8v4zPUn6G6yxFKblmNe9mra7ya4VRayrLk7icFn3LlVm/ /r71kk/78FSyFxCtHH2rKXVJuO43ybG9buKSoHcpvY6k2POxaJJuStrS7hF06cZukKKrh4dS1JCM AKytr2lIRnTvbmrD2nRZm6bUia7WmYN5gOmpjcI15YlOmYK8iVedHxTmMRNpV+Lxa2fqjcp1i96l dB5+ZCSc8TSAlIdaeiF1clmmxQw/unD05YN9noy6h2xiOd3Y9mEO258/eud4Ey1V97CWIyVosmAo yVSzJ+nX2hIieMpwB0up+7Nc/HRjc6BMIAACIAACIAAC65GAQ3HNc1XhlISokErKEbncGrKQojX9 qDh9+wdv0zmx58po6G1n14S8zucrh/prjWe6Xt+8tEDcd23ntEZCY0foO/yKnxenv3isKIpbaIFu us7vb7SI94RfOiomvhbS7yxdODEhisVaRpQ+KMz06IJaU5tyJuzCvBo+IXburUtOL6jHF45d4ppO j4qz+8O6GI1svRxzqxnyNZTaJMf2ugmKsZx9h97wuxb3OvlCzoc1n4TN0W3JWts93JcxTfeTOtzE Q9KHVj+UjEPSTNnYjbVDMnJS6ramdHX0B84OeLPo7RfEpGvqonTm22d2XY57D+8/OMUz7ZldQrgT 7NRhT0FB9ELy31xjNiam3qi9btm79vjYExA2dh1vOjpdP123p6/J8XXsBfUJSxkrD9laT2hPgXS5 2OjXokrZd+jl0aHLx2MffHE1jWl30jqNXaY0J7e5gorFhfPZGKAlXfzEVQC/gwAIgAAIgAAIgEB2 BDiquYwjxRGkOML5WrKQ4rcgf9G2fccuMXf9zWRmO/H8br00OrNrIqTJir/JS3Hr1bNzu44EX4yD +5Tr79ydFwP9/e5Pff2DYv7OuzX5N187J0ZfPDIQXFl689r83hFv0d9/cGTv3LlJ972umXIaKnRz fEycefuNg17pglQ3b1wpjr7ovmdyGcSV6FWySY6p1UzpTdxNcmyv28pX02/aMiQWFhflJVs+iftT dyVsdfcwdoNUXb1hKIVhmoaqkspQHuOQbOGk1IKOQHzmlFdf0XdonCeupanJ2mAXW09N7BGXb/iK V5tiLL4+ebl4dNqfpUn+4a0293c6rbG3GybJUHkT9C4v/dYv0DeMdIQ7Smhp6uv8qPKVjx0tS1sy 7z/44rFizIPPoiC6dl98/WtnhTJkSNzwzsFrb7lPGRwgAAIgAAIgAAIgsK4I5GlPPXnmg532Kogh xU28+M6C2LNje5rW5nc53b2h62T8X5wZc23v6Z2H3tlGgvc0+eId1mct3ZlTi9I3WBR33uF7myin sW7bT749rnlpnL02IwY3eWYP/J4pxNzdKP2fQY5tvmnaoF33sFaiOPx0P+dnzaddhcw4n1Z3D1O3 SdPVNUNJpWEaqiFihvIYh2TGuFsrjjvt3h2eIUYtq6W3rs7VBjtdZ8XrzI2aT3TSUqkDJOk9XZXO 1BsTTG6Jepe+so3OktLfqt5ZMs7/UfUKDHnzaZwxZUGC6/vPhR44pibhfjL07DbfWS+y5bgw47OB N2vY70x1dfRdBbnKZIskndcCv3szhzr5riep56TP1Zk/u9/zpq9lbfKwjuLQ98zw0Fzr1EN6i7On hwf0H9skz6TOlV01slAYEAABEAABEAABEGACbBtF1lE5h8KZ08GaKdJPrU02ZJ8iijufqa2Nr4xq oplQ3UzXQ9UmC6biFhGEVrGI2iDX6Mee177jKdfZz+L04MQBWmqz12HNFItfY/aeORXWhW0bJguF SS8SFn9B9V8X0pczTSsPDT7Ja3zCsu/uyPToUBoZ4XsaWi2lSJMc2+um7OvleG8sB+hTdi14isie T0ocnbmttdW37+raoaSgMQ3VRPSMQ1K9O6vunahEKRItLd7xOm3jzW5rekf/ppq5pk0+rLYLtNg2 N679tFa9i22p/KcD6Vxu7PCczdmVT6ob+g4dCRmpkSZxqMFRLgSNvbwnBjy/9UtK8COtfLqVnTRF kF7xFze3xbv35kLP3CBl8JANx3acGTu/5aLr2jlX81IPO3WGXPxIzuQgO4lfPCbOnaDvN9EcZsY8 F/5L/L2HdXCuPyP9Uwy5zuZ0vuEaL6v1PTNwdr+v1onj0L9tZ3Hu3juZ9FC13VngIlmcDZ4J3F1r eWzfMXB1tnnz70SLn0xqBiEgAAIgAAIgAAIgkIyAVEVJjz0+SCtFplJrUSHFcVvoU7/v1OYtQ73Y UvRp1F9rhqL/KNfraS3dWxBzE5PiBbmE5RhPBxLGi5UuMCONLgz11/lL79idUVqdn947MxaEXXfN 9WvWUn7Btp/kFfk+qWI7IUbIv0Me6cuZrH80pHqXI85cHb4YeEqmlCNvq2+1tLJMcmyvm/LXyNl6 yn23mR6+vk+NMZ8pn7Q8OndfC6tv3dVNQymgYxqqCfEZhmTt7qy6d8LyNJksZLpCioYmxb3vb0/U u2jmd7+acGw+Xw1BD6nAw3HrjiAyFPuk+0Zq0hFS/frSiFu6lAYfNlQ9jl6+66T5BSujYDZa1B9q DCnl48qe054ySKmXuHXjMsWcCqocFrjX0870bR7wDHKjOATOp7K+rhGx6ZAe1n592XVuXmp8EnJY uNeMdkjb7lTQmXPBp6b6Ym/dMTjxaqOJIlnqKfHaIkdd0sXP+37oAgAIgAAIgAAIgEA7CVDYKNZG SfMoVydFx9pTSN16ad/EfHH0os7RTGw/SdFeQxGa3GqarssfefkbxEtq+CprbqKlC+fpw7XGPKr+ uhu6Ra7Ot42TTmpOfv4Vs5OaALFudrVwuW8cFL7dQdpypuxk82ePX3/2kveFmcNgNXNEtpqFYJMc 2+umLCPL6cbSuubFac6UjwWCLkna0urbdvWIoSRxmYaqBUvtkPTvz6p7W5QnXVJvbpRvtrQ1hBTy 5OZieM5k1UNx86ZUOUTrBVKJ7PqbEvauILh1yCxI9V8bI89o72CliTvVhOKXGVjUuZRKp0vvMMgX nbFli3TF3TXsO49z/3SVVok5RHqUuwputlCW5wFVE9Rymz59uwtB19mWTeuCt21kdMF/0DTb/yMX P80Kx/0gAAIgAAIgAAIgkJ6Aq5NaYwopMjU6Tp86L3qfXhtrz24pusN03U9bt5yVu+bFHKxm0n24 brjOq2FFIMeE4oO/FddCXZDNl1wxNyxP5SflYKWeopxx9dD+LgtZM/7iKmiizyQUHdtqTcoxybfN N1F617kpUz4Jq99FydpRfYuuHjeUTEM1JdHwkOTINdGTUspssr6t7+lntbG0eZsF1cCENSDBJgyK gqluHmssHjs2tjDgTtY8spLXTO+6Oc6OwN4GrPStolYmjl7EjtvkDKizoo0ufPD9wCw/xqQoKzga Of6+EMmySMIhtmdyVrRs8FwjVVe+UM83lWhgc/xyIFlt6lLxRn76HWzJVfDOjbdSCW24KW7xk00u kAICIAACIAACIAACSQg4FM6cTaTYSkr+35py2aMXv/20y49ZG0UW+F8nJVGjE5zpusdMBh2f5OAd dHBoZDV0q/eFucGJT0YIDtwGa/Qbr0sHhMACnwNJyK/TviOYu0omawW5Yg5HlOAIF7UgU5HlTNL+ ydP0HR4hnxGPiYxjVVOKuYGl6FNzIsfG+FZrLJVOvkmO7XXOzUa+UjoZkN71nYnmk5zzGk2ZXfcw ALAbkjFDyTRUbbpxUM7wkGRtVMyk1D1N7Laat7uCUiwyxxiqRfmpRboJRyPMzB4AAP/0SURBVHSW 16NjWnOrzZ3b50aY5nF2YcozJ+weCJmXxNS7rDPi6UW5Se6ven3ytevC20ghQqCMcXacgoLXHmGN pruKfPlI8mJ1z55MFtRcRlNqdmdbKcQ1EE56xHOo299Q7mMbjsEke7LGCS6ew+Ls9bkGa0HX4zXR 4y+ulrRN58SeK6ONEetJfbxw/Wr49lRBzWMWP3EFxO8gAAIgAAIgAAIgkB2BapXCmsvTU0mR595a 2mWPP0TTXm81w/unvL11arvnHDg7oIQMN11vREoBFzjQaUOADzP8+s3y/JTa6+SAwItOL4AIKZi0 G9spmQUll3Fna86J9uWM7T7+3kz8LnT5OBPwYrpvPTXNH2/5igyXWxd5vV6wSY6p1Yz5GkpskmN7 3QQkrpzMIRSQ3pJPbEN0Z4JWdw+j/Oy6ummoaoEby2MYksZJqTubkzR3Mkae67tEVpnuId+KfWtN JcIRXx/wgtmpkY88Ssev+LtGKGH7ZIRpzzfq6+IZzQ6e3YmGS2Vq/YjJyqp3NdbcU+HJ5ji/5ahi IUVpSc00f3lmQN2D1VSS8COmFqPKJF+JiUZxxFXLLHPrsIXd/NnXfG1jLaEa1DxuDzga10oPTLZn nIYDZ16LzURPSfXxtG2cw6h7ndx9nFFPnh5d8Hc+qe1VF8dBv3Gk6xF5+UYjijR9m13qSI1br5Mi 9fHAXOrobskXP2mKjHtAAARAAARAAARAIBUB1keJKsU1LzvVMv8p6O/O4uK71WqlXK6U5LGysvzo 0aPP/bsnvlT43nN/+GVTRt+5cP5zh46kKgZuAgEQAAEQ6DoCbO1170ic6rnrir1+C0QWMawEN4QA 70C92TxQicjerhI0cuBdBe+OtJoM53Jt53RtV1y/wmvJLrJdjYR8QAAEQAAEQAAEupnAT77/3Y99 ZncmJSRRu3fvvn//vpW0ifNT3yp99qPvft8p9FYLvZWeQj5XyItcQeTWWAwpq2ojMQiAAAiAQEIC 7Ot05by0KKFX8Uw8khLmjGQaAtJ5XLNpRgdheWahvm9ge0rSKQ5LF04Ydh1hPz4R477aHjbIBQRA AARAAARAAATWIgG2lMrJkw4opNZiE6LMIAACIJA1gW3jvjsVeekGGylknQvkxRFw/a06YYsUVzLX u9PTWsYmbjZBRzmQN+7gmXBIR67P7EnPh73xp2ari/tBAARAAARAAARAYJ0TqFDIKC+EFOuiyF+P /g8ue+u81VE9EAABEAABEAABEAABEAABEAABEACB9yeBLnHZ+8hf3coVenP5nlyux8kXhJN3cnDZ e392SdQaBEAABEAABEAABEAABEAABEAABEAABNpFwNtmjwyj2EaKDKbgstcu9MgHBEAABEAABEAA BEAABEAABEAABEAABN6HBEj9VM6JKp2ki3IYgFOlf+EAARAAARAAARAAARAAARAAARAAARAAARAA gdYQyJdFj4xl7ggnJzVSVceBQqo1sCEVBEAABEAABEAABEAABEAABEAABEAABEBAbqiXqzh5UkjJ /fXIQIr+g0IKXQMEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQKBlBBzH9dSTGil23ctXApe9hX87MXH2 f/iffviLB+/c+p//Py0rAgSDAAiAAAiAAAisUQI3x5967vWlNVr45MWmap68lTw5UoIACIAACIAA CIAACMQRqFY5ehS565HLHumm8qJaYLWUelQW37w4M/fLcpyoTv1Oa8RPfNo9X7oZLsTi64e9n754 YTH46dZLfvrDU3FLaL0ETVWXpr4YFMP/y/isEKbrLKImXC350oXnvOpIOUrJ9emFUAhk+VbgZle/ /rah53LSyolttYTrfpMc2+um3quXE2qjcK+z59OpgdNkvi3tHqZuExo16qCOrIxbVP+FOWpIRojR 1jfBkKyflJrE3prbFSb6qTKYBzilOjZ5gPBEp85m7gSozq4G+a2pTOZSIyaroOIhdUyySUDpPEws 4Yyne/jUHhnphdTJ5Sku/vkYzPCjC0dfPtjnyah7hCWWk3nDZSAwzGH780fvHG+ipZQHor8IqUkL hpJMNXuSBlFtCRFMIzyUmtH9JV7SZAAPIkAABEAABEAABEAgGYFqtVytVlw7KToopFTovvs//dnK R/4Puw4lE9bmVLS6GhWnb//gbTon9lwZVd6maHm379rOafnT7VcO9bslo1eF4wvHLvHF6VFxdn/U 66Jegr6GfYdfkRl558VjRVHcQgt003V+fwuKNz26oJZciF0TgSi/5Kb0TGDhqFfNS0fFxNditWwJ 2ohXwyfEzr11SW3oBavqRjnmVjPkayixSY7tdRMQYzn7Dr3hNxD3OvlCbtu7ErRC1yZpbfdwX8Y0 3U/qXjWDOprT0oUTE6JYDBIZh6RZjL48UUPSMCl1Y4vyK/eBswPeLHr7BTHpmroog/32mV2X497D +w9O8ex3Zpc/fU0d9hQURC8k/801ZWMS8YhhSvW9y+4RI/b42BMQNnYebzo6XT9dt6e3SQLHXvCf sF6myiPsB0FPaE+BdLnY6NeiStl36OXRocvHm9Yyx7Q7aZ3GLlOak9vcwhSLC+ezMEBLM392rtGQ MwiAAAiAAAiAwPuCQEWwKor+JFOpStUpCz7rY0j9w0/v+T/9/ge6kge/BfmLtu07dom562+6Rk+3 Xhqd2TUR6KH8wt+8caU4+qL7ptR/cGSvuGJc5xkkJMJw69Wzc7uOBF+Mg3tq15fevDa/d8RbxHNJ 5s5NRr2nGdO/c3deDPT3u1n09Q+K+TvvJipjRKKb42PizNtvHPSkBikt6Ml7THJMrWZKbyqqSY7t dVv5avpNW4bEwuKiW9/kvavZJurk/a3uHsZukGpI3nztnBh98ciAgZhpqCrJDeUxDknjpNTJRjPm TXzmlFdf0XdonCeupanJ2lQptp6a2CMu3/AVrzYVWXx98nLx6LQ/S5P8w1tt7u902ujWbOxdKSeB rV+gbxjpCHeU0NLU13l8+crHjpalLZn3H3zxWNG8bLAtg67dF1//2lmhDBmSObxz8Npb7lMm/ZFq /kyfHe4EARAAARAAARAAgSQEKIBUhY2i+M/grFNI/Xbfk92pjYqo4OI7C2LPju31KWavzYjBTd6H e35TEmLurt5tzyAhCVR+l9Plrl5fujOniuobLIo770Q4EBrTkxNBcWbMteGnN2d69xtp+n1v+8m3 xzVCLOi5dTPIMTK0TZ+kMVqchrUSxeGn+zkbaz4tLlurxLe6e5i6QZohKd/BNKphj41pqIbQGcpj O4Rb1RzNyeVOu3eHZ4hRE7X01tW52lRJ11nxOnOjzic6QdbqAEmQfG0l0fSujCaBmtOf79Il/eDq nSXjvFZVr8CQN1+jfJd8cH3/udADytQu3E+Gnt3mO+tFNh8XZnw28H8M+52pjrS+qyBXmWyRpPNa 4L1u5lAn3/UkJRM2doHn6syf3e9509eyNjlXRnHoe2Z4aK559ZARqdbi7OnhAf9jW/hGyTORc2Wa +XNtjUeUFgRAAARAAARAYI0ScPfX82JJkb9evcue+N2P/IM1UTX6NC2KO5+Ra2OyGypuEUFcJ2Xt OzT4JK9S6ad9d0emR4dMVTNLiIMh1+jHnte+4wXXtw2TxcGkF9mKv4iGlv9XRr0wUsFC05ye/TVO D04coCU7ey82GIXFFdfq96T0kgtVWy35XY0pTXJsr5vKUC/He2M5QJ+ya8FTRPZ8mmHS9ntbW337 Icn6pr1nTjUopn0wpqGaCFz0EPZEZNW9E5UoRaKlxTtep2282W1N7+jfZLIxi86V1XbBN4AUBeyq W8KtaepdqUYBW+r5TwfSodzY4Xl/syuffAr0HToSMlIjzddQg6NciBa7lE4MeN7fl5TgR1r5dCs7 aYogfc3JNaIN3r035z9zw6mCR1g4tuPM2PktF13Xzrmad3nYqTPk4kdyJgfZxf7iMXHuBH13ieYw M+a58F/i7zSsg3P9GemfYsh11afzDdd4Wa3vmYGz+/2nbRyH/m07i3P33smka6rtzgIXyeJs8IzG yXH7joGrs3ExLyOLZD9/ZlJDCAEBEAABEAABEACBaAJVQcGj3JOspegsO3UxpNYGQY70QZ/6PSe4 pXsLYm5iUrwgF6AcWelA7fvwuxwz5erwxcDXT1fDSAmRSKQLzEijC0Pd9e0neYW9TyqeTogR8tfw jlB8Ivqo662Sjen5C/DYnVFa5Z/eOzOmBkFvScslopc053CrJb2rMZ1Jju11Uwk0craect9tpoev 71Nj0mfKJz2RTt3ZwupbD0nX8yXCYNA0VBPCMw5J//6sunfC8jSZLGS6QoqGJsWtu9vrWjOqdyUf BTRju98eOLKhr4agR0Dg4bh1RxAZin3SfSM16QjpfX0xkJYupYE2VtXj6OW7TppfMGpvddmw0Y3+ UGNIKRrhPac9ZZBSL3HrxmUKmxhUOSxwr6ed6ds84JkzR3EInE9lfSONjl0Pa7++7Do3LzU+CTks 3GtGO6Rtd6r4zLnwpymFxdYdgxOvNpookv3m7URRuqznz3U3glEhEAABEAABEACBrifgmkrRUR9D qutLTp86903MF0cv+o5mvHgNYkWFv6nOnz1+/dlL3jdSDsCkPyIkROJYunCePlxrzKMar9eCK79x UGjtCLafpDi1QUwofXo3BIxc5W8bJ53UnPyM3KojIb1k2de3WrK7GlOZ5NheN+UfWU43Etk1L/5X pnzS8ujcfS2tvu2QnJ3UxFpW2JiGqgW+yCGcVfe2KE+6pN4MI99saWsIKeTJzcVwNDpWPRQ3b0qV Q7ReIJXItt9U35oRvctmFATBrUM6BdV/bYz8yr2DlSbuVBOKX2ZgUedSKp0uvcMgX3TGli3SlWzX sO88zv3TVVol5mDyx5cYXAUNWxbL84CqCWq5TZ++3QUHuWdbNq0L3raR0QX/QZOi/9vOnymywC0g AAIgAAIgAAIgkIoAqaFcTRQppHIVUaisNYUUmQgdp0+dF71Prz6EusWou+cdhWoSNfMlXpJq4qdE SYhBzOoh3Ydr03VPnPxEHKy8a3mwQ43uqKXnKsiquYesYKsOO3oxpTC0mnXZTXJsr5syTlRO10kn Uz7WIDp+QzuqrxvUhorzGKlFjSHzSfnyWXvTixmStjjrhnCibmObRwvS9z39rDaWNm+PoBqYsAYk 2DxBUTDVzT+NJWTHxhYG3GkBEo3IxtY09q4MRsHNcXYE9jZOpW8MtQJx9CJ29CZX00jTPy2V4OuL WX6MSVELYfv7QiTLIgmH2J7JWdGyQdkb13flC/V8U4kGNicKnJWsQmoq3shPv/8vuQreufGWvcTa HRbzZzPZ4F4QAAEQAAEQAAEQsCXguuxR9Kh8ReQbYkjZSmtrenpV2E+7/NRro2So70kOvUEHh551 A6/2HR4hrwfvuozcpFMDyZsMEtzKeV+YQ2Fi+bqMEOzvnadwMF33iveJ49pIN7yB0VxjkHKOcBGk l44MgSU/B6Ro3VfuaHomJrruYGi1yJ6jk2+SY3vd1KYJyikDybu+Mxa9q61jpE2ZZdc9DAW2G5K+ T6X7wkmGP/LlMwjOYhqSNt04KGdoSMo4yrpJqU3tYJeN22rergjKrWSOMVSL8lOLdBOO6CyvR8e0 5labO7fPjTDNc+eFqajtRO1K347U2tY09q6MJwGeXpRKyv1Yr0++dl14GylEAJAxzo5TUHDvKUMP wUbTXUW+fJR4sbpnTyYLai6jKemDbSdvGinEzrA3nkPd7ply/9lwDCbZkzVOcPEcFmevzzVYC7oe rw1LguQYailpY8eJPVdGGyPWk/p44frVsMjkQc0j58805cQ9IAACIAACIAACIJABAdZDkRiKJCWt pOifdKwhlz02c6Cd8mqG9095e+tQmAwOU9oQnmPrqWn+/MjXZcBXc8BjkwQzddMmd/rrwT4+Mo5s bVe72r4/B84OKEHKDenJkYEXr14gElJUaTfIs+sq/t5M/C50+Tiz8qLCJ6cnMzTJMbWaMV9D8U1y bK+b6MSVk8mEAslb8rFrla5J3eruYZRvPySNLWuzH6WxPIYhaZyUuqYFQwUh3YqMsuf6LpEpmXvI t2LfxEyJcMTXB7zgd2rkI4/S8StCuNORb4xGrSYjTHu+UV8XzzS9DWg7QVq3ZtOTgKfCk81xfstR xUKK6k1qpvnLMwPqxpGm/hl+NNRiVJnkKzHRKI64apll5s0WdvNnX/O1jbWEalDzuD3gZA8JemCy PeM0HDjzWmwmeqqqD/dt4xxG3evk7uOMevL06IK/f0itx8Zx0G8c6XpEXr7RiCJNb2VvfVLj1uuk SN05MJc6ult282eaKuEeEAABEAABEAABENASIKso9tTzFVIc15zUUouL71arlfJP/r//3fR8pbJl 5/995+8/evS5f/fElwrfe+4Pv2xC+Z0L5z936AhAgwAIgAAIrA8CbB9070iE4n59VHPt1IIsYlgJ bggB3oF6sHmgEpG9XSVo5MC7Ct4daTUZzuXazunG3WzXkl1kuxoJ+YAACIAACIAACHQzgZ98/7sf +8zuTEpIonbv3n3//n0raRPnp75V+uzvLs7me3tFoSeX35h3cvlcNSdya8hCyqrKSAwCIAACIGBB gH2drpyXFiX0Kp6JR5JF7khaR0C6n2s2zeggKM8izPcNbE9JOsVh6cIJw1YJ7McnYtxX28MGuYAA CIAACIAACIDAWiKQyxdyopB3Ck6Fg5vnhEPqKCik1lIToqwgAAIg0CoC28Z9dyrycdZsvNCqfCE3 TMD1D+2ELVJsS7gxj1ytZcuPjnIg/83BM0EcuqCusye9CACNP7WcBzIAARAAARAAARAAgbVNgBzz KuWyWC07pItyHHLZqzg532WvXCnJY2Vl+RFc9tZ2Q6P0IAACIAACIAACIAACIAACIAACIAACICC6 xGXv9979D7n8BsfpyW3YkHNyFdJHOWQzhQMEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEWkOgLKol Ua2I6mqlulql2OZ5spOCQqo1sCEVBEAABEAABEAABEAABEAABEAABEAABECACThkE1Uq0FZ7FMw8 V8jne3p7oJBC1wABEAABEAABEAABEAABEAABEAABEAABEGgVgWqlUq1SEKnSarVcKpdWy8vLqw+h kGoVbsgFARAAARAAARAAARAAARAAARAAARAAARB4+Ojhw0cP6I+V1eWHpYe/WXn46+X3oJBCxwAB EAABEAABEAABEAABEAABEAABEAABEGgVgdVSabVUXi1VyiuPVsurq051uYoYUq2iDbkgAAIgAAIg sM4I3Bx/6rnXl9ZZpRqrQ9U8eWvd1xIVBAEQAAEQAAEQAIE2EnhYWl5ZeVRafrS6urK8/OjRw/ce PnywtiykaI34iU+750s3w+gWXz/s/fTFC4vKT+71JCtLk4SGJlqa+mJQDP8v47NCmK6zgJrwZCWP SB9Iy/CtQE/p1ks+7cNTyV5AtHJiWy1J61CtTXJsr5vGnF7O0oXnvC7X0Ovs+bRxuGeZVUu7R9Cf G7tB4iFZq6x7iz80ooZkBCBtfU1DMqJ7Z9kGmclSmKhTZa0zB7Mlp1QbhWvKE506m7kToDo/GORn Vv6WC7KaxBK2vtJ5mFjCGU9TVWU6Si+kTi7LtJjhRxeOvnywz5MRmh7rekLLWyrjDMIctj9/9M7x JlpKFs7U7sFQkqlmT9Igqi0hgrUND6VUT/mU817GPCEOBEAABEAABEAABOoIPCQlVGl5ubL8cJkc 9x48eO83Dx/8eg0ppGhtNypO3/7B23RO7LkyqrxN0fJu37Wd0/Kn268c6vdqzuu8E2Ln3gRdwSBB e2ff4VdkRt558VhRFLfQAt10nVelQfGmRxdiSx6Rngu0dOHEhCgWE9QqURIDJXpBPb5w7BJXc3pU nN1frwFskK2XY241i9ZxV/ba1re9bkJiLGffoTf8tuZeJ1/I+bDmk6gxui9Ra7uH+zKmHaQ2Q9LH Vj80jEPSzNnYjbVDOGJS6r6m5KnjuU8fODvgzaK3XxCTrqmL0plvn9l1Oe49vP/gFM9+Z3YJsWuC R8fUYU9BQfRC8t9cYzYmdpOYXevv8bEnIGzsPN50dDrJQy37HijH17EXgiesm4PbB9wz6AnZZ55U oo1+LUpm36GXR4cuH4998MWVK6bdSXk0dpnSnNzmCioWF843a4CWYt6LqwV+BwEQAAEQAAEQAIHm CVTKpeXy6kMOILX6YGX5AZlLramg5vwW5C/atu/YJeauv+ma7dx6aXRm10RND+Whujk+Js68/cbB /nh0BgnxN3Lur56d23Uk+GIc3FO7vvTmtfm9I94ivv/gyN65c5Pue5o+X3N6edPN186J0RePDCQq XWwiE6WbN64UR1903zO5zOJK9CrZJMfUahatI+tgkmN73QTE2LuUGzZtGRILi4tuK1jyiW2I7kzQ 6u5h7AaphmTM0DANVQW9oTzGIZmk23RPyxKfOeXVV/QdGueJa2lqsjbYxdZTE3vE5Ru+4tWm9Iuv T14uHp32Z2mSf3irzf2dTms7iaVs/a1foG8Y6Qh3lNDS1Nf50eMrHztalrZk3n/wxWPFmAefRUF0 7b74+tfOCmXIkLjhnYPX3nKfMtkcCea9bDKCFBAAARAAARAAARCIJuAUCjmRE+VKNZcv5fJlx6Fz DVlImWq3+M6C2LNje8PP20++PZ7sdcgkIUGP4nc5Xe7q9aU7c6qkvsGiuPMO69IM+RrTsxT5oq7R fyUoqzaJgdLstRkxuMkze+D3TCHm7ka57SWn7RbDNn3a+mV4H2slisNP97NIaz4ZlqOdolrdPUzd IM2QjBkapqEawmkoT+SQbGd7NJUXd9q9OzxDjJqkpbeuztUGO11nxevMjTqf6AQ5qwMkQfLuS9KZ SanRWVL6wdU7S4Zd0Rvhqd5hIW8+jTOmvDu4vv9c6AFlahfuJ0PPbvOd9SKbjwszPhv4M4b9zlSH Mt9VkKtMtkjSeY1Ot7JmDnXyXU9SN/0nuDrzZ/d73vS1rE0e1lEc+p4ZHprLVj2kctNbnD09POB/ bAtDljyTOlf6tyaa97pvLKJEIAACIAACIAAC65FAXlRzopIT1Xx5NS/KwnGqYq0qpMg+RRR3PiPX xu/cnS9uEUFcpxQxF9JLkGv0Y89r3/GC69uGyeJg0otsxV9E/eW/IV9jeteWYe+ZU43atxZ02KHB J3mNT2D33R2ZHh1qPgu11ZqRZpJje91Uhno53hvLAfqUXQueIrLn0wyTtt/b2urbD8m4oWEaqonA RQzJ2v1Zde9EJUqRaGnxjtdpG292W9M7+jelM79ktV2gxU5RwDVxSwaTDFus+E8H0qHc2OH5u7Er n1Q39B06EjJSI03iUIOjXIgWe3lPDHiuc5eU4Eda+XQrO2mKIH0i/+937835z9xwS10Z1UbZmxk7 v+Wi69o5N/E1Pwph2Kkz5OJHciYH2Un84jFx7gS5rUVzmBnznLgvHS3OjLEOzvVnpH+KIdfZnM43 XONltb5nBs7u99U6cRz6t+0szt17J5OuqbY7C1wki7PBMxonx+07Bq7OJovaGFuwpua9WOlIAAIg AAIgAAIgAAI2BFZ/9YvSr++vvvcr8Zv7lYfvVVYeVJaX16KFFEfuoE/9nhPc0r0FMTcxKV6QC9BL R8XEActor+klSBeYkUYXhrrr20/yCnufXLWfECPkryEPY76G9BRHic37R5KZfdl0DUPadznizNXh i4GnZDMyw62WXpJJju11Uwk0craect9tpoev71Nj0mfKJz2RTt3ZwupbD8nYoWEaqgnhmYZkcHtW 3TtheZpMFjJdIUVDk+LeN7c3NcnMjHl7RHBsPl8NQTqUwMNx644gMhT7pPtGatIR0vv6YiAtXUqD DxWqHkcv33XS/ILVhw02WtQfagwp5WPJntOeMkipl7h14zLFnAqqHBa419PO9G0e8AxyozgEzqey vq7RsemQHtZ+fdl1bl5qfBJyWLjXjHZI2+5U0Jlzwaep+mJv3TE48WqjiSJZ8NlG6Wpy3nvfjGxU FARAAARAAARAoD0Eco5TyDs9PauiWq2sOqVHufKjtaeQuvXSvon54uhF3x2PF69BtKOGb6pJyKaV sHThPH241phHNV6vBRl946Dw7Qgi8tWmn53UBJRNUsF0aebPHr/+7CXvCzNZrKST4t1V32pphZnk 2F435R9ZTjeW1jUvTnOmfNLy6Nx9La2+7ZCMGxqmoWqBTzsk/fuz6t4W5UmXdP7Ou3yjfLOlrSGk kCc3F4V33RXKqofi5k2pcojWC6QS2TU3NTnJBMGtQ2ZBqv/aGHlGewcrTdypJhS/zMCizqVUOl16 h0G+6IwtW6Qr7q5h/1sL909XaZWYQ6RHuavgPuBvGntA1QS13KZP3+5C0HW2ZdO64G0bGV3wHzRN 9P8M5r0mcsetIAACIAACIAACIFBPwBHl8srqoweVyopYXc6vPMqvrjWFFDkgHKdPnRe9T69+DesW o3LPO7sjhQT+9qj7cG267hVIfiIOVt7x+Qbp+S+10BhkIyZX2LYRJRJi4UBXomb8xQt6TfSZhMIM rZbw7loykxzb66aME5XTdW7KlI81iI7f0I7qxw+NAEPc0IgZkrY4w0OYI9foJiVbqS1P3/f0s9pY 2n39g0I1MGENiBjo75cFUhRMPAlETq3s2NjCgDstBxSZQVaTTDiTm+PsCOztD/sDde88jl7Ejt7k cmVvFRt8PzDLjzEpaiFsf1+IZFkk4RDbMzkrWjYoe+P6rnyhHm4q0cBm6wVFwsrRRn76HWzJVfDO jbeSSTGmynjea7I0uB0EQAAEQAAEQAAElh/+qrzywKksl1bfq668J5YfOI8erCULKXol2E+7/NRr o7Y/TyEkJr0QFRzYOGng1aBLRErwvjA3uAHKCMH+3nlK7zJdl0k4YkUtCFR8ydX0vuOYu6om6wa5 wm7RNtt9h0fIZ8SjKuNe1ZRobmAp+tqcyDXS0GrRL38a+SY5ttc5Y135E5STNuHyfWei+az7ySa7 7mFAZTckY4aGaUjadOOgnOEhzNoo3aTUlT3AbbWxhih7ZI4xVIvyU4t0E47oLK9Hx7TmVps7t8+N MM3j7MKUZ07YlTySFyrNJJNcupeSpxflJrkf6/XJ164LbyOFCIEyxtlxCgruPWXoIdhouqvIlz5x Xqzu2ZPJgprLaEr6YNvJqyqFyPhQiY94DnW7yLGC1fXICw7ZkzVOcPEcFmevzzVYC7oer4kef3HV pI0aJ/ZcGW2MWE/q44XrV8O3WwY1j1yKxBUMv4MACIAACIAACIBA9gScalmUVqrLy2QeVS6vVsvl Srm0hhRS/LmP9nqrGd4/5e2tQ2EyOEyp3FVHCc/h7zrEq/zLx/lXY7xzg4SINpC6CU04J/31YB8f GUe2tvefKV9T+uw7BcWlOiwdGRoobT01zR9vmZsMlxsTSd0kx9RqFq0ja22SY3vdhDCunMyBY+i+ cqjfFWHJpwVN1w6Rre4eRvn2Q9LYsoahqk1vLI9hSBonpXY0jn0epLmTUfZc3yWysnQP+VbsW18q UyhfH/CC32mm1uNXhHADWvt2mtRqMsK05xv1dfFM2wLe2cNovMN2Emu+9T0VnmyO81uOBjGkZNlI zTR/eWZA3VPVVELycWO9hhtcXGlBk3wlJhrFEVcts8wc2cJu/uxrvraxllANah5nsSt7SNADk1n4 ajhw5rXYTPRUVR9P28Y5jLrXyd2HPvXk6dEFJfi6V844DvqNI12PyMs3GlGk6YXbT57eS2rcep0U qY8H5pqI7mZaoqQpIu4BARAAARAAARAAgWwIVCrVcrVadYTICydfzhdKFFJqcfFdiihFyqmSPFZW lh89evS5f/fElwrfe+4Pv2zK+DsXzn/u0JFsigUpIAACIAACnSbAdkD3jsSpnjtdyvdR/mQRw0pw QwjwDoBg80AlInu7StDIgXcVvDvSajKcy7Wd08FHiKC+a8kusl2NhHxAAARAAARAAAS6mcBPvv/d j31mdyYlJFG7d+++f/++lbSJ81PfKn32b2ZeELmck+sVOVHJ94hCgYSsIQspqyojMQiAAAiAgAUB 9nW6cl5alNCreCYeSRa5I2kdAel+rtk0o4OgPLNQ3zewPSXpFIelCycMu4iwH5+wjgzQHlrIBQRA AARAAARAAAS6l0A+J6qVEu+vR1ZSZCYlDyikurfBUDIQAAEQaB+BbeO+OxV56QYbL7Qvf+TkEnD9 QzthixTbAm7MI1dr2fKjoxzIH3PwTGOIxtmTng97i6I3thwqMgABEAABEAABEACBjhEoLz8UFDqq Qme5WiqJUskpV5z/6cp/LpdLZe+/UmVldWV1+eW/GoTLXscaChmDAAiAAAiAAAiAAAiAAAiAAAiA AAiAQNMEusVlb/pUNZcXOUfkCiJH9lI5kc/l3v7x37z9l//17b/8m+//bz+99Zc/ffvHP/tPcz9r usoQAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAKimstR3CinZ4PI9zikmcqTTopOIRwKLJUjDVU+ 5zj5gkP/BC0QAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQaJ6AUxVOqeKsVpxSWZRoxz2KJ1UihVSV RNPme7zTXrlSrQr6/+YzgwQQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQqFbLgoKakx5qdbW6ukJ/ VkghValUK95/pJSqlFZLpJYCLBAAARAAARAAARAAARAAARAAARAAARAAARDIgEBpVVTKjiixURSb S7FZVI7UUuUy2UWR1x456+UqVQF1VAasIQIEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQIAIkGEU6aRK q45gUylyzaMzV6Id98hRTx6CTKTk/+MAARAAARAAARAAgTCBm+NPPff60rqnQtU8eWvd1xIVBAEQ AAEQAAEQAIE2EuBQ5RQfanXFWX4oVh6K5UdiZSW3cWOebKVWS2QoVak4TrVA+/BxpPOuPGiN+IlP u+dLN8MlXHz9sPfTFy8s6n6KXUNHSAjLW5r6YlAM/y/js24apYThVfutl/ySH54KL+bdfOvXvob0 EQSaaTGrMkRkpJcjRPR1JtPQaqZcXFF+a0a1hW05ax0g3LtaxLyZ9mrzvS3tHrGDOuFroUmO7XUT W72cpQvPeTNSw6RkHvJtbj7j9KUOulppg7mIB5cKnwnIiU4ZKe4EqM5pypBMPKg7CiQ284QTfv0j SZVbRyxhl9aUTOlv6YXUyWWZ9U+liOl3dOHoywf7vASh/l/XE2LBdlmCMIftzx+9c7xZnZSp3YOh JBHMnqRBxCPL7WlBR+J/xq5bYh9zVo9XnTTNiDbMAOGR0vTwt33uNKRPOHI1kMPLDI+Ktjwplg22 9Qqm3FpnMD13Ip5HshKN9bIuf6qlqZZnl41/FAcEQAAEQKAtBKq5gsj3ityGSs8Gp3ej6OkR5KRX YF892mmPisB6KI4nJcOcd99Bj7RRcfr2D96mc2LPlVFluUPLu33Xdk7Ln26/cqhfLfzShRMToliM qU+UhPpb+w6/IjPyzovHiqK4hRfoXMKFo14xLh0VE1/zdE/0CD++cOwS3zI9Ks7uD1acvBI9IXbu rcvCkD6CQBPNZVcGc0YGOXK1ramjVN4ZW82UTX1rGtvCtpzENijM9OhC0Ltaw7yJ5mr3ra3tHma8 xm6jBWCSY3vdRNdYzr5Db/hTAU9KvmJaGId8u9svlB+/rhw4O+DNordfEJOuqYtS2ttndl2Oew/v PzjFs9+ZXULsmuDqTx32FBTUaiH5b64HG5PICd/wSNI08x4fewLCxl7i9bfT9Y+M9nQrOf0eeyH8 hPX6gPtADHpCewqky8VGvxZVyr5DL48OXT4epWdMVMmYdielydhlSnNymyutWFw4n4UBWprHq6Y+ +hFtngHE3jPe0mhi4Ny+hg+HiYhxItvnjja9/VLNLZ9m0agvj/2ywbZehvKYnjum64Z6WZc/3dI0 2SI8cd9AQhAAARAAgbVMIN9byG/o6dm4QWzcWN3wWG7jY85jj5E1lMM2UU6BtVPVHEWQotjnXXnw GshftG3fsUvMXX/TNTW69dLozK6JOj2UX4Wbr50Toy8eGYisUqSEGBi3Xj07t+uI/GL8zt15MdDf 797Q1z8o5u+8y3+9eeNKcfRF952t/+DIXnHFXXHeHB8TZ95+46B3R5CRKb2RQBPtZVsGU1ZGOYY6 RreaMZfo1lTawrKcS29em9874r1ocRvNnZuU79KtYN5Ec7X71lZ3DxNeU76m+pvk2F63la+m37Rl SCwsLspLpiHc7vYL50eT4Zzy6iv6Do3zxLU0NVmboMTWUxN7xOUbnsmnVYEXX5+8XDw67c/SJP/w VisBayGxMsmknBy2foG+YaQj3FFAS1Nf54epr3zsaFnaknn/wRePFb2HdQYZ6tp98fWvnRXKkKFs hncOXnvLnUbSH80saZRcmxnR20/St7qU9GyfO4meFwmWam7VGxeNBvnWywbbepnKY3ruRF9vqJd9 +Q1L2eiZMNEiPH1fx50gAAIgAAJrikC5tFourZRWl8WjVToryyvVlRIrpJwcee3l6CAzqVzZyVXY XGrtHIvvLIg9O7ZrCyyXZa62KOKIkhDDgd/lgtzJyL84M+aaVdPKg97NRvh9bPbajBjc5JWBV3hC zN3lNNtPvj2ueWEzpm9Fm2RVBoMcUx1FGuYxrRlqCxMrQzmX7sypd/QNFsWdd9Z/nJTYHtXq7mHZ TLHl7WACXtwXh5/u5yK0dQgnrjOXau8OzxCjdtfSW1fnahMUXWfN2syNOp/oBLmoBBIkX5NJEk0y djVrdJaUfjf1zpJxDlCqF1XIm0/jjCkLGFzffy40+ZlKz/1k6NltMQ9T924uzPhs4OUa9jtTHal8 V0GuMtkiSee1wIPbzKFOvutJSoYt7D/L1Zk/u9/zpq9lbXKhjeLQ98zw0Fzz6iEjUq3F2dPDA/7H tvCNkmci58o0j1dNIZsc0X2bB4RKL3n5bZ87puWHUqckSzVvXDQuGrNaNtjWyx2nkYtYUxs1XNfI sV32pHquJVuE282ZSA0CIAACILCGCVAUcwphXqZw5iui9EiUV0W1lGP3PId0UvSfQ057hXy+QGGk uv0gAwRR3PmMXBuTXVJxiwjiOilrX16C7D1zSq+rUqpolhDHQa7Rjz3vv+OxvfTpwYkDtKRm78Ka 0dbQ4JO8XqZC7rs7Mj06FCc3Pr1KIE5aut/jy5BOrnuXPfO41qxrC7vCbRsmq5BJL/oYf7XWvaK1 nrldoTuaOvvukRVekxzb6ya89XK8F9oDZOlQi60jsufTbHMvLd7xStUoyS2td/RvijYoNRWEX28C zXuzpe3O+82TjEXvZUsN/6lBOpQbOzzvb3blk+qGvkNHQkZq9B441OAoFwLErjcTA9J98u3bl5Tg R1r5dCu73oggfZxHu8zr3Xtz/jM33DhXRrVh1GbGzm+56Lp2zgXe66xyUpw6Qy5+JGdykB3bLx4T 507Qd51oDjNjngv/Jf4OxDo411+J/imGXAd5Ot9wP0ep9T0zcHa/r9aJ49C/bWdx7t47mfRGtd1Z 4CJZnA2e0Tg5bt8xcHW2qc8h9o9XbQ2bHdGs2s74SDuvJl2qxS0zQtXJcNlgqpe5PPrnTqBornse aeWkKH88//BMaMUz474CcSAAAiAAAt1IwKlSpCiyfqrSn4LiRFUrOVHN0bZ69H8FR8jTyRfo7Nqg 5i5WjudCn/o9B6ulewtibmJSvOCtxcXEAff7sGsML22Uog+jhLgb2bR7bs9IzYWBv9CO3RmlVfjp vTNjoUDd73L0lqvDFwOvwxjhkenDBGKLmTaBbZkt8rFmHtua9W1hURhOyv4FgmJe8Hf1E2KEfGrq jjYxtyx2J5Nn2j2ywmuSY3vdBFYjZ+sp99V3evh6KGZKpnyybeiQ6QopGrKVvn6lmSaZRL2Xngiu 4objCfpqCNKhBB6OW3cEkaHYJ903UpNuU97XFwNa6XoTfHpR9Th6+a6T5hdiP9Wo2bHRjf5w44i5 p/L5Z89pTxmk1EvcunGZYk4FVQ4L3OtpZ6RljWtEHMEhcD6V9Y02aJUutH592XVuXmp8EnJYuNeM dkjb7lS3mXPazx6MZOuOwYlXG00Uyb4mWZQu68dre4Zs4vJHFifVvJpwqRa7zKgrWZbLBl29ospj eu7orpvkpCm/zdLUlmd7+iFyAQEQAAEQ6CiBStlh/zzppecWpMKBzKtOtZqvirw0k8rnqnR2tJgx md96ad/EfHH0ou/sxovXIEKT8k11dlITflUr2yQhjsLShfP04Towj5KhByhEi1yFbxsnndSc/MzL x/zZ49efveR9reVQUzFHZPp6AnHCUv5uW2arbGyZx7VmQ1tYlUYmrgVAfeOgqLf1aBNz+1J37I5M u0dWeE1ybK+bqEaW0w0Pd80L450pn8xa2YtqJ98MaWsIKffJzUU/2p2bD6seips3pcp0PTu6miaZ hL03CG4dMgtS/dfGyJvbO1hp4valUJwXQ5vUud5Ip0vvMMgXnbFli3Ql2zXsfz3i/ukqrRJzcBVY Jj7yqxVbLsvzgKoJarlNn77dhaDrbMumdcHbNjK64M8kKcah7eM1KotmRnSCpY5t7VLNq0mXanHL DE1hs1o2aOuVqDzh506tiMr1CDm25bdamiYqv20PQHoQAAEQAIG1TYD0TRQqis5KD2mdyB6K/5Ij uynWRnFoc9JGFfLVPIU379qKkgnScfrUedH79OqXs24xynve8ZfYWiAJsqiS61Fj/AWNhDgIrH4K fbjmz5Ludnvy4DhEtb/UDKk4mSaSSy07eaMpvYFAXGFtf48sg60wQ3oL5nGt2dAWzRVRfsYP3o44 NImu1zWXx5q+O9PukRVekxzb66aWSVRO16MhUz5Z9ZS+p5/VxtLm7RdUAxPWgASbMyivo3XzW2Ox 2AGkhQF3suKQVo5+kknUK4xZ3hxnzxpvY1b6hqE8BSh6ETsRk6tRIjvfUBaBIsAsv3Mx8vzA/8na gaM4xXGI7ZmcFS0blL1xfVe+UM83lWhgc6LAWckqpKbijfzUXXdrv5Gr4J0bb9lLrN1h8Xg1ZtPk iOaQQ35YvWaqEtybcl5NulSLW2bE1CH9ssFQL4vyhHyulXLK6wnlxJffcmmaMN9MugaEgAAIgAAI rBUC7KRXLVcqJYeCSVXoX4KUUbke4ZCnHp1kHtXLHnuF3nyXxpCipf9+2uWnXhslQ4lPcugNOjiA ogy86tstu2tQsgWQ61H9ptR6CV67el+YQ2Fi+ScZIdjfl02mlY4GgaU9B4xwv0L3HR4h/wuvhDI+ kaLs0PQec3oDgRb0wOgym5hYFMSOeUxrNraFW5JU5eSoIkrosfYxt6DX6aTZdY80eHXNapJje93U bRKUU+5j4LpW2Q759rSnWypv1wUlSzLHGKpF+alFuglHdJbXo2Na86CeO7fPjTDN4+/ClGcv1p4K tjQX3SSToFckLxP3HyW13Ovz+uRr14UXKT9CkowFc5yCgstDPgRV0133siJfjTY9ezJZUHMZTUkf bDt5HaWQwHA40X3xHOo2V5X724ZjMMmerHGCi+ewOHt9rsFa0PV4bVgSJKpOXSLanmxiz5XRxoj1 pD5euH41nNoiKLh2UeRLS17+JkY0zdK8r4sSVo96YNKg7AaU6ebVxEs1m0VjfQmbWjYY6pWsPMpz J1So2vUkchKV33JpmiTfNIMG94AACIAACKxlAhy0PEcBo8oUxZyd9iiQVFk4/+r0/yLVVBRLqlKR /+9UHl3Kf/JLhe8994dfNtX3OxfOf+7QkfbSoNUMGTqFjiCKhHyayp8omqlG60T3UoDVOruqkCij BFpXsYX/3jOhHfG4MAtHp2thyz1haiHVW2TQWddTjyJueIE2lIve7YHxlzZ9FIG0bWFbBpmPholJ ToR8GWhW22p65kEV61rT1BZW5VQKU2sgyrEVzNO2VQfua3X3MOGN6ja67meSY3vd1L0TlTOYjqQU 7RDuQBPWZSl1KEHQqGDCUSoYmkK11xtaR7lFlV/UzJCdJ5CqBNpJJvnkwMTujmgCCCq4iqNHByeu DyrPLyk/NB1FjAt9Cxrle3OsfGKO3NlP0cT1X2sUWvKWgdOhWoS7U/D8DdeXApkr8kO3+D2HL947 ooagUjKO4xBCxPfVniz8Icp97ofRBT02mgP/SpEf61YOnqjweNd2K1O7c41o2xMvlhbxYd3N9CtP v6lmJ2uh2oNLDvoVjiZ386Ioefnl016ZMfwRbZgBApiyOA18kpff9rkTMy5slmraZYZRfg1yomWD bb3UZlWXPSE5CmfTdZOcFMue1EvT+EV4qpkZN4EACIAACCQl8JPvf/djn9mdNHVkOhK1e/fu+/fv W0mbOD/1rdJn/+u/+bLI97BSihz3KEyUu7/eybN/WhGlChlPkTKqUnFWyk555dXcP+8+hZRVlZEY BEAABEDAgkCkUsBCDpJmRCCstshIaDNi+PVbicjejCibexs5GBV8NmJj03Iu13Y2fnZydTSNxtqx ArslwVovf7dwRDlAAARAAARAYO0Q6BKF1M/e+JccQ4qUUE6eQps7HMy8kuvtyW3syT/W42zszT/W W/hAT35joUtd9tZOi6OkIAACILDGCLCv05Xzch8GehXPxCNpjRHoquIaPO86Wcatp6YNMY9aWKpO cVi6cMKwLwr78YkY99UWAmla9Fovf9MAIAAEQAAEQAAEQKBTBKRVFHnrVclvTxREzwax4bFcb97p LTislio4GwpOfmMu10s/4wABEAABEHg/Edg2fumokJuR7ZsYqAX1fz8h6Iq6kiESbQbXCVuk2Oq7 MY9crWXLj45yoEjYg2ca3RjJvY5Hx4QhHmXLmTSbwVovf7P1x/0gAAIgAAIgAAIdJUBxoxyyi8rl H/uA2Ph4ZQOdv+Wc+X//e4ohJYR02KMoUtVSZWXlW7/5Z3DZ62hbIXMQAAEQAAEQAAEQAAEQAAEQ AAEQAAEQaIpAl7js/erqy5VcjjbVq1ZXyxQ3qsTRzXO5PB25PF3PU9BzscGpFpymaoubQQAEQAAE QAAEQAAEQAAEQAAEQAAEQAAEQMAl8Lv/ePPvbxr6x1s+/nv/5GMf/kd9T3zk95/48D9iVRRFlMrn enpEvlAhdz5Kyf/hAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAIEmCaw++HXl0QOx+rC3p/DB3/7I h//xP/3Ilk/kyBxKnuTPRwZSghRSFamUwgECIAACIAACIAACIAACIAACIAACIAACIAACTRL4+1/8 8u/+9r/+3U9/9tO/uvuzd3/8s4X/9a//97dJB1WRJlG05x7/hZRR1Sp89ppEjdtBAARAAARAAARA AARAAARAAARAAARAAASYwMP37v/m/t/9+u9/9ujvHzz8u18/+Pn9B3//q5xrDcXhzIUos2aKvPZg IYUeAwIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgkAkBUjiVKqXlSvl+tfrIERXHcXKVKuuhKqJarlbo T6mNgoVUJrghBARAAARAAATWE4Gb40899/rSeqqRti5UzZO31n0tUUEQAAEQAAEQAAEQaCeBPMUt 3+jkP1DN5ap5IfIV4ZRzFQoZRTqpSrlMVlLVKumn6P/aWSqbvGiN+IlPu+dLN5UbF18/rL0ubr3k Xz88FbeErgn54oXFuFIpJQmvzs05NshfmvpiUB3/L+OzXs4WcuLKmuB3t2z1628bem4mejlx17mN EjBXs/DfiCIZmiuuLaepF5l6XQKu6yRJS7tHBF5TdzK9QGonAZN822bVp1+68Jw3I9VPSlaTTxs7 ijJk1EFXG+zBPMAp1TmBCcgJShkp7sSlzq4G+W2sYdZZRU0yCXtRHbH0mg6lv6UXUgeIZcY/H4Pp d3Th6MsH+zwZof5f1xOybodWywtz2P780TvHm9VJmdo9GEqyTrMnaRDxyHJ7WrC24X+m0v2lfCwa AGtGtGEGCOeb+Jlualjb505D+oQjVwPZFVUHP6tlg229gim3Vh7TcyfieaSs0NR6WS97DMvC6JlQ y7PVAxryQQAEQAAEupJAoSfXu9F57DHn8Y/mPvCR/Mbfym/YyC57bB9Fuqhyhc4Kq6S686BH2qg4 ffsHb9M5sefKqL/coev7ru2cltenRxeC6/xCeHzh2CX3uji7P6TDqqsjPU0DIbdfOdQfiYBLsnDU zfH2paNi4muetsuco05+3+FXpATvvHisKIpb5ELfTk6TzcWr4RNi5946MTb0glW1Ro5cbeuuCyvm wfvPiQlRLAZlNTM0UtGXx9SLTL2uSehr5/bWdg8zXmO30aKLmBxMk4b2esSrkT5936E3/CHMk5Kq UE48+bSvM/DryoGzA94sevsFMemauiiD/faZXZfj3sP7D07xrHVmlxC7Jrj6U4c9BQW1Wkj+m+vB xsQ4ydhNDnt87AkIG7uE199O10/X7elDSxdo+j32Qt3z0e0D7hn0hPYUSJeLjX4tqpR9h14eHbp8 PGrZkKiSMe1OSpOxy5Tm5DZXWrG4cL5ZA7QUj0VTVfQj2jwDiL1nvM4wMXBuX/jDYSJcXiLb5442 feTI1S7h3NxlP1eWGXQpq2WDbb0M5TE9d0zXDfWyXvYYloUxM6GGp01fQFoQAAEQAIH1RCAnytVc uZonD71Vp7oiysvVlQc5x9M/+bvteV57XVhxXgP5i7btO3aJuetv8svU0pvX5veOeEvk/oMje+fO Tcq3oJs3rhRHX3TflPi6uGJc5916aXRm10ScHipg8s7deTHQ3+/+u69/UMzfeTcyxyTyb716dm7X Efnl2VjyJHIsW+7m+Jg48/YbB73aBHdb0JP3GOUY5NM7sBVzt2A3XzsnRl88MmCopMLQhMFQTmMv MvQ6S8prNnmru4cJrylfE0iTHNvrtvLV9Ju2DImFxUW3oyaffNrYN2j4zCmvvqLv0DhPOEtTk7Wp Umw9NbFHXL7hm2raFG/x9cnLxaPT/ixN8g9vtbl/TaRVJpmUk8PWL9C3h3SEO0poaerrPP36yseO lqUtmfcffPFY0bxssC2Drt0XX//aWaEMGZI5vHPw2lvuNJLNkeCxaMqomRG9/SR9Y0tJz/a5k+h5 oXAwLeFMy4yslg229TKVx/Tcib7esHyyXvaYnmvRM2HMsi2bXg4pIAACIAACa4RAZXWl+uhh9eEj 5+HfVx/+qrz6sFpezQnHodPJ5Z18gf7koOYc2nztHEt35tTC9g0WxZ13SFM1e21GDG7yPtzzukqI ubt6t73FdxbEnh3bE9eZjPmLM2Ou2TOtMOgdbITfu4w5JpDP74R+GZqRk7gOfsLtJ98e17w0WtBz JRnkGK8nYNJQF6nDcnV2ukNlaORgKKepF1nzXGc3tLp7mHCZulMX4+XFfXH46X4uovXwaUu9uFR7 d3iGGLUcl966OlebKuk6a9Zmbqg+0cmKpxJIdsfaS5VokrGrVqOzpPS7qXeWjHOAUr2oQt58GmdM WcDg+v5zoUeoqfTcT4ae3WaafkO3cWHGZwMvnrDrk+pI5bsKcpXJFkk6rwUe3GYOdfJdT1IybGH/ Wa7O/Nn9nhd8LWuTB3oUh75nhofmslUPqZz0FmdPDw+4H9vqD8kzqXOlf3MzPbbJEd23eUCo9JKX 3/a5k+B5EeJgWMJ546JxmZHVssG2Xu44jV72KM+dUN+qv66RY7vsSfVciym/3WSJ1CAAAiAAAmue gLO6IlZXndXVKm2kl3NyuXyupzdHEaRk8Cg+ZDgp+rH7q0ofakRx5zO8Nt42TN/zJ72oT/y9sba4 Hhp8klepFIhh392R6dEhU73oc1lxiwgiOsVHbWC76NODEwdo6cyOPDXTKn2O8fLlWv/Y88G7Ylo5 WbZcUnrp8oxnUi+XF5R7z5wy6g3rGVqVK6IX1eQovc5K+LpMnH33yAqvSY7tdVOz1cvxXmgPkKVD LbaOyJ5Ps91oafGOV6pGSW5pvaN/k8kEMboI/HoTfANotrTdeb95krHovWyp4c/2pEO5scPzd2NX Pqlu6Dt0JGSkRu+BQw2OciFA7HozMeC5zl1Sgh9p5cu33E8cF0H6mg90BPZ37815z9y6RFdGtWHU ZsbOb7nounbOBV7trHJSnDpDLn4kZ3KQXewvHhPnTtD3nmgOM2OeF+0l/j7EOjjXX4n+KYZcV306 33A/YKj1PTNwdr+v1onj0L9tZ3Hu3juZ9Ea13VngIlmcDZ7RODlu3zFwdTYu5mXCIjX1WGx2RLNq O+Mj7bxax8G4hItbZoSqk+GywVQvc3n0z51A0Vz3PNLKSVH+eP7hmdCKZ8Z9BeJAAARAAAS6kQAp oZx8XtBJhlC5QtnJlwTtsse767nxo/h0VVPdWPxamdhfnT71+256bBkuKFoBfxE9IUbIG6J2vMsx U64OXwx8/XQ1W7q3IOYmJsULQUyoAzHxYvlL7NidUVptn947MxYKyK3JMV6+dKUZCblCpJKTcbsl opcuz3gmdXJd1wZpiaY/NAxtihbVi6Scul5nI3udps20e2SF1yTH9rqpzTRytp5yX32nh6+HYqZk yifbPhQyXSFFQ7bS16800ySTqPfSk8JV3HBwMV8NQS/GgYfj1h1BZCj2SfeN1KTblPv1xXRI15tA Wa/qcfTyXSfNLyQ3CuYJkOyI9YcaQ0r5YLDntKcMUuolbt24THHHgiqHBe71tDPSskaaM0dxCJxP ZX2lWbT56cAutH592XVuXmp8EnJYuNeMdkjb7lTSmXPKx7NwybfuGJx4tdFEkexrbKN0NflYzHYo pyi/pgCp5tV6DoYlXOwyo648WS4bdPWKKo/puaO7bpKTpvyR/OtmQlue2fY3SAMBEAABEOhKAo5T dUSV/PNI4UShy8tlUS5RUCkvoDnHM5cKKTq7svheoW69tG9ivjh6UXE0q4WufOOgUL7Sz589fv3Z S943Uo4aoD94+RtEm2r4Kqu5xw3FIlfb28ZJJzUnP+fyoc0xTv7ShfP0AbxmHpVWTsatlpBeulzj mNRLnZ3UBNNVEmkY2hbM1IukHE2vs5W/ztJn2j2ywmuSY3vd1FaR5XQD1V3zwnhnyiezvuNFu5Nv hrQ1hJT75OaiHwXPzYdVD8XNm1JlGq0XSCWya24yTTIJe28Q3DpkFqT6r42RX7l3sNLE7UuhOC8G FnWuN9Lp0jsM8kVnbNkiPbV3DfvfG7h/ukqrxBxM/vgSg/v9gy2a5XlA1QS13KZP3+5C0HW2ZdO6 4G0bGV3wZ5Im+n8Gj8UYTV904cyLrtSVSjWvNnAwLOHilhmaUme1bNDWK1F5ws+dWhGV6xFybMsf yb9+JkxU/tRdATeCAAiAAAisSQLkpOfkc04hX3UKVWkkJfIFUkiRcorc9FhbRScFkOpmdRR91zpO nzovep9eG9tBfoCV61oOJiVqZke8JNXET/El1C1nvd3u9O3MopQEMiM+onKMkM9ro9AH8JRyMu2U dvTSZW3BnJu1FhaE7OPk20VtKd/AMF2J/Ltqvch9nYnrdc3ltgbvzrR7ZIXXJMf2uqk9EpXT9WjI lE9W/aPv6We1sbR5Wwb1tZM1IMGmDYqCqW7eaywWO4C0MOBOVhzSytFPMol6hTHLm+PsWeNt2Erf NmoJOXoRu6KTq1GkZahWdKAIMMtvStGQFqG8zw/8n0xIEg6xPZOzomWDsqet78oX6vmmEg1sThQ4 K1mF1FS8kZ9+/19yFbxz4y17iaE7mn4sNjmiOeSQH1avyaq4t6ecVxs4GJZwccuMmDqkXzYY6mVR npDPtVJOeT2hnPjyR/JvnAkT5ptJ14AQEAABEACBNUPA308vR3ooDmLOvnsUQ4r31ZN76/l/dmuF 6IG3n3b5idBGUVyMIMxQ3+ER8nqY5JAc7G9FsaVqH2DraigjXHopZQhJNXSr94VZceKTDgWBRT0H hnC/NhtzjJQvIw377ofuqstU8kg52bZaNL1GJta52zH3rdDdNwqy7JBvF7XN5hsYuuVJVU6OKqIE q4rtddZVXwc3ZNc90uDVNatJju11U7dJUE65v4HrWmUx+bSxN7il8nZjUPIlc4yhWpSfWqSbcERn eT06pjUP6rlz+9wI0zz+Lkx59mJtrGWrsmqcqKWqOvqRZFMY7j9Kerlj7PXJ164LL1J+hCwZC+Y4 BQWXh3yEhU1u+bIiX402PXsyWVBzGU1JH2w7eS2lkMCgONF98RzqdpGT+96GYzDJnqxxgovnsDh7 fa7BWtD1eI3x609UOdr/d2piz5XRxoj1pD5euH41LCR5UHB5n67Hyh+Sl7+JEU2zNO/3ooTVc/O1 DcquIkg3r2qWWPolXMwyI7JFm1o2GOqVrDzKcydUwtr1JHISld/MXzsTJsk32TBBKhAAARAAgfVD oErhokrl6upKhfbaW3lEf3FKq85L5/6dqFYcGUeqXC6VnJXV1ZVXV//5lwrfe+4Pv2yq/XcunP/c oSPtZUOrGTKNCR1uFAn5KJXXKZhFKOi1DPXqeurV/1Rf9poQioeqxhmldRVb+O89E9qNTi2M+pMx R4N8lrNwdLoWFt0rl62c1E2hZOTJCAzQzPQ0TExyIuQrDZeIeVBHgkbhcgMrORNDqZCqbztjeQy9 yNjrUhNfUze2unuY8EZ1G12zmuTYXpeNo+k2icoZBLWRUiwmn3Z2CfnmEASNCga7UsHQYNReb2gd 5RZVflEzs7WzrhnmpZ1kkk8OTOzuiCaUoYKrOHp0cOL6oPL0kfJDT66IcaFvQaN8r5MLjv89cmc/ RRPXRNcOA5S3DMhnbnCEu5OUxnLC9aVA5or80C1+z+GL946EH9/qhB/JoeHhXpvM+dOF+6QIowt6 bDQH/pViUNZZZHuiwuNd29lM7c6NRduheCSJD+tupl95+k01O1kL1R5cNnHds9LYx82PRR9FgvLL 6VCZMfwRbZgBApiyVA3yk5ff9rkTMy50SyzTEk67zMhq2WBbL7V11WVPSI7C2XTdJMe0eI6Y2bTP tSQzYd2yLcPJGaJAAARAAAQSEfjJ97/7sc/sTpQ0LhGJ2r179/379+MShn6fOD/1rdJnf3bp/ymc ghB5p6eHXfbIQoriSb3wrWukjXI4dlSpXF59VC5RcKlXS5/oPoWUVZWRGARAAARAwIJApFLAQg6S ZkQgrLbISGgzYlhFokRkb0aUzb2NHIwKPhuxsWk5l2s7Gz8XZWsZF1uM7BNkatmXffEgEQRAAARA AARAIHMC3aKQuvgvhSPd9MhRT9CWezlH5HJlOioczbxUJV2U3GGvm4NIZd44EAgCIAACIECOhuTr dOW83J+BXsUz8UgC1vQEDJ536QU2f+fWU9OGmEfNyzZK6BSHpQsnDDtpsB+fiHFfbSGQpkWv9fI3 DQACQAAEQAAEQAAEOkWAdtajg4KYl0n5tFpZXa2urlIMKbKNqpBOinbgqwhB4c2hkepUAyFfEAAB EOgYgW3jl44KuRnZvomBYMuzjhXnfZsxGSLRZnCdsEWKRe7GPHK1li0/OsqBImEPnml0YyT3Oh4d E6GtEltOIrsM1nr5syMBSSAAAiAAAiAAAp0hQConUkuxnVRB9BQqGwrOqYn/hVz2chRHioJIkZHU SoliTb1a7sIYUp0hhlxBAARAAARAAARAAARAAARAAARAAARAYC0S6BaXvX/zL4XIURipPIWOyucr 5LiXz+WcapmspHKVar7i5Ms5cuZzqqS2wgECIAACIAACIAACIAACIAACIAACIAACIAACTRPIU8wo RziimquWyTXPIQc9UlC5bnrsuFclGykKLeXQDzhAAARAAARAAARAAARAAARAAARAAARAAARAoHkC ubxDFlGFfIXd9uTpVOkCRTcnuymnIqplQVoq0kdBI9U8bEgAARAAARAAARAAARAAARAAARAAARAA ARBgTZMo5KoF2mVvg8j3kO+ekD57OTKTItUU6aKqbECFoOboKyAAAiAAAiAAAiAAAiAAAiAAAiAA AiAAAlkRcKp5CmeeEx983PnA487GjaKnhwykaHO9clmUyG2PPPik6ZTcjQ8HCIAACIAACIAACIAA CIAACIAACIAACIAACDRHgDzzSP1EKqfq6rIorYpSxSmVKIaUp34iSyk2j6JIUqSSwgECIAACIAAC IAACIQI3x5967vWldQ+Fqnny1rqvJSoIAiAAAiAAAiAAAu0kUMgL0jqRZ16lRDZRpI1yVkusn2Kd FP8gDaRo273uDCG1NPXFpz7x6fA5PuvyW3z9sP/TSzc9pFHpG6nT6jMQnnC17WaqrFljcqwV8osX FsMlcH9qzFd7vSHfDPqQXuatl3wmh6eSvYCYyhZ9nXNpYGKqVZiJXSsHMrXl0fUivkPpG0HvyoD5 GhLR0u4Rgdeqq5vk2F43tYteztKF52qTUrh72A+ftnQJZciog65W2mBO45TqOzkTkFOuMlLcaVOd Hwzy21K3TDLR9LpQKyuTVUTr62b44BGTXtOh5JheSB0mlmkxw48uHH35YJ//mFX7f11PyKQ12igk zGH780fvHG9WJ1U3UoImC4aSrN7sSRpEPLLcsRNawyRcjWSypDGw1oxowwwQfhwnfqZHP+vr+7l5 XrVakkUv+ZIvvVIsG1I8T+vLY5p54makxnpZl9/AP3qZZFritnF4IysQAAEQAIHuIMCWT5WKWC3n VlfF6mqltFIpr7KFFKmjeMM9eVBcc7KR6o4Ch0vRd/iVt2//IDgvHiuK4hZeFtOjbt+1ndPyp+nR hVFvGWRM31g5kkCLbFfC7UtHxcTX4vQvvII8IXbuDcmKypGe1kEhb79yqF+9cenCiQlRLDaUS3Nd m2+TrWWQScuO4wvHLrlUxdn9sboYU9mMZY5iYqpTPROLVvZF6stj6EXcu0bFabfjTey54veuJpmv odtb2z3MeO26ukmO7fWIVyN9N+g79IY/KXH38FXkwnr4tKVL8OvKgbMDXn++/YKYdE1dlNLePrPr ctx7eP/BKR4RZ3YJsWuCqz912FNQUKuF5L+5xmxMInqdW1N5BhO4qfW1jbnHx56AsLE3eDmeDj96 2tJ5KBM5/R57Ifz88vqACyfoCe0qUmM+Nvq1qFL2HXp5dOjy8dgHX1xNY9qdlDhjlynNyW2uoGJx 4XzTBmj2SxpTLfQj2jwDiL1nvGEyMXBuX025Fkep/nfb547dkiyGT+Kll/2ywbZekktjeUwzT/SM 1CDHuvyG51rMMsm0xLXtFEgPAiAAAiCwHggsP6ouPxKlZdZMkTlUIe9s2MAWUrTPHllIUVxz2n6P FFJljmve7cetV8/O7TrC32mX3rw2v3fEWyL3HxzZO3dusvEtqJZeU7N37s6Lgf5+95e+/kExf+fd KAA3x8fEmbffOOjdoU+q5njrpdGZXRN1eij/tpuvnROjLx4ZqBfTeD1RvpYtZ5J588aV4uiL7nsm UxVXolfJRjkmVpFMTJUwsfLSR7aym8ZQTmMv4pW3/6qwfccuMXf9zWTGYpbt0KXJW909THhtu7pJ ju11UzMk6QabtgyJhcVFt5tZDp/2ND8Nnznl1Vf0HRqXU+jUZG2wi62nJvaIyzc841Orgi2+Pnm5 eHTaHy8k//BWKwEdTmzb69Tiqq0fU42tX6CvKekIdxTQ0tTX+VHlKx87Wpa2ZN5/8MVjxZgHn0VB dO2++PrXzgplyJC44Z2D195yp5HUh+2SxpRRMyN6+0n6apiSnu1zJ9HIVZYH0XwSL72slw229fIW LYYlovuraeZpvN5QL/vyG55r0c/HmGVb6l6OG0EABEAABNYiAefxJ5wP/QPx4Y9UP/S7zm9/xPmt f+g8/mGKKkUHqaUctp+qUmjztRDSnN+gxJ4d27kZlu7Mqa3RN1gUd96p0xmo6TVNR8b5xZkx1zae Vgz0TjUS+R61/eTb4zEvWqEcF99Z8EvbkLvUy0jNWvjQXU+Qr3XHNMicvTYjBjd5peJVqRBzd6M0 Maayma5HMTFVwsTKSx/Tym4qQ3mS9CJrtuvghlZ3DxOiVnT1FjcHL+6Lw0/3czbWw6fFZXPFc6n2 7vAMMWo5Lr11da422Ok6v8nM3PB9n5MXTSWQ/K4uStlEr2ui7o3OktLvpt5ZMs4BSvWiCnk5aZwx JfPg+v5zoUeoqUG4nww9u63hUaVLz4UZnw28eMJ+Z6pjl+8qyFUmWyTpvBZ4cJs51Ml3PUnJkIT9 Z7k682f3ez74taxNrl5RHPqeGR6aa1o9ZOzieouzp4cH9J89JM9EzpW2SxpDCZvo1Syxb/OAUOlZ lF+/xDLOqwlGbmh5EMXHYullvWxI8zyNW/Yozx21GRvaTiPHtvypnmsx5e+i+R9FAQEQAAEQaAsB 2l9PcOTy3Ac/5HzgiWrvB6uFD9C/Aw0UWU5V+CS/vu4+5Mr42PPum9W2YfqeP+lFZeLvjY2L61B6 XdXYzvn04MQBWgqzY47BlMkCSjhH+hxX3CKCGFjK6pwXSXvPnJKatdBiwnDdoghNJx0afJLX+FTs fXdHpkeHmhYYEmBmYsrHxMpPH9vKURVI0Iuk2Yso7nwm0RtZtrS6UFr23SMrvCY5ttdN0OvleC+0 B8jSoRZbR2TPp9lOsLR4xytVoyS3tN7Rv6nBXDNR3vx6E2ixE92xlhJdGfWChYU1AvrWj6wYW2r4 zy/SodzY4XkCsiufFN536EjISI3eA4caHOVCWbDrzcSA51R4SQl+pJVPt7LrjQjSN/qLayrw7r05 /ewXkFHjHwkxM3Z+y0XXtXOu5gUfdgELufiRnMlBdhK/eEycO0Hfh6I5zIx5XrSX+HsS6+BcfyX6 pxhync3pfMP92KPW98zA2f1+I8Zx6N+2szh3751MOqra7ixwkSzOBs9onBy37xi4OtucIW42S5pm RzSrtjM+0s6rdcsDI5+4ZUaoOhkuG0z1MpfHNPPor2vlpCh/PP/w89GKZ8Z9BeJAAARAAAS6kUC1 vFwtr1REqfqbX1Ye/TpXfuhUH7KOiqOY5ytOzsnnNlTLOXLb6+5DOp6MBI4DbBkuKFoBfxE9IUbI G6LuqEuvqRx/WR27M0qr59N7Z8aSB9g2cQrnuHRvQcxNTIoXghhVB9wv2K65fqM1lul6u5vlXY44 c3X4YuCzll0BjExMWcQyiW/lyNLH9iKOkkAGJr5zaHYo1qykTLtHVnhNcmyvm/thQzfYesp99Z0e vh6KmZIpn2x7Sch0hRQN2Upff9JCkVnI+kbRSZlavxECPVlclRbH5vPVECQ58HDcuiOIDMXewb6R mnSbitaDS9eb4MOGqsfRy3edNL/Q8CEkquXYplV/KNG1fqB8XNlz2lMGKfUSt25cpphTQZXDAvd6 2hlpWSMNcqM4BM6nsr4NZtEh0dKF1q8vu87NS41PQg4L95rRDmnbnUo3c07z8cwt9dYdgxOvNpoo kn1N0ihdWS9pMhnTFuWPyC/VvFq/PDDwiV1m1JUry2WDrl5R5THNPLrrJjlpyh/Jv+45a8szk24G ISAAAiAAAl1NwCkUKGiUeLDs/PKn4hfvVn/51+K9n+doWz25uZ4sulOtVstkI9XN9Vi6cJ4+F3vm UW5Ba5Gt3zgo6r/Sa9LXV88NrSJXz9vGSSc1Jz/Ppj7qc+TldRCPSfnqOzupCRBLuZqupy5Quhvn zx6//uwl7wszx1zI8jAxMeURxyRBK8cVP7IX3Xpp38R8cfRinKtmXCbr5/dMu0dWeE1ybK+bmimy nG6otWteALtM+WTWbbzoePLNkIL0S7lPbi6Go+ax6qG4eVOqTKP1AqlEdtdN209SQHFNkMFw6+vK HAS3DpkFqf5rY+QZ7R2sNHH7UijOi4FFneuNdLr0DoN80RlbtkhP7V3DviM8909XaZWYQ6RHufv9 gy2g5XlA1QS13KZP3+5C0HW2ZdO64G0bGV3wZ5I0/T/DJU0zIzrrZQOhSDWvNiwPDHzilhmapshq 2aCtV6LymGYe5XqEHNvyR/Kvfz4mKn+a/o17QAAEQAAE1jCB937j/PLvnV/+olLKVVed6nKp8uBR jpRPbCElBEU0J389inFOZxdXklcSEZ+L5QfYYF1L9YhJzzXl1aq7YZ88OApVM4c2x7rlMmfHRa2F uiDrG7liPjz1J4brTajI7KsjIdTM0BiRJvqMvVz1Dg0Tk0ATK59Jgla2KWtdL6KvqcfpA/tF74O/ jaR1mjbT7pEVXpMc2+umNktUTtejIVM+WfWhvqef1cbS5m0cVAMT1oAEmzwor6N182RjsdgBpIUB d7Li0KQc9nw0HSHPxyT53BxnT09vg1f6FlK7h6MXsSs6uRrprGijhQeKALP8GJOiJIVPmcYP/J/s 9iQcYnsmZ0UTuLJLr+/KF+r5phINbG6RmzZv5KffwZZcBe/ceCsZosZUWS1pmhzRHHLID6uXtiqh +1LOqw3LAwOfuGVGTB3SLxsM9bIoj2nmkdcTyokvfyT/xudjwnwz6RoQAgIgAAIgsFYIVFYflR8+ ENXVfLVEZ6FSzq+u5MoVMomqlumo8B+knCoLqaDqzkPG5TW5TXE8iLqQTJHpvSpKB4HAQp4DPahf j70vzKEwsVFsNDnKCJqTHByEDg7xKEPD+pbV7iqZrBXkinnq8B94HkD111u0JtbXpe/wCPmMeGWW kblUNZ8tE00eeiZewgb5Jlb+ZvOGXpGqnHW9iJZZ+2lvKWij1EbMrnukwatrVpMc2+tcSxv5ChW5 H4LrWhXNp1NTq1sqb/cGpRBkjjFUi/JTi3QTjugsr0fHtOZBPXdunxthmkFemGrc8LRTtc8mX95p bk6364XS+ilzYgnKrXLH2OuTr10XXqT8CLEyFsxxCgpee8SEjYj5uiJfjTY9ezJZUHMZTanZPUal EDsD5HgOdZuryn1ywzGYZE/WOMHFc1icvT7XYC3oerwmXhJE9Qfanmxiz5XRxoj1pD5euH41fGvi oODRSxrqCUnL38SIplmU94dRwuq5+SYKym5Alm5ebVySGfjELDMix3VTywZDvZKVxzTz1K4nkZOo /Gb+2udsknxTTpa4DQRAAARAYM0ScMrkl5d3ChvKToWd85wq/V+OzKHon7ky77FHJlKkkSK3vW6t o34LvGCXHBmlVXWqSrJlHtWVHAR4UegF+CCVVswmev5+Rvz+cPk4r+2COOX6HCmQBwdSbQggYsk5 Il9LSbXkRplbT03zx1suswyX2xh5PZSnSY5RfkZMvBetuI0Rg7Iay2PoRfxxlXYYrLl7POXt6JSa +Jq6sdXdw4TXtqub5NheNzVOXDl5mIT2Q7AcPm3qFPSGcOmo8DszWWW6h3wr9q01lQhHfH3AC8+n Rj7yWuf4FSHcadN/yaRBLSNMe75RXxfPxOxG2qZ6J8wmfnIgb6+B2q4X6sZ26XbD8F745aPn/Jaj ioUUFZnUTPOXZwbUPVhNJQw/wmoxqkzyldgxFEdctcwyo2ILu/mzr/naxlpCNah5nLpB9pCgByZT T2g4cOa12Ez03FcfT9vGOYy656DnPpqpJ0+PLvhh6Ws9No6Dfps51yPy8o1GFAk7WigZO4GSGrde J0Uv/wNzaaO7RS9pLMpvGNHGGcBfEbFfpDJSbLnYPndsl2SZLfkslw229TJxM8081jOSZfnpM6p2 Wfg+XybZdm+kBwEQAIH3NQEOWl4oiN686P1AueexSu9jYsNjzqn/4bu8z97q6kq5tLpaelQqrS4v X96w9UuF7z33h182AfvOhfOfO3TkfY0TlQcBEACBdUSAv3LfOxKnel5HFe72qpBFCeu5DCHAO1B6 NqNQIrK3qwSNHHhXwbsjrSbDuVzbOd24624au852wUqSz1ovf5I6Ig0IgAAIgAAIgIBK4Cff/+7H PrM7EyYkavfu3ffv37eSNnF+6lulz/7NG8dktKiq4+SdXEE4eZErUDxzP3YUBZGS8aMq3R3U3Krm SAwCIAACIJCEAPs6XTkvLUroVTwTj6Qk2SKNnoB07m70vOskLs8+wvcNbE9ROsVh6cIJ/a4jgv34 RIz7anvYpMtlrZc/Xa1xFwiAAAiAAAiAQBcQyPWISsERPUJwKHOKX84ue+SmRzGk2F2P/kbaKvpn 13rsdQFDFAEEQAAE1ieBbeO+OxV56apbQ6zP6nZtrVw/mk7YIsUicWMeuVrLlh8d5UBeSINnpg7X h26cPen5sDf+1HIeWWSw1sufBQPIAAEQAAEQAAEQ6BQBZ+Pjzgd/23n8d8Rv/a7z2//I+dDvig/+ jnPiX/9bGT1qtcTH6qPl1ZXllasf3A6XvU61E/IFARAAARAAARAAARAAARAAARAAARAAgeYJdInL 3s++O+7kekUuXy1scHp6OK55qUS2UtWyqJQoihSdgv6srNIFHCAAAiAAAiAAAiAAAiAAAiAAAiAA AiAAAiDQNAFSQIlK2SmXxep71Qf3q+/9Sjx6kOPAURQ9igNICfrJ/TsOEAABEAABEAABEAABEAAB EAABEAABEAABEGiegFNacUqPROlR7tFDUkWJ1RXHETkZ5pytpRyKKEWqqGpOiELzmUECCIAACIAA CIAACIAACIAACIAACIAACIAACFSXH1ZXH1XLj5wy+elVRY722cvlBJ203V4ul5faqYqTc0hPhQME QAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEmiZQLXPw8qpTrZAFVJ7c90rVlYekiMoVcvl8npRTTr6H /l7JC8SQaho2BIAACIAACIAACIAACIAACIAACIAACIAACAiyiKrmyC6KYkaVS4LOlUfVB7/OkXVU 3iErKf6PjKR6c9UepwpcIAACIAACIAACIBAmcHP8qedeX1r3VKiaJ2+t+1qigiAAAiAAAiAAAiDQ RgLV8oooLYvlZfFg2Xm0KiikVHk5l6c455UKaary1VyBzgqbSbWxVImzWpr64lOf+HT4HJ91b198 /bD/00s3FYm0pgxuiV5DJ08ZiHczrVuzRsjRpF+68FytRqGShyr1xQuLfq6mmibGqE+orYu49ZJP 7/BUsheQOCb6OiZc9ytsTa2c6LqJlV5+RBvZ82mymTp1e0u7R9DVG7tBrbcrQyAagnuLP9ijJo0I Odr6Jphk6rt3p9orMl+FiUq11pmDOY1Tqo3CA0ROuQoKd4JV5weD/K5koS2Uvrf7ta7vpckmgTpi CWc8TfGU6Si9kDq5LNNihh9dOPrywT5PRmh6rOsJa6fJ3ZKGOWx//uid483qpEztHgwlmfHsSRpE PLLcsRNMI/zP1Lq/FEuatdZgKC8IgAAIgAAIgMBaI1ClLfTK5UpplYJEVWlDvRJ55uVyZA6Vo4jm Dp1O3nEKPeTE15U16zv8ytu3fxCcF48VRXELL4tpzbfv2s5p+dP06MKo/5ZF12np7F6/femomPia SauSPKVPhleQJ8TOvWFSZjn69KLv0Bt+jSb2XBn19WsklVaTQaVuv3KoX2Zkqmlz7WUoG71oHV84 dsmlKs7uj33ZNjMRp92G4zrW3oEN+Roqw2x1cmyvm1iZ5BjbyJpPc63Usbtb2z3cl7HGoWQaAjEY li6cmBDFYpDKOGmY5Ri7sXGS0XfvjjVYVMb8yn3g7IA3Hm+/ICZdUxelM98+s+ty3Ht4/8EpHtFn dgmxa4KH9tRhT0FB9ELy31xjNiam3pjFKNjjY09A2NiI3iPjdN2jp029TY6vYy94zyM/U7cPuGfQ E9pUIk02Nvq1qFL2HXp5dOjy8dgHX1xNY9qdtE5jlynNyW2uoGJx4XzTBmj2S5q4WuB3EAABEAAB EAABEMiAQJXClhdEodch3z1H8P9ERe6yx+58Dnn00Q+FvENnBpm1WMStV8/O7TrC32mX3rw2v3fE WyL3HxzZO3duUr4FvXN3Xgz097sF6esfFPN33tWXKnlK9/6b42PizNtvHPRkB0JNckzp1dJs2jIk FhYX3Uu3Xhqd2TXh66H8ZMaaNsPaVLabN64UR1903zOZqrgSvUo2yeF3V3+pvX3HLjF3/U35CpyE iVovkxzb6yZWJjmmNrLl00wbdfDeVncPYzfQD4EYEjdfOydGXzwyYEhWmzSMcgzlMQ69JN2mg81X lzXxmVNefUnZOi6n0KnJ2mAXW09N7BGXb3jGp1aFX3x98nLx6LQ/3kn+4a1WAjqc2NjbDRN+yklg 6xfoa0o6wh0FtDT1dR5fvvKxo2VpS+b9B188Vox58FkURNfui69/7axQhgyJG945eO0tbyVgIT2U 1HZJkzYf3AcCIAACIAACIAACNgScSjknygWn4lDcqIKTL5AyinbXc6pkGJWXO+4V6J+CLKW6XiHF b1Biz47tXP2lO3Mqhb7BorjzDus8yOS+ODPmWrzTmwa9KY0Y3o6Sp3Rz2n7y7XGdKJMcU3ql3PzG Wxx+ul9eWnxnwa+dWjVjTW16QX1aQ9lmr82IwU2e2QO/ZwoxdzfKbS9BHUNZ26Zvpo4Z3au2kTWf jMrQbjGt7h6mbmAYApHVlzosqaTWHuqkYZRjKE9Lhl6721Jwp927wzPEqOW+9NbVudpgp+usHJ+5 ofo+JytqaBJLdkt3pTJO7PoJP6NJoNFZUvrB1TtLxnmtqt5hIW8+jTOmxB5c338u9Ag1tQn3k6Fn t5nGV+g2Lsz4bOA1FvY7Ux1pfVdBrjLZIknnNTrdypo51Ml3PUnd9J/g6syf3e9569eyNjlXRnHo e2Z4aK5p9ZCxl+stzp4eHvA+29TdKHkmcq60XdJ01zhEaUAABEAABEAABNYrgerjGyq9hXJPvtyb L/f0VHp6qxt6c0JqoKSFFJ3krUcaKrrY1YdcGR973n2z2jZM3/MnvShL/L0xWFyzd8PpwYkDtMBl b696gyOlislTRnNJIcdbDR+gz6RBYA76vFncIoKYWf6S2lzTlrTW0OCTvManYuy7OzI9OtR8JmRQ IIo7n0n0RhOVm0mO7XVTHvVydG0kRPZ8mifcRgmtrb5hCETUj/VNe8+ckkpq3RGaNGw5JRp6WXVv 28IlTb+0eMfrtI13uK3pHf2bTDZm0Vmx2i7QYict1dpOl2oUsKWe//wiHcqNHZ6/G7vySXVD36Ej ISM10nwNNTjKhcCxN/fEgOc6d0kJfqSVT7eyk6YI0tecXCOa4917c/rZ+8qoNhLizNj5LRdd1865 mr982Kkz5OJHciYH2Un84jFx7gR9SYrmMDPmOXFf4i9PrINz/Rnpn2LIdTan8w1XQ63W98zA2f2+ WieOQ/+2ncW5e+9k0kvVdmeBi2RxNnhG4+S4fcfA1dlkURtNBUuxFMmkjhACAiAAAiAAAiAAAhEE co897jz2AdH7gVzvRtGzoVLorfY+liNlFKmiyECK/fbWxiEdT0YCx4HtJ3n9uk+uiU+IEfKG8A7+ Xjp2Z5TWxKf3zox5H121VUyeMuaNLHGOgZytp9x18/Tw9X1eNNOlewtibmJSvBBEvzrgfvE21rRF 7fYuR5y5Onwx8LlrJh+OakEGGr5zZWpRJjm2100F0MjRtJG8O1M+qYF07MYWVt84BMytxp4vJhNI uqtu0rCFFjv0suretgVLlz5kukKKhnRScJfVJEDPIFdxw7H5fDUEKQ4CD8etO4LIUOzd7BupSUfI aD2+dCkNtLGqHkcv33XS/IJRe6trWTZa1B9qDClFI7zntKcMUuolbt24THHHgiqHBe71tDN9mwc8 g9woDoHzqayvaxZtOqRzpV9fdp2blxqfhBwW7jWjHdK2OxV05lzt41ldubfuGJx4tdFEkSz4kkbp ympJgzEOAiAAAiAAAiAAAlkSePCoUKpucPIfyG/ckOtxKHh5lTz2yD/P9dHjEFL0b/biyzLXrGUt XThPn4s98yhXeC108RsHRfCV3g2YItfE28ZJJzUnP7rqjuQpoyvTjBw3TtM1VjzxcjyI3xT+Sqyv adaIXXnzZ49ff/aS94WZY1I0c9x6ad/EfHH0otbV0UKwSY7tdVOWkeVU2ihrPhYIuiRppt2jvk4R Q0Bb/dlJTaxlJaVm0rDFGDn0suretoWyTu/F0ZNvtrTJgLz/yc3FcHw9Vj0UN2+yFs43ROsFUons 5ptsRkEQ3DpkFqT6r42RZ7R3sNLEfRyE4pcZWNS5lEqnS+8wyBedsWWLdMXdNew7wnP/dJVWiTlE epS7Cm62lZbnAVUT1HKbPn27C0HX2ZZN64K3bWR0QbZ+yqOZpUjKLHEbCIAACIAACIAACMQSqK6s iJWSs1qpCIeDl/f0iEKBrKKqVbqV/mPNlPyjq/VRvNKK+FwsP8DKdS2vQd1t+OTBsaVMq/nEKaMZ J8/RJKfmOFO3vFYq4t9bq2lsy6dIIHHVzNC4aproMwkF09fa4/SB+qL3wTzhXY3JTHJsrxs7QpJy um2UKZ/UQDp2YzuqHz8EgurzWKhFjSFDPPnyWXvTi5k0bDHWDb2surdtMWzT9z39rDaWNm/4oCqS WAMSbAehKJjq5rfG7NmxsYUBd2zr2/L0GYyCm+PsrO1tBUtfTWpl5uhF7IpOrqaRpn/aWgbfD8zy O6c6DPbuSNRASTjE9kzOiR5Ayi69vitfIhXqwOam3cz1deWN/PQ72JKr4J0bbyUipEnU/FIkbc64 DwRAAARAAARAAAQiCFQ39q7mneVq+aEorTiVCumiKIp5tVrmkzRSpI2i+FHVqkOmUl17yLi8Jrcv jgcRxJGRZv+B3TuHbzB9E45O6X1hDoWJNawuE+eouV+GXff8MmRE0kkOJkIHh2puCCUbqmkrGqvv 8Aj5jHhlkJG5ap+v3cBS9Kk5ARMZaHY/7c1kpY3SyTfJsb3OtGzkK3SVNorm04oW6SqZ2XUPQ7Ui h0BD8/k+le4LJxn+yJfPIDiLadKw6cZBOeuGXpru3ammdFvN2+dBKQSZYwzVovzUIt2EIzrL69Ex rbnV5s7tcyNM8zi7MNWElUenMCXON+NJgKcXJW+5Y+z1ydeuC3+zC3PBZIyz4xQUvPbICBsR83VF vnzkebG6Z08mC2ouoynpg20nJiakEKOpslZOPIe63TPljrrhGEyyJ2uc4OI5LM5en2uwFnQ9XhM9 /uLQ0DadE3uujDZGrCf18cL1q+HbEwc1T774iSsffgcBEAABEAABEACBDAk4Dm2tR9qmcnV1ubr8 UDx8IB49zFWkdRQppCqkl6pUObZ59+qj9JvlBbvkyCitgVMYmf3zUs8L20GKKv3WeEQ4eUq3Ofz9 jPj94fJxXpu6ccdNckzp1X2RQmHXKfAHB15tCDhiqGkzncRUNtr9fZo/3nIZZLhcc7joSCZsnEI7 9NXcJZ5yd0Qy5muojEmO7XUTq7hyModQG1nyaaaNOnhvq7uHUb5pCNiziN5hs06esTyGoWfqNvbF bMsdpLm7dFT4g5FMydxDvhX7JmZKhCO+PuCF51MjH3mUjl8Rwp1gfWM0ajUZYdrzjfq6eMawsWlb amudSdxEXT/h206SjQXyVHjyIXV+y1HFQorSkppp/vLMgLpxZLJHTy1GlUm+EhON4oirlllmaGxh N3/2NV/bWEuoBjWP2wNO9pCgBybbM07DgTOvxWai5776eNo2zmHUPQc999FMPXl6dEEJvu6VM46D fuNI1yPy8o1GFNZdTi4bOJ7AvnqdFKk7B+bSRnezXdKkKTfuAQEQAAEQAAEQAAFbAk6J/PXKolQS D38jHrwnHr4n3vuN8/V/PV2tkNtetVKuViplp7qyurL8Pzqf/lLhe8/94ZdNeXznwvnPHTpiWwKk BwEQAAEQ6E4CbO1170ic6rk7y74uS0UWMawEN4QA70CV2TxQicjerhI0cuBdBe+OtJoM53Jt53Tj /rxryS6yXY2EfEAABEAABEAABLqZwE++/92PfWZ3JiUkUbt3775//76VtInzU98qffZvLv1LClxO mieRK5AhFP0/6aFyUg9F1lH0r5JwSvQXUk5ZSUdiEAABEACBtU6AfZ2unJcWJfQqnolH0lpH0sny S2ftRs+7ThbJMwv1fQPbU5ROcVi6cMKwVQL78YkY99X2sEEuIAACIAACIAACILCWCDgUJooiR1Wq vIseOe/19ojeDRRDyvfQo9/Zew8HCIAACIDA+4/AtnHfnYq8dIMtz95/HDpdY9c/tBO2SLE1d2Me uVrLlh8d5UDeuINngjh0QV1nT3o+7I0/tZwHMgABEAABEAABEACBtU2guroqREUUHIojxconChZF x6n/7t+6UaQq5VKlUhKV0urKyoXcU3DZW9utjdKDAAiAAAiAAAiAAAiAAAiAAAiAAAi8vwl0icve z/7Nl52eHmdDT9XpZX0UeeY5IkeHQw589FeRr1bzpKJ6fzcWag8CIAACIAACIAACIAACIAACIAAC IAACIJAZAecDj+c3Pt5b+IBTKedLq/mVldzyai6fY5upgsjlHVHI0R57Pfl8PrM8IQgEQAAEQAAE QAAEQAAEQAAEQAAEQAAEQOB9TOC3Nzz20d/58ODvP/nP+gf/6T/52D/56D/94G9/JFetUJxzjwoZ R1Gwc2kthQMEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEmiXw6Nc/f+/v/voXf3X37/9q6dEv/25D vkrmUuSvJw8Kbk66qBwHPM9z0HMcIAACIAACIAACIAACIAACIAACIAACIAACINAsgeWVB7/8zS9/ +ou//dnf//Xf/uZv3yv9alU8Ipe9XC4vKIoUOeqR216PPJvNCveDAAiAAAiAAAiAAAiAAAiAAAiA AAiAAAiAABFwcpVcruLkyr09D0TlZ7/55S8f/JpCmrNpFFlF9ThOb14U8qKHQpzjAAEQAAEQAAEQ AIEQgZvjTz33+tK6h0LVPHlr3dcSFQQBEAABEAABEACBNhLIVQS55OVzhfxvf7jwwQ+VK06ZFFSk oirkaXc90klVCxTXnEObd6WF1NLUF5/6xKfD5/isy2/x9cP+Ty/dVJCarjdSp9VnIDzhatsVXrdm NclRrodKqE+/dOG5Wk1D6UOV/eKFxYz6j7Yu4tZLPpPDU8leQOKY6OuScN2fgKGJbX2+Wmx6+RFt Yc8no+Zqt5iWdo+gSzd2g9r4TdzV3Vv8IRw1aURA1NbXNJmYumW7GylpfgoTlWqtMwdzGqdUG4Vr KqdcBYU7barzg0F+0uJ1OF10a4Z7lyxqskmgjljCGU/DQpmO0gupk8syLWb40YWjLx/s82SEpse6 ntDhprTOPsxh+/NH7xxvVidlavdgKMlCzp6kQcQjyx07wdOK/5lwNdJY2eSLH2tQuAEEQAAEQAAE QAAE0hGo9GyobnisumGjU8kV6H+km+rpJfWUQxqonnxuQz7XS1cK+Z58IV0Grb2r7/Arb9/+QXBe PFYUxS28LKaF175rO6flT9OjC6P+W5bpunbpRotsV8LtS0fFxNfi9C+8gjwhdu4Ny6IctXL4ujjt Fn5izxW1hPp8+w694deU0/t6N8qNFrJBZW+/cqg/A+b6uvCL1vGFY5dcquLs/lidjpmJru7uKryR oalCUQxNbPX56nMwyRemtrDmk0FTdUJEa7tHRDdI09WXLpyYEMViwMk4aZhJGruxaZLRDu1OtFSC PPmV+8DZAW8uuv2CmHRNXZTOfPvMrstx7+H9B6d4NjuzS4hdEzxTTR32FBRELyT/zTVlY2KcBFy0 9b0rxC1+ktzjY09A2NiW3nR0uu7Rk6Dts0giCRx7oe654/YB9wx6QhbZpZNho1+LyqHv0MujQ5eP xz744koZ0+6kdRq7TGlObnMFFYsL55s2QEu++IkrPX4HARAAARAAARAAgewIOBsfF70bK4We1Qe/ Xv71/crD96qlZVJIkY8eOes5vYUeOguFXL6nKy2kwiBuvXp2btcR/k679Oa1+b0j3hK5/+DI3rlz k/wWZLquAfrO3Xkx0N/v/tLXPyjm77wbxf3m+Jg48/YbB707gqQmOfz+5i83t+/YJeauvylfA5Pk u2nLkFhYXHTzuPXS6MyuiWz0UF6pTXW5eeNKcfRF9z2TqYor0atkkxxT3U3pTdxNcmyv28pX06tt Ycsnu3HcVkmt7h7GbpCqq9987ZwYffHIgAFRbdIwMjSUxziZmLpfWxspcWbEZ0559SVl67icQqcm a4NdbD01sUdcvuEZnyaWzQkXX5+8XDw67c91JP/wVisBHU4c3ZqNvSvlJLD1C/Q1JR3hjgJamvo6 jy9f+djRsrQl8/6DLx4rxjz4LAqia/fF1792VihDhsQN7xy89pb3xLeQria1WPykzAG3gQAIgAAI gAAIgEAKAk5FiFJJrKyKSqW6uiJWS5XlR7keJ9eTz5Miiiyj8oU8xTXP57s+iBS/QYk9O7YzhaU7 cyqMvsGiuPMO6XtM1zXkyDi/ODPm2sbTGym9U41EvkdtP/n2uC6BtZz4fHllWRx+ul+WevGdBb/W Kdpff4uhLrPXZsTgJs/sgd8zhZi7G+W2Z2JiKqht+swqnF6Q2hbWfNJn29E7W909TN0gTVeXOiyp pNYe6qRhZGooj8Vk0tHmis6cO+3eHZ4hRi3p0ltX52qDna6z4nXmhur7nKxSockq2S1rJ5Wmd2U0 CTQ6S0o/uHpnyTivVdU7LOTNp3HGlNiD6/vPhR6hpjbhfjL07DbT+ArdxoUZnw38H8N+Z6ojre8q yFUmWyTpvEanW1kzhzr5riepm/4TXJ35s/s9H/xa1ibnyigOfc8MD801qx4yd3K9xdnTwwPeJ6u6 OyXPJM6V62O+WjuTA0oKAiAAAiAAAiCQkEB1+ZFYfuSUSo7ICafgFDY4Du2xR/qnfN6h4Obyfz0F 8t7LJ5TYqWRyZXzseffNatswfc+f9KIp8fdGb3Ftuq4rNPtBnB6cOEBLYXbASW2ClEAOfVQXxZ3P uKv6iPTeKvkAfT4NAnaQRVVxiwhiaaWOLpGs3YYGn+Q1PmW37+7I9OhQsruiUoXq3oQ4kxzb66Yi 1MvRtYUQ2fNpAkn7b21t9e27Ouub9p45JZXUuiM0adjiSjSZZNW9bQuXNP3S4h2v0zbe4bamd/Rv MtmYRWfFr8GBFjtpqbo1Xbg1Tb0r1ShgSz3/+UU6lBs7PH83duWT6oa+Q0dCRmqk+RpqcJQLgWMX rYkBz3XukhL8SCufbmUnTRGkrzm5RjTHu/fmgidXKNmVUW3Ew5mx81suuq6dczUv+LBTZ8jFj+RM DrKT+MVj4twJ+j4UzWFmzPOWvcTfk1gH5/oz0j/FkOtsTucbroZare+ZgbP7fbVOHIf+bTuLc/fe yaSXqu3OAhfJ4mzwjMbJcfuOgauzyaI26guWaL7KpE4QAgIgAAIgAAIgAAI2BCoVUZXpCwXh5EXV oTPXQyGj2EQqTwf56+VYSWUjtANppePJSOA4sP0kr1/3yTXxCTFC3hDuYbquKTF/WR27M0qr59N7 Z8a8z7MpahYnh2OUkJGC72Aov+ga8t16yl1PTw9f3+dFOV26tyDmJibFC0GsqwOZxbXVVvZdjjhz dfhi4G+YAklwS33d08oyybG9bspfI0fTFvLuTPmk5dG5+1pYfeuu7nq+RBg21k0attRiJ5Osurdt wdKlD5mukKIhnZT1e1dda0b1ruSjgJ4sruKGY/P5agjSoQQejlt3BJGh2LPbN1KTjpD+Nww9c+mi FWhjVT2OXr7rpPkFo/ZWlwsbLeoPNYaUohHec9pTBin1ErduXKa4Y0GVwwL3etqZvs0DnkFuFIfA +VTWV5pFGw/pXOnXl13n5qXGJyGHhXvNaIe07U4lnTnnfzxrKPbWHYMTrzaaKJL9ZsIoXbHz1fod u6gZCIAACIAACIBAFxOo5nKkinJ6egTFiHLITIrspMgaqoesoshrj6Obk6UUXeefu/hYunCePhd7 5lFuOWuhi984KJSv9Kbr9bVzQ6vI1fO2cdJJzcnPs/ZHjJxbL+2bmC+OXgzc/ZLk68ZvusZRsXiZ HsR1avh6bF/cmDvmzx6//uwl7wszh7tq5mioe0phJjm2103ZR5ZTaQu6P1M+KXF08LaWVt+2q89O amItK3A0k4YtusjJJKvubVso6/RedDz5ZksbLMj7n9xcDEfNY9VDcfMma+F8Q7ReIJXItt9U35oR vctmFATBrUNmQar/2hh5RnsHK03caT8UD8jAos5FSzpdeodBvuiMLVukK+6uYd8Rnvunq7RKzCHS o9xVcLMFtDwPqJqgltv06dtdCLrOtmxaF7xtI6MLsvVTH0kXP6kzwI0gAAIgAAIgAAIgYE2APPIE eePl8mQXlSOrqA0b8xs30m57tMueyOcqdBZEJU9pulohxUqciM/F8gNssK6tMTJd5xS8WnU37JMH R6FKdUTKIWOo4/SR9qL30dgu35pDTd2yWyl2qiIbb5IQamZoXDVN9JmEeWrqnvDOcDKTHNvrpswT ldNti0z5pILR0ZvaUX2Lrs6juxY1howQ5ctn7U0vZtKwRVk3mSTqNrZ5tCB939PPamNp8zYOqiKJ NSDBJg+KgqlufmssITsKtTDgTguQaEQ2tqaxd2UwCm6Os1O2t8ErfQupFYijF7ErOrmaRpr+aakE 3w/M8junOgz26EjUoEk4xPZMzokevsouvb4rXyIV6sDmRIGzEtUnlIg38tPvYEuugnduvGUvUXdH 1OInmxwgBQRAAARAAARAAAQSEaiWK9VymU6KJFUpLVcqq3TmaIs9MozK05/SZorCSJHXXiJ5HUkk 4/IGLm91ReB4ELo4Mqbr3u3SQSCwkOdAD+rXY+8LcwLnOLMcesnZT/sTqdooVmpE5usVTgZZ9/w1 ZND0SQ4yQgcH2U0aYta+qfoOj5DPiJeXjMylqvmSM5GBZjV1jy6RTr5Jju11ztlGvlJSpS2i+djz XmN3ZNc9DBWP7OoNzef7VLovnGT4I18+g+AspknDphsH5aybTNJ07041tttq3u4NSiHIHGOoFuWn FukmHNFZXo+Oac2tNndunxthmsfZhammrDzaDkrbmsbelfEkwNOLUmO5Y+z1ydeuC39TCzMOGTPo OAUFrz0awkbEfF2RLx89Xqzu2ZPJgprLaEr6YNvJ20kKsTNAjudQt3um3Cc3HINJ9mSNE1w8h8XZ 63MN1oKux2uCJUE8GNrYcWLPldHGiPWkPl64fjUsIHFQc+W2mMVPfAmRAgRAAARAAARAAAQyI0Ab 6OUoalS1IirLorxcXXlIYc7JWc+hvfXoT/ba4+hRtBdf1x76LfCCXXJklNba/nem6w3VIwcBXhR6 AT5IpaXfRC+4z9/PiN8fLh/ntakbX9wkhw00aJe6msvAU+6uQKb06n5JoSDrFBCEA7I2BCJposFM daHd36f54y3nJcPlmsNFy9xNckx1N+ZrqItJju11E6q4cjKHUFtY8mmiiTp5a6u7h1F+dl09yb6Z sUO7tiVZeJIxdZtOtllE3qRbuXRU+BMRmZK5h3wr9k3MlAhHfH3AC8+nRj7yWu34FSHcadM3RqNW kxGmPd+or4tnIrcr7TZK1q3Z9CTgqfDko+f8lqOKhRSxITXT/OWZAXXjyGSPnlqMKpN8JcYQxRFX LbPMbcIWdvNnX/O1jbWEalDzuD3gZA8JemCyPeM0HDjzWmwmeu6rj6dt4xxG3XPQcx/N1JOnRxeU 4OteOeM46DeOdD0iL99oRJGmR28/yVEC9tXrpEjdOTCXOrpb4sVPmhLjHhAAARAAARAAARBIR6BS WuFzdVkUNlZFoVrOVat55zvTtyi4eUUe5XKZ/lhZWT7xzuCXCt977g+/bMrpOxfOf+7QkXTlwF0g AAIgAALdRoDtg+4diVM9d1up13F5yCKGleCGEOAdqDib2ygR2dtVgkYOvKvg3ZFWk+Fcru2cbtx1 dy3ZRbarkZAPCIAACIAACIBANxP4yfe/+7HP7M6khCRq9+7d9+/ft5I2cX7qW6XP/uy1P+KA5Q7F Me+tUjApCmCeY/+80GElF4lBAARAAATWBwH2dbpyXlqU0Kt4Jh5J6wNMZ2ohnbIbPe86Uxg3V88i zPcNbE9ROsVh6cIJw1YJ7McnWucv3x6syAUEQAAEQAAEQAAE2k6gsPEDPR98oveDv1PO9VbyvZWe nnJPLxRSbW8HZAgCIAACXUhg27jvTkVeupqtIbqwyOuySK6/VSdskWJxujGPXK1ly4+OciD/zcEz QRy6oK6zJz0f9safWs4DGYAACIAACIAACIDA2iaQ791Y6Okh86iNv/V44fHH8hsfcyii+fTMD8hj r1p1pMNeuVRaIZe9/3ZxAC57a7u1UXoQAAEQAAEQAAEQAAEQAAEQAAEQAIH3N4Eucdn7+bePOdVc RVRpR70qhTfnCOa0qx5tr+fkgwaS/nvv7+ZC7UEABEAABEAABEAABEAABEAABEAABEAABDIiUF55 WFp5r7T8oPzg15UHvxYP3hOPHnlRpDiWlOe9x7GlMsoRYkAABEAABEAABEAABEAABEAABEAABEAA BN7XBKpVMogi66hCdWO+uqGn2pMXeRnWPJej6xTmvJLLVRyn6uQoIQ4QAAEQAAEQAAEQAAEQAAEQ AAEQAAEQAAEQaJoAaZrozBdErlDNFcpOTyVHQaRytO8e7b0n7aLkCQOppklDAAiAAAiAAAiAAAiA AAiAAAiAAAiAAAiAABNgbZRTEPmcU5ZnRVQqfImsouikBBRUirRTZeHAQgo9BgRAAARAAARAAARA AARAAARAAARAAARAIAMCTq5H5PJ0VgqFaoE0UxsEWUiRYoq0UtJrTzru0YUM8oIIEAABEAABEACB dUbg5vhTz72+tM4q1VgdqubJW+u+lqggCIAACIAACIAACLSTALvlsXdeNd9b7X1MfOADuY0bWf/E qqh8NZ8j4yk2kaIU7SyVTV60RvzEp70ztCa+9ZJ//fCUulQ2XW/I1CjZXLzF1w9TpnVrVpMc5fpL NxWZrhB5hq5TktpPX7ywGC6G+1OGbwXauojE9ILSxTHR1zHhut/E0Pa6qUn1cpYuPOd3ufo2sudj 09m7KG1Lu0fQ1Ru7QcQQMNEJD42lqS/WZgxvoI3PxpLV1tc0VE3dLzaXDiVQmKgTS60zB3Map1Qb hWsq6SkoXLzqrGuQ36HaZpWtbmK36F11xBLOeJrCK9NReiF1cllm+LkZ+dQbXTj68sE+L0loeqzr CVmxb5ecMIftzx+9c7xZnZSp3YOhJOs2e5IGEY8st0cFT0n+ZzNP+azm7XY1APIBARAAARAAARBY 9wRYz1Rx2HVPOOS4l8/lCvSf3FzP3WRPnnyhK1HQ6oqWwtM/ePs2nZeOiomvebonepU6vnDsEl+f HhVn9/vrOdP1htoZJRs58AryhNi5N5zAJIevi9Nc7B+8PbHnyqj/HkjX913b6dZoenQhuE5SacEa /HT7lUP9akZLF05MiGIxq0bS14W1UVqqKZjo6u6uwhsZmsRHMDSx1V63lS/6Dr3hdjm37QJ1hjWf rNqrzXJa2z0iukHUEDAxqB8afYdf8dpOtuDFY0VR3OK/S+uFGIe2dqiaumWbGylpdvzKfeDsgDcX 3X5BTLqmLkpnvn1m1+W49/D+g1PM88wuIXZNMNipwx5UoheS/+a6sDExTOyWvWuPjz0BYWODetPR 6bpHT9IO0GQ6Ob6OvRB+Hnl9wB1oQU9oMqcmbrfRr0Vl03fo5dGhy8frP6JYlyym3UnrNHaZ0pzc 5kouFhfOZ2CAltW8bV1d3AACIAACIAACIAACRgLVcrlaKdOfTmmluvyg+ui98upDVke5KikyjfL+ 0aUWUu/cnRcD/f1u/fr6B8X8nXf5rzdvXCmOvui+EfUfHNkrrrjrOdP1RkAmySaUN8fHxJm33zjo lSVIZpLD72/+cnP7jl1i7vqbXMClN6/N7x3xFvdc8rlzk+77262XRmd2TdTpofxsbr52Toy+eGQg m65uqktyem45THIMdTemN9XKJMf2uq18Nf2mLUNiYXHRra+h12XTKl0jpdXdwyQ/eggYB2b00Lj1 6tm5XUcC4w6dFEN5jEPV1P26pgFDBaGpY0559SVl6zjTWJqarE2hYuupiT3i8o14O7LGOi6+Pnm5 eHTan+tI/uGt3UnCrlSJHhAJepeX69YvkGI0HWG7cmecemnq6/zo8ZWPGUvvQnH9B188VvSWExkU T9fui69/7axQhgxlM7xz8Npb7lMm9ZHVvJ26ALgRBEAABEAABEAABDQEnEqZTiH/dFZXxaNH1eUV 9tgjTRT/x7vtkdMeq6W6kh+Z0BdnxlwLdlpv0ZvPCL/tzF6bEYObvA/0/EYkxNxdSmO6rqmbQbKR wvaTb4/rXrQs5SzdmVOz6BssijvvcO0W31kQe3Zs1+YvdVXRL9VWrWeoiwU9NzsTE1NhbNNbVao1 iVkrURx+up+lW/NpTZFaLrXV3cPUDaKGgKnSMUOD1S7GYeXLNJTHOFRb3gBZZsCddu8OzxCjJnjp ratztSmUrrPideaG6lmcrBTqAEl2xxpJlWBiT9S79NVtdJaUfnD1zpINjtt10lTvsJA3n8YZU94a XN9/LvQgMjUK95OhZ7dFGxh6N3NhxmcDP8ew35nq6ui7CnKVyRZJOq/R6VbWzKFOvutJ6qb/BFdn /uz+Btf+WL9+DYe+Z4aH5ppWDxm7ud7i7OnhAfeTVf0heSZyrsxq3l4jAxTFBAEQAAEQAAEQWCsE 8nmRL3DEqHzByeerFOCc1VCCDKIch/z4+O+utVR3KqSk89TpwYkDtGBlb6yaAdHQ4JO8GqWAC/vu jkyPDvkNYrre0GBGyZZNm0AOWdaI4s5neFW/bZgsESa9+FD8pdR/LaAP8sUtIgh/o6zm+bVn75lT el2VZWHjkiemFyco+F2pe+J7dAlNcmyvmwpRL8d7kzlAn7JrwVNE9nyagtLum1tbffMQMNUzbmjI 1+ljzzeoYxJxMw5V9e6suneiEqVItLR4x+u0jTe7rekd/ZvSmV+y2i74NpCigN17S+zEbtW72JbK 74qkQ7mxw/UIls6SUt3Qd+hIyEiNNIlDDY5yIVrs/T0xIN0n2Z+9FvxIK59uZSdNEaRP5P/97r05 78lV11BXRrVR9mbGzm+56NZrLvCvZ5WT4tQZcvEjOZOD7Hp/8Zg4d4K+PEVzmBnznLIv8Zcq1sG5 /oz0TzHkuvDT+YZrEanW98zA2f2+WieOQ/+2ncW5e+9k0jXVdmeBi2RxNnhG4+S4fcfA1dkWhY1v 7bydCScIAQEQAAEQAAEQWLcEqr091Q29dFbyPZWeXtFLm+6Rdsp30GM1FO3Bx0eXKqT4++fYnVFa 457eOzPmfUR1m+tdjo1ydfhi4BnntaLpel0jR0i26g5xcjgWCRkp+G5620/yynufXM2fECPkxyGP pXsLYm5iUrwQRMs64H7xds37pV1YW46E9JKVpa7uyW7SpDLJsb1uKoBGztZT7rvN9PD1fWrs+Uz5 pAbSsRtbWH3jEDC3WszQkN5qI6m9jQxDtVacrLp3e1ozZLpCiob25Lp2c4mb2BP1LnpmuYobjs3n qyFIhxJ4OG7dEUSGYs9u30hNOkK63zBMh3QpDT5UqHocvXzXSfMLVh822GhRf7hxxNxT+Viy57Sn DFLqJW7duEwxp4IqhwXu9bQzfZsHXDNnEcUhcD6V9XWNi02H9LD268uuc/NS45OQw8K9ZrRD2nan gs6cCz5B1Rd7647BiVcbTRTJ7imDKF0tnLfX7ghHyUEABEAABEAABNpDoFoSlWVRXs6tPnJWl51S RVSl8smpkokUH/n2lCNlLm4AFLnG3TZOOqk5+RGVj/mzx68/e8n7FsrxPrzDdL2+AGbJdkWNkXPr pX0T88XRi4q7Xy0s7hsHhW9fwMvxICqW8pV4dlITUNauhDapk9JLJFNT90T31ScyybG9bso8spxu hLJrXpzmTPmkgtHRm1pafdMQMNU4bmgsXThPNiYpzaPcTLVD1S9PVt275S3qxd2Tb7YUpF/m9+Tm oh+Pz82fVQ/FzZtSFSZaL5BKZOdvipnYE/auILh1yCxI9V8bI39z72CliTvVhOKXGVjUuZRKp0vv MMgXnbFli3TF3TXsf2vh/ukqrRJzcBVYJj7yGw/bVsvzgKoJarlNn77dhaDrbMumdcHbNjK64D9o su3/LZ23sy0qpIEACIAACIAACKw7ArlHpdzDqvNQlEvlKp8lp1wiEym5uR6ppeRRFYLObjzYaELZ IYsjLslD/qVm+8DJZJwU0/XGupkk21KIlEPf2I/TR9qL3kfjRtny03GwIq9bXnPFOUEtNAZZWskV dqKIErY1saGXQHZs3RPI4CQmObbXja8tcW3EN7ouD8l7V8K6ra1k7ai+ZgiYIMUNDVYoxNiY2PAP D1Vjt7QR2Y60fU8/q42lzRtEqAYmrAEJto9QFEx181tjkdmxsYUBd9rBSJtHzAOimd51c5wdgb2t Y+krSy1/jl7EDt3kDGhvFRt8lTHLjzEpaiFsf1+IZFkk4RDbMzkrevj6ZlyKK1+o55tKNLA5UeCs ZBVSU/FGfsq+wMpP5Cp458Zb9hKj72jHvJ11mSEPBEAABEAABEBgHREgRVPFKVTzG0SPe+arFFGK LKQ4inkQOKrKRzfWWprxB3bsHI7B/cbbd3iEvBsmOfSG69Q256p1TNcb62aS7Kb0vjCHwsTq+Zjl kMZkP+1PFKGNoogeteBQMoauVyO53ZgMJes7jrmrarJukCvsFm2zHU0vOROpRYquuwamTr5Jju11 U5smKKcMpe/6ziTvXd04lpouU3bdw1AU/RDwEjd0j5ihIYN5+36ySoY23Ti4jYPOKHHcEnSbpmln JcBtNW9fCEUomWMM1aL81CLdhCM6y+vRMa251ebO7XMjTPPceWHKMyfMqgodkRP9gDD1Luui8vSi 3CT3Xb0++dp14W2kECFQxjg7TkHB5SEfGY32gIp8WSMvVvfsyWRBzWU0JX2w7eRVlUIC0+ZE98Vz qNvfUO7AG47BJHuyxgkunsPi7PW5BmtB1+M1wZIgvoK0TefEniujjRHrSX28cP1qWEDyoOaGjN/n j6345kAKEAABEAABEACB1hKoFgqixxG9Tr7Qm6Po5nQ6hRxpn+RZLVerFXnSX1pbkJTSyYyfl25e GA56J/S3utt6apo/M/IaUQZ29cNYmK435G+UbCipv58Rvz9cPs75unHHTXL4Ezrt/VdzGXjK2xUo 2PdHxpetufJR4A8OvNoQcCQluajbTHUh/ZeeqiUTU92N+Rrkm+TYXjexiCsnt0UolL4lnxY0XTtE trp7GOVnNwSUHTnjiRnLYxiqxqEdn1UnUpDm7tJR4U9EZGXpHvKt2Le+VCIc8fUBL8idGvnIo3T8 ihDuhOzbaVKryQjTnm/U18UzbQt410qcEQ8Iq97VWEZPhScfaue3HFUspCgtqZnmL88MqHuqJnv0 1GJUmeQrMdEojrhqmWXmyBZ282df87WNtYRqUPM4i13ZQ4IemMzCV8OBM6/FZqKnp7rRx7ZxDqPu Oei5j2bqydOjC0rwda+ccRz0G0e6HpGXbzSiSNMLt5/k+AP76nVSpDwamEsb3S2reTtNfXAPCIAA CIAACIAACJgIsGNepSIqK9Vymdz2nErZqVadGzf+nIykqqKyWq6USqWVlQfLjx59eX7Llwrfe+4P v2yS9Z0L5z936AhYgwAIgAAIrA8CbO1170jo3X59VGyt1oIsYlgJbggB3oFasXmgEpG9XSVo5MC7 Ct4daTUZzuXazunafr5+hdeSXWS7Ggn5gAAIgAAIgAAIdDOBn3z/ux/7zO5MSkiidu/eff/+fStp E+envlX67M/+5zHeSc+hUOa0m16e3PToz1ylKkrVKgU4L1eqdLJqqkstpKyqjMQgAAIgAAIWBNjX 6cp5aVFCr+KZeCRZ5I6kdQQMnned5OSZhfq+ge0pSqc4LF04YdhFhP34RIz7anvYIBcQAAEQAAEQ AAEQWEsEnJ5e0btRbPhgbsMH8r0fyG94PFf4QI622mM3vUqF9FGkjKrQv7o1rPlago2yggAIgMDa IrBt3HenIt/nYIOFtVWH9VBa1z+0E7ZIsfTcmEeu1rLlR0c5kDfu4JnGEI2zJ73IAC2K3thyqMgA BEAABEAABEAABDpGwMn3OoWNTmFDT6634PTmRU9O5J3vXf8zVkZR9KhKif6ysvpwZXn5X/5kEC57 HWsoZAwCIAACIAACIAACIAACIAACIAACIAACTRPoEpe9v7vyYpV206PqkE9ehTz3yHfPyZUphrnn o0chpWSA86YrDAEgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgwGqo1VJlZbm0/JCjRQkKaV6mM1ep sEZKiApHNq9WnCprqnCAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAQPMEnHw+v2Fj/rEP0p+FDY8V HvsgnTnhlB1BJ1lLVRynkq86heazggQQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQECJXKOQKPaLQ 01Po6e3d+Fjv449v/O1cLkd+fK6FlMjRzntkIiXd+nCAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiA QLMESqXy8nJl+eHKygoFL8+VqxsqOdJB5dhXT4aPYkUUK6fgs9csatwPAiAAAiAAAiAAAiAAAiAA AiAAAiAAAiBABEqVaoWjmufKK6srK6ullUel1Yc5MofiEFJlGc+cdVGUBgcIgAAIgAAIgAAI1BG4 Of7Uc68vrXssVM2Tt9Z9LVFBEAABEAABEAABEGgjgUrvY85jv5V77InCb/1O7wcf79nY09OTy/Xk 872FXL6QI1c90kqRkVQXRzWnNeInPu2doTXxrZf864enwkvlxdcP00+xK0ujZHMDaSXr5SxdeM4v 9ic+/dLNBpmuqLpVvnuRzy9eWFRuSVgjq56ll2mmahJuKlv09cY6RhQ+zGpp6ou1LuHhGp+Nrbu2 PDXg4TZS2lTTdrF5rYMELe0eEXiturpJju11U3vp5UQMbfvh05auogwZdWKplTaYLTmlOnMyATm4 lJHijj511jXIb0vdWpNJ1CSTcHKoIxb7PDJWROlv6YXUSWeZ9c/NiBl+dOHoywf7vASh/l/XE1rT Gq2TGuaw/fmjd47Hrxyii2Nq92AoydtnT9Ig4pHl9rTgKcP/TK37Mz3O7PlpRrRhBgiPlPC6xT5f b56p7+cWi72EI1cDOWJJVleeFMuGFM/T+vKYnjv2S03r8hv4R8+EWp4pugRuAQEQAAEQWPMEco89 Vu3Nlwo9Gx7b+Nhv/cONH+7r+Ug/RZDigyNIeUeOVVLdeNAjjZbC0z94+zadl46Kia95uid6QB5f OHaJr0+PirP7g/Ucr/NOiJ1742pjlGy8US/ZKKfv0BtusX/w9sSeK6N1GpOlCycmRLEYyoye7vuu 7fQq+8qhfu/HpDWKq7H6u0GmkapJtqlsxjIb6hhZ9npWfYdf8cBKvBePFUVxi/+ypJdkbLsA+PTo wqi/mOY2Fadrbdf0ItumabohbWu7hxmvXVc3ybG9biJuLKdpaFsPn7a0Nb+uHDg74PXn2y+ISdfU RSnt7TO7Lse9h/cfnOIRcWaXELsmeNxNHfbGHLVaSP6b68HGxDjJ2E0Oe3zsCQgbe4PX307HPtRa 0p/k9HvsheB55Gbi9gH3DHpCS/JPJNRGvxYlsO/Qy6NDl483/REipt1JaTJ2mdKc3OYWplhcON+0 ARr1TO3jLBHAUCL9iDbPAGLvGX+pM3Bun+7zW7Iy2D53tOkjR652MekWTrMky2rZYFsvQ3lMzx3L paapnxhnNsNzLWYm1C1xk3UDpAIBEAABEFh3BHK53p7CY7neDe9teGI5V1h9+N7qL/+K1E+Cw5h7 BymjOIhUVx7v3J0XA/39btn6+gfF/J13+a83b1wpjr7ovhH1HxzZK66467mb42PizNtvHPTuiKiT SbLpFpPkJHI2bRkSC4uLiuibr50Toy8eGVAu3XppdGbXRE0P5f2UvEbJG9Ak00TVlomxzIY6Rpdc w0q94darZ+d2HQm+3utkGcqz9Oa1+b0j3osW96K5c5PyXZpX3v6rwvYdu8Tc9TfXv7dKDVyru4cJ r21XN8mxvW7qfkm6gTq0bYdP8gHbTEoaPnPKq6/oOzTOg2VparI2hYqtpyb2iMs34s0MG0uy+Prk 5eLRaX+8kPzDW5spb1feq0wySXqFpg5bv0B683SEO0pkaerr/KjylY8dLUtbMu8/+OKxorecyCBD Xbsvvv61s0IZMpTN8M7Ba2+pKwT7rI2PM1tRzYzo7Sfp+1BKerbPnUTPC2XkRi/VGpcZWS0bbOvl tlf0sqdxSenelWCpab3sMT3XomfCmGWbbadEehAAARAAgTVNoJrfUN2wodrTIyrvrVQePcpVHzmP UQwpzx6KQprzyVHNu9NCikzoizNjrgU7PdfpzWeE33Zmr82IwU3eB3pePwkxd5fTbD/59niy1yGD ZGNrmyQnkMMrgOLw0/2BbKmXqdOhLL6zIPbs2N6Qf/IaJe+oBplGqibJRiaGVjDVMarkOlZKen6v 1nJTZRrKuXRnTk3VN1gUd955P2meDNxb3T1su1Pyjt32lOrQth4+bSktl2rvDs8Qo5bj0ltX52pT qPcmM3Oj0bM4rpANk1vcDWvw90STjF29Gp0lpd9NvbNknG2m6kUV8irSOGPKAgbX958LTX6m0nM/ GXp2W7T9qXczF2Z8NvDiCfudqY5UvqsgV5lskaTzWuClbuZQJ9/1JCXDFnaN5+rMn93f4NpvcvWK 4tD3zPDQXLPqIXN30FucPT08oP/sIXkmca7M6nHW5Iju2zwgVHqJy29avDWz2AuN3Kilmm6ZkdWy Ic3zNG7ZU7+k9LpbkqWmbT9J9VyLKb/dZInUIAACIAACa55ArqfHyeUpZlSh97HqxsfLvR+sfuC3 WSFVs47qUlWUh56tkU8PThygBSt7UdUMiIYGn+TVKAVc2Hd3ZHp0yLqpjJItJUXI8Va9B+hzaC0A h7RN2HvmVJ3uiT7fFbeIIDpS6igSlqWvS9401cjs7euoZxV+rx469nzD+3YiCtuGySpk0ovVxV+t da9o9HlQFHc+k+iNLFGuazlR9t0jK7wmObbXTa1TL0c/tLPn02xvWVq8I9xSNR6h6/2bVHPN5Nny 603wbSD5bWsppVTKaCcZi97Llhq+ENKh3Njh+buxK59UN/QdOhIyUqP3wKEGR7kQNna9mRjwXOcu KcGPtPLpVna9EUH6sL+4oUHevTenn/2ujGojJM6Mnd9y0XXtnAv861nlpDh1hlz8SM7kILveXzwm zp2gL0/RHGbGPGfqS/ylinVwrr8S/VMMuS78dL7hGsyq9T0zcHa/r9aJ49C/bWdx7t47mfRRtd1Z 4CJZnA2e0Tg5bt8xcHW2mc8hiR5nCerU7IhmI52Mj7Tzat3INS7V4pYZoeok4pxsZjDVy1we/XMn UDQnWWqmKH88/3B9rXhm3FcgDgRAAARAoBsJONUKxYrqFaKQ63HITa9azlUrHDHKVUrl6C9SIRXY THVbJfj759idUVrjnt47MxYK9f0ux0a5Onwx8K6yK3uEZCtBEXK2nnLXx9PD14PACq65vrTzUo+l ewtibmJSvBBEyzqQWfxaq+o0STUqL+s6GljV8pDuSCOp3UnYv0BQzAv+rn5CjJBPTd3BURLIwMR3 67MCuT4TZ9o9ssJrkmN73dRkGjm6oc23Z8on2y4UMl0hRUO20tevNNMkk6j30jPLVdxwxENfDUEv xoGH49YdQWQo9g72jdSk21S0Hly63gQfNlQ9jl6+66T5hUYj3IimY5tW/aHGkFI+ruw57SmDlHqJ WzcuU8ypoMphgXs97Yy0rHHNnCM4BM6nsr7RBq3S1civL7vOzUuNT0IOC/ea0Q5p253qNnNO+9mD kWzdMTjxaqOJItnXJIzSFfs468gYTV7+qOKlmlfrR65hqRa7zKgrWCznRDODK1RXr6jymJ47FktN skSzX/ZE8q+rry3PjnRLZAoCIAACINBWAtXSSqVSKpUrTmW1mhPVnl7Rs4GVUfSfYijVnf56RMoN gCLXuNvGSSc1Jz+i8jF/9vj1Zy9530I5OoDlYZZsJyiJHDfK1TWOTzQ7qQkQS9d5OR5ExWr4SmxX pCZSN0s1MmvbOppY+ZksXThPRgQpzaNcIbUAqG8cFPW2Hrde2jcxXxy9mNAJtAnsa+XWTLtHVnhN cmyvmxohspzK0M5gUmpNP/Di7sk3Q9pgQWby5OaiH4/PzZRVD8XNm1KVYD07upommYS9NwhuHTIL Uv3Xxsjf3DtYaeI+JkJxXgxtUud6I8PHeIdBvuiMLVukp/auYf/bDPdPV2mVmIOrwDLxkd942LZa ngdUTVDLbfr07S4EXWdbNq0L3raR0QXZ+qmPyMeZjdRmRnSKxVhc0VI9dxpGrmGpFrfM0BQuq2WD tl6JyhN+7tSKmGCpSYltyx/Jv34mTFT+uBbH7yAAAiAAAuuLwEZRzVdFmQ4n7+R68rlcvlLJkf6J okjx/7kH/7sr6802NcoGahzlRx7yLzXTGE6miZMSVSWTZFsMyeVIs2f+VlwLdUHWN3LF7C1P65bX cTvH2RY1Nn3zVGOz8L6BB+mi6hjJiiTw+jJDZzr5GT94O+LQJMfpA/tF74N/fM3WfYpMu0dWeE1y bK+bWi9ROV2Phkz5ZNWb+p5+VhtLmzeIUA1MWAMSbB+hvI7WzW+NxWIHkBYG3MmKQ1o5+kkmUa8w ZnlznD1rvN1U6StLLSFHL2InYnI10ljRxtQhUASY5XcuRl54T4+41kjCIbZnciY0gftbASqufKGe byrLwOYWuWnzRn7qvsC1ApCr4J0bb8XBSfZ73eMs2U0yVZMjmkMOhSJmWmStTZpyXm0YuYalWtwy I6b46ZcNhnpZlCfSFzuhnPjyR/JvnAkT5ttsr8D9IAACIAACa4rAhwqPPV7JFZZL+eWHPb/5pfPL v3V+9bekiWIXPXlKXRRdyPHWe113SDP+wI6dwzG433j7Do+Qd8Mkh96gb/sc/UdRJSSqhUmye7P3 hTmB01y0HK8oMhy79L/wLavdVTJZK8gVM7tyyIibXo0o+MXoTNJQsomqmyhRNNXkTIyZRdaxQb6Z lcxARmvWONOlKidHFVECe9Eyaz/tLQVtlNqU2XWPNHh1zWqSY3vdNOQTlLM2tDOYlBKNUstEbqt5 +0Io95I5xlAtyk8t0k04orO8Hh3Tmgf13Ll9boRpnjsvTDVl5WFZv9Ym100yCXpF8kJx/1FSy70+ r0++dl2om2DoxclYMMcpKLg85COj0VxUka9Gm549mSyouYym1Oweo1JIYNqciE08h7rNVeUOvOEY TLIna5zg4jkszl6fa7AWdD1eEywJ4itI25NN7Lky2hixntTHC9evhgUkDwpeu6/ucSZ/SF7+JkY0 zdK884wSMdPNN0lQdhO3dIu9xpFrWKrFLDMiW7OpZYOhXsnKozx3QiVMstQ09hP9zGbmr02frPzx gwQpQAAEQAAE1hOB3/mtJ36np/fDPT0fKK30PnxQfbS8Wqk6N9/6kaiWq9XKSqlM/nyr5dKjR4++ /OP+LxW+99wfftlU/+9cOP+5Q0faTocWNGRJ5B57z9Q20ZMhXV1PPYpn4YWxUC56t0QYuZgkS4UU W/gbsquXrJUTKom67boCkG6kELA1Gxy5vpG/U3xWL+CIVY0SNk6ETC1VKdaCSVSZdXU0yVerU8eK mS8cna4FuQ/SWpRTRr11gde6EP1DbVBPrqEFEwJfW8la3T1MeCO7uqZZTXJsr5u6X6JyhjuGefh0 tAvIN4cgaFQwJSoVrE044f4fMREpt6jyi9pR2dHqp81cO8kknxy4M9wd0YQ4VHAVR48OTlwfDMJL eZNPaDqKGBf6FjTK9waRfL6M3NlP0cQ10bXDtOQtA6dDtQh3p+BpFa4vBTJX5Idu8XsOX7x3xH92 17WSrFoEh9BPfG9tMufPPO5TNYwu6LHRHPhXik1ZZxvriUrwIDC1O9eINmbxYmkRH9bdTL/y9Jtq drIW6qJFcggNT2N3NjzO3PTJyy+f9sqM4Y/ohn7oliqAKbNp4JO8/LbPnZhxoVsemJd8HlR1mWGU b7lssK2XadljWlJaLzUtyx8eR7Vxl2QmrF/ipp2KcR8IgAAIgEBKAj/5/nc/9pndKW8O30aidu/e ff/+fStpE+envlX67H/z1/9+ZaVUqlZWy6ulUuVRubJK9lBvvfXnQpQrFbrKAaZWSivLy8ujf7mp KxVSVrVGYhAAARAAgaQEIpUCSYUgXXYEwmqL7OSmlsSvr0pE9tRyLG9s5GBU8FlKjk7OuVzbqfnU kallXKZFTiZsrZc/WS2RCgRAAARAAARAoEagSxRSn/j5zVLFqVZF74bHKlVRKpdL1aoXQ0rus+fk utNZD30JBEAABECgxQTY1+nKeblTBL2KZ+KR1OISr2vxBs+7TtZ566lpQ8yjFpaqUxyWLpzQ7zoi 2I9PtN+PPjPGa738mYGAIBAAARAAARAAgXYTcMq5fDWXI53USi5fLvSIDb1OruKIqiwIh5DCAQIg AAIg8P4ksG380lEhNyPbNzFQC+r//oTRwVqTIRJtBtcJW6TYSrsxj1ytZcuPjnKgSNiDZxrdGMm9 jkfHRGirxJaTyC6DtV7+7EhAEgiAAAiAAAiAQPsJFES1x6kWcqJHVAuF/IaNvRs3bnDe/A9/7oiy oCBS5epqufzg0UNy2evWGFLth4YcQQAEQAAEQAAEQAAEQAAEQAAEQAAEQGBNEugSl72tv7xezfcK h1VS+Q9szPfkRaWaY/Moto3i/+Q/cIAACIAACIAACIAACIAACIAACIAACIAACIBANgQ25J2NhdzG DT2PP9bz+MbC4xucD/Y4rIMqVxyKaE677FHIc9JR8YkDBEAABEAABEAABEAABEAABEAABEAABEAA BJomkCs4FDTqgxucJ36r5wMbnA09uY0bc7mqe5B0+YcXUKrpzCAABEAABEAABEAABEAABEAABEAA BEAABEAABDb25Pks5Ao5jiRFIaXozElNFB8VUS1XK1Vy3UN0c3QWEAABEAABEAABEAABEAABEAAB EAABEACBLAg83pP/IAWP6slRaPMNOac3n8s75LLHqijy0nPtpGr2UlnkCBkgAAIgAAIgAAIgAAIg AAIgAAIgAAIgAALrkMBXvvKVulo1XnETPJbPb8jneymMFAWTIoWUoO32HM9CihRSvNOeVE6VXd89 HCAAAiAAAiAAAiBQI3Bz/KnnXl9a90SomidvrftaooIgAAIgAAIgAAIgkAUBVQNl0kZRPht6ChsL 5LKXLzgiT455FTqly15wkDbKDSfVrQetET/xae+sWxMvvn6YfgqtIJcuPOcn5ru+eGHRXK8Iydqb lPQv3VRT3HrJL+HhKWXRrpO/NPXFWnW8u8ZnWVhEyQ3ym2wxDT2SaJ+XXo4Q0ddjW0etnSvKb30z w0gi2vK4F+UZalNjWzcJfe3c3tLuEYHX1G2shqRJvm2z6tOHhmqiqaDTza4MGXVKrA32YBbllOqM ygTkBKWMFHe8qHOdQX6nq91E/lGTTMJeVEcsvaZD6W/phdSxYJmhp1UEK6rI6MLRlw/2eWnqHlWJ 5TTRHC27Ncxh+/NH7xxvVidlavdgKMnKzJ6kQcQjy+1pwTTC/2xG95fVvG0grhnphpkhPIIiV2JJ Wte2Xg3pE45oDfzw8sMrbFbLCdt6BVNxrZOYnkcRzylZicZ6WS+H4pe+4eejId8kHQBpQAAEQAAE upSAq4eK0EbRr48V8hsKbCHVQ856OZHPORQtqqaQkg57gmJIdatOyl0KT//g7dt0XjoqJr7ma3x4 PXdC7NyraZxdE256Ol851G9oPbNk/Q2cXpx2xU7suTIaLLDokXx84dglvj49Ks7u9x7ABvl9h1/x y8aiLh4riuIWf6EvdCU3yG+uUxroWedlagVj69CifN+1nV6DmlsnVLulCycmRLEYXItmqAWjLw+1 UVCY6dGFoE2Nbd0c9LVzd2u7hxlvxKDWwDPJsb1uahdjOfsOveHPMDwVuAplOqyHT1t6BL+WHDg7 4M1dt18Qk66pi1La22d2XY57D+8/OMWz35ldwpumpg578xa1Wkj+m+vBxsQ4ydhNDnt87AkIG3uD 199O6x52re9Ccvo99kLdk1R5VP0g6AmtL4wpBxv9WlQp+w69PDp0+bjmLdqubjHtTsqRscuU5uQ2 V2yxuHA+AwO0rOZtU131I908M4i9Z7zVzsTAuX3hTz42PG3rpU0fOaL1i0xZxvrlB13KajlhWy9D eUzPI9N1F31DvayXQxFLX+1S2ZCvTU9AWhAAARAAgW4i8M1vftMtTqCNCq7UFbOX40aJAv3ZSzop h04Kby532eOt9aRhFKuoujao+Tt358VAf79bq77+QTF/513+683xMXHm7TcOer+kaByTZJMoXnX5 y8ftO3aJuetvyte6mzeuFEdfdN/N+g+O7BVX3JVlIvm3Xj07t+tI8OVZl7dJfooqB7eY6NnmZZRj ap1bL43O7JpIqIfyi3vztXNi9MUjA4YaJ2GoL8/Sm9fm9454L1rcdnPnJuW7tKmtm2G+hu5tdfcw DiXLQW2SY3vddsir6TdtGRILi4vyku3waU+XoOEzp7z6ir5D4zzhLE1N1iYusfXUxB5x+YavWbMp 2eLrk5eLR6f9uZHkH95qc/+aSKtMMiknh61foG8P6Qh3lNDS1Nd5+vWVjx0tS1sy7z/44rGi9xDP IENduy++/rWzQhkylM3wzsFrb7nTSOojq3nbVIBmRvr2k/TtLSVV23olWhwqIzp6qda4/DDIt15O 2NbLbZfo5ZD6PDI9pwxy7MtvWPpGz5Axy7nUvR83ggAIgAAIdISAqoEyaaOoYHmnSp56tLNeDx/5 noKzoYeCmnNA8wrrpJyqQxZTVT678iAT+uLMmGucTM9vevMZkW8720++Pd7ca49JsiWG2WszYnCT ZyrAKzYh5u5yaRPI53dCsWfH9qgsjfItyxlKbqBnnZepFUzXF99ZiKtvQ7WkDsuss0vC0NRblu7M qdn1DRbFnXfWf5yU2J7T6u5hKkDzgzq2alkn4EV8cfjpfpZrPXyyLoxWHpdq7w7PEKOWYumtq3O1 iYuu85vMzI2QJ3Ki8qkEEt2wBhMlmmTs6tXoLCn9a+qdJeMcnVRvqZA3n8YZUxYwuL7/XGjyM5We +8nQs9sCG96oWnJhxmcDf8aw35nqMOW7CnKVyRZJOq8F/vVmDnXyXU9Sz9WdqzN/dn+Da7/JAz2K Q98zw0NzTauHjKT0FmdPDw94n7jqbpQ8EzlXZjVvG0re5Ejv2zwgVKqtq1eC50hoREct1XTLD4N8 6+VEmvaKWw4pzyO1GRvaTiPHtvypnncx5bebRJEaBEAABECgKwi4eqgIbRSX0qnknAqrpXIFspOS CilpIUU/uSZSpJaquKZSXXmw1fHpwYkDtGBlj7lExjVXRr2oQJHLuDSSPURkCiGKO5/xVulDg0/y uphCP+y7OzI9OuQlipUv1/rHnlffFbUlN8hvSXO1Ni/6FFncIoIoWgkiZfDCce+ZU0adnYZhci7b hskqZNKLMsZfrXWvaOG2Ti58XabMvntkhdckx/a6qdnq5XgvtAfI0qEWW0dkz6fZbrS0eMcrVaMk t7Te0b/JZIIYXQR+jQk08s2WtjvvN08yFr2XLTL82Z50Ljd2eE7l7Monn1N9h46EjNTofW+owVEu BIhdbCYGPP/0S0rwI618upVdbESQvuYDHYH93XtztSedmi54VIWj782Mnd9y0XXtnAv51ytOnSEX P5IzOcgO7xePiXMn6MtTNIeZMc9x/hJ/qWIdnOuXRP8UQ67jPJ1vuEbHan3PDJzd768H4jj0b9tZ nLv3Tia9UW13FrhIFmeDZzROjtt3DFydbdHnkEzmpWZHOqu8Mz7S1qtuRBuXanHLj1B1MlxOmOpl Lo/+eRQooOueU1o5Kcofzz88Q1rxzLivQBwIgAAIvH8J/NPfEZmcEQRjtFF0p8M2UBXpppcjdz2K bp4v0N/doFEUPIr/kB58XXrw99KxO6O0xj29d2YsOkg5VyHkNk+fTM06KVvJPiCOIUJGB76rF19+ l6O0XB2+GPj08cU4+dKVZqTmChFRcq38FjVYC/Naurcg5iYmxQtBRLAD0TF6XdcG1yZOe9QztGTC fgSCYlvwd/UTYoR8auoOTVtbZrHekmfaPbLCa5Jje93UWBo5W0+5r77Tw9dDsVEy5ZNt5wmZrpCi IVvp61eaaZJJ1HvpmeV+HeE4g74agqb6wMNx644gMhR7gvtGatI9KvjmoYUrXWwCZb2qx9HLd500 vxBpkNswAZJNq/5QY0gpHwz2nPaUQUq9xK0blynuWFDlsMC9nnZGWtC4xsURHALnU1nfaINW6ULr 15dd5+alxichh4V7zWiHtO1OdZs5p/3swUi27hiceLXRRJHsaG43H6Wr++alDtarfkQblmqxy4+6 kZHlckLXXlHlMT2PdNdNctKUP7Jf1c2QtjzX7yMFNQMBEACB9x8BMn4qy5O89HJ5kcuxTiqXE1Xy 0eMt99hpj6iQTqo72bgBUOQad9s46aTm5EfUZMf2kxQF1os51XhHSsm3Xto3MV8cvag4DM6fPX79 2UveV1mORyCPGPlLF87TB/CQeVStjOGS6+UnY2CbqqV58StHEG+r4Ut4Y1FnJzXBdJVkkQyT1bwW 6PSNg6Le1kPT1smkrttUmXaPrPCa5NheN7VaZDndsHHXvDDemfLJrBd5c6B8A6QNGaTcJzcXw3Mj u9MWN29Klel6dnQ1TTIJe28Q3DqkU1D918bIy9s7WGni9qVQPBdDm9S52EinS+8wyBedsWWL9NTe Nex/b+D+6SqtEnNwFVgmPvL7B9tWy/OAqglquU2fvt2FoOtsy6b9TrZtZHTBn0lSjUPjTZnNS82M 9GBplF3dUtWrYUQblmpxyw9NNbJaTmjrlag84edRrYjK9Qg5tuWP5F8/QyYqf3Z9A5JAAARAAAS6 iQAHiqKjwv9fod318rzRHplLcRwp+SeFkKJD/tGFB9vUKJvQcZQfi4PdVaJWq9aS6UvacfroetH7 CMyyZZFqhk5cYBmxJabkvAaK+ABeK7lJvgWGxEnbkVfdK4TSBA3F5O/qtbAgZJUm3y5qS/kYhomr 7SWUn/GDtyM2cKtva1uJ6yx9pt0jK7wmObbXjfNEkm7gei5kyiervtP39LPaWNq8QYRqYMIakGD7 COW1s24eaywWO3q0MOBOVhzSytFPMs313pvj7EHj7TRKX1lqZePoRexETC5FkZah2trUvoUY5Xcu Rp4f+D9ZOyThENszOSt6WHuukaorX6jnm0o0sDlR4KxkFVJT8UZ+td141V/IVfDOjbfsJUbfkdW8 1ORI55BDfri9TKqYsl4NI9qwVItbfsTUIf1ywlAvi/KEfLGVcsrrCeXElz+Sf+MMmTDfTLoGhIAA CIAACHQdgUqFrJ8cMpESFXdXPdI9cQRz9uRjdz7y6WPPvS41kJJm/IEdO4djSP6Nl7cHmvODoDe0 S7Rk7wtzyKGMHrH7ab8hVRvFb6GHR8jPYpKDgFB8CI5D5Co1ouXLSMOq01+ofGrJTfJb0dGi89Ix sSyFjB7qsaIAH6MzarjcBvm+tbn7RkGWHfLtorbZvIFhqnJyVBElWJW+rS1ru96SZ9c90uBNPiSl t6xmqJqvc0vZyFdaVu604LpWtXOoJu9bbqm8fSGU28gcY6gW5acW6SYc0Vlej45pzYN67tw+N8I0 g7ww5dmLJS9k16bUTdRpeq+xgtx/lB/lXp/XJ1+7LrxI+RFkZMyX4xQUXB5yOm00uVXkq1GlZ08m C2ouoynpg20nbzMpxMK0mSTHc6jbXFXuwBuOwSR7ssYJLp7D4uz1uQZrQdfjNdrHPCET2oZsYs+V 0caI9aQ+Xrh+NSwlefBvQ+4x81LyejUx0ml25R1plHB7tEdN0mDt6epluKtxRBuWajHLj8imbmo5 YWivZOVRnkehEtauJ5GTqPzmfqWdIZPkm3D8IBkIgAAIgIAVge9mdFhlWp+YnPScXA/9x3oocuAj tZRwrv27/yjNpirlanmlVFpZLa08ejT2Xwa/VPjeqRNfbio/3AwCIAACIAACIAACIAACIAACIAAC IAACINAhAvfv3+9QzpztE0888dLL//pbpc/+q3/wZxt6N+Z6eyisebmQJz89R/Q4V//9fyRtFKun SuXqaulReWXl0fLYf/mnpJAaPXLYttwLC6bAp7aSkB4EQAAEQAAEQAAEQAAEQAAEQKCrCQwMpNug t6srhcKBAAhkRUCjkMr30P56jkMKqXyuQj56FNicFFKOKJPXXpc67GVFA3JAAARAAARAAARAAARA AARAAARAAARAAATaR4C0TZRZniJFse+eQxvs5XmTPRnEnNVS/D8vslT7CoWcQAAEQAAEQAAEQAAE QAAEQAAEQAAEQAAE1i8BjlhO2ie2gapQDHP6k07eZY80URTbnK7wr+u3/qgZCIAACIAACIAACIAA CIAACIAACIAACIBAmwlInRP/V61QEHOKZE5/lnNVctyjk1RVcos92m4vtlhf8Y/YlEgAAiAAAiAA AiAAAiAAAiAAAiAAAiAAAiDQCgJrRT/DBlGkipJueXSQQor+YAMpUkiRWkpqpmgDPtJZRemkqLbu /d/85jdbQRMyQQAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEYgkEmplAVxN7S0cSlCtOuco6KTd3soXi aFLy/yi+uTzpv0inPWijOtJyyBQEQAAEQAAEQAAEQAAEQAAEQAAEQAAEGgmsCZ1UqSpIIUV/sree d4hcvuqQlRTFNqc/HTKiMqukoI1C1wcBEAABEAABEAABEAABEAABEAABEACBriLQ/TopihnlqqFc jZT8h8gVhENnviLybDnF/3kb7zXQ7f4adlWHQGFAAARAAARAAARAAARAAARAAARAAARAoNUEut9+ iGygcoKimNOfMna5dNPLkZse/SWfy/Hp0Ml/N8GCTqrV3QjyQQAEQAAEQAAEQAAEQAAEQAAEQAAE QCAhge7XRlFF8mT8xBoo0kaxEkpqn8gcyo0mRaGjOIYU/5qXF6GTStj2SAYCIAACIAACIAACIAAC IAACIAACIAAC7SewJrRRrkLKNYxi5RP9nVVRwnlz9s/Zf6/M/yuVSpVHyyurK1/68aYvFb43euSw Lc2FhQXbW5AeBEAABEAABEAABEAABEAABEBgLRIYGBhYi8VGmUEABNpD4Iknnnjp5X/9rdJn/9Xv /FlPb29hQ8+GwoZCoSA99Pxd9lhT5W28x+ZT7SkZcgEBEAABEAABEAABEAABEAABEAABEAABEFjn BMgnT26mx555HDiKD7aX4qtsOSW9+Tw3vnWOAtUDARAAARAAARAAARAAARAAARAAARAAARBoAwG2 gWJFFGmj8nkKXe4qo3iLPRk3qoe326Nt9kg1BQupNjQHsgABEAABEAABEAABEAABEAABEAABEACB 9U+gymZQopITuYo8y0JUhPP22/+/SoVjSNFRLpdWSyt0/N/+199PF0Nq/VNEDUEABEAABEAABEAA BEAABEAABEAABEBgLRCgKE6dLaYbQ+q//fCPent7N2zc0Jt7LFcoVPMOqaScH/zgL1ghJTVS5VKZ FFLLy8uuQqqzhUbuIAACIAACIAACIAACIAACIAACIAACIAACa5oAKaS++g//fIM88vmCk8tX8/kq +ez9x/8oLaRYIVWlXfboIIXUyJ9/9H//f3x0TVcYhQcBEAABEAABEAABEAABEAABEAABEAABEOgs gf/mv//pVz/y5xt7yT6q1ynkc3mKGkV+exzgPC/32suTtZS/zx5Hm8IBAiAAAiAAAiAAAiAAAiAA AiAAAiAAAiAAAk0SqHDMKLKFqlZFlQ6nIvJVCipFgc5lnHPeZ0/IPfbIcAoHCIAACIAACIAACIAA CIAACIAACIAACIAACDRNoFoWlZKoVESZw5nnqmWnWqa99oTDSiipg3IchzRVTWcEASAAAiAAAiAA AiAAAiAAAiAAAiAAAiAAAiDABEgVVao6qxWnXMmXKjn6e7maI1VUVTgVUkqRNkoI1kZBJ4X+AgIg AAIgAAIgAAIgAAIgAAIgAAIgAAIgkAmBlUp1tSqWBemhBNlIybPq/Nmf/bhKfnykrJLH6urqIwpq /qPfwy57mUCHEBAAARAAARAAARAAARAAARAAARAAARB43xKgXfa+9ME/633ssULvhl6RK/T0UjBz 3m7vP/2nOVJIkVUUaaPK5fIKK6QejfxnVkidOvHl1Lzu37+f+l7cCAIgAAIgAAIgAAIgAAIgAAIg AAIgAAIg0FUEnnjiCVttz8T5KVJI/dHj/6mwobenp7cgcr0bNhQKvYVCgYKah45KlQKfI4xUV7U4 CgMCIAACIAACIAACIAACIAACIAACIAACa5YA7Z5He+uRq57D++jxnnrCqVdI0ZZ72GNvzbYwCg4C IAACIAACIAACIAACIAACIAACIAAC3UUgX8jlnRxpnPJ5OnOFfI7+Ua+QIm0UVFLd1W4oDQiAAAiA AAiAAAiAAAiAAAiAAAiAAAisWQKFQr6nkOst5MhTL8/qKIeUU/UKKaoddtlbs02MgreZwLWvfOhf nL/b5ky7Jzuq/leudU9xUJJuJ4DxgvHS7X0U5QMBEAABEAABEAABEGgRgR7HIW3Uhl6yksqzFRS5 71WqjQop+inGac9WY3X3/L/4kHp0/hWe3ov8Q/OC4Ja3sZSm61bt5QoJ5RriY/oldD26/HXlYfHv v9cgDWerdkqQmLL4/I+/8cdHtqhpTflaXDf3B8qo9mPcMIpu90z4DI9+48efz6ZzYVwk6HHdl4Sb La4j+qXGeMlwvNh2hUzGu22mMr0ynSXtKanyUW+qPSDblmXTZYYAEAABEAABEAABEFj3BPKCgkZV C8LJV/O5ao7UShqFFGmjyJMvgsVf/MVf3Lx5s1Kp2PE6/O1fBsefhl/h7QQ1n5rfi4RXnG8fnvp8 3ZL17vk/+qr41Kca8jFdtygQL5P/SPzB4bpbthz5U58Nl8dXHlE5P/knf/Aj+dOP6MXfL2dM+S3K Y05q856ZSYZrT4jsD2F1lKF9heV1Q38gRCQo6BK/bMUwsm33LUf++BufqnXZlK2IcZESnPE223bM On+NPIwXgpLNeGl9a2XXf9xmd59iLZmyGmHQdEIfCmSWP/qG+Oon339fY1rfQZADCIAACIAACIAA CGgIfOUrX4nmkqs6TqXqVCv0F1HlvfRoQz0KbV4ziSIdVbT1E/3685///Kc//elbb71lrZPqllbj 9/1vDrulGd59WPzwT76nOF1dm2A1w9jH60trup68Vte+wnqwPz0yGHHLwNCnxI/vyOLc/d6f/PDw mKe723Jk7PAPvzoh3aOiy5+8POs7pavV8ds587pqX6/17Wtqd8v+wOqoz08d/nZGeqis+Liv2Keb 8Fu05IBxkXlnboNAjBcPcvPjJV1rZTXebXNfmP/hp/7gsyEjUlsRlumvfXfqU/6HAn5uiqZmJ8vM kRwEQAAEQAAEQAAE3q8EXG1UjE7KERUnX6rkyQCKrKUogpSgIOcBMdZLud56laoJI/3+9NNPf/Sj H81EJ+X5FPnm9aqlksYnTcarca9/5Vq991xWJvrynd/XAikUTNel0YrOvU9DcPibsfoRftn2l++0 kleFKKqqVJ285jjhfjCW/1a/HXNFqAncdJ/86g/FD7/6Sc+vsdYyJs5KeyXx4FKd0oIyuN0hkBTt a6H5hB9cUqQ3OEDShej+lszFQ20ovzlM7Wt7XWneUDZ37/xYHN7taVIT94H6dveb3m3aGp+k7V7n bkritnz2Dz4VVuomLpxMiHGhtrji3qx0RZ2Pbt148drS3I5hF04lmlOieTg8LoLy8ESR4MB4qUGy GC/Nz5PBVF8/3t0nQON8m3QeUPpDRP8xdQ2jz7laY23/j52fSR8lPj7oacDunj89JcQP5xcS9FEk AQEQAAEQAAEQAAEQSEtA1UNF6qRyDllEybBRbBcleMe9HJlK8b+lJio2ehSlIYe+DHVSYurzHzo9 xNb1bFz/R66dBS1Kv7vbc2IL+dRNfZ7S/oh9hD45P0b/770Gs4l+4IP38a9+MnbNWgPNq9faB1xe vh7+dqNVjel62gZrvM9boH9ScQJj463g2y4bGOje/MLlN5dHEnN9GDwPK/fb8XeDkNT+d2X3Szol E5/yHS18TwsTZzc2jOeVEW+VxK6IX/245zPJvoiKWkS2MJfz22QQ5nUHba22DH5c954h30Q8l7dv H9bcqetvKfpPq7/7a/qD4DyHRKCwSNTLG9udmGj5RLR7XPvKN+zWvPO9n8aF65EZjIyag5NxPhQ0 fXoznzKujeM3arqyGRfqeOGJIsGB8aJASjheMpknOduI+bBxvk0x/3Mejf3HG7qfn6p92fDU38b+ bOj/1vPzp4YG3GXEh9x1QoIOiiQgAAIgAAIgAAIgAAJpCQQaqG9+85uuDLNOijz12CxKOunxFnuk liLtlGcP5VlI0QVSUkUepJPaunVrb28v2UnNzc0lKjktWPVxxH0fJEXDQGviQCnEapna4Rsvfeob ozVLEalK8f9NYWMTm2vwi/aUCAyiXK8SRbCXr+m6+zPZd2QQG0NKYUXQH/zJJ339zPA3ZQQMie2P xFjjurqu/FHtQCG8XKRSD+U6BUqNl6eRYpVbnGdFJOfkJjLS5SrQ+tXpxQKPtHC7a6rGFmPy4Bcf +aYjFTb8JhJ5NPa3FP2HjZVaemj6A+f5w6+eFn/sBRVLFBxF1+6pCh7bvp6jaSrh5pveR+OCejJp x3X6cPN8SMkbx3W6Jkg8LuRUoZkmo7LFeGmgEzteMponk82G8mEQc0TPkw39xxu69Fkg+LLhPdVN /dnQ/1PMz2KBlVEcgLFlPttxtPA7CIAACIAACIAACLzPCLjaqEAnpa29tIpiEynWQZF9lCMKOVct JQ/HoRhTVUHxzuN22aPoUbdu3VpZWSHfvWKxmAi1GtRcXSTWfJB4Aev9otrtk8oo+nBf1H3vMuls lui49hVKSmtlvzRukKjGeOum64kysU0U1s/Uolv/6RFBHnyBJwKLrS+/RVaeOQsr71yNVCguj0GQ mTMVs6Y6izXcqXNFFIFmyaIClJQVmPxSd+27Pz58+MdUCy5fCJBWXmN/S9t/7IqbMrXSH7jCQWwU V7GoGLglkp/SjMmufROVxDbR+2BcyA6sd8lMOh+mbF9uDLtxET/ObBs4o/TraLxkNE9mBJaeEZHP We1z3JS3vj8b+n+K+fmHX/08K6PcaHv1HDMDAkEgAAIgAAIgAAIgAAI+AVUPFaGTInVTLldxchXa RY//Lqp5UWGFFFtKsTbKDyIVqZAibRRFNCfbKNJGke9e9JZ8qdqINS3Bvjzku5VASM27LOFmPtK4 iO6qRYjmz7M1vZbvaPAvzv+PhutKHPQEBbRKorPzkV+PawGEGsufNAde3/sZsO8IewWSPkpnGtYo 0sjZV52l2NUo7QsDKbLoBfzuHfEHo7s/7qpmEhhI6TFZ95+ktDNJV6tWncbBpr5qu9uXKr5926Cj eB+MC53dTLL5sLn2NfQI07iINe+x72EZ3rE+x0vaeTJDsIoXd8LnrC7zqP5s6Fg287P8wFGLA5ku 8l6W0CALBEAABEAABEAABNY5gUYNlEknJbVRMnYU++tJnZT8O1lI1Xz05HUjMtplr8XaqLqsOZh4 TAPKiBzeBnTJ2loG5yCVV2i/Mt85yHWd8x0N/vTI/9Vzpqu/7u8blDyoeZLCcX0bXec4iIYS3Epb /iTSKQ3Ze9X27pN2Nj/8k4mJPxF1GyFJB8rQ7oNu7Oo4znxfzCE9BT/vR9OWFbZ0AHIzkFnd+d78 0Ge3kMip707M/zCVUiRRverqZBGXOA5H9O9qf5AGbf52dvqOYhYWbndjOk27h9Jq21dGrK53lvS3 H2iu/v7d74Nx4Q2wqMBp7kaLWqJ17WtqR8+mznX2jT5M40IVLa00E7QwxosKSTteGihmNU8maJ7G JGnnf9vM1P7sdriG/m87P4c21pOxF+13grCtBtKDAAiAAAiAAAiAAAgkI1B1vfOkPorMpEg7JeOa 53J5Ptl9T0iHvqhd9j784Q+3zDbKrYUMA+X54J0e+sbhuLpJjyIKjR0cMV5j/O5GO+/UvPwaNw6L yzLV776jAr8KuiG13IKGHBgoOHugJwu2IpKBiwNHxzTlD0J4sSjVZZJee344NfXxho0Fh7/JYcU9 R0i3nEbO6hZ7HN08Jm4Hqf44VL3bXJw+pBhMjpY+hU999U9IHyXDYU1NTXlKERNnk2Tb/sNydG9J ce1ravfE/YEK+m2K2W/DTdfukXw07R5sS+i3V1376nZQE54nZhKnwjhuMtv3wbhwB5gfNa62d2fU fGge17rx+8e8owHjpFjP8ZanpnGhxLajHQji5WC8hHfG1I+Xxtkpq3nSdj50H8IW83/yKTv6+W7o /9bzs9JB5R4BiCNl2UJIDgIgAAIgAAIgAAItIkAqJwoa1ZOX6ijByikKYO7c/vMFsomio1QulVYf raxWHj547/n/9JEvFb536sSXtUWhxLH78d2/f79F1YDYTAl4Wxhh0W5LlcGl16bZ5ta16dlcjwK2 NCoVm7Hj64Ladv+4YMC0deZaGbkYL7JXG8dLF/R5FAEEQAAEQAAEQAAEQAAE4gk88cQTttqeifNT 3yp99qWP/mVv74Z8IZ/P95JFlJPP5+hk9RQfMpS5/CvZTEWXIlYbFV8JpOgOAuk95rqj/B0shfcd 3vc97GBJOpi1uwOlZisAGSdfxG3c2MGSR2eNcZF502C8SHWUabxkzhsCQQAEQAAEQAAEQAAEQKDb CLjRoRwnL02k2DWPwpxzOHOOLMX6KC+elDmIVLfVCOVJS8D1s4ONT1p+dB+70B0Oojo1IWjN3kre ox//dqNxFPct6SyT0hmzkzwwLlpGH+PFMF5aRhyCQQAEQAAEQAAEQAAEQKAVBBZsjqAAZPhE6icy iqIrpIqqVMvlcsX5y7+4WxWVarVSLpVXSivLy8sPHzx8/oe/G+Gyl6RKtkZcSWQiDQiAAAiAAAiA AAiAAAiAAAiAAAiAAAiAQEcIkMvej370o+RZDwwMeC57v/+/9fZuLBQKTqFQJYMoDgTFAc3lTnsy rpS0kKpUnXJy6UgJAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiYC5Wq1XK2sliulsihXRKlMccyr cme9HOmm/DjlrJPCAQIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIZECAl1Gq5ulopP1qls7RcKa9U ymwdxRvueeHMoY3KADREgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIuARWKtVHpcrDlcqD1VXSSS1T zCi2kKII53SwUoqCS5ED34ZC7jEgAwEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAIHmCZRWnJWVykOy jVquPFopPVouv7e8wi57rI8SFYoeJWNI8Y57OEAABEAABEAABEAABEAABEAABEAABEAABECgeQK/ fvTo/sOVXz4o/3ql/JtV50Ept1zp4S33goO890gtxeopHCAAAu0jcO0rH/oX5++2Lz/klIoANdNX rqW6EzeBQBMEMD80Aa99t2J+aB9r5AQCIAACIAACILAWCfztr3798988+uXDyi8ervz8waO//fXD v7n/0FNIVVkHxf/RtnsU5Ty6elWZOvlx9/y/+JB6xLx6c/K18NpXXy1fpWC6nhxYkDIkqq0aCyXn cL7uD13QPg2YUxYrvRz3Th9PU3I+/+Nv/PGRLW67x/b/cL7JuhXfk7YDhWpW3/JN94f03MI1Ty8n eTsOj37jx59vsvOHy5m2TZK1eihVhvOSPnclg4b5wTifpKhI4y3GnElD4B3JQJvT17JIJikive34 pfTq/MDVN5XTtr5m+lbjupZtbT5M07BrvR2zmB/ScMM9IAACIAACIAACILA2CPztrx/94r3lv//N ez/7+S9+9ne/+OnPf/HXf/fzHCuXKIBU1aG/VCoV4VScHBlJGY+/+Iu/uHnzJqe0Og5/+5fB8af+ q7f78p1sgW+VW+rENuXZcuRPuUrfPiyEWzuvXqbrtoWisnzyqx+vcVOw2YqyTE/vF0rOfyy+141W IR5mv1f96BufEp8aGrCsKSVPK+fu+T/6qvjUp4IMm5JTU0fFVqA+39gbmk6g1Ozbh6c+X1M28Hvo H4k/oAHQxJGWW32WaeVYteOWI3/8jU+pCNJVPJgNv/3xr34yiYLLZl4yFSnNvGSVr5JBuAytnU94 nvyTP/iRnAh+RArD4HlC2ZIiR/7wo2+Ir34yTotuTs8V8LPwp/molo9Kbzt+ZfrQ/GAqp219jTWw G9euvszlL0H/UTpbz/XQjhnND+lmFdwFAiAAAiAAAiAAAt1OYLnU+4vfPPqbv/v5z3/xq7+//5v7 Dx78ZnU5VymLapWCR5GplENqpmq1XK0alU1kG/Xzn//8pz/96VtvvWWtk+p2Pl1Wvrvf+5MfisO7 h9terLvnT0996hs/+qaf85YjR5RCuG+dwY9tL50hw2sTX/3h4bGapjNtuRLLoYT0mjj28SbL0/i6 GVPymHzT1jvhfQNDnxI/vuP6Fl77yufFt+n1fDDhvYmSJeYfjylZf7BtR/eV83S6d+6GQg9/kxSp mUlLRLjtiaLnk6aLw/NkMPK3HBk7/MOvTkgF+rXv0jTm2R3ydRHD2ZieOvrU4W8n/x4Qmd5y/Grm B1M5betrIm87rhfmfyg+PuiZd24Z/Lj44fxCilZdJ+2Y7fyQgiNuAQEQAAEQAAEQAIHuJfCrhysP Hq0ur5Z7ejds2PBYz8bHejc8Ji2kBIU2Z4UU6Zvcw1QJUlw9/fTTH/3oR5vXSbnW+Z/86g/FD8lI wD1UW6nAej9kQKV1SfB8nPzfVB+qr1wL7oiRE1eetrcrL+3171CG+soSqn45jTVOYozGLwaf+oPP ei8YarUjXHJUn42QIYK+POrVOLsFtwTGenm/np6qU97JEjXUN8alhd+dE8qhd1Sz/ksjR99/ksBW Acl3XW2+MfXlgaYcZg56Od6toeIOfzNKL2mQsw7acctn/+BTP/yT72UU8Uu+wQfSGsdR3LwU2V6J Ji13OqmfJ6PztXANM3fx8KiudfOo+a2xRqwPUY5AZUr6mZqeRA7IkKakgZsx/d07P474MNDIPyq9 efwmnh9M5bStr8xQ146245r81Mho0J1quX6f+sZo7QNG8ufRumnHbOeHREMYiUAABEAABEAABEBg bRC4/+AXD1cflkRlhTbaW11dfrT8m9+8xwopXw0lDaPIey+yOhRkKo1OaurztShS8tXDtbSRjla+ ub/iDDH1+U/Oj7kOcT8MXADYJYFsMuTBvi6quoHknx5it4H/f3t/AibHdd73wrX1PvtgXwgQwAAE CFkSJYEWKDOSI5IGaDtULCKy77VJXyegqO9amNwb3sf8HvrmJuYTJuFNHpBORBFxvoCO44WURdoO AZPQRloAScgCKRIEiJULCAy22ae3Wr/3VHVXV3fXqaWnBzMA/iUIBKpPvec9v3OqpuuP931Pfc7A 7nuds+F2gv2ZjRm2oyccta5ZtPEdb31qTJTcEp9x1f2Dd93nvJScupwNb/SUvz91qYgsxyY0Zyls XPY7r/c1yH+6gtaPfUVEO6SOPU4hE/wosah2BIFg+4p/7vpnATRuklxYvw3D9o6X3WjVI5RDM77K i+stDclDMW+La2Qe7TfOlqJA/HgxBcU5fO+jK/Ncan5OBvQbb/1wnyeBzwHO89wH4B13e2KfWEBR TZ9yUniZJkI/Tbx3AGfd+rdn9+g6wa2DGCrq89vHvH/JS//nA29cMccbbx759zpbKnbuaY/987kW ShZ2v9eZvHbmsb3Ph5jPWDQHARAAARAAARAAgTlMoGzpZdNQBatolgtGKa+V8uWSRHFR9uZ6TIYS qZo5+3/IQZrUbbfdlkwmKU7q6NGjYc3tz701pCLke1FzpxX7mlo57JSE6j++sn+WrQtTqOZU1OcM uJkWke1EGs0VauS8FFKRKlvOq1elfMbL/o2cq5PQv3u7Va5mwH2/kBF/f+zUDFfNcXJpXgwsUhU4 LhqLb5pX83iD1090O04WjScKoBFn9LQzFkzhe7jr3+bjJMkF99s0XidTysfNYA7+68Q+y+Terzwf qeYR3bjN6+2amsdq4mKb76XYoVftua/9npO8kYXeR9GQhDwH/J/nfqaZcE8Voux/8Pi68JBHeSVB h4lRrPpT088cf24+7dk9evDhx4VvuzWS6opRNd93vPahz43mwXGfD7xxxRlva/Pow40pfk4VKVZi rhaWGvPn0bU1jzP0fIh2b6EVCIAACIAACIAACMxNAoas6AnZUOSCJeVNIW9aRcuSZFmQZJKh7Jrm FtWQYiFTwQOg6lH79+9XVZVy99avX3+FRuu8GFSz++xkP89RK7bEvjEHSV7Bdq7QYOJ0Y78C1EXK 0NU+4w1OLYnTo1smKNpFpJvVXglrAQQcfxpSM4RahAint5BxcYWXBnNh8x7VjlMEhl+tKqqdaGzt VnY4Tli/fvbc0i6eD8M4BPoVRT/kGcA8+pKp3Q+c+yjGQrkSTVtZP35v58HPgejPcxpzrZ79yw8K nopGBx++l4lRTshOY38+rHzbs3/hcGtRUVdhAjqvfSv3L2c+eeOKNd5W5tHXH1t/d0ps0Y+qWkhz /J9H19s8XonbFX2AAAiAAAiAAAiAwBwioKoltTilTo0bumoaOnkmK4rEykeJTJCS2GZ7gmmQ3BS0 gx59ShXNKTaK1CjK3aNoqSs4xFp2n/3P1dHrzDb42C47V27odkWp8H91DW8R6jKLJYsdp1F9lWjc zSqCPxFeFINGzl6H/Ete+Yw0YN6j2mH/7F/TRe+t/KUmw0W1EzoPlQbstY6l4oT162uPh39667+l zQwd//jrIRa3OTCPflpf1Dn1tmPzWlu/vPuoFcszeE2c9RP1eRLpORA6Jjsqx94Jwha6a/XWQuWR oPYNCZqhN4BP+5buX7/h8vyMO15mO8488tBXH1CVz+v/fSHC89/f7lU/j+16PoSueDQAARAAARAA ARAAgauHgJzulhMdipxNiFLCDouSTJPEKJPUKJKiSFqS6W8CCUxcjYnCp9qrRtWX9A1kaVdmqGyg NB3ogXZi+NOiD041nmiVvD1d1L+3+vbtDIy353b04sd2NqRnk/TTTz0VmFHndcbWzSoHxx+7Vohb FqmpCm7z0ALHZb+4+FX5bhpv8PqJbKeavFYpZXa/81LnSqNcO/wpC6yP7ab/hfTrlCf21rfxLuV9 g7WAwpD7KHid2NPlW/G+cXzNdq6ZebRLhNnlibw3aCv3NasaVdsKzmPNex+x0/znUvT7upUHlk+/ sZ/DnOdJ7OdAuP+sKJJb3K1uYz27tlTdlqXN94t3Iz5ve7tod3VbxaYboJm/f/uw+zfy84E3rtjj be3nqf9zxv25zJ5XlVryrf88usrn0ff5EL560QIEQAAEQAAEQAAErnkCiY5ctrevc8HCvr4V3f1L O7sXZHK9EmlRdpKes9seHYosKTwWtMtef39/K7FR3qLm3tfmO3ayGP9KIl5wvVg7o4VKYLtHaHlZ /2EE2onhT2UDIQqScWo8VeUA3nnHG+dfkEOqJrGG3v2JqFos1egICwirS/nx22Mu4hK37VAt7Qro rwt32eW8qg41Ddi7NRjzs5owyfHHzuuoWp/euCLIWbUxB8x7LDsBFGPb4b3du/BZleAINdf8fPLU ZKHK/lSJrHLEvY+8C9FbtJi7HniA+OszFrfZnkf/beMi39eMTnV6b3l4g6cINO8+YlfEeC7x8Ac/ lzhX+fTL489dD5znSeznAG9gLjd7y4va3eK5AWzQYfcRrz35X6nZHfk5HKt9wAPF9/nA8zPmeGPP I3eJeJ/nJAhWQcf9eXSNzGPQtpIRfwKjGQiAAAiAAAiAAAhcmwTSCTmZFBKKJSQMOSEmUsl0rkM8 eeoDwzB1XSvTznuarqlGqVT8X1/r/4by0u//3g5fEhQnRcpUMKTx8fFrk+K0R2VvLiWEy0vT7ggG rgoCLBwggtp4VYzlOnCS3b5UmKhZHMZ9fR3M/iwMEc+HWYDeepfc50PrJnElCIAACIAACIAACMwx At3d3YcOHYru1OrVq598ave39LuWnv8BC4ESZSthiUpCkhIKJenJsuzUgbJMwdAtEqcMI6Soeaga Fd25668l+/dTT9GY6w8ARlxPoBLXEDuJExxngYCzU5pfSXvc17MwHddDl3g+XEWzzH8+XEWDgKsg AAIgAAIgAAIgMFMEjEJBLGuibui6rOmyaohFS5IKeb1UNOiXquoU9sR22bOMmXLhOrfLchLqs3Su cyC14XvTlWpJma1U27r6kLKUoPvdKjVXn//Xj8dUIWeDs59Y3YH7esaXAJ4P1SpWM44aHbRMgPN8 aNkeLgQBEAABEAABEACBa4uAYlqSqYmmlhWsjKEmtYJSnBDffvu0ZZmqfVCYlKbqpXL+/p8sDEjZ i4IFKXtRKKENCIAACIAACIAACIAACIAACIAACIAACFwVBFpO2fvExOuiLFP5J0E3RUkUKV+PflFA lGma9DsNnv0m0v/NqwIEnAQBEAABEAABEAABEAABEAABEAABEAABEJjjBCYmxyfyE/nClMlS8uSE ouRyORKmWHly+p2Vl2J/NERWUQoHCIAACIAACIAACIAACIAACIAACIAACIAACEyXQEEtqbqhWUJe 06bK2mSpPFaYkirBURQe5URICbIkKtPtCteDAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAgCAUBWnS ECY0s6DTL31K08YKJYny9XSDNtazSJmi3y2LcvZk4AIBEAABEAABEAABEAABEAABEAABEAABEACB 6RMwlJQhJQ0pVRKFkiQWRblA4VAW21jP/j+LkLIsiZQp7LI3fdqwAAIgAAIgAAIgAAIgAAIgAAIg AAIgAAIgQLXKRYp+IgXKlBRNksqWVRZIf2JKFB2smDmrJUXNTBQ1x3IBARAAARAAARAAARAAARAA ARAAARAAARBoAwHZFGR7Cz1JlCVTEukPFitgbhePYnoUaVMmFTw39IpGxevTCaeKfJx+6s6euuPO p05HvngON2wY1+C+ueqrx9FQJ/cN9vQ0zI99eeiFcQfvONV2s143nC6ms9rqpng6huLSEQR/Pmx6 nCOqN752amaaZiDWvPDsxD3Pw+Nvp25W6ldQfD5NXdff1lExx59gzhUzOu/UJ29+a8OOPOT6+6vp MR/t9vb1h/fECli3bZsAGAIBEAABEAABEAABEAABEJgJAglFTipKMkHb6xlpWcgqckZJVHfUY1l7 7JdhGlRSKqD7d95555VXXokTRbXqwZfH6HjufkG4/zn2p5cfXBU2PvZGEvnFKMxYjM/j9usMyB7d 7nunIa/E7TfGkATBMwGh191x9/3Cwedf8iiGp196/qBw/913hF46xxqcfurrDwubNrXuFc3JLQ9v qE5wpGXbemd1V7L37q8LX6EbpvH0vUceO8SW26HHhIdvCVXz/O3QuO4VKsNiy7Z2n3H65UsnvnZ4 9vn9+nfAbV9Zz9XbzsVA7sfjw52u2m294eFbotzW7bl/Z3beBYE7v/TBLc9/xV5Zkdd54/3lmRVn hW4SNq1bHXhHcNen68yhx4646zPu+mnTzQgzIAACIAACIAACIAACIAAC7SCQUoRkQkwlhVRSSSXl dEJOKyKl7LHDtEhiYodu6AFiE7UcHh4eGhp69dVX42hS7XB/btu445v0Arb7xTkbJRWZXpMiderY jOhRzvvrzhnTufY9+bDw2Lcf2hB54I0NZ02I2zfIdJ6XH1zTqEe9uHvTY992xNxVDz50v7D78cBQ Q54dRr7K3TvbvPY8gjw7cc/Hte9tv3rdJuHISUc+3ReTT5SVccdOElZCOEexE6XNTM87d37pg933 Pxfhnwm8owi5v+jjg/c/FPgvDxx/2H3nXsnW+cGHn7Qfq7x1FYUt2oAACIAACIAACIAACIAACMwy AUUwZPpl6SkpmZRIkkomRZHtsmcf9i57Ju23ZxoWt4aUKIq333774sWL26FJsaiCwX1uFkYlUMPJ 1rjl4YPCQQpOaExP8k3JcQzZ//7vTWbyt+9MQrOd4H5jTR3HH7LhTWupBHYE9uvTvuKJ95NaiAu/ ffQBNChS9JrviY+Kw7+esyc9j5eQ48vHOdm8ToIHZL9jB78PhxFZtYbELF8tgj+/9SOoC/GzyUUK +rtjp69OxyZiw5pKbOHppx7fLQgHj50KGAXHDveKuO3DAF6Bz5l4sekrd9lQYvOJ5h9bBrWQQU/O WCVwKuy5MXfmnTe/p08eiR0BGXJ/2cszLKqS4w8TwD2HV3KMNmNoBQIgAAIgAAIgAAIgAAIgMAcJ pEQ5LSlpKZExzIxppQUxLSdYhBQVMXdlKdKjSJUK8F6SpPZpUsLuex9fZ2eKPEf/EP51FvDhRM7Y CR9OdlItiYSl5Li5RpRL4329p4Q5xxJLZrIN2Uezffbq6mcnoN8oc8kiAjY99k034MfHn7oUMJaL Yr/S8vv1b2+/e1OGjSeZrBLbwG8fZQC1NnWKlFePisuf5dhUUszYLLrRUJwUwiD/feeROyz2Pnz/ c9ONvrKjYxxVtDk5zne9+c9LPPpBrZ0UKCaB3HLsIXaLTPtg01tVdKZjjGcn7nmeD412KsLQLSwK rhaG034+5A9TRJzDdz1P87kRCfqMjMvtmRSgTesEt9BfBNE07P6ydULPwzDSIKuN2OPH1YFZXmCd PlVp1a51G8szNAYBEAABEAABEAABEAABEGidQE5J5uRELpHKygLVkErLYlqiuuZOgXI7ca/uD/yO SJO67bbbkskkxUkdPXq0dY9YUamKmsJeQ0IOOyWnKvmwFLm6WkdVS3ZEgxs54mc/2E6YF/Wfky7h HEx5qUt6afLHTkVxVRIn5yooxY/f3haJmvSWuPb5A7UVKQdhnR7VAv+GelRBcAP9j7NO7OI2rb4O 13noiA1U/Mye5npVyme9+c9LxSLFg0Quz8PHdIqJUazaz3TVNtYFE1hoJU0vkCzADs9+3H592ts0 mfz8lefrajy1lY/fNNTXV4vwsJiD817vNQuQOvjw48K3HaDhxclC768I6XpB4JgQTBXS7Mfq14WH mnXXuOsnwiyhCQiAAAiAAAiAAAiAAAiAwAwTSJhaUjQSgplSEulEMq0ksgm3qDkl49mHQFl8UrXS OcchCqfav3+/qqqUu7d+/foZdrtq3nlxqmbx2Ul9nqOWH8LeAINe14PtxByMW/24sVJ7sz8NqSie yAv/PrntOSk2ce0HjNQOUmBimVePis+f9Jzaq2Vo4EW7/HeK24TXzY8807akwEoJ3euRpHzWWyup T5GdsBsefPheJkY5wmcjr3imWJgd3UIUhThdaYtnJ+55nv+Bftbrum3lU/Wnxjneeo47HwHtZ2Rc 1f6Ygu/WJqsUJwsSysPuLxY+1XJ4lONUrT76yw8KlMHnZqqyD9u1bts4PzAFAiAAAiAAAiAAAiAA AiAQSiCTEnNpsSMr5GQrLVpJSUrKJD5Zgmiaom5SBSlWp5xl8HFrSFEf9ClVNKfYKFKjKHcvVL0K dStOg1oWX5z9oJp7aJedOL43to0rKNS1rxZyDnAgrn2vqYoiVV8/ihrE5lZ9tYwQeDFdPpXrmc81 3ZIigOy/hMphYTNpV5QKpx7eIqwj7ud26lgtnGl68pcdZEKzGbOSdZNzPDtxz/NGHclPJ6OtrXxq /tQnh01jPbc68TM0rjp3GoqRBe2OF3Z/2bnLlbJerQ7Zc13DIyjSemhDtzABAiAAAiAAAiAAAiAA AiDQZgKpdC4hZyRTlhRRtiRZ1QW1VB8MxdQoVt2c1zOl9V0ZNaq+lLDtzqq7vkIVfZwNl6ZzBNrx 6Xc6fXmvtUUeN8iGVQX2xBH49Mtt7wygVier0kmg/biDcAq5PO6tdjwt/raeE3y0yf9qMpeT0kXp draIVhNenOpDzUWhQryLULSGMy8Vw9GLW3M8qdtYz66t460aXSkUH2lcdrEuIZ4a5WefZyfueTbg OPY9gOzbyJE/gvlUtjGIxKdmv6J/NMfbNa5n/nNjDs07Z2Gx7Ge3aJMHqN28aV5C7i9bQPJJAo2z Pl0/WdE6TzG4VtZt2FMHn4MACIAACIAACIAACIAACFwZAuUJ1chrVsmwDEOUhFQ62ZHLUoBURX5y akixrD3+QZ/29/fHjI2qvItQsIpTiydSuModO1mZ80qCnhPfYmfMUClw92gx7CXQjk+/7ZodepV7 7v5q0anGmlM+/XLb16UO1Xjy2lc3tYs1AXYdqYN1mkds/t4tydh4K8lhPH8C+bRrEiqZkoHVu5y+ qm5yaoT5OMSZl7iuc+fLU1zHrmkfkmzHs8NiWFj6n5v9WtHn4q4Tnp2453l8wvy0S7fRJgeu2BjI x6lNHmHemTvVu9TG7NrnrGfb/zY8N2Z63rn2ad0+R3tE+NfCi7V6G2T24Gu5/ric7S0s3FXOWw+x PERjEAABEAABEAABEAABEACB2SGwdFGmu9vKZPIJoaxYJUsrmkVVfP31dwzd1HVd1TX6pWlqsVj8 58dWf0N56fd/b4evpyRdBetWdNX4+PjsjBK9gkAgAcRZXJ8LBPN+fc47Rg0CIAACIAACIAACIAAC INBGAt3d3YcOHYpucPXq1U8+tftb+l33d76XSKeUpKIXdcNMaBqVjdIlTzXzSlHzUNOhalSoBTQA gVkiwDbzE9pY5GaWhoFuYxLAvMcEhuYgAAIgAAIgAAIgAAIgAAIg0D4CH58dvnRpfGy0lEgkcrnU /Hndy5cuZIIU/Z9qk9N/KGGPipo7uXs4QOBaI8BygeqzsK61EWI8fgQw71gXIAACIAACIAACIAAC IAACIDCrBPKl4uXRkfPnh86cufDx2Qsfn7t4ZuiCHSHFFCknUkpg0pRUX+l8Vp1G5yDQNgJOQeaQ 0ktt6w2G5goBzPtcmQn4AQIgAAIgAAIgAAIgAAIgcJ0SyOa6stnuXEeXonRJUtay5LJhMe2JSVKS JNu/2F8C65pfp/AwbBAAARAAARAAARAAARAAARAAARAAARAAgfgEMgklk0xmUxlZMRX6lRASyQTL 1ZMVSZaZHqVIirvpXnz7uAIEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAE6ggkRVMxddE0ZJnFROmm oOsmC42iv1BD0zQ0OmGYdIAcCIAACIAACIAACIAACIAACIAACIAACIAACEyfgCRYCVlQREswRdKc LIMEKYGkKIukKF3XVU3XNNU06a8oaj592rAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAgWIJhUQAU xUFpllbWy6peKpdZbBTtqle/s54IWiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAwfQJ9/b2dXd0d nd3pTDKVTiaTSkKxk/VIkqL/29vryexvFEOFAwRAAARAAARAAARAAARAAARAAARAAARAAASmTaCk aqph6YKSTsvpjJLtSHV2dbCUPYqQYjKUvd0eKy8V1lN9OFVY69NP3dkzuK/Wat9gT93fw65v9XPW b+2486nTrRqaa9fVD+yKsGwNgcdR7wJowVjdkNs9lXOWp+NY83Abz9cNoGXSM36/zDnODQ7Vg3Y+ bKZZuyhCe/asqxwtz0sLtwsuAQEQAAEQAAEQAAEQAAEQAIE5RuDc+UvnLw1fGh4ZGRkfHRkbH5so FoskSNmRUVTo3A6RcqKlAo533nnnlVdeuUoKn9//3JhzPLfh4VuiSDfsdbPdgsdMLIPawO7ffW+U gXGcmNHxrnrwZZv9/dMjQD7e8vCG6kyOjb384KrpGfS5eg7yPP3U1x8WNm1qcrb5fIWzw3r3vdOQ Pmb8fplznF2HvOuK6UhfF77SvG7pg1ue/8oh55lSW4f+7Wnd3itUli2bl6vhudL2GwsGQQAEQAAE QAAEQAAEQAAEQIARSCayspKyLElXE+WiUCzoxYImOVvsMU2Kip5bpiIoEguW8j8oNmp4eHhoaOjV V1+9SjQpZyB37Dz02Kbdj187YVLV+bnjm49tEna/6IlAu9YW++mXnj8o3H/3HVdmXHOG574nHxYe +/ZDGxqHzTvvtFu9bpNw5OT0gwFn/H6ZM5ybl9W+QaYjvfzgmib0g/fuvv+5Jj2U157phDsry/aO u+8XDj7/0vQn5srcBegFBEAABEAABEAABEAABEAABNpLIJVJd3Rme+ZlexfmVq1dtvKGZblUTpJE SSExSpIUWUkq9AeBYqV4HVM+3+2337548eJ2aVKenJamvD4n18UTV1BJ/qteEy/iYNWaDZ5XwuZc GicV55aHDwoHKZiqsW9O7k1D0k/F2QA/fezQqcF9zvnBfbwsrUgrgd+v189KAE3geH3aVzzwflKb AH77SI4HNmITJ/hqiUHrwd/PuN74j8u33+D1Iwj2DEdesiRy7L7/oeZQMN756uyQeLfpK3e1I4KM e79U7tOw8cZCPWuc/by8Y6erI9V9fPrkEV9hlNc+FgE0BgEQAAEQAAEQAAEQAAEQAIFrmkBZtYol oVBKC+WUVc7KRlfKDoySZaZIKbKsKAn6I/01AANJV+3SpFhOy5HHKgkwY7W3QHp3r+W6UK6d9zWe EtQeX8cuOfSY8PDX40Q8seAR56B+X7y7mstXzaVx8p4ojkrY5LpUCYbwbU929g26qWSV62rRE35+ 8uwIu++lMbEQrntvOfYQ/TdGLAUFzBzc9Ng33fghn37rUt4OPXbESfHjj9e/PQPHMpY8yXM1PLWz rv323Ul2tI6jEjZno/muB38/I3nk4cnnQJaa+g1YP5E69jY6/dTjFIpTja6pfcI7X5G7mJ5KUVVt ymisu1+a79NpjndOcHbmsUn45szXqWMHN60T3Mp0kcVF+855cbfQJqUw9mrCBSAAAiAAAiAAAiAA AiAAAiAw6wRYWp4oU46eoRU1tWAaZVmxSIhytCgmTdHv9i97rz3+QYZuu+022qaP4qSOHj06rYH5 aC/08laTWFhqT12bas6MHcFx7FQrndO7tPuyz3Jpwg5Oe/aSWU0lW3XXVzbVe+PjJ7/fajCMV1oK 9Mp9j2ZKQV0SUVO/LOWtpm6sevCh+4NT/Pjt7QE36SRx7YfR9vncET+oFpU97HpVyoezv59xeYaM K+46pDiaiOWv7CJRHo2x6jjvPPvcts4E1a88H6lWWuxJiKGRBtn2WbezxrmiyTo15u4nxTNYYmIB Ugcfflz4tgOa9PBbIlbrYsI73Tk+AW+xpwEXgAAIgAAIgAAIgAAIgAAIgMBVSUCTBFUWy6JYFBNT pliwRJVS9JSUlEhLclJiG+yRWsVOhQhSVD1q//79qqpS7t769etbhkE6g/1eV5+a57z4VbPm7CQ6 z1ErJsTewZuDSPjOUIBD7dW+tgEfvSqGHt6Molp7pmVVqzext+pN61bXLPn66W8ntHufBrVazA0l bZr79YzbNlSLfPHvmNuek7IU134rw7WvsUUXO47MIwT4cOalVgV17MMzeFytr8Ow8TtFonyy9Tjn 6+yF641h3buf18bvf59GNlR3+7q16d11O1uc6/y/YyfJncH6NlPAN7kTEx00i6OkIMZDcZ5VLbHF RSAAAiAAAiAAAiAAAiAAAiAwZwkUDD1vaJOGXrKEvK5P6VpJ0yVFkRMJlqYnygLFT7GAKTlIkCI1 iiqaU2wUqVGUu2dvzBd6eOosM7mgJt1UNwhrCDioZc017GcV2hO3QS1phr0hCm5aXvgecIHtKyEf LGctbPe3uP22PtbAKxsFgLBu6tpHKJgd135Y//Wf2xWlwr0IbxGvW2o9s+Ny3WHrtKbHkvxp/+XO p/4757xPnew6ZTT2OCsX1CeZce7TVo0HXXeFODe4wB5L4UeDZBUO2g6OoqdZ2LMhvGu0AAEQAAEQ AAEQAAEQAAEQAIGrmQAVK2fykaSbhm4YuqZpuk4xUZYomPRLEtmn9DtpU7xR0i57sdUoO5vN3WDK rh3TXHbZ1hmcw27/8JNt3Teu8l7YHHfCikR7B1tfyrkZg7e9nVrYXAEr0gpp7DfSRa01sgO53KAi 1rEnMdBnvNz2zsQ01e0KtM93uVrGPeagIhTj4fgZsyOhpXHx10/UoubV5DsnBY/kUnuNvfzgb1aS 8hrP1xcwt6e37vZqiTP3fvHcp87NWrdVQFzEdvtZ4lznK8uGrCvF5jcSlj3sFtdvBt18iV2EjKRv qFEtLQxcBAIgAAIgAAIgAAIgAAIgcE0RMEXLEixT0CXBlAWLfieNikKeTJN+F+0TTt4eb9S0y15/ f3+c2Cj20vrgy89RaXKndrC35pF3iz12vpLUYmcIUelt94hVPrjO9WrJGrvodvW90C5LVfHn8XWP 3V93BcvdcQNUnI557el8Nd8wUl3kwH5ncJ2RxPEclW5v5m/LAT7j5bWvS92q7RnHs19NUGSSn9O9 dyKdzMFqymPA8Ot3MmyqmeVzJcfPuIgDufGM+fCM22/c9nWJoEJtnTt2InNmjX3vF2eDwMrhuU9t 820Y76xxro2r7vnAXbfeB5lnHfLaM+1d8GYf+xXljzvZaA8CIAACIAACIAACIAACIAACVyMBOyzK MDXTMixLt9jvliV+8MFHdJ4OqgmlquV8Xi0Wy/e9Mf8byku//3s7fMfJLuOLVs4l4+PjVyOjGD6z +Ifnv1ILf2B7AzZWGI9h7rpriviRKzPl4HxlOKMXEAABEAABEAABEAABEAABELjmCXR3dx86dCj6 MFevXv3kU7u/pd/1xanXZCVBJaOSCdpIL0GlokSnAhT9znbgowJSomRQrJRgBlsPVaOiO3cVt2yo dWMXodmwpj6D6ioe3ky7zsrACz7JmzPd7/VmH5yvtxnHeEEABEAABEAABEAABEAABEBgzhGghDyJ 0vJEgZLzBBKdLLtylEA5eiREOZKUoiQSSfrPnPN9DjpUl6zUQ7sBUlYgdtKKNFEsV6ouSyrSVWgU lwA4xyWG9iAAAiAAAiAAAiAAAiAAAiAAAjNAgLLsWNVy2kyP/sR+CUyMcjqiU06QVDqhpBJBu+zN gGNXq8n6+tNQoyLPowMO6l1kYC02BOcWweEyEAABEAABEAABEAABEAABEACBthJgChQTnyyB7bVn CbJpUXAUnaGaUHTCKWcuGjL0qLZihzEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQuG4JGJZgWoJBe+rZ Bc1106Q/VyKkCIq9255Fdc9N2ocPBwiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAhMn4BFihQrHkXl owyLVCkSpAwmSFG+Httwj05QQXMxYbJ4KRwgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgMF0CVELK Vp+cnD1W2Zx+p1PVTD5RlCWFoqMMY7o94XoQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQIAJUtZy0 J9PSLVnSKEBKkiVZkShsisVGGQLl6mmaQUl9FgQprBcQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAIF2 EFBMg8qVK6Is62ZGkpIsVMogjYrtvmfn67FfAqlRVjt6uzps7BvsufOp01eHr/ASBK5RAnQbDu67 RseGYYEACIAACIAACIAACIAACIAACMiSkJCFpCIlDTMpiLJoSYIpOQWlSIyiIuearhMmEqjaf5x+ 6s6eyuFVgOhNtHpU30hZS+/bKWti/91jwrnGa4hjP3AgdM29Rx779oOrPK1asROVlsf2dF+/fbiF eOF0HqVf1jKGSsebr/rp8hhsmMdQlwLnPSr7udpuJtdbW8ccff200O0d33zsyL2RFmcLxnEJCIAA CIAACIAACIAACIAACIDALBNIS2JGUjKCrMiWKJIKZVCIlER77RlU3NzZY8+pa86ipPwPatDwQfOZ 5ivZu+wtD294bsw5vi086QQlkapCgtAh++Rz9+8OeyNd9eDLTktBuN+29XJVSiJDdfZfihJtcfqp rz8s1MlRPD/bNW+eAUzLZExu0+prehc788QmbcPDt3gFh9oH05l3vnMxRbXpjdJzdbx+W1q3bfPV z1A8/9vnyqoHv/3Ypt33hoqT7esRlkAABEAABEAABEAABEAABEAABK4YAVmQFErZE6wE/cfSRUuX KVmvkqlHEpUgi6JiUbxUk+rkuLh79+6HH35Yt6OonIP+TGeeeeaZwDHse/LhgyRA7Lyj0mrVgzuZ knT6qcd3b3IFoTt2ktC0+8UoSlJjZ46hQx77D1a74vvVLEcJHD+v2PxE7KhFbo4a5kKK2Fm7mt2x 8xAJDo83Z0dSbMymFue9Xb7Nlp2W1u1sOSvM9PpxJCmfFTJrI0bHIAACIAACIAACIAACIAACIAAC bSJgUHKebBmKlUhQ9p6QEIWEZUqaammqqesWba5Hhc55fVEY1XvvvffGG2888sgjjiZFv9Of6czR o0fpU66T+17cLdx/d5NEdPql5w8KG9bU0uVWr2tNmWCGNn3lLm/eXTgwn4s4ftq2vFlj3iiOKOcb kwt9naul4IUly/G51efOeapjBaUKekfg07XzcZhP4bwFYdWaDcLB519qY70uZ7wuuYqTjse3PHxQ OEhBWY25nb6cK+Cqn1VH62/fGWuzneB+fQgFrVvfdcXzJ56fFU+a5j3Af/76ieVnPbfm9NFVd31l U3tXSJR1iTYgAAIgAAIgAAIgAAIgAAIgAAIzToBl44mWnBAlRVYSkqJIMtWQUsu6Qf/TKHWPtt7T qISUryOyLP/BH/zBrbfe6mhSxWLRUaPozKOPPkqf8tw/ffKIsGndat+P684zxaKV49SxemErkg26 qEHE4vtJb921hMBDtWI3vPOkVrjtKS5IoOgtN7mQp0bdK1SS21huW6j+E5MbN1WwPmWslgJZEy1u oazGQ00fRELc2IgJjs0HC0vb9Ng3w0Pa/Pvcfe/j6+ycz+fuP/jw11kAljPYCvdKwmAFP0t15HGm hFHH0qHHBMeQfTTbp5O+dgL69Xedu26564rnTyw/mTN+8x7gP2f9xPaTLnBTdP2i9WxF6tipllYX LgIBEAABEAABEAABEAABEAABEJi7BCTRoqgoEqFES1AkIZOQM0mR9tcTLHbGtERdoF/0B84ue4lE grQnR5Patm2bq0YpCqUARjnqglnY+/isHUx94h/1QTcskuX+56q5bqsefKiSWsg7L3hDraK8Y1P7 miTDUtgCw0TayM121B1ZA49TFRkuWEtrdQZJ/3EOplBMo4v7n6tcfMfd94f5Esy5asmO5HJVET/7 8eYrzKumz7nrirXkjTeWn4HzHtnflvwMD5I7crKNQXSRB4OGIAACIAACIAACIAACIAACIAACM0hA lkxJsAQKhyqppExlk3JHNkGCFJOkqFvLEum/Jr+GFLUh7cnRpKamppzYqEhqVOUF/46d1aLkZIoF zNSFQwSFUoVRadNbrJ+fQqMCVI304Z0XmDZSrYZl52Vx4sMqg2LjrmWX2clmQUf7uLGOfXIp7c4P Pnwv+cH7NGw6fD+v4+UWNW9P9FUUh4I514bKVmlQqa2Y8xXomt+65a6rKIP0tOH6GTTvMfqI7ydF WrH4MyeRMjQMMIYraAoCIAACIAACIAACIAACIAACIDCnCZAaRTvraZqhlgsJRU6nE6lUSjJJg6IP 2AZ7jjAVcjia1G//9m9TBl8UNYrFCPlVrbYz9Dwv5HW1kbznA1L+bFeZ/tOG0jM8P5tw8EKU6s9X QoBY7l6EACDK6qtkl9n/CboikFvY5DV9zlPymENs48OIskGE+WJhObFLfcUeT8gFMTgHWmqHnajr djohcVw/26TgeiFF8rOS/WcnRt7iu6eet6xcu6cf9kAABEAABEAABEAABEAABEAABGaHgEV1ogxT U0WrnE3L6VQymbAjpKi4lP2bQP+lffdE2nAv8CAd6rd+67cogy/SMJwkt2Zpw05Oc8v11GoJ1dc2 ts8Hlyx3DNVeb08/9VTYZn1+9ZO5frKAJ3dD+n2D91YS7OxAKJ/zLGXPIwSE7mtn+/Lwk2Euu6x5 3OwGlcgsVq1nd9jsOB3X6iU1tmc745FsEKZJRZkv25/alophnk3/c58S6nE585wItBOndDtn3XLX VUwqXD+D5j2G/9Py07dgXIRwwpgM0BwEQAAEQAAEQAAEQAAEQAAEQGAuEFBEK6mYqaSZy8hdnalU QiYVSqL/25oUU6Po94CN9loeAyVB1VJ1elylhKIlWClqJ4PHU0uInafS3k01hipberHrnfijqlRi pwJtcssSfV24K7RGtu/bOsdPOs2ChZr84Z7/ppuXVLfJW3VLssYB2O4fqRZVCs9m4nP7dpXCLcce eu7+6nzx+mX1vz3z4pNF5fbkG8tStc+bL6aPVUZlF3mPECnmu8S48x60IO/YWVtblYUSlzNXkQqa L59+uW5y1i1vXcW9/7jjDZp3H/956ye2n7WtCZ37vUGrbWm7zLhQ0B4EQAAEQAAEQAAEQAAEQAAE QODKE0gqVjYtdHfJ/T3peb2dubQiGqZ48I13KSDKsExN00iZ0nVV09T7Di74hvLS7//ejpa9HB8f j3gt26zr2EOBZXsiWorXjO2VNr2K2v79sfE8/5Vape6Z7Gc2uMWjjNYgEIlA420T6SI0AgEQAAEQ AAEQAAEQAAEQAAEQuIIEuru7Dx06FL3D1atXP/nU7m/pd/1T4+We3o5cLpNUpBtXDeTz+rnzI6yw lHOQRZN+sTgp+u+VO1j2zu7Hn2J7a9FLaWAsTludqmSktb3Dhlo69oZ+M1EYZ7a4tXUSYAwEGIHT T339YeGxbz+4CjhAAARAAARAAARAAARAAARAAASuQQKmIZliQkpaBpWRMiSBKkqpkiWIpEVJ9mEZ znFFBSmhogxRrhpldt0dmm3XvomxM9IqWlj7rNYlPdljem5mwr9mjVv7WMESCDACVCkuUvF/0AIB EAABEAABEAABEAABEAABELgaCZS0kpwUkknTMvT8ZF7XrXLJoJS9IxYLjRIoZY+S9XRdL5dL//TN JVcsZe9qRAmfQQAEQAAEQAAEQAAEQAAEQAAEQAAEQOC6ItByyt628T9ffeOK/r6uUr7YP3+JIKY/ +OisRAFSzrZ6znZ7tBGfk76HAwRAAARAAARAAARAAARAAARAAARAAARAAASmSUCWhKQi069MNkOx UKZZkimF7yc/OeJIUXaEVJkOXdf+2VvLphkhNU1fcTkIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgMCc ItBaUfPt4ovrVt/Y091BuXu6LshKdnRkipWOoghHS8XkAABx/UlEQVQp+k2iYClRlGX6qzSnRgtn QAAEQAAEQAAEQAAEQAAEQAAEQAAEQAAErlIC6UyKqkUVSyVSnZLJlGUIMhUzJxHKPlhdc1mWFYV+ QZC6SqcYboMACIAACIAACIAACIAACIAACIAACIDA3CJgGub5i5dOnjo1MTplGML46FixVHQEKVeN UkiTIpFqbjkOb0AABEAABEAABEAABEAABEAABEAABEAABK5OArqhj02MX7x8uVgsmLqWL4wrCYGC oaioOQ2okrUnKxL9ujoHCK9BAARAAARAAARAAARAAARAAARAAARAAATmFgHDYBvomaxilGAKmpIU Fy7oI+3JJE2KKVJ2JalkQkkkEjPneMwt/E4+cVs1p5D994G9IZ6x9r6NPIaaP3c+DDUe1HeDo+Jt T5y0mwf2O3OYgyzvfaCKtOpksB+B7Z3xRTM0O8NFryAAAiAAAiAAAiAAAiAAAiAAAiAAArNJgHbW ozpRmWx6ampyePSSpJg9fZ1uDSlSpujPsi1MzVTK3jvvvPPKK6/Qjn6xMGzfQyoWO/Zs37W1Vdlo zY79jolYXcdr7DpKHe3fsca++Er0G8dLUpe2Ht55grE4sVMYHAhT4YLbn3zivkFh8+Y4DqAtCIAA CIAACIAACIAACIAACIAACIDAdUVANzRTMFPJZElVh4eHSZ/STVWypR6Xg2jrUTMiSFE31OvQ0NCr r74aV5Ny/Nvy0M7Nwq4XwqKk4k+qoxo9vSX+lVfbFXtf2LV55zOOWLZmxyPbhV2PVkK5/EcS3H7v 44PCzmce2Xi1UYC/IAACIAACIAACIAACIAACIAACIAACV46AJeqarqp6qaRNFUqaYYyNj7EaUvSr KkrVpKm2u0U61+2337548eLpaFJVr+pT8yiMpy5prJYnFxYAFJhS503Dm4GktFoqXF3YFy/5T/C0 b4gTsz+J4iHpS8LGtU7sFg390V2CcODIiWpioQvLtcdrb1+/94Gtu7Y/UokEa/tygUEQAAEQAAEQ AAEQAAEQAAEQAAEQAIFrg4Ao67qVz5fKmk6ZeaZlFooFStOjeua0y54lyRb97uhTMzReyhicjiZF ATkHNu98KCyQadfWgSOPODlpm3dtDZGkuCl1JMoMDG6sZgu6KXjtIkOy0wv3eFIRq3LS3gfcXsl9 YfPOE07yH7Wvptqxq1qP5tq8YcAxJxIl1gU7iEINFhOa3H4F3/YVOWv7ntb9aBdI2AEBEAABEAAB EAABEAABEAABEAABEJjTBEzdMHTLMshJyzDNYrGoJETaU4/+JykJSVFEWaFkvUqN8xkaCmlSt912 WzKZpDipo0ePRumFCkc5B1NkqrWZAi6kUk6OTmLnpB0+7lQXj3mw2KC4eovraIQK6SQBuWLOlnvc ylZ2t/c4ktuau7dttuOXqseBZ1/0H8uWpz1Vq0IHeoKJUc9uO1Gvaq3Z8Qzpd48+8QSLe9rjxezX 3i4eFa4NhvqCBiAAAiAAAiAAAiAAAiAAAiAAAiAAAtc4AV03ZFnu6OxMp5O5XC6hJPv75kl0iv2f /UbilGhn781UhBQBpupR+/fvV1WVcvfWr18fBXmtVngENarJYJ2kE6U7u83J44ddYSjyRd6i5qGh Q97MvK2UOuccTJuqVsk6+eKzB5z4JDrsGCYqQm4rc1Gy83heHxjcysQoB+WJIwdq7ZgkJQwOkhzl dd63vVM8Ctl6kZcGGoIACIAACIAACIAACIAACIAACIDAdUuAippTfJSiyIlEJplIT0wWznw0RIFR CTpFgUuWJVomS+QzTRZENRMHmaaK5hQbRWoU5e5RpzPRS80mk5VcSSd2Vy3GVkXqh2XmCc5md817 /1UirVjunleCq2QXRtsdz9+LgQ2Uoler+1Qvu7Gop4172FaGruDFac/iuA5UxDEKXKv8ZToyWSRo aAQCIAACIAACIAACIAACIAACIAACIHD1ETAsvayq4xPjaqFcmCorQnLo44tUO8qiGlIUGUWJfKad z0dFpWZicCS8tFeNqkQSsepKboRRneOs5lSLVbftdLnB+wJ3oGsXJFazqWrL3tWuqlNxKkWtWdu4 rV3kouZ1G+sxAepANT+QSpQzAezpLVue3rPdHTmnvZ0i6B57trNSV1bby2y1iy/sgAAIgAAIgAAI gAAIgAAIgAAIgAAIzCIBgw6dKU4jwyPnLwxdvnxJFC3JJJ3KNOkXbb+nlnVzxtL1KNWsv7+/TbFR TsUju7gU1eYmScRz1GpOCdVqUu5mekz6cT534nmqiXON5+tT5FrPkuPZ3/LQThK8nAS8RzfsdP2n 89W8PKduVq3YeaWQVqWWVmhKIGehbXnazfyzq6c7dkjRYoXMnXrxFd+cavD+7WdxFaNrEAABEAAB EAABEAABEAABEAABEACBq4pAMqGIoqkWy4apZ1MpytMrlgri4aOnKEtPN0xN01S1TEl9hqZ97dW+ bygv/f7v7Wj7ACmuhiSVtpu9RgySfsXKjbuJekwoilbJ/RoBgGGAAAiAAAiAAAiAAAiAAAiAAAiA AAjMWQKHDh2K7tvq1auffGr3t/S7fvn8tygcigQnUZCzuSz9KZFUJBY1ZdL/KGFPFoUElZEyrBks 7QQ1Kmjm6oqMO6XVhY1rWflxHCAAAiAAAiAAAiAAAiAAAiAAAiAAAiBwNRKgTL1iIS9JYq4jRyWj 1LJWLJYl0qN0nTL2TKohxcpHUfjSjGXtXY3UrqjPTgEnJ5OPZSPWkuquqBvoDARAAARAAARAAARA AARAAARAAARAAATaRKCjq3veggVLly2b37+gr29ed1dPIpmSRPofFTWXLEGi+lL0i7QprU09wkxs AvX1wjllzWNbxQUgAAIgAAIgAAIgAAIgAAIgAAIgAAIgMDsEunv6Ojq6k6lsR0fnvL7+dWtv2vS5 WyVZlugQJZPqS0kSxUkJEko8zc4EoVcQAAEQAAEQAAEQAAEQAAEQAAEQAAEQuNYIyHLWtBTNknRR MkQ5lc3Mnz+fgqNYmh5pUjIdipxQJEWRr7WhYzwgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAKzQUCW UoKYlqS0ISUtJVHWjfHJSUrXE1jGHqlSlLTH3KIKUigiNRvzgz5BAARAAARAAARAAARAAARAAARA AARA4JojYAmKYKUMVbF0STIUiowyVE2S6X+UsseUKIttwscOlriHAwRAAARAAARAAARAAARAAARA AARAAARAAASmSUA35LIqTk2apaJRVg1DEwzLZAl6iYSSSiqpVCKVSrJfydQ0e8LlIAACIAACIAAC IAACIAACIAACIAACIAACIEAEREU2RSogJWqGqBqCpguGQfFRskialJJIJNmRUBIkUKGGFBYMCIAA CIAACIAACIAACIAACIAACIAACIBAGwikMonO7nTfgu5MZ1pJKbpplVVK3pNk0d5Wj1L16HfTNOhX G3pri4mTT9xGFderx21PnKy36nz8wN629BXDCL9fj8Meb2faz5m2HwPNHGy69wH/BcQ5Xztdv7L8 z9et0PCVyJr7tuLb4flTI82ura62mP5wpyvMjvN5bY3X36meD1gPbVmf4Rw8g+Fypja89WBf3jiu sPUcyKFxpmNx8Iy3AaefT4H8440r/L7w8aeeQ4M39v3nwAhcV7UP6x/1vuc9lsLvu/p+vQuXP8Ec DvH6DVs/+BwEQAAEQAAEQAAEQAAErhcCqYSS7Uj19GWXLutfumxef39HNptim+tJbJM9e5c9+rMk 0J/nEpLte5zCVtaejYMDs6A+xWBx8on7BoWdJxx39+9YE+PSCE29ukOE5mjCCNBb5dbDzpSc2CkM DlTfXTnnifFWobLg9mzftdWj8/ieF9bs2F9ZnhZrH+HV2H9eOHZ4/nAnd4b9qfRrL/TNmxu8cO9U 7+Jnr/X3Cdu2T285xubA6463Hpz2/uPiu97cnss/Hgc23sqydRbufY1ivI9Tvvxjjivgvgjwp5GD h4Jz520WNm8YYK7w1yf1PPDstuaHp+954uM2PrHzsHufBq4yPp/my/gc4vc7vaWPq0EABEAABEAA BEAABEDg2iCgltXC1MTk+PD42LBaLlEOXzKRkkxLtyguytINU9N1zdTFuRMgVc99y9P0YrPrUc+b mfN28/SWKz0/vH5PHDmwedvdzTrUTPs50/avNN/29bf3hV2bdz7jSINrdjyyXaisH955RrK6nrbc s1048OyLdlQe77zX04ENm4XDxxuC+FoYitdOlH55XcyEP05fex8n3fWZRzaGD27vA0zH279jbXjT wBbT4eA1zJv3uOOK0t7LPy4HepIIG9dWniRr1m4UDhw50TrCGPPFuV+C/QmxTx8f2P5Ikz5ftz4J 0K7te5pFfP/zJ198tmaR3dcHBh9va5wsZ53MeL+tzzGuBAEQAAEQAAEQAAEQAIE5TmCyqJY0q6yJ 5ZJ8abRweaqYp5Q9UaCUPQqSol33ZNp4b06PwX4zcyQC38QJ+6Q3SIWFJbjZH74pGJXcnupn3lQR b86MazRuwkZQe2/6iqfj5twkp+HA4AHhAAWJOUflAr59r/U69x/Y6/bQlATZOP0OHt/28e2HjrfR HbvfUB9dn5vt03tl7b3+5BOP7hKcN3ve+emsfvayWidH8lPDao76RFQ12eE55dpnC6P5iOxPYAob 3WnN4yLtoFlf8HVzy9N8vThmKiV3bmJwDpx3W/vwGRc/hzOQQx23IA516WSV1b7lIdLeK3E/zK/N Ox9yZfeQ+WriFGNcXD7B/gRzYLfd9nua/tWgjs/J44f92gic80wf8xz10mtcPj78eRwC+53OwwPX ggAIgAAIgAAIgAAIgMA1T4CKRhU1vWxYJZ2CoCQKjCqqqqTTXwxTpw336GB1pOiXOVdZsDcP56ik fuypSwVyYmBecP+tnL1XVF4xWQqGm4tFuX9emWPXVvHRDSxXxJMbU5cz44nC8u23WpZm666aYlSR Gvzb0wBYJsrgxmo6opvgR/2+cE81R7GaM+YYsRNfqgmB1Qs49llKi2ud5bR4dLpdW53RUo7ZgSip QH7t49vnjDdoXmKtQo79SqoQk4AGjjzCEFYOJ4Wo+XytU7Z6/ALeGs9XXoAHWNSQGwYSMK5dW8mT SiaTN8nP146HQV2/XvueUbHmsfwJ8NPfHybrbd/jG5VI91GdWBo0f7x+I6wHLgeW0+u5r/058+ad My7f+5ENjM8hbB7rsXDWLbuv7Rxl0X5uuaFDIc+xZv5xx8Xhw/MngIMzTlt38shp/uuTxZZuENyK ge4scs6z4EU3VpblC7r6VGw+sZ4b/H5jPavQGARAAARAAARAAARAAASuQwIUBCVJIpOcJMmSREOw dNOUCiUtT6FT5XJJ01Xd1DSD8vauWjr2v+RXFSlbj3L+ad5OwagGGbBG1Vwse6TVXJGG3Ji6NoFI KADCUXhqilFIIqHtm897Pb34uVey15/WDju1xLXeoNO5mTER7fu0j2+fM97gebGxRqvFxeNJ/E4w MYpVp2mYEt555z2aivi4aqZnEnzOVybfOrHtWbfGWdC4qJSN44k9L7UkPz87bs/1/TKVof4t3+Ni HH+C/PSz41RJq0XruN3W1QaiOL6QuDZev8HroXleWuHsN+9B4/K7H7ntycXAeWy8n3nrlimlThUp VprMDRPkjpfDP+64mHu+9wXHnyAO9lB90vV8+LBAqAODjwrP2I/RWrE33nlibDey9bf7hEdcnTku HztWkqOv+nHg9dvaYxpXgQAIgAAIgAAIgAAIgMB1RCCXSaeTCVmydFUtFUqGSpKUKJVKaqmklUu6 VjZUVaNfmqbPVSoNKRM+bq65e1tVkfK8nDgvNtVsNzv5zXPU8knYu1JVLNhfe+WJnjUWFRwvRaV+ GyqSRFo7GjnVIstas9d4VWz7nPEGz0sMX/k8DwxuZWKUI2t5/Oadd16jH6AlQtFojaoi77x9kUf3 izGu5uJAjXF+HH/cEkM8TBH8ieSnx45TLCikWv+Wp0mYDa55xOs3zJ9G/mHtPWiqDvnOe8C4vHmg 7v0YiYPPPDZNFW/d2jqOU1KJnkluKGOk8Xr4xx0X+ed/X3D8CeMQKJx6+LB/CXBrvXluJN55+26r 7iawf4dQrbgVlw8vJZDLgdNvjCcVmoIACIAACIAACIAACIDAdUogl84mJEWyRFGwqKK5JCUkISXp LCTK0HRD1egXpe9Z9GuOEuIlUXnddRUppkd5K4zXst0iboJXfeWp252tjWT8CmCzN253nz4WcdWe I1zIm14/kexzCn7Hnheeqz72bSGuVhfIff3nnbdN28FI5FVjaBbvfJ0/lc3E6FyEcTF/ahdw7PD8 iVY/PdyfCH6y0bAMR3b/1XTdaoJqk1zLhhV+8Prl+sPhH8F/lzNn3vnj8r8fI3JgDDjT68XjM5EN C6NOTw4fr8s/7rgE3n3B8SeMA5OxfHd5qA2/xqdBwnQ/4J2v2fBEwka67xrWZ4znRv2qru83fMWj BQiAAAiAAAiAAAiAAAhcGwRWxzncIScURZJkRU4YGm2qZ5qGRTKUcODg4R+//s7fvfazV3785g9e +cn3f/j63r99ddEfHP3Xj+2s7mc/e/9l1XGqm3XblXIa3sZsycazm7fjKZ3cvsf+zfXcvripYaUw k99575h9OvHtty5lrx5aU3vf0diuu2O05SjvgL0fNsxJo3372uq4PNd5gdanGPpPMq99bPuc8XLn pTqRzVPOd7RpdThroXq6ri/eeY6fdgEvP/seb7zTwxtXHU//RVS3Bnj9evpyVMvGG6N+6I4Zn3Ue zN+9nXxH7k1Q9WCIdJ/G9ifm+uFy5s17/Ty6NAPvx8o1HA7181hrWz8NAc+Buvu38pcI88VdqV4/ uePi8Gm6330WUxMHzvquoq57nHkL5DXeSNXZ8H3+1XnGXefc9cmjFbpO6vutpBraFeqabrNKjbfI 52fv5y16BgEQAAEQAAEQAAEQAIEoBMZiHiQukcT0b/7w2f/n//3zf/Ufv/P7//bPH/l3/+PRJ//8 333rWeHHr7396oGf/Wj/W9/70U++98Of/O3LP/7rv/nBXBKkahpio8BUH1Lilvt2VIimF4P60s/V l5x6xaUG3zFROWpv+w31o5sVowZhIKh93Wdef9xed3pqUtUUGudj54IA+54R1Ptfw8h7la5hCBCw Ytv3HW/jEOr42V34SC0BmlTglNW9EnrcqSPSqFnbH9YtB6eFfb5uTPVvnL7rrf5k7QKeHV6/np6J T20e4/rTtIQqtAPsuPDrVo/X0Wj3qf/9yFkPfA4Nt4Cf/z4SkGcKmxZT3bg8Xm7e2XQ/Vm9Kd43y uMV+DtQvOe/K8ufG4e8dXMRx+d4XDbeAr4Tf8DTxlY+C1lVtCPW3vO/52slGX2LzCX8uebrg9+uu 3MjCE0+oivIVAG1AAARAAARAAARAAARAYPYIxNSjxiqC1BN/+gf/8X/82yf/8ok/+pun/njv/+8v Xvrjv3xZfOXHPzNpZz3R0oolSRQ1VSur5QffXvoN5aXf/70d10ZEGUYBAiAAAiAAAiAAAiAAAiAA AiAAAiAAAiAwTQLj4+OxLDz51O5v6Xd9s+P1RELp6uzOdma6srlUKikrgqRpJhUx12l/PUMnMYqV kDK0WNbRGARAAARAAARAAARAAARAAARAAARAAARAAAR8CWTTUn9vpr8nNb+jIy0nJFMwdUMqqHqx rBbLRlm3iiRKCYKpSCAIAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAtMn0NWZm9/Xnc0mcmk5qZA9 FhQlTZa1gm6WdEuzlLKZPD+sDl0uTr8zWAABEAABEAABEAABEAABEAABEAABEAABEACBjlwmm81k k8kkCVIUIpVWZFmS8qqRL+njk8XL44Wh4anRSePi5RJggQAIgAAIgAAIgAAIgAAIgAAIgAAIgAAI gMD0CaSpaJQoJihZT7aSqUQqmUgqCWkyr5VKVMjc1DRB1ayiWjLE6fcFCyAAAiAAAiAAAiAAAiAA AiAAAiAAAiAAAiAgCKKo6wb9KhU1+p221iNZSrIMUdcEqmausbrmhiAYsgxFCssFBEAABEAABEAA BEAABEAABEAABEAABECgDQTypXJJNUplStFTS6Q+WVYqmZQMU1NV1RQpeEpJSUlJSRlmGzqDCRAA ARAAARAAARAAARAAARAAARAAARAAARBQi3qxUCoLZUGSyqpapmrmBV1S5FQq1SEpSd00y2pJtGSL wqRwgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgMD0CVhGKpHMJDp1PSGYCUOXSyVVOj+SvzBSGJko T6mGJomXL18eHxmdfl+wAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAKyRGWjLCphXixPlsv5YmFi 9PKodO79s5fOnh8eujh6/uL4xcuGURCluRMidfKJ20TP8cDeFqeR2bntiZMtXh16meOm613rvbEr Wx5kqJuBDfY+4IKeJQ+m5z+uBgEQAAEQAAEQAAEQAAEQAAEQAAEQmIsEVN1SDbNsWbJI++2l01Qy ShSl3p7kvPnp+fMz8+bl+ns6ls7vWzivZ065v30P6Wjs2LN919YrKNfElJU2bz786MxJXjM8IzTW rUKFM8M8g+LdDI8E5kEABEAABEAABEAABEAABEAABEAABOYUgcmidnF06qOLl2mTvSlNKwuilUpL a9YuXbFy3pJl3fPmd3T35BRR1FRtTvntOrPloZ2bhV0vtBolNdOD2rZt47MvzlgQ1sx6v2bHfuvp LU4fW+7ZLhy4akcys5xgHQRAAARAAARAAARAAARAAARAAARAICaBibHyxYujum5Nqsa54fEzw2PD RU3qSCqSaRilop4vlqcKY5OFiXwhpuXZac7NMfPm+fmE+jgf1z6o2amec1oMDB4QDgwOVBLZIsQM 3X1PkyJVn4JHPTlm6A8P7HX6fWBvoz+CUBuAN3mu2U+yVOmg+lm9l/bZCI7PzvyhVxAAARAAARAA ARAAARAAARAAARAAgeuAwOvfP/z69/7+2FtHz50Yeu/Qe0d/+t7Z0+ekYtnM5/Vi0dQ0QTdESxSk RGJu0tj7+OCBzTsfsgN5SIh54R5PKp8ru5AIMzC4sZrlZ+3fsaZuMHTdwKCw80T1A2pey1XbODhg 22HxQpZ1guKxNlNL52g05IdoS7MixSW5a+ujG05QF7u2Dhx5hP5bi0myz7Au7U8rkpSvnxXjlMhI tuwLhMH7pp02uPeFXcLmbXfXc5ubKwJegQAIgAAIgAAIgAAIgAAIgAAIgAAIzHUCxw6f/PDkh8fe PPzG9/a9vu/lv9u755X/+aJUKJbLqllWRVWXSoaQL+rj43MrQor0FufYenjniaouRJpRNcXMzjGr HkxN2b7H/ah+Tk4wNYrEqpq4RM2rEhflqlFK4PRy1UiRGnw8Ykrh9kccrazWf8VZqpnl+L9mxyPb hcPH7ZCqQD+373FGtGbtRuHAkRPuoLc8HVFJq2FixaSIYMW3ub6k4R8IgAAIgAAIgAAIgAAIgAAI gAAIgMBcJ6DqQ7mOci6j56cuj44MDZ07dfrYzyTdFFRLUE1JtRTNSphq0lClOTUUt6h5XZSSNy+P JJTKcfL4YWH7PZViSA2jODC4lZLw6j5lzWtZeXaS3vQO0rQOt7fIlS0wBftZGxJToDhiXKRx7X2A EFBU2HRsROoIjUAABEAABEAABEAABEAABEAABEAABK4TAh0dpXQmXyh+rKQNSy6bYskUxillT58s lCfL5bIpCIlER1dn77zeOU+EKScs8a66/Z7XYSemqPlg6Xc+O8jVsvIip+YF4Flz97bDL7zYJn5M h9q8YcCx1l4/fTy0g6OolyjJiW0aIMyAAAiAAAiAAAiAAAiAAAiAAAiAAAhc6wTkpKUZ+pmzQ2fO fVTSiomkbEm6ZIkpXUiWDaGglguUvZcVzewcrSHFmaC9D9QipEgP2nwgoI7SlqdZnSWnUhQdTnNO kp2dABd7tzmmSD37rNfVyr6ATjJcnIPVzHKS5wL95JuMUdS8WlsLalScGUJbEAABEAABEAABEAAB EAABEAABELheCQwODjYMvfmM02B8cvLsuUtnh8Y+OnNmfGJEM8qaYZIgpeiWMDFZOHfu/AenTp8/ e+nyheE5D9Mu91TZAe/RDTtrNaSotpQtOVXKTjXvMUcN9mxnl9rVwu3mh6tFqhr2pNvytNPSPiJv VkeVnzYeqKb+rdnxDKtMzgxQpfI9NT8DCNdqZgnValLBfrZhtpj2JXizF9n2f22wCxMgAAIgAAIg AAIgAAIgAAIgAAIgAALXKgGvAsVTo2jsS5YspV+rV61dMK+/t6eru6ujq6tL/M3/67/n1VKxVDDV sqjpiqCkUvL+FVu/obz0+7+341pFhnGBAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAjEIjA+Pu62dxWo nTt3ev/sNfjkU7u/pd+1/K/+t77e/q7OrsuXLyRTKVGRL126LHX35JYvX7R+/epbPvXJTZ/77Gd/ /jM33XxTLG/QGARAAARAAARAAARAAARAAARAAARAAARA4LoiQDqUM16eGuXSOHHy+Jtv/fS1N/af OHaikNd1VTr38QVpyZK+/i6lKy2kM6YmTRbLwxP5C9cVQQwWBEAABEAABEAABEAABEAABEAABEAA BEAgLgFXk6ILvX9usFPOTxpqURGtzlRay4+VJkdkwZBMUxdM3VRVtVDIT0xNFkolzYjrAdqDAAiA AAiAAAiAAAiAAAiAAAiAAAiAAAhcbwQcHSpAjaJPFy9etvKGG3t6emVFmpicvHD5Im26J0kCSVSS plqmLiXlnCDIgqBcb/gwXhAAARAAARAAARAAARAAARAAARAAARAAgRYIBKtRZDCTThm6Xsjn86WC IFsJWcnlcpKum5KUkOWEJUimZQmGqZe1FrrHJSAAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiDQQCCX 61Y1XRClnnn9spJQdS2TSUsTl0cNVUsmpIQiGFqpVJjSdQhSWDwgAAIgAAIgAAIgAAIgAAIgAAIg AAIgAAJtIJDOdWe6ejv65vUuWJjq7Mx2dvb190spUTLLumSKHal0X64jk0xkFcrawwECIAACIAAC IAACIAACIAACIAACIAACIAAC0yVQLGqSmBbFpGlJqVQ2m8tZliV1d3emUomkomQTqe5MZnn/vPmd XdPtCteDAAiAAAiAAAiAAAiAAAiAAAiAAAiAAAiAABFQrdJkvjxVmBqZLE8WzZJenMyL/+GP9pm6 LsuKLIq6VqL0vWIx/5T2mW8oLwEaCIAACIAACIAACIAACIAACIAACIAACIAACLRM4Fv6XfOf+d8K U+OiYi1atKQjl1NkaWTkkvjk7u9LFlUzF3VD14ySUVZNU/vDqVve+93FLXeGC0EABEAABEAABEAA BEAABEAABEAABEAABEDgpj8cuuG7/0It5QVT7enpUWS5rJYuXTgvJRJyB6scJUqCoUhmIqGkkxnw AgEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAIHpE/jsF/7h52778ic/e3vPouVWutNM5jrmLxL/9G/e JB1qdHhEUw1BMjOZzPjY+L+/vA4RUtMnDgsgAAIgAAIgAAIgAAIgAAIgAAIgAAIgcD0ToAip+4W3 JMsSDFVQBE1TBZGKm5tSIp0wLLNU1jRNKBWEscmJC8PD1zMpjB0EQAAEQAAEQAAEQAAEQAAEQAAE QAAEQKBdBPKGqSeTqf6+nr4Fi5bdsPCGlT0Ll0qyLOcLhdGx8YsXhy9eGjv+4cWLI4V2dQk7IAAC IAACIAACIAACIAACIAACIAACIAAC1zMBU04YckITUmUroYppQ+wQlD7xpTfeH7547sSx00PnRkxL ETPpdDr1FyJ22buelwrGDgIgAAIgAAIgAAIgAAIgAAIgAAIgAAJtIEC77N0rHk2ms5KkJJJpWZbS 6YwkJcT/9t0fdeQS+YnCoUNHLpwftozSjWvWPCP+wjeUl7754P1t6Ll9Jrq7u9tnDJZAAARAAARA AARAAARAAARAAARAAARAAARiEBgfH4/RWhCefGo3CVJfHPpRpqNbF0Ql3alrRcEyDFWVFCFNv6dz nbfdfuu2r/3y3f94y00bVsWyjsYgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIg4EtganhEn7jcKxf7 xOEeZaJLyXclTen80MWJ0cmpyWKxpJVKepaKnEsyCIIACIAACIAACIAACIAACIAACIAACIAACIDA 9Al8dOzQW298/8ff/+s3D/7YKk0um9+3duUiabxoDV2cHDo3evHcyOULY+cvTV66PDn9zmABBEAA BEAABEAABEAABEAABEAABEAABEAABD764K0PT//s/NkT7729/3v/87kf7Xn+zdd+KGW7+7Nd85Id 3WYinTeEyYI+UdCjwDr7xncqx76jE54L2nU+ig/eNnsfECvHbU+c9HzAOx/XviCcfOI26uGBvZGu rHUrivUORbrcbeR0ah/1PccdF799rYtojga0dz4KNcOaBXKMaKcOJbsmtOd48CtT7ss/5nrw69gz t9U5jrq8mkbuGuA46z/wes4t+cNZV7HXf1vv38b10zCyKMukrf7EXHaz2nwm7iN7QLGen3wEnrmM Mo++hhpXesuGZnWm0DkIgAAIgAAIgAAIgAAIXEUEUmkpoQjZXCqTFC9feP/Yuz/52U8OSMOjo5Ol YlkQVTmRl8VxtTRRVkNHRarTaxM33/lVOu68WXj35TfOOpe063yoAw0N6O1x6+GdJyw6TuwUBgeq agfvfFz7Ans9vU/Ytj3ahfS+U3XHcei+Oo0smhHnFW7g2W32sMjM4a3ue1PccfHb0yduF9b+HWvC fAtqf/KJ+waFzZvDTIR+3i47oR2FNlizY78Nn44923dtrYlo8dYDpx+PdWeGNwubNwyEOtXUoFU7 jZzj2+Gsq9jrv733r//62b6nOpXh67y9/sSf0WvuirbcL46mNTC4sTqTzwiPt/ZgZXw96yF8QVxz E4IBgQAIgAAIgAAIgAAIgMAVJrBu/c0LFi5OJ9N9fQs6Ojo1dWpk+KxUyBdGLo1eOHdp6NzFoY8v nRseuTTuDXjydfLsx2e6b751fRf7sGv9huXCmSN2lFS7zscls/eFXZt3PuOoKWt2PLJd2PWo/aLC Ox/b/gNbhT301rI24oUnjhwQNq6tiDtr1m4UDhw5EfFSb7OTLz57YPsjFZGIjevA4ON2fFbccXHb 731g667teyLoUBW3AtvvfXxQ2PnMIxtbGGndJe2yM10/6q8f2LBZOHzcib0jDLHWQyRPaNi12Y50 hX+jyHZCOEeww1tXcdd/e+/f6a+f9vozjbm8Ri5t1/1iL8k91tNbKlzW7Hg6XEK/RhhiGCAAAiAA AiAAAiAAAiAwpwkMDg4G+6fr5WRS6cim581f3N07v6u3N9eRkpbM7+ntzGQlKSkICVGgeubhJc1J dxK6umw5ShAmjh45IwjjE1R4ql3n43Km98ea/nPyiUd3CY4CxDsfaN8vVWfL07WXoCjObXlo5+Zd lXgmpuFs3vlQ9R2qmrniZFYFp4qw93rP4UoiccfFbX/y+GFh+z0118LGFtTe1qqq6lmYIfvzWt6M N30vrh13vgYG62jFTWkMcZmJg5u33e2IjHHXQ8Nw/ebdXrZR5iJkXDHsBM5XFDvcdRW4/ptBt/n+ jbsOmxxqqz+RboU50Ih3H7XDtZbuF/91EuUWaYfLsAECIAACIAACIAACIAACIBCZgKNGBWtSJ46/ OzT0wejYBVExsrnOdK4nleuQUrKREHVZ0pKS3pkUOmWxKxkuSQndXZ3U4cTRfd95eWLDnTd3Vz1t 1/nII680dFKd7IyOI4+w3KeQ8xz7LFWHYl+cHK2NgwOt1hZhyU/setKcnFiaaiocy3irpZyEpIps uceN9WJju8+juPDGy+Pm354Ur80bBLdKVeho+e2ZfrF9jxu6EGH6dm2lmapkqtWS4WLa8c6XZ9ZZ hmVb5pHGUXlRH2DRX62HY4TNu613eWVLf4Kh44poh1ZT8HxFtcNZh9z1H299CpUUxub7mmcnYFy7 tvrWmPO31KbnSYT7YE404d1Hc8K5qhNMDm8ppdV/FO56iF4YcE7hgDMgAAIgAAIgAAIgAAIgMDcI eHWoAE0qm8uKgllW85payORShiAZQkKSFTnbkenqznV3ZLsyqb6OXGcmFWVck0yM+njZnV+9dWld 83adj+KDt80JJkaxgksNqgjvvJ99O1WnGszEwjwOPPuit0B6ZJ/YG7RTRYqVHqoFQrHYixi6zZan 7YpY9ov0fcIjNZ2NHIkzLua3T3v2hndg8FHhmUqRKk/xLd+RctvbRXvC5ZQ6o27qjZ1j6STDxbTD 1AdfFadt80g+UXSHg2fbswMtlRxnow6b9wjpcRUzweszop1QzhHtcNaVowz7rf+AG6gd9y93XHW1 wA5EEprb4U/k50Vdww9++F/p+O5bYw2Xz9h57n3kOBC337ijbsG+G87l1dBj2vHWkKr7mcGzE3dc aA8CIAACIAACIAACIAAC1z4BV4HauXOnM1qeJpVUpEQioerGxMSUpuuJpJxIy1JXR27pogUDq1as v2nVunWrb7hh6YL5veHYxt99jYlRd9h1pCYnxqtXtOt8uAf1LQ4MbmVilBOK5El14533te8ILo7+ Q0dDDlgMl5xaJ7YzpGfsodpPTlXzuClyrCJWtar2/h2CpzJVrHFRz77tWXUrt/ZWpfjWCwGbCPLa O0V7Wg8fYv7ZKZYt2HFLdXmmp23z6J1ypzZZEB7+AgmZ9xBBwLUbNq6odsI4R7XDW1dsIn3XP59Q W+7fsHHZ3W95es/28JpubfEnxhOjuWlvT4/v9TN03u8+qus/br9xBx/NfqUYn6MS00ROnxvPT54/ cceF9iAAAiAAAiAAAiAAAiBw7RNw1ChXk/Id8KL58wbWDay56abeefMzuc75i5esXH2TZJbzhYnh seFzIxc+Hr14tjB+US+GFTXv7KIUveUbnKLmlLg3MSEsX0ZxUu06H3e+WHEloVa/yH39550Psr/Z 2auvekSv9+0x2pBbYrvhHtXC2HEH6UTZ2AWf4o4rqH1DufXQlBif9syxmo63tfKX0Pw/F0AVV0t2 eDjbMY/NUxSKhz+r/Hln8o1bnipsWQSMK6qdMM5R7XDXYeD69xlgm+7fsHFVembeBR9t8idsKnmf r/zS79DxpZWNn8/o+YDHUtx+4447qv01d2/bHCQJR7UT5h/PTth1+BwEQAAEQAAEQAAEQAAErksC Xh0qQJPSdVMUUz29C7vmze+at2T+orWLFt8srVoxf+XyvqWLepcs7F2+eN6q5b0DqxeEYPRurEd1 pN54d9zWo+o23JvO+biz6N1Yz6m15Ag3vPM8++yNp7qRXVwfvO3tffUqG+LZcT/VPfecDpxoqXgH K/LiFmmKPS7PxoNePoJdfNrZkNDeOm5XiC7i376a1FYpvbWdoq5I1Iss5bnpYbHt2JwrSZV7H6gF tLVrHuumKAIe7pQGzrstNEaqBh88rsh2QjhHtsO9v7jrnwOoTfdvpPVjPx5CqnW1yZ94d/gstubd R7Pokm/XzrxUNouYa87BHxAAARAAARAAARAAARC4Hgk0K1A8Taqre14ilRUl+q2rs3u+YSTOnx8T zp47d+bMmfdPf3D8vZNH3n3vZ2+/+dNDBxf9wdF//djOsaDjo9ee+6PK8dK7nobtOu/TtzdyqenP npLW3uIgFu88z5i3NDbVVHbipepPsmXWEKjSbM2bTsJzKNxMzUqdjXqXGj/yHRqXQ62L0DE5td7d PBn/9vR5qKF6nv7+R7HjmRnqs+4K33kMXEE+H9YZ8bjZwnqoX0M1QgxnKC+Pa7xxxbXjmmzgHNcO b11x1z9nDtp1//qPK643dbf8tJ4ncZfcLLV38TfeR23xp5X7JdYDOq6XjQ7FuQPj9oX2IAACIAAC IAACIAACIHCNEQhUinw+JHGJJKa7fukf37r5y5/e9MU77/ntf/y//J9f+PJvr//EFvHCxfMC4TEs CqCiylL5Ih2lX9mb/oby0jcfvH9OSXzd3e5mfnPKLzgDAiAAAiAAAiAAAiAAAiAAAiAAAiAAAtc+ gfFxt4h4pME++dTub+l3Jf7LPaYlpNOZlQMbMumO4UukRX0svXN86M2jZw4d+fDtYx8fPTX0/vuj J05ciGQVjUAABEAABEAABEAABEAABEAABEAABEAABEAgkEBPV+dnP33LZz7z2UwyderkscPvvj05 cVkaHi5P5oWClhgeLX9wYfK9sxdPUCIfDhAAARAAARAAARAAARAAARAAARAAARAAARCYNoGxiZHL wxcLk5N6YcosTolqUS9rUllSpFxOSCZVURAUKZVLJ7LJafcFAyAAAiAAAiAAAiAAAiAAAiAAAiAA AiAAAtcUgVNxDnfkoqAcP3HsncNvJTtSKwZuzPV0pHNp6cLFsfPnx8cmtfGJ8oULY/nypKaXryla GAwIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgMAsEVhxww2KIhWKYx+f/TDdkc11dqbSOenixZG33z19 6J1T50a1VG5xZ+98QUaE1CxNEboFARAAARAAARAAARAAARAAARAAARAAgWuLQD4/mU4p69at+uxn P7l8yTLRTIwPT1C6Xraolo+/f+bQ4ZPvvPfh2IRYKieurYFjNCAAAiAAAiAAAiAAAiAAAiAAAiAA AiAAArND4PyFIU0ry7Iky+bS5ctW3rgumcpJnZmEYqhmaWp89MLJ9w7v2/uDU+99ODsOolcQAAEQ AAEQAAEQAAEQAAEQAAEQAAEQAIFri4BhqKqqvffe8R8feFUQzSXLl/b2LZAEo5gQS0vn5zasWzxw 47yupFkauxhl4Gff+E7l2Hd0wnMB77wgTBzdR1e8cbbeOr99FC9qbfY+IFaO2544WT198onbqmfZ fz2fBBivXeRpXzMvPrA3mmeOnaiteTZ9x0WNeecDfXNcqsMQ105b/KmbFw+hacxXM+f28Gc8PW5F W0KcSWiw0zBae6WGLpe48+XjSlC/ns9CXak3za6cFh3eyvW9H7nLfIb5OP363EfRngmttWLdxZwN fkdxZril+7G1MeIqEAABEAABEAABEAABEACBa5mAKFBsVII20stm0qJoKAlh6bIbpPXrV976mZs/ uWHlZzYs/4XPrbvr9s9s+syaUAykIr02cfOdX6XjzpuFd1+uqky88wKTnd4Qli1vsMxtH+pBfQN6 C916eOcJi44TO4XBAe/b2/Y97LR97N8ROjSyNPDsNttSrT29l20VKmb2bN+1Nfy9m70W3yds2x5z HI3NeeMKGm/Qq+h9g8LmzZ4Gce20y581O/ZX54TxrHvZjjVfPM5t4l9RHwibs7giLSG+sNJgx0PB Wbmbhc0bBoKWTNz58rfF7ZfWubv4T+w8HGGdT3N9h1/uez9yL5thPpV+Tz7ReB+Fj2OOtGhhhmPd j3NkmNNwY8Z01Wn4hEtBAARAAARAAARAAARA4OonkOvs7ujqWrV2zWc+86m0ohQnpvq6eqSUnOzv 7FrQ1bGoM7N26YKbB5be8slQ1ebsx2e6b751fReD0rV+w3LhzBE7Sop7/o3XhM9/9Q7nAs/Bax8X 9t4Xdm3e+YyjNq3Z8ch2YdejtSipOMb2PrB11/Y9TboVe4N/eotjaMs924UDz77oBmH5mSczpF/t 37E2Tt8+bXnjam28ex8nXeWZRzbWOoprp73+OH4MbNgsHD4eiJNLkce5Xfydjk8cObB5292hN0Xo XIfYoek5sP2RQMk07nyFusQa1Po9+eKzNQ/YfXRg8PGI0YCReorfiHM/8gzNMJ9Kt833UfyBzc4V TEnb6D7e1ux4ZqcQ8iSbHT/RKwiAAAiAAAiAAAiAAAiAwLVGIJvL9c3vv2H18hU3rkmmOobOnLt0 8bz01uEPz54f6+zsv2H5ys6OPlmWy8VSyNBJRxK6uirq0sTRI2cEYXxi0tajfM8LS2/96q1Lm41y 28dET++hwsa1FcXg5BOP7hKEA0dOxDTCmp88fljYfk9FeWrh+uolW5529asmKzFSinjjamm89rt9 vd4R105b/amAYSJIy3IPj3MQ/2lMa92lMeYxSpf2sg1Ze4Hz1UJOqb3kPf2SYuZ1NZpU6PY7MFh3 dVw+fu1j3o8zzceG43MfRZnfNrSp5c+1mL5nK2kPeR5va+7eJrT0oGzDaOKbsMfvHTpbMuHBqpE7 cviyZXxgcKA5/TuyHTQEARAAARAAARAAARAAARBoJnB5+NLkxPjI5YsTk5amipeGL509/7506tzI kdOX6NepM2NvH3n//Y9Hz10gbSns6O7qpCasKtTLExvuvLm72p53nmcvbnueHSfVib1SDBx5hOU+ 1Y5dWyO/XLAYlg2CW3fK92WHvfW2rKCwlCI392/j4EDo6xRvXAHj9UXEdIfte6pRXrUmce20yx+3 BtYAi9qqCwuKMV9hq3San1c0kq27am+olffhePPIt+M6aOtydWKBv+8c/rTwX7inkgQZLae0Yr6u Xxb858YWsmiaOoXJzyEvB+9dF4+PvRj87oso92O9WzPKx37C+N9H01xpES7ftZWebJXMzoYk1whX syYsfoxF+rnSn72YQ6MT58z96MS+vuDG7Hnj4SIiCGzmZLLaibPVBN0oSd7t6Bo2QAAEQAAEQAAE QAAEQOCaJyAJ1vjIyMn3jl/8aHjs4mgpT8eEND6pXh5W3zly5qdvHbk4OjxZmFKSiSgsJpkY9fGy Oxtjn3jneTbjtufZOcHEKFb9yau61NUqon/3DhaAWEDGgcFHhWfsV/umYlT2++htJE+EJFbx6dmv UNUQhS0P7dwclvtHpnzHFXDer3e76A1H7uDZj8U5pj/MNkUxOZi3PTvgxj3Em68oy3Q6bSou7tle e0N1FlfMeeTacZ2LkK5Xbctb5+6yZ7JS1KOh3y1P24veFnDvEx6p03V9TDJ1xldFi8mHxzP8fvRx aib5BN1HUZGHt/vgh/+Vju++NVbXlEo5OVNs6zJeGcm/vSA0nCeaTI9ysiAttqgb6pX52Am8H3n9 8kYY0U/38ub2tmJaUaTsxVeXSTt9++FzgxYgAAIgAAIgAAIgAAIgAAKtEejp6ksqmYnR4tCHH7zz 1k+L+fGuzpyUlORkIpFJSYuXdK/fsGTF4q75PREEqfF3X2NilFMWigKvqi7xzvNcjtueZ+fA4FYm RjnVnxpSj5xrtjxN72DBmXxr1m4k6aEar9P4D/IsjoPyOehfz5sDjaLNiPOCXc0GsZNDwg7euMLH 67HsFL3xrU4Uyw6ZbIs/dYNuxhx5vsLgzdTnLcxjoCtcYaf5Kh5/73ZoJJlGO3z6rSkQ+3cIlMHn ZsLyLPo1iMuH1z7sfvTxaUb5BNxH0YDHadXb0xPQvPlBxmvvnqenIk1WRStkyP3nlmeH9/wM9rN5 CKF+NlxS156J+I4iVVfvzHvJtOzHmSC0BQEQAAEQAAEQAAEQAAEQiEFg/qKlS5bc2N+3ZOCmjROF YkkrTxUmpaQ81pmZvGmg5/bN6z9x0/LVNyzq6UyGWO3sohS95RuqNconJiaE5cuoRhTvPM9c3PY8 O6zYjSdsiVN5hp0OPxre9GpRBHZwFKlREXbqC+qllg0Svmkbb1zRxut6wZIMazpYNQGNgsVi2rHr j/txjmunmY/f5nLR5it8RmemRZx5DPGAhSlFSgLlcmZKqbsPIAt+iXSE9MuWTXhBNV7GV1w+vPbc +9FniDPMh3sfRaIdvdHKL/0OHV9aybuC3RjeG4bX3u98VYiykyEHmHRfk6VC+m26H8P8bPQ/jp/s Wr/2VPVqM8sqJT2qKeSzHfajzxJaggAIgAAIgAAIgAAIgAAIxCGwYOHCdC7b29uTTHeOj0+ZoqAa Jel3fnPr//q1X7z7jltWzO+SSqWyXqTN+ELMejfWozpSb7w7butRdRvuec/zzPHsxBkVa1u3sZ5d +6b5Rdo+HValx/4H+OoGfSy3paoTsN3S2Sv/9NQo9jYVZ+My3riijNfDsJoc56TIVRPQaCgx7XA5 x7VTN79ezJ4PIs1X3IXSpvZx5zG4W1v4Cd5dr2IgEmfGM9I4A/tlRZ18i455TbMIpmrSqR09WPUz 7jrntefej/4DnGE+3PsoEu62NYqR3tncJ5sy0hAr4hLL4mvI2+O5OVfuR3vzx2cff/xZoR0bX/qM 1ruo2zZnMAQCIAACIAACIAACIAAC1z2B80Mfnfv4tCAZukoxTReKheFiflRa1Jlc0t8hWebHQ8Pn xoofnRv/6NylUFZLb73zZuHdl79Dx8vvdn3erSPFOc+Kn7PjNdqP78xr7E/7jk6wTnh2Qh1oaOAp fjNAG5u7daRqW3fZp0P1JMpY2kO1xu0iOlsPuwIUewdk6Wputl39bk9N3lYTqJg04NQEdopXkfkT Ow9Xi6y7p/mj5Y2Ld75d3Hh22uRPXYIZFXl35yXmfPE4887HxcNrH3se+R3belyEauaOBQ5/uxxZ ZXU+umFnlAgp/35d/naJ8dDUVI87j244UYvMisuH255zP3JxzjSfdi2gFuy4tcXZ1ITOjE8HFD9G UhT9Titl4MjG7ew/z27zz+StXh7zfmxhWPEvoUJSB3bt2hhJwo1v3cntdh/1obtOtNIDrgEBEAAB EAABEAABEACB65DA5QsX8lP5UrmcL0wtWrhg9Y0bbl73WfGHr/6sVNamiiXK4dN1fWKsZFrqvx/Z 8A3lpW8+eP+cwtTd7W7mN6f8gjMgAAIgMNcJkLpEsmGoKD/Xh1HdkrEVUW7Ojw0OggAIgAAIgAAI gAAIgMDcJ3Do0KHoTq5evfrJp3Z/S7+r64//8ZmzZ9esXv2Ve3791KljY2MjXR1d0vtDEx9emDx3 qXhhrHxhtFzQrYImRreOliAAAiAAAnOfAMXRCYP32aGa7Dj5xAPun+e+866H8UIKr6KBwVUQAAEQ AAEQAAEQAAEQuKYJlNSyosiWaZXLhZHLw++8/c7Bg29IE/lSsaxbkqwkUkoqle5IprJhRc2vaUwY HAiAAAhcgwRYZuS2Z6t5xwNH7vHdeHPODtzJH/RkUs9ZT+EYCIAACIAACIAACIAACIBAIwH6Mt+R yRqadvL4sYnxEdHU1UJe3PXnB0wSqSxT1bRisTQ1NUmJe7u1zyBlDysIBEAABEAABEAABEAABEAA BEAABEAABEDAJTA+Ph6LhpOyl/j2XZZhdnV0KgqFQBmKrIiWKBmGVS6pxQLFT6mmqZuGaOhGLOto DAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAK+BCgjL5POGIZeLOUlwUwmJMvSpeEROkZHx8Ympwpq 2UimUplsGgRBAARAAARAAARAAARAAARAAARAAARAAARAYPoEJFFUFMkSLEmiSChtdHxkePSypCsJ K5ESEmlNTghKWjN1Su2bfmewAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAIgAAJlraTrGiXrmboxNjE2 OjFWVMtSwUyUxFRBTE/oQr6sj02Wx8bygAUCIAACIAACIAACIAACIAACIAACIAACIAACbSFAkVFq WddUVVcNQZREWZFOfXzx9PnJjy4Vz1+cHLowMnxp6vLwVJTOzr7xncqx7+iE5wLO+drp77xx1muf ZyeKD542zhZM9vHA3sZrTz5xW/XD21rd6rzWQTQT/PaON81eNo+YtfRrxzsfkxlr7kETxaPY7bku +fLxeMMmLBppdxSRm0fl1EbOtS6Z0Wl4GrgOHX7TsC4IbVrngfejD3//9nXrIdL69J3a2PPI7zfu uKIuNQ6S1sc8jY7DLm14gE1zQYf1Ns3PyTv7foi4Bq7g/E5zYLgcBEAABEAABEAABEAABK4qApYh GLoliYqqa6IoS4JEkpRUKhYuXR67eHlyYqJczGuZTKqjoyN0XKQivTZx851fpePOm4V3X65qTJzz E0f3vSZ8nrX+6lc/v/zMa66ExbMT6kB9A3rZ2Crssexjz/ZdW+vfyE8+cd+gsPOE8/H+lrY6p9cU tt04M3BipzA4EPaeyG3P3nfuE7ZtjznAGWpO3Aae3eaQObHzcAO35k7jtg9So7g8t1cmMvpk2RO8 efMMQZpLZoPX4fQ5tGmdB9+PvuvK//5ds2O/c9s693XYbde2qeL0G3dc0/Jn7wu7Nu98aMu0bMzc xZs3H360VW1/5rzysXziyIGNa9dE6/KKzm80l9AKBEAABEAABEAABEAABK4RAmrJ0DS1RKqTboiS LEtyJpWSejtImiqKVjmdSGZzHZlsJp2lTfiCj7Mfn+m++db1XaxV1/oNy4UzR+woKd75rvV3fPXW pY7NpcuWC+Mfn7WDqnjtw/pv/Jy9Pz5deXXbcs924cCzL9K/iVcPeiXZvO3uiO8kvl3b74bPOFLW mh2PbBd2Bb+M8drvfYC9d+/fsTbuAGem/ckXnz2w/ZGKQsfGdWDw8aboMk/XcdtzvY7LM3j4ex8n vfGZRzbODKS5ZDWY2/Q5xJ0XXvvg+7GZaJT2Axs2C4ePe27rKzQx3n6j+Nkmt04+8eiuaT612uQJ x8y2bRvrnrIz29v0rbOfAhsGgu1cwfmd/oBgAQRAAARAAARAAARAAASuLgJiTlI6VU0SLNnQTcES 0smM1Ned7etJ9XQlezrTnR2dtMsehVGFjIt0JKGry5ajBGHi6JEzgjA+MWnrS77neebitr8yuL3p Ok6oFb13C+6/srM3RUE4cOQE3xtu+y1Pu7pZjLHUHKqPEOGd55huHhe9o3nbhr7yB7dvts8bY1ye gaxI5NvlqmqelnFTz/idcDhHH69t2vVnYLCOegw/A7nxOHDHNYPrPMbijtqUiaGRBJqwVFn/pF4+ paj9Rh1ItHZ12m+0S650q7vvmeuKlL0Utu4Sdm11/ntgcCBirvSVZon+QAAEQAAEQAAEQAAEQOCa J7Bk2YZcbnlP3xpZ7lRVQ9V10zCljlzPonmLFvb1dmbTyZQiiGqhQNpS2NHd1UlNKBXvOy9PbLjz 5u5qe975mj2mQnUvW1qRs8Lbh3nS+Dl7a6+8uVbeTd1XkQhvI3TJwOBGN2nMTfBz/nGdvcMPHHnk xM7Q9LC47fmj3LWVenRy6jZ7k5Z45/0t+Y6LBZO5sV4s36tOKWk2FNCex403rgA+9utj1ApSTB7c vqcaHef2xlLP3BzOjYMD06iq5M855ni9/nhXT2w/edw4HLjL6sqtc8/9GOlWbmxfuYkHWBRcaLpt AM9494srIHL7jTuuSIOvNqJgtwPb75mr6XoVL7fMdUWK9H/21NzMcq3ZXeckAzc9LDhPzNrPkVhT h8YgAAIgAAIgAAIgAAIgAAJ+BG5cd1Pf/BvWrrtVSfaVDaus6VOFspTLzuvumpdNZSXDMLVyZ2+y sycdBeAkE6M+Xnanm4tXuYh33v6YFZM6Iyzf4GT72Udg+yiOeNuwIiC7hGrADHshsavPCPY7SYS3 EfaW6aNvsC5OMDGKFVyK+EITtz1vqPQW5fRo5wrWkpZ4533tcMa15Wm7IpYt/9wnPBKqs3HbB3Dj jcuXT13tHgpoCBGSnOpgzXV26srvbHlo5+b6HM5Yq8qXc7zx2ulXfuWAWvHTjxuPA3egV2qd19+P 4dx92lduYuvEtmcHwnYCCOIZ634hTwP7jTuu8JHXtfAvH/XBD/8rHd99a6zB2mydF0iRCs7xrXd0 VvyslpDyydjj+UNez/D8xlwOaA4CIAACIAACIAACIAAC1wCBG9Ysz/Z0XR4dF5UuVRd006Ld9iS1 rImmqpfypEcJhtHTs2zFjevDRzv+7mtMjLrDVpYmJ8arV/DO25+ffePld8e7b76zWk6KTgW2D3ej vsXeBygdirSniJJRs/mTxw8L/oEJBwa3MjHKiZhqSF3zczNu+6hD5aUKBqYQCvxx1RSg/TsEyuAL q//r355vnzeucD5bniYhMXhYTtGk5rAZ5o6TnmMfDTlyUVH7tnMcij9eX7At+OnLjceBO9IrtM7j 3o+B7Z3abS8E1jiLPu/BC8sLzqffuOOKueLsaLdqabema3t7enztzcZ50noPB86Ij6dXzk/fjL0m idvHnxme35jLAc1BAARAAARAAARAAARA4Jog0Ncn3fr5T6U7e1UhJwidkpVVDV0q5aeGL16aGJ8q l7RCQT32s1PH330/ZLydXZSiVwtzmpiYEJYvo5rlvPO2OTs4itQoR8Oyj8D2cZnb/6hNalRr2+jV evMpnMyKK7lhVxHkiLjtIw6VyQh+dXl55+vNhhaEtqNmYqQJNbQPtV9zJxofNqzAgzlQ052qiZmV N043Jm46myvWd1/POcZ4mRle8zh+crgFcuASnOl1Hvd+jNQ+tCx1LRaSP+/R7pc6cJ5+I/kZ8Y72 bWaXj/K7D1d+6Xfo+NLKxqtm6zz5sebubYdfeDHiaK+0n5WMPTtTz83Y8/x48Pdnxuc3Ii00AwEQ AAEQAAEQAAEQAIFrjIBUWLA4+4V/8Mn+vv7O3DxDS4lCShKtQrlcKBUL+fzE6Njl4fOjk6P5kIF7 N9YjoemNd8dtPapuwz3veVuNevldoU6NCmwflzy9RbBiL9NVo+j9avOBwfsatzOv21jPrrUULNzE bR9ttHZdGZ/ACd55j1XOuDwtWPEdv2JMPNfq24fbr7MThY+NOXjb+2pSlSM9VBMz6Y3TcSdww8Bo yOtaeTjHHe/aje7Gj3b0RcVuXD853LgcuIOc8XUe936M0J4VbQ+pah6NZ4T7xQuurt8IfrawshqX mV8W6nTNztD1TJF69tkZMt4Gs1H21vN0cwXmtw2DggkQAAEQAAEQAAEQAAEQuAoJjI2dS6XLAwML 16xaLUlZy0olpYyUTEi5VCopy4oiZnPpvvm9HV3Z0NEtvfXOm4V3X/4OHS+/2/V5t44U5/zZo+9S Ut+4c4FzvHGWdcKzE+pAfQP2jkk739WytMSwajOcDigjrVZVibK9qgkenuJJds3zsKRATvvqxmYU zeNs/eR2wB+wW+ObVen29Ms772uJNy53SzK7BHjYqDxbxTW059nnDYvHs7ZFmo251Wg3253D1eLo kTBzJ8CXc8zxeob76IYTJJ1Vjth+xl2HvFHN8DqPez/y2ns3AmQrLmw9BPGMc7/w+o07rpiPMdac lY/adjdLDL46DhJJNx4I2QxhDowkmjB1BeZ3DrCACyAAAiAAAiAAAiAAAiAwGwQ+/uj9Cxc+kuXy 5z7zc93d3YIoGqYh/vs/+gGl641NTJm6pSgJRZFKhannU7d8Q3npmw/ePxt+cvtkTuMAARAAgWuU AIvQoT01w5Xha3T8GBYIgAAIgAAIgAAIgAAIgMCcJzA+7hYRj+Trk0/t/pZ+143fu+/GVWs+97lf 6O646TvP/tW+l/9GMidpbz0rkRQ7OpKJjKLpZj4/qWlqJKtoBAIgAAIg0DYCdjZhjDJubesYhkAA BEAABEAABEAABEAABEBgRgkMXxw7e+bs0NnTpnjp05/buGjJEt00pGLR1FTLpP8JbJs9s2yZ0KNm dB5gHARAAAR8CLBqYIiOwtIAARAAARAAARAAARAAARC4WggMDg42uNp8xmlQmNJGhycunD8zPH6q f2Hv+ps/lUh2SKYg6LpV1gVTkJSElMqklaRytQwefoIACIAACIAACIAACIAACIAACIAACIAACMwK Aa8CxVOjyDHdMCYnCufOjoyMjglSYd2GdV3dC6RE0pQUU5QsURIk2bQUTU4YszIMdAoCIAACIAAC IAACIAACIAACIAACIAACIHAVEXB0qAA1ij4lxckwzfGx4qXzU/n8WN+8nr75i6VMWk6lRdpmL5WQ k7KSlK1UQrqKRg5XQQAEQAAEQAAEQAAEQAAEQAAEQAAEQAAErjCBnTt3Oj26apR7psET0zAEyyir pXND5y5evCArwtr1N0miKCZlOZdJZJJyQhZyiURnJn2Fx4DuQAAEQAAEQAAEQAAEQAAEQAAEQAAE QAAEri4CXgWKp0bRiDRVNy22q97UxMTlS+eLpfG1Nw1IVDtKtATSpRRFSCiWaZgJRb66xg9vQQAE QAAEQAAEQAAEQAAEQAAEQAAEQAAErjwBR4cKUKPoU1lJpJIZRUlTVl4xX5ocu9g/LyuJclY3k6om 6boiUNJekjL3Eld+AOgRBEAABEAABEAABEAABEAABEAABEAABEDgqiMQrEbRcPoXzOtf0N/d19PZ 3Z1QElP5kXL5kkQVpCwpVdYTeVWaKiZ0JV0yxatu8HAYBEAABEAABEAABEAABEAABEAABEAABEBg DhJYsXrFqrUrB25edeO6lctvXDl/3nxRpFy9lCmkLFOxiro+VSxdmiyPjGlz0Hu4BAIgAAIgAAIg AAIgAAIgAAIgAAIgAAIgcNURWLp84YrVyzdsXHfTJz65fv2nV9/4iUyiVzIs3TBVQTQkWSwbqq5a E/niVTc2OAwCIAACIAACIAACIAACIAACIAACIAACIDAHCSxcPH/hgqUJoVsoJvMTpWLRlMQOyTQ0 UbIsUzcMjXL1pvJGoTwHnYdLIAACIAACIAACIAACIAACIAACIAACIAACVx+Bzo5eUciUSnJ+SpTE zmSiW5I6xH/3Z6+MF8r5SXWiqE0Ui8VRXRTMny649RvKS1ffEOExCIAACIAACIAACIAACIAACIAA CIAACIDAnCHwLf2uf7n874vF5NSkJYm5XDZlGEapoImPPvOD0XyplDcnC+XhQqEwTjXNjWNL/sF7 v7t4zjgPR0AABEAABEAABEAABEAABEAABEAABEAABK4+Ajf94dC/vuG94WG1WDATyZwkWaVCwTQs ydApJMqyqJKUXtL1omFqqlq6+sYHj0EABEAABEAABEAABEAABEAABEAABEAABOYegYkpbWqyQNqT Wi4WC/lyuWhZmpROSD25dDolGlbBVCcSippQjLnnPDwCARAAARAAARAAARAAARAAARAAARAAARCY HQJDQ0MtdzyZL+cLJU3TdVWj301NKJdNqbe7s6+rM5dNSKKuFcZNbVIR9Jb7wIUgAAIgAAIgAAIg AAIgAAIgcGUIvPDCC25H3j9fmd7RCwiAwJwlgIfDXJsaQzUEQxQ1QUnICSkpColywZLm9/f2duc6 O7Id2WRXV667v7O3pzO66/n85At/9fR/fGLH//2v7qVf9Af6K52MYuHdMxf/xcsnfnfv8X/2P4/9 1l8d+yfPH/vKX753918c/fbfHaU4LrJw4LUD/+rR/+f7P/heFGtoAwIgAAIgAAIgAAIgAAIgAAIg AAIgAAIgMNcIJJRET1dHZy7RkU7lcjIVjjI0QcrmEqmU1NuVGVi14uc/9+lPf2rjwJobI7r+zuHX /sMT/yyVOLz1zt7f/frn/vcHbrnzF9OyeIhO0kehRjTTUtNdxXR3d/+8f7tl/bz580fk7kuJ7j0f l85fGCIdal5/fzqZ/vH+H4eaQgMQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAIE5SEDSE5Pj+fPnLxUn C+mk3NuTUyRNmpwcLxUnE7LV15Xr7+5Im2ZGZNFJoQdJTj/60X/6ja9uuP0XNtywfEk225nNZlcs n3f7Lyy/9x8t/cEPnwzVpCRR6EhJuaT06G0LV3crF4tGNilnE4ouiM++/IM//4s/+89P/adf/uVf uePLd4Y6gwYgAAIgAAIgAAIgAAIgAAIgEEqgp6fHbeP9c/DJULNocCUJ+E7cdBxou8FpOkP+OEez nSvpatv7arvB6XDGtVeYwMFXXv3+3r0/+N5L33v5xf2v7jt57KeXLx2XqKqUaQqSKKsl9cLZC2MX R7SpQqhnlJT3/F8/cdcdqxct6hVFWRRT9LsgSIIo0e+LF3V8+YvzqUFw7l5PWvnVNb2/flNfT1K0 LPObn+7f/nN93/hk3+3y0OH9PyQfCoXC+fNDmz+/OdSf0AbTX/q8J0Jw161dFTocNAABEAABEAAB EAABEAABEJhRAq4ocA18pW8Yi/evXiWO18zL2bfNjE5Eg3FyYGxsrL09ksHpvzD6utQCeXLGPZpt zpyrVzXn9q6HWNYang8NkveVf3rE6jFA+owFIUrj48fe+vjMex998M6ht3706it7vv+DF959+3VJ sGSTfpmSpolqWdfKZcsM32Vv3/f+9JZP9Cxe2CVQ5p9l0s599Dv9mf7GfhesxYszn7gpRc0CPOtM iF9cmqZfdhvxjmXJX1+TXvD+K6e+/x3nql/4wu3/8Be/HGVsV6BNa0+9KFfxftQ1r+zQM8Sh+Unq vaq5ryg/aCNe1fCDLYpl78+/5idg80/HgDPNlzfcXcE/d6Nb9vW5+U7m3dvuBAXwaZhE35+OAW3i zlfA7RNxXM3OhK5VXz48Ow2Pdd+vRAHrx7kvfG+NFuY9SkcNDofScGz6TvQVeLihCxAAARAAARC4 fgjQT1vv9/Pmd/vmBo400AKi0C9IvJ/+M/GVwKtxBOgdvs0axh6lTSgu3lfBuGP3/YbPey9o/hof t7vQcTU3iEI+WIFyv8p6oQW8SgQ7yXtJmf5Vvi8OV8W33CiriMfHeWLwVMKWnx68NRy6YoP94a3P FhZ2C5dke5P9CzvL2kRZnRwdv3R26MMTp49KxVK5UFQnp4r5qXy5rMqS1dWRCbV++oMjK1Z0WIJu WfSLYqzK9Dv7s2AIpE8JJilTN9yQpGbBpkjKOn78+LlzQ8OXh48fP/mnf/Zn/+NPKxrWvV+99+dv /XyoJxEbtPZTJKLx6TdrfgY1rCT3r+5abz7j+yOtwY7DwXtjNJ/xXaYNV7l/bTAV1zLvCdXwPu/y cc77jr35J6XrpHOVd6Q8O1EsN/sccXYaJohHvvm7S/OMBLeJMstRRhpxXM3OhM5XxNXr2nEJhPbl u6J8n8vBayziTR3qT0SGvjdvRB/QDARAAARAAARAoF0EnB/cbfm5HPolgddL6Atnuwbra8f7Zt6s L7Sra95XwYAXe++3Qe+bXfPXxQYneV/GmjnzNIV2jXo6drzDnI4gGOUVwP067XKOctVVzbn5PbGF yXJxzYTy0IKH03RjJh5EZXNCyViWrFqCqhtlQTQNS5V0g/Qj0TBNzdCpqFMykcp05EInYGzs3Ly+ pKNGWUyNorgqR5PSSKUSLIOUqfnzEtQswBRFUhmmIcuKSYKWWj59+tTev/1bp/2v/PIv/+qv/HKo G9dqA/dnIQ0w1kpqaBxgx/tR80OHB7b5quaWrVmelalsZhuLdrt8DqYaxSVem4C5iGI24gDbZSrK KBraROm65bspyvCjOBDFDtqAAAiAAAiAAAhcAQK+X7oaZAhHhfG+ijtnmmWOYIejfEmI0qZdWCK+ XgaLHb5ylfek623E7rztp/M+H+UlJcprS7toe+1EQdHA0Bcp2fT9bh93Zc7EGINttjY7V97P2e0x yjqZXQ+n3/vFixeGL12WJIUEKRbJJGqCqEqqKU4VtcmJfHGqIIuCJKfy+VKUzqpqlEp75ZGgRL9b JiXukT7FwqZIk2K/gg/K8DPNG1YsW7xk0cjoyPvvf/ClL36Rrvjqr/3avV/9Kkv+i384E+n93fmr d4Ldv/LOO93ynq0Na8VrhGe52YfmB0fzjzrvGecnpXM0q06hj4BmnwOeXN6BN4yu4dna7LPvg949 6WvZd0TeMTaPvUGtb5is5hnxWmtmGHwmos/umgkG2/y1o3lqQr+aNBPzXQANlt37onkSeT02c45y RwasVffyKG2i9OW9VYO9bb7ZfUfdDM33Vo3uW3NLXz9D59T3ceRd+Q13Ge8hFmonlMB0xo5rQQAE QAAEQGAWCTg/bZu/2rnnyTdHjvE66Qo0DZ6HfmHjtQ/+oR/6laDt30x8DTZQ8n6F8ypWLrFmShH5 NH8TnrmvIs2WnfXQ2pqM8h4U3XIAVe93PO93P9eBhiFEJB/dt+m3nA7n6fce3YL3rdCL10u4+Z3C nRTv1+/QTpvXT2sTF+oPz73gBewMub2LnAzmx0fHhy8olpGQM/RL13XDMiSrZGll3TBERcpIUqeq iiOXJyMQXHLh0hQpULYOVYmQqmpSJEuxyKkLl0o9PUsCTZEeZRw98h5JUX/+Z3/xf/wf/+LYeyd+ /Wu/fvPNG0+dft9kRanaczT/XHH4en/kuH/1LjjfZ6v3jmq4yumowbL3Cc4bj9uR23uDZfevbu/u D9TgtcsbV8DPVO8D0YuI9+O54Rb1pe1012y5+Ycu74xzLa+vAJ8brmq2E3wmis/Nc9F8pnlcLhPv j5nQJxHPTvPSajbleyb0J0T0Ht2ncPN6bnCveT3zbo0ovXtn0Le9793k7XE6d1NrDymvnxHH6N5B zU+JhiXkfUo0XOWsgYY1731kha7A1saLq0AABEAABEBg1gl4fwh6v5c2fCWL8nO55bEEG5/Rrp2X lOaj4RuRl1IDsZZH7fs11fHE+8XD97UlSqfB3Hhf1B0god+EozgQ2iaUfKgFd8U2LN25/M3NZXvF OEfBGNDG+YbsfSB4vyS7C8a7ZprvkSgz0vJSb3C+2U6zPw1tGgbIo9GWe/9N+/B2IbLiTlRxXBQF 3TTVhJzu7emR1LJmqIZgirTVHtWC0lRdN/XQuVy1csMHH+QdNcpk+XqkTLGsPXaGJe4xTerDD1Vq FmzKMvTu7s5sNn306NFvfOPrX/ziFzZu3EB/zeWyRgQ3eE83d7kEL7jmGXXf9Jxb3Xl2BBtpbtO8 CkOfkr4DCZ0F7z0TvJii2I9y80RcwQ3dBVt2Abqom880+z/TP7CD4Td72DwXzWd442r4SexwCFh4 Ufh4n6TesUSZZW/72eUcegv4NvCdHd7N7nKOeDeFPhOi+NxMNfqc+tr33pgteNj8RS3KKNAGBEAA BEAABK49Au7XsIbvpcFvBBE5RPlaFfcrQZQvMK57TuPmw2kQPEbvp80tW+Dj++U5Ism4zWair/aS d+bdO/sNZwKGHPfrfVx602k/l32LMq6Z87+Fb+zBLz684UTRNKKgaEsbSxJNSUhmM7mOjq7urt6+ 3s7OHqmkmRrVIrckiQQpw6JKUiRLhfZ3x5d/4533ymfPTjLtiXQos2THSbGsPZbBZ2kfny0cOWFR s2BTlmVk0slcJvXMf9v18MP/5y23/Fw2naC/ZjIpip4KdSOAewvXuk/nhqd2sDQQ5WHkrAOeSy08 wb0/M6L8bOMt34bz0T2J3jL4J5yXuXPDN59pdr7lIYeON8q4mj30fmVxRtF8Jsq42tUmyuKPMtJ2 cY7iT2ttmkfRGsPm+eLdMlHu9+CxNFON4nOoTfdGa8FDx6WZ+4nb2uTiKhAAARAAARCYIQIB33C8 Yo3Te/MLQmteRflaNf2vBK355o6U9/0w1Pnglx3fL/Pery6x3G5LX74jCh1mLD+jN26Yd+8idL+h +cpVzktHu6SNBofjcg748tzw0Wxxjj4jV6Blux4soXZm8Xv+p+3DC1OWqWi5mM1mVqxYnU53ZrK5 VCor/stv/8A0jIQkUQpfXiuUClOCaf6luOm9310cPBPvHH7t+z/Y+aVfyC1Zkq60ZGWfaN884+Oz pVf2q1/+h//8ExuDtskbGRnu7EycOXMumUxSnNTo6LhlkQxlXrgwvGTxguXLl544eWbt2rVxF4QD 3bvQ3Wdrg1jQ8ALGa+b8KPJ+6vy5wZrXT9dyQ0veK19D187Dxf3Z4D6vfc94bYZe1fBjpvlB4+th s1lfD52TDWN3sQS87kZ325d5sM++M9XsZMAZ3uPVOx3eifbOV8Aa86XaDDYK/NAVHsVIwHeF5pG6 VGOt1bhXNayoiH1Nh2HAKm24DZsfC8H3Ke+JwVt4zT+qAybR9yHg62HocyyUQNwHMtqDAAiAAAiA wIwSeOGFF+655x6nC++fAzpt+CHL+5nb/ELR8AM3+IdmwJtF87eC4O/zbQEYoAI0f4H3fZdxv+p4 P+UxCeiO91WZ993Y9ztqwFwETKhrym3TMPaZ+CIUnXzzi0OzP6EORyTv/VrOW2C+b3a82ed9UXdf 3wIubMsKbzYS/eEQ+jbqXTledN6X64YX1eD3Vt8eo7wvN0xcwHPG963c1ysvutCX4qGhocWLg5Qi J02PpCj3D479m/5wSP8Pv0Ci04IFC1cOrB8aOmsKJqXGif/qv7xq6Ho6oVAmX0kvT06Mmob+59qn QwUpMkqa1PN//cSGAfGGG5QF82Q6c+GS9tFHxtGTwld+dUewGkWNR0Yud3QkSqWyJEmmaRkGZRLq yWRaUWT6azqVPHV6qAVBaoYWNMyCAAiAwCwSCP164etblKtCv9nM4qjRNQiAAAiAAAgEE4j+zunY 8VUrePrLtfQjMqIs0oAoWLwLlfZmbvVG+YYTq/e2G3R7j0Leq2s0uB1Leos15CiN246l7QYDRhH3 4RAFCNpMR5ASnvwSVZDq7u5dsXaDJVmTk5NUOUr8v7/9d6JoZdPJhKxopjo+Pqxr2h/n10cRpGg+ 8vnJfd/709MfHBkbO2c/v5ZQ3SjK1MvlOkNn6/LlS5cvn6OoLXs/PQqtYv8VSRgTJPt3QVGyq1ev DrVzdTVoftzMhBJ/dTGBt3OBAFamdxbmGo3o/2boO4rQh0xr9ufCuoUPIAACIAAC1zmBWO+cwREf DSR9NYLQH6lzeTqCVY+AT51B+Qb+X9VArthkRdSbmv0JlkSvpLhzxVi1saNYD4c29nttmwoVpHjD pwgp4Vu/lO3o7Oru6503j/L1JiYm9bIu/n//86tyQsokE4ogaGo5X5pQy+U/KW2IKEhd27gxOhAA ARAAARAAARAAARAAgTlLAO+cc3Zq4BgIzC4BPBxmgj9PkGrO1GtO2ev/7j+VlUw606EoSjqdpeLl yaQiGWXDKJrFvD4xVZoqlUtlnfbcwwECIAACIAACIAACIAACIAACIAACIAACIAAC0ydQyhcnxihR r1TIF7WyZJlKoVAS/+WTb6iGbtA+e6KuW1RFigQq4bvWACKkpk8cFkAABEAABEAABEAABEAABEAA BEAABEDgeiZAKXvy079qWZKoJCwxnU11dXWm5bQoiaWUYnXSNneJZFoz8pakGCar34QDBEAABEAA BEAABEAABEAABEAABEAABEAABKZJYNMv3HXTp25d94nPfOIzGzd8atXNn1yxatU88Zd/6b939i6Y t3hx75K0nJ0aHZvQrOJfmiun2RkuBwEQAAEQAAEQAAEQAAEQAAEQAAEQAAEQAIFf117M5boWzFuo mkKGCplb6tjIWXHzZ/95Nr0wl1vet3D54uULhIQopKdK8sWpwiW1VLR00TQlkSKrBFMRrYRsiYJO 2/AZhpYfO/cbX9vajPXvD719xz/4eeAGARAAARAAARAAARAAARAAARAAARBoF4HxySlZpM3oFdqV 3j3IuPPn5l4m84WDhw5/9pafa/7oj575K13otJRsIpXKpBOZVCIpS5RAZYiSJQhyQk6l0tSRYYmG YamqUS6plmFSE1mSRVEWJcmyLNNitX8MU6A/iqKkkAHBkmUxociJVEKQqa1sUW0gVS+UysWyalis XrVl0m9kSEkkk5KUoD+XioWbbshs3tCXTdFea7XDNIWfHh89eGRYkkiVIPusa0lQlYScSCgJSUhK QoJ8kQVLkAzTMk3dMnVV0woFdaJYKpY18lCig5wT5YSSTCYS6VTirs+vmN+baWCi6eaBN8+ePjcl yQnykn7R8ARy1aIh0ghNQZLIa/qvbhlkVyFHBNPuXLSbGSKNXTIJgSQKstMrnSI8ZIfhIkSElkwQ JJP+SC7R1CUU8fOfXrZkYWeDP5P58r4DJ02iT3ztwzRN0aReaKJFnc4zpUYol0oEXFYkRaEeZeqI GpBTmXTys59aOa+vo8FssaS+/c77ZJaaSTQEiQQfGhMtKzmTSR155+SP9h26fOmSKQ2nJG3lqtVL ViyaT85196ZTHWOXxybGJmgGklnibqXS2aTcUS7Q2JOFydLbb7957uNTxcKIoU7Jitnd3bFg0Q19 /Qvz+al8qbhs5YqbN36yu3NeKa9evKCX8nnLLCWShvjVf/LPJKHjzPvj58+Wc5mFq9fcvmj5/P5l nao8MlUeKqtThkqYiKyRkAgW8dTUUoFYFKeGfvs372le2W/8/Vu/9Iu3teuWgx0QAAEQAAEQAAEQ AAEQAAEQAAEQAIGxiUlXkKoIHlU1yleQmpjKv/73b9/62U81o/vjP/trIdGZTCWZKiGQmEFaU0IQ k5aSEEnwIrOCSZJTsaTrJqkpcqmskuZBqogtrJAeRe1JUCEBhnQbi2kbEokFIskyLJpFlHVtkj5O ZuRsRzbXkU1lUqQJaWV9crwwlSc9galeuq6TeJJKpj+/vueTN+YSCnlSd1Czg++NHnzvMnVCag7T k+TU4oUdJMGwbvUy1cEmpYI0IHKAamGXi6XCVGF8Ympiqpgvk8RkaZZEShsTsGRSkEgok+7cvHrd yn5yvlGQ0owf/PSD4x+NkfhBao9G0hapbSZF5NBgSTsSBZKOFPqPQME6NGpN00koIUeInkBDFkxJ JtmExkWXWHSe2pIiJxAPJt0ZlqXReSqhRHE+pJ9RM/o1rzd76yeXzWtSx+hj2nRuz4+OGVRQybJo eggxSVAiU9zIHJt1Nm+CoFN5cElM0gCTKepOJ03OsHq7Mp++eXlfb6553kmqe+31E8wxmclopLTp tK2dIeTS8xWza8/f7Nn/2j5Ly1vi5LJV/bduvmXpihWmlRsfls99cPnUe0fGJy73LepdvHJptqsj mcipBWFyJE/Yy6paLIxPTVyamBjKZKVsB6lVqXkLF7M99aSORQtX9/YsujQyNnJhxNQFVSufP/9+ LpfqXdAt3vc7Oyje6e233jp97MNccoFWXLT8ho0bNt628MYlSo+mmhdLhUnD0hMJXZaJtCmYmmno NJMTIx/95m/4CFKvH3xz65e/gIcFCIAACIAACIAACIAACIAACIAACIBAuwi0IEgdOPizn9/06WYH vvvCvs55iynISEkmJCUtCClVlYsUCaXrhqkJpkERNxQhZZI6Y7IQJ7WkTlmqYisyLALHDlZSKEwp lSTdhfQWiqIqqXpZNVXNMClayZA1rajrZSUpZDvSnV2ZdEaR5YRWsijYiukzJGaZZndn8o5bFq5e mPUL8CI5SDh0YvTQyVHL0BUKJiJdhjQqq2iLcRSdZKUoFCsp00ECFSk1FDNEmg9t36aTNEbqhSSb EgVhkceaafu0ekn2k6t6m5Uv4kPy1d8dPnf8o3HSoHTSPFiIlCiwOCS6jq61yDYLDyP1JykqSSmb 6aRrKBqLAr/KGvNLJkWO5CBTJ/2I9C8mnhEvUupEKZlkoVIkSJFOZQdGkS1hxaKOjat6Mum6oDB3 psYny89//5jAKnyTvCXJCsV3kX5IBknoYuFpaqlULOUt0mpkMZ1OpXPZRDJBWBf25W5c2p1OUi8+ x8RE8eVXjqbTaQpNowkmm3ZAWzopdZ4+dvHP/2T3pctHO7usTE784pd/VUkIIyOjo8OkNinjwxMX zp0kZXLZ6mUUM2WJqeKUcOHMhbHhC4XCiKmo5FlPV+/8+f0d3V2GqAmK1buwv3fBkp6OJVYpM/T+ 2cOH3pgYu5jNZOavWDE2fnHFjasWLVkmbvtftp+/+PFPDv6oOFlYtfzTnR3zLp/Xk8qKGwY+s+rn 1nYukFV1QjeKFLZGCppo6bKlpVKJjo7MpaETX/vq3c1DfO2Nn/7ynf+gXbcc7IAACIAACIAACIAA CIAACIAACIAACIyOT7BInQSluVFuFksJc5P1eBFS+9948/O3fqYZ3X995q+V7gW5TIZEJcrOozAl SoBjOhSTEhTa64zEFSb+CIqm6/mpgmWQ4lTMZjtoMzTBShRUa4qCp0j7oRArSlSjcCXNIDGGctVY 3p9J8k43aUIUMUVCEIlBpJtQzSCDJJ0EiScpakTZYp9a0/25tbnurL8iQz6TDnT8TOHdDyfVcolF GhlmoVDQ8lMsNEuRKWCKhJVEkoQnijuSFFOiUB+D/kKiD/nPorAsyjMkhcgwVQoGmt+bu/2TSzsy jF7zQR6/dnT4/Y+n6DKDiU8sNIr6pIJFapFkNhYxRXFhFEAmJ0mNETKZHKXpCQaNWyhrVNiISWqJ hEi/2MSwVEa6xMm2Y9FYLFGRZeyR0GVm08qmm5eQbES0eKt6ZLz0Fy+/xxIGWaYeS46kLMUcZeIl KRYqmUynyM0yxSYVKb5IJcLUZzab/PSGpcsXBZklneuFl98jkSuVUjo7KEQulR9XL54buXRp9OSJ k5fOn/ns5z7V1Z3tnZcsFkc+OHX2g9MflUvaokWL+/q6hobenyiO9i3op0CvYtEUtNToxbFycaRQ vGgrjOa8ef3Lb1ypWwJhX7Bw4fJlK+b1LSkVlXd/dvL948fGJ850dskUWtXfl9MtqW/+ihLJbf/k N/+pWi5+72//dnJibPnKRb/6j/4/U4XRY+++f3Go2NW9dtPmrT0LlCl1iAXy0QSQGpUUaX8+Uube P/nmfb/5a834Drz+01+5C4IUnpYgAAIgAAIgAAIgAAIgAAIgAAIg0DYCo+OTlNbWUEPKK0s19DQ+ mf/x64c2/7yPIPWfdj0nJuexkB+FyRt2hE2mp7OruzNH5Z90U1MpJkrPUwAQ2aQW2Uy2p6+HhAxT K06OFS6NqhfG9Uu0JZquJajaFIlkyTQL5GFpaazKkiyl7PrTTNUieYj0EpbPxrLZKPnOXDU/+4X1 Pcv7k746mjsK0oNOn1ffPHZ5fHS0rGqpdCbblRENUpcog01g0Ud2ABIdRpmy7ASDOqIIKVtM0tTy VClPApFASXLkVMLa8rllS/prWWylsplO1ZIESZB65e2hEx9PkJOU6KdTnhwVwTKEBPOXBlRUZYMC oUj80Sh+yjK7c51UgCtJQycthlQv0p5o1HZ1LdNUWVqdRfFlhIIMUzBTiUpNsTpWicTnNi7eODCv oVpW8xIZHi//yQsnWM4f6WN2JSsWBcZ6UiVJI1WKxLhUIq2RxKWzYt+fWte/dkUvyUzBq22yoL56 6ONUutuysuPD+bPvf/Teu29Pjo3nMn2yaKSzpCYV19+8/uzQ2RPvHaNKT5mMWNYmOzq65i9cIivJ 4fGLJMgpYi6fVwuTk+OXz02MX5xSxylsa8HCxUuWL81mqNSTtWbVTWpZ6ujo7e7uO/yzo2/+5E2K Y8t0JHM96cuTw51paeHCG5OpzPmLH4m/8mtfo1Cvn77x+tjoWCbX8Wv33L9wce/xY6fefvOYLC3+ whe23bBylWaSTKiZgiok9FzWynbQhKgfHD+8/be/1jzaH7/+k3/0S19q2z0HQyAAAiAAAiAAAiAA AiAAAiAAAiBw3RMYHZu4fPnypeFRyhQLhpFUlEWLFvT29Lz6+k+/8POfa278R3+yR0wvoOgekXK3 SCciyUYWc6lULptKpyk/TEgmSamSKCqHii+RBEYFxdXyGBWTEnSKOKIkNXlk0vrw/MSl8QkKJ6JA myxdSBlgrM4SyTIUQ8NifyhiiRWYonJRFM/DnBBXLMrcetO8ZfMyrPp200GhSCk7wsj5hMSsd98f +fvDFybGiqPDU5SzN29hd66rI50hYYfKpbMi5iz+iMKtKFaJorRIttCo/nq5mC+UC4WyWqa0wnRH hpSb2z656NMD80m+cizni8bQWHnN4qzrAulGP3x75MQZFiFFSYc6E71YiBSVbqIAJUE0qdAWCUNa ySwXVdroTTI0KUXBZXKW8JBdVqGKEgbJJ4P8tgtJUWeUaEg9WEYmkUnIP7e6e+3yzkzaZ+TUOw02 5cmzGxkr7f7uexRgxmCy6lpU4YuVskqQ4EN8qK66XZi8Myl98uZF61b2ZtI+OXqsjJYlUFKmO8zx fPmlHw9PXJr86NjpoY/OsBRLnUKRsqmUcOHSSSlRIu3pxpXr33//7ImjhwyDqkONp7PpZTesXrZi DclwhWJ55YqBSxfHLp0f/fijU+Mjp/L5iyRHLlm2bNnyFaqh9ff39XSTqtlfJvZSltw/dfp9Ujep 1lW5PLlh47pzF8+OXB7qndefzeRWrFgtrr5pY7FYuHThrGSlch3zN2/6xWUr5x048OrQx2c7c8s/ cfOWZYvX6aqazGQ6+nrTHbKYGpNS46JkXj738W/9xj9qXkM/PvCTe7b+4nX/rAAAEAABEAABEAAB EAABEAABEAABEGgbgZGxiXePvLd61Yqujhwrlc20jspvdulsu3y2nWpHITkffXxuw/qbXj3w91/Y 7CNI/ef/9tdCekE6lWE76pGiwyQkVrY7lZZzaUoIIyGKlc0m6cPeOo+2dzNYhlo5SbFAomJQFJWq Jj4YKp26MDxRyqcScmdWoaiflCKy3fpEK0M76LEt9qgEEv2NkvjYZnFk6Wtb1vV1UcmqxoNKcX84 NDVZ0D+xpsdNZKOr3jk5/Nqb50YvlUZHChQWI6eNXDqdJeUsKbORUg4gFamSZMreI12oSDls9IsS /DSVfE7IpKjJHZ25Tw30f+nmeamqLkN9HTw+Rg5/YkVtbzvKyXvtlHb0o0Jhaop2JyxR3BHbOJAB ILWLbYrHalKRYsTkJBbrZekULMWSHFmpcmprUi141oM9C0wkY0of22TQ0q2iVbr9k4tvvXmeb47e +JT6+uGLn90wr99DZni89Cd/fYzpWRIJbayyF5tclvbHyqizMlXknmDd9uklt2wgoc1H3SOzPzky dMtNC73AxyaMf/Nv3vjo2OGzHxxOJNWf+7lPmnL57IVThXJ+8ZKFFAQ3MVESTGV0ZDybSWnaVGcn JXSmSRdLd+U0kufE1PIlK0+894EsZj44ffSjD/9eLY8uXnrj4qVL++f303R0dXV3dfTkpyjEjiqQ i+PjY/lSobuno1AYHx4eWrvmxmIhLylUd8wku2tXb/z/A16C4z3ug1yxAAAAAElFTkSuQmCC --_004_5DFAC0AB21354792A3A354D7D35B942Alenovocom_-- From nobody Fri Aug 17 16:18:26 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309E1130F43 for ; Fri, 17 Aug 2018 16:18:24 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=msQz3XRM; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=B/0mlWA9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7Ib6puIlhv1 for ; Fri, 17 Aug 2018 16:18:22 -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 D5B2B130E08 for ; Fri, 17 Aug 2018 16:18:21 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w7HNEnB5014025; Fri, 17 Aug 2018 16:18:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=NIApBukh4ddmPkLnlYI8+69629zMLAYT0Lx2PAYakdw=; b=msQz3XRM2jFNacz78/JQ9Gt6nY9J7lWA9i8/R+0LYk4EUPTE5NyoYlDYf1t3jeMKZPd9 irtuhzOrq4pCY4qGj+mYMpJXPVUzKwnxBWz7JP7cXdXa2qzth/nO6119lLuv7y00R/cq 2rjKbSez8f2j3xEKufH/i27AQnTEKHZPzJk= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2kx60489au-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Aug 2018 16:18:19 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 17 Aug 2018 19:18:18 -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:X-MS-Exchange-SenderADCheck; bh=NIApBukh4ddmPkLnlYI8+69629zMLAYT0Lx2PAYakdw=; b=B/0mlWA96jWp4kPUig+cfkdzXpqLAgdMsCSaeCyR4AZKLLaycOVYzl/tWJAHVtuSBPZh6L5zCAgRVpufZftA9Cm3WPgceL/zn9Crzmhx58jT+WVyZ1XP1FstAokyIrsnjhTEUa74H9kAx8eWayUb8BlcAEDMgNdDFp6tsl9WHjM= Received: from MWHPR15MB1181.namprd15.prod.outlook.com (10.175.2.135) by MWHPR15MB1853.namprd15.prod.outlook.com (10.174.255.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.21; Fri, 17 Aug 2018 23:18:16 +0000 Received: from MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::7079:d902:8876:1e8]) by MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::7079:d902:8876:1e8%9]) with mapi id 15.20.1059.021; Fri, 17 Aug 2018 23:18:16 +0000 From: Alan Frindell To: Roberto Peon , Dmitri Tikhonov , =?utf-8?B?QmVuY2UgQsOpa3k=?= CC: "quic@ietf.org" Subject: Re: [Potential Spoof] Re: QPACK ordering guarantee? Thread-Topic: [Potential Spoof] Re: QPACK ordering guarantee? Thread-Index: AQHUNoCToON9SqAs1UievF6NIw6rog== Date: Fri, 17 Aug 2018 23:18:16 +0000 Message-ID: <8272994A-E21F-471D-B78D-0A5D0595F546@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-originating-ip: [2620:10d:c090:200::4:7e69] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1853; 20:qExga5D0973wnynLg8iOTpbxSjNECXaYtLUJ/3Y96BEviq1qGgLdL2vTUxlNw26wi5gQKsSXeRAAW6ACxNdVHVmxRcMGb3FjJVSnpeL5kAhHRkZyY3/gCN+0BscC4xST+hPkLTGYc/fdz6yHk3sAPwxwzb5CYZXjRrARwOu0Wqs= x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(396003)(346002)(376002)(199004)(189003)(82746002)(105586002)(106356001)(8936002)(110136005)(6436002)(5250100002)(58126008)(81166006)(305945005)(2900100001)(53936002)(7736002)(102836004)(83716003)(33656002)(25786009)(316002)(97736004)(2906002)(6506007)(6486002)(46003)(81156014)(53546011)(478600001)(6116002)(8676002)(99286004)(36756003)(68736007)(6512007)(486006)(2616005)(256004)(14444005)(6246003)(476003)(4326008)(86362001)(5660300001)(229853002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1853; H:MWHPR15MB1181.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-correlation-id: 7aed7434-4387-4b0f-b66a-08d60497b640 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1853; x-ms-traffictypediagnostic: MWHPR15MB1853: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67672495146484); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231311)(11241501184)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201708071742011)(7699016); SRVR:MWHPR15MB1853; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1853; x-forefront-prvs: 076777155F received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: o63sQUfcQZDZ3l58wyTCnlRDBMA6g7mCbzZw82NNpiuqkNJ8iLTrQerzlpZQhRUZ8Mk//n6Cqx+yTQCVfoeMU3Bb6au23rpwI0vA5+2aJ4nFifM9wQrhTbbPRFY1pMzFc3H7kaRgkBiGu/UBBP2lRyr7jceI3j3MzCBfG91yZzPokNrZ03m6G8sS5oVVES7hTxCbCUEv6bc0+/Rx0xFtp2lahEfz7tAsKFenQ9TmVZv/2naZ7duFA54MPVnI/WN07OAm+0xwUF/JOofXSve/rAnrGbdqfTkhRjktSYObayuwvn1FxFh5f2yfLy/dcwVZa2Sd705B3y9hd5Te9XRevWbVIfs1Djnxnpi+iQQaAlk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <021488D3203FDC4E93DCAFBF6C3E5796@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7aed7434-4387-4b0f-b66a-08d60497b640 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2018 23:18:16.2369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1853 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-17_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2018 23:18:24 -0000 SSBmaWxlZCAjMTY4NCB0byB0cmFjayB0aGlzLg0KDQrvu79PbiA4LzE3LzE4LCA3OjQ5IEFNLCAi UVVJQyBvbiBiZWhhbGYgb2YgUm9iZXJ0byBQZW9uIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBmZW5peEBmYi5jb20+IHdyb3RlOg0KDQogICAgR3JlYXQgY2F0Y2ghDQogICAg DQogICAgSSBzdXNwZWN0IHdlIHNob3VsZCBiZSBzYXlpbmcgc29tZXRoaW5nIGFsb25nIHRoZSBs aW5lcyBvZjoNCiAgICAgIFRoZSBvcmRlcmluZyB3aXRoaW4gYSBoZWFkZXIgbGlzdCBNVVNUIGJl IG1haW50YWluZWQsIHdoaWxlIHRoZSBvcmRlcmluZyBiZXR3ZWVuIGhlYWRlcnMgbGlzdHMgYW5k IGhlYWRlciBibG9ja3MgTUFZIE5PVCBiZS4NCiAgICANCiAgICAtPVINCiAgICANCiAgICBPbiA4 LzE3LzE4LCA3OjMzIEFNLCAiUVVJQyBvbiBiZWhhbGYgb2YgRG1pdHJpIFRpa2hvbm92IiA8cXVp Yy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5j b20+IHdyb3RlOg0KICAgIA0KICAgICAgICBPbiBGcmksIEF1ZyAxNywgMjAxOCBhdCAxMDoxODoz OEFNIC0wNDAwLCBCZW5jZSBCw6lreSB3cm90ZToNCiAgICAgICAgPiBJIHByb3Bvc2UgdG8gYWRk IGxhbmd1YWdlIG9uIHRoZSByZXF1aXJlbWVudCB0byBwcmVzZXJ2ZSBvcmRlciwgYW5kIHRvDQog ICAgICAgID4gdXNlIHRoZSBleHByZXNzaW9uICJoZWFkZXIgbGlzdCIgaW5zdGVhZCBvZiAiaGVh ZGVyIHNldCIgdGhyb3VnaG91dC4NCiAgICAgICAgPiBUaGUgY2xhdXNlICJoZWFkZXIgbGlzdCAu Li4gY2FuIGNvbnRhaW4gZHVwbGljYXRlIGhlYWRlciBmaWVsZHMiDQogICAgICAgID4gc2hvdWxk IHByb2JhYmx5IGFsc28gYmUgaW5jbHVkZWQuDQogICAgICAgIA0KICAgICAgICBJIHN1cHBvcnQg dGhpcyBjaGFuZ2UuDQogICAgICAgIA0KICAgICAgICBJbiBhZGRpdGlvbiwgdGhlICJmdWxsIGNv bGxlY3Rpb24iIGFzcGVjdCBpcyBub3QgcXVpdGUgY29ycmVjdDoNCiAgICAgICAgDQogICAgICAg ICAgIEhlYWRlciBzZXQ6ICBUaGUgZnVsbCBjb2xsZWN0aW9uIG9mIGhlYWRlcnMgYXNzb2NpYXRl ZCB3aXRoIGFuIEhUVFANCiAgICAgICAgICAgICAgbWVzc2FnZS4NCiAgICAgICAgDQogICAgICAg ICAgIEhlYWRlciBibG9jazogIFRoZSBjb21wcmVzc2VkIHJlcHJlc2VudGF0aW9uIG9mIGEgaGVh ZGVyIHNldC4NCiAgICAgICAgDQogICAgICAgIFNpbmNlIHRoZXJlIG1heSBiZSBtb3JlIHRoYW4g b25lIGhlYWRlciBibG9jayBhc3NvY2lhdGVkIHdpdGgNCiAgICAgICAgYW4gSFRUUCBtZXNzYWdl LCBhIHNpbmdsZSAiaGVhZGVyIHNldCIgZG9lcyBub3QgYWx3YXlzIGNvbnRhaW4NCiAgICAgICAg dGhlIGZ1bGwgY29sbGVjdGlvbiBvZiBoZWFkZXJzLg0KICAgICAgICANCiAgICAgICAgICAtIERt aXRyaS4NCiAgICAgICAgDQogICAgICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Sat Aug 18 17:45:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0F1130F65 for ; Sat, 18 Aug 2018 17:45:27 -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=mnot.net header.b=Vsw4fhpu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FtxtOsoG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLeOF8-Yyv4R for ; Sat, 18 Aug 2018 17:45:25 -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 9D78A130EAE for ; Sat, 18 Aug 2018 17:45:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B1BBF20B78 for ; Sat, 18 Aug 2018 20:45:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 18 Aug 2018 20:45:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tQCjDBEkGZbQIm5+I VdylrRDpJX5HmpMmjK91ooliVc=; b=Vsw4fhpuDqnEsj4o1PQ2pVhx1E4KmR1xM tzgjPl6vzTQe7IVA1R8NmEJvy55UNQah8pw2RffFiMTdaRp3AOIcb4k0Bbp5+o2v Ox8CBPgrBUapilVSdM2J3vZTdqD/PnZzcXu4OShrmlsmVPoXjX3QvdjlVQbPlj08 gddmHceo3YiqML6ZgMvo7pD5IgqF8L0yZYhbOVfxCsHmg9qhJIljvZFpxe7YVYcO roY1Wa0XCJfXV7a9cJ7ADFJ5BKVjeNqv/d2SrByJhLps02JZtBiHvNUaYw5BnEAy MSRQ66aS0VG5L/zPx3nmiCpja+uZ1iDb93VFMJBZ6NNqsU3JwOQsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=tQCjDBEkGZbQIm5+IVdylrRDpJX5HmpMmjK91ooliVc=; b=FtxtOsoG W4nIUf3hL22XmGgLvOj45nRD195UKovylQFTXga2yl9nZ0IfDLY8NC5+OKeSoww9 Fwd3I6YN+nRtCMASuVX/EMRkLAWombxtiQALAWwODo7AoiGygvyJhOQgvFDrL1+P lkOZjWu2Ldo1aAae9Oj8ygzdC/5+9ONt6M/ti4fcckN1ls5HfyQK9v5WFxGd+9qM t/DB2IHrmFTb4HN5gCVDfMkwGqlbIpWlBIACiOTEeZVHKQIAZrYzbv4WEeHCDymJ i5R+YPqaSavtFz2GCg7uFCgD/EWd2Nypi+YSWIgP5111K43wHYxkFeXS6prqgXWT vXV9utPf75+f7Q== X-ME-Proxy: X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 14EBF10255 for ; Sat, 18 Aug 2018 20:45:21 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 80B33CB60F for ; Sun, 19 Aug 2018 00:45:18 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============8824209976146141302==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180819004518.80B33CB60F@cloud.mnot.net> Date: Sun, 19 Aug 2018 00:45:18 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 00:45:27 -0000 --===============8824209976146141302== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+13/-3/=F0=9F=92=AC53) 13 issues created: - QPACK does not specify how to handle invalid input on control streams (= by afrind) https://github.com/quicwg/base-drafts/issues/1683 = - Small packets don't trigger a stateless reset (by huitema) https://github.com/quicwg/base-drafts/issues/1681 = - Does the first byte of stateless reset include random bits? (by huitema) https://github.com/quicwg/base-drafts/issues/1678 = - Target of HTTP version fallback (by MikeBishop) https://github.com/quicwg/base-drafts/issues/1677 [-http] [design] = - Opening streams implicitly (by mirjak) https://github.com/quicwg/base-drafts/issues/1675 = - PN of CLOSE (by mirjak) https://github.com/quicwg/base-drafts/issues/1674 = - Recommendation for rate limits (by mirjak) https://github.com/quicwg/base-drafts/issues/1673 = - Invarinats in TP (by mirjak) https://github.com/quicwg/base-drafts/issues/1672 = - ambiguity on reaction to RST_STREAM (by mirjak) https://github.com/quicwg/base-drafts/issues/1671 = - A few cases of use of normative language... (by mirjak) https://github.com/quicwg/base-drafts/issues/1670 = - TLS dependencies and packet number encryption (by mirjak) https://github.com/quicwg/base-drafts/issues/1669 = - Greasing version negotiation (by mirjak) https://github.com/quicwg/base-drafts/issues/1668 = - ACKs imply stream state transitions (by MikeBishop) https://github.com/quicwg/base-drafts/issues/1667 [-transport] [design] = 13 issues received 53 new comments: - #1681 Small packets don't trigger a stateless reset (13 by mirjak, mart= inthomson, marten-seemann, huitema, mikkelfj) https://github.com/quicwg/base-drafts/issues/1681 [-transport] [design] = - #1662 Restrict delayed ACKs (11 by mirjak, martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/1662 [-recovery] [-transpo= rt] [design] = - #1671 ambiguity on reaction to RST_STREAM (7 by mirjak, martinthomson, = mikkelfj, MikeBishop) https://github.com/quicwg/base-drafts/issues/1671 = - #1674 PN of CLOSE (5 by mirjak, martinthomson, ianswett, mikkelfj, Mike= Bishop) https://github.com/quicwg/base-drafts/issues/1674 [-transport] [design] = - #1677 Target of HTTP version fallback (5 by RyanAtGoogle, martinthomson= , mikkelfj, MikeBishop) https://github.com/quicwg/base-drafts/issues/1677 [-http] [design] = - #1667 ACKs imply stream state transitions (2 by martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/1667 [-transport] [design] = - #1669 TLS dependencies and packet number encryption (2 by mikkelfj, Mik= eBishop) https://github.com/quicwg/base-drafts/issues/1669 = - #1675 Opening streams implicitly (2 by martinthomson, mikkelfj) https://github.com/quicwg/base-drafts/issues/1675 = - #1518 Make EOED transmission optional in QUIC, please (2 by huitema, ia= nswett) https://github.com/quicwg/base-drafts/issues/1518 [-tls] [design] = - #1668 Greasing version negotiation (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1668 = - #1672 Invarinats in TP (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1672 = - #1673 Recommendation for rate limits (1 by mirjak) https://github.com/quicwg/base-drafts/issues/1673 = - #1678 Does the first byte of stateless reset include random bits? (1 by= martinthomson) https://github.com/quicwg/base-drafts/issues/1678 [-transport] [design]= [parked] = 3 issues closed: - PN of CLOSE https://github.com/quicwg/base-drafts/issues/1674 [-transpo= rt] [design] = - Opening streams implicitly https://github.com/quicwg/base-drafts/issues= /1675 = - ambiguity on reaction to RST_STREAM https://github.com/quicwg/base-draf= ts/issues/1671 = Pull requests ------------- * quicwg/base-drafts (+4/-3/=F0=9F=92=AC9) 4 pull requests submitted: - Eliminate outdated reference to PATH_CHALLENGE (by martinduke) https://github.com/quicwg/base-drafts/pull/1679 = - Full (mostly) editorial pass (by mirjak) https://github.com/quicwg/base-drafts/pull/1665 = - Move RECOMMENDED values (by ianswett) https://github.com/quicwg/base-drafts/pull/1664 = - Limit delayed ack timer to 1 RTT (by ianswett) https://github.com/quicwg/base-drafts/pull/1663 = 4 pull requests received 9 new comments: - #1652 Use the 'no outstanding' rule to defer idle timeout (5 by martint= homson, mikkelfj) https://github.com/quicwg/base-drafts/pull/1652 [-transport] = - #1657 QPACK: wrap absolute index values (2 by martinthomson, dtikhonov) https://github.com/quicwg/base-drafts/pull/1657 [-qpack] [design] = - #1659 Insert omitted parenthesis (1 by jugglinmike) https://github.com/quicwg/base-drafts/pull/1659 [-transport] = - #1663 Limit delayed ack timer to 1 RTT (1 by mirjak) https://github.com/quicwg/base-drafts/pull/1663 = 3 pull requests merged: - Eliminate outdated reference to PATH_CHALLENGE https://github.com/quicwg/base-drafts/pull/1679 = - Move RECOMMENDED values https://github.com/quicwg/base-drafts/pull/1664 = - Use the 'no outstanding' rule to defer idle timeout https://github.com/quicwg/base-drafts/pull/1652 [-transport] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============8824209976146141302== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday August 19, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+13/-3/=F0=9F=92=AC53)

13 issues created:

13 issues received 53 new comments:

3 issues closed:

Pull requests

quicwg/base-drafts (+4/-3/=F0=9F=92=AC9)

4 pull requests submitted:

4 pull requests received 9 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============8824209976146141302==-- From nobody Mon Aug 20 04:30:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7595B130DDD for ; Mon, 20 Aug 2018 04:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.073 X-Spam-Level: X-Spam-Status: No, score=-17.073 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_IMAGE_RATIO_02=0.437, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu19FnW142Cn for ; Mon, 20 Aug 2018 04:30:35 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7200130E23 for ; Mon, 20 Aug 2018 04:30:34 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id f4-v6so4444741ybp.7 for ; Mon, 20 Aug 2018 04:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xKrrCO+zUp/pC1EolXcRwMxBuGNBkWIHWpuLhM//TR0=; b=IhYPj2jHy4smxOVbRh75F1b1R1iDp+1wZ5norON3+LQZfzBtCuBkUxhzdbUdULzqws NdMJUBqT4tbWjxyvSGxfUxNBF38nxlRR2yveKwpQOehbYQBMLO763wU6VyyuqYJUC7ed 6pb3ynKauQes/esqsG67DIGZnby3V8paK1mWn9pY/9MBlKohG+xc8DQD/zxpiuLLGnBW IZXY/hTCRUVNDKS+Q3h9Ewb9gBUmydw2uDVlzjVhu86OnfuPWB3Ooaakm5UoU72Uu6xZ p9UK4KqNlB3qgE+B3WBLLoF4QfmsjqoXfJ0Uda35AwSboMGqVdH5nkuWB5+EXWHsKFk2 +kjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xKrrCO+zUp/pC1EolXcRwMxBuGNBkWIHWpuLhM//TR0=; b=opBcEIIZSIdczfiZ230Gz8dUABSkPF7CRFvxUv8qnnyLdC1T6aHJsr51TR4RO35XpC jU9T00oLPnt9EQW1hxXDU8/1TIVOAXdkdfnErs2fjilLhuZbSGq3XzjrE44hnaSXCBJd ZN802BaouJwRQPqyXFO1n0ckNG0sfDmkBOHW8Rkm/GU4QjdDsanc5UP/1DIp5SCeRlkl PRGllLHFLgYzmSnfsteCGg0JnG26bnOGw+nke3wSUAblQAUXxyOwiFRHJUJPhVdQE8yJ Q2GaYOQS9mdPA8RUTIlsE9khGY7KMpEEhS3OuEHO8mF1HvGVIfz5N4hAntGboorPiDJM ZPPw== X-Gm-Message-State: AOUpUlGlbBHrHkQqXUYnk54eXG1ijCpWKYWMxe/sls15TuK+1Aofjb4K GD/9jAcRcZt2jlybSegJsIfStS5QAW9RLuNnyDkCLQ== X-Google-Smtp-Source: AA+uWPyEfR7V+6w9TFxmPUhxMXCHOnhbZbeFxY8/Cii86JXTczMohgo7xJ9XBeyrG7NGWExPl9Ao9CSqnQh0p5WZqwM= X-Received: by 2002:a25:ad49:: with SMTP id l9-v6mr5120928ybe.519.1534764633728; Mon, 20 Aug 2018 04:30:33 -0700 (PDT) MIME-Version: 1.0 References: <7335E3E9AC2DE240988251CF62CAE90A0A236086@CNMAILEX03.lenovo.com> <5DFAC0AB-2135-4792-A3A3-54D7D35B942A@lenovo.com> In-Reply-To: <5DFAC0AB-2135-4792-A3A3-54D7D35B942A@lenovo.com> From: Ian Swett Date: Mon, 20 Aug 2018 07:30:20 -0400 Message-ID: Subject: Re: Same packet number in a QUIC connection ? To: changzhi2@lenovo.com Cc: quic@ietfa.amsl.com Content-Type: multipart/alternative; boundary="000000000000cf6e090573dc3cef" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 11:30:37 -0000 --000000000000cf6e090573dc3cef Content-Type: text/plain; charset="UTF-8" Yes, the client to server packets have a CID, and the server to client packets do not have one. Both client and server send their own packets numbered 1, 2, 3, etc, so seeing two packets with the same number is normal as long as they're going in opposite directions. Wireshark very helpfully parses the flag indicating whether CID is present, and if so displays it. On Fri, Aug 17, 2018 at 7:17 PM Zhi Zhi2 Chang wrote: > Hi, I have a question about " packet number ". > > > > I set up an environment about QUIC and I capture some QUIC packets by > wireshark. I find an insteresting phenomenon by watching these packets. > Please watch this picture: > > [image: cid:image001.png@01D43635.2CFF1C30] > > > > In my environment, the server is 10.121.222.230 and the client is > 10.116.47.192. Why there are two identical packet which the PKN ( packet > number ) is the same ? Just like two " PKN: 2 " packets, two " PKN: 3 " > packets. > > > > After my consideration, I find that the packet which client to server has > " CID " and the packet which server to client has no " CID ", for example > " PKN: 2 ". > > > > This is a pair of packets which client to server( PKN: 2 ) and server to > client ( PKN: 2 ), isn't right? And the packet client to server has CID and > the server to client packet has no CID ? > > > > Am I right ? > > > > > > Hope for reply. > > > > > > Thanks > > Zhi Chang > > > > --000000000000cf6e090573dc3cef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, the client to server packets have a CID, and the serv= er to client packets do not have one.

Both client and se= rver send their own packets numbered 1, 2, 3, etc, so seeing two packets wi= th the same number is normal as long as they're going in opposite direc= tions.

Wireshark very helpfully parses the flag in= dicating whether CID is present, and if so displays it.

On Fri, Aug 17, 2018 at 7:17 PM Zhi= Zhi2 Chang <changzhi2@lenovo.co= m> wrote:

Hi, I have a question about " packet number ".=

=C2=A0

I set up an environment about QUIC and I capture some QUIC = packets by wireshark. I find an insteresting phenomenon by watching these packets. Please watch this picture:=

3D"cid:image001.png@01D43635.2CFF1C30"
=

=C2=A0

In my environment, the server is 10.121.222.230 and the cli= ent is 10.116.47.192. Why there are two identical packet which the PKN ( packet number ) is the same ? Just like t= wo " PKN: 2 " packets, two " PKN: 3 " packets.

=C2=A0

After my consideration, I find that the packet which client= to server has " CID " and the packet which server to client has no " CID ", for example =C2=A0" = PKN: 2 ".

=C2=A0

This is a pair of packets which client to server( PKN: 2 ) = and server to client ( PKN: 2 ), isn't right? And the packet client to server has CID and the server to client pa= cket has no CID ?

=C2=A0

Am I right ?

=C2=A0

=C2=A0

Hope for reply.

=C2=A0

=C2=A0

Thanks

Zhi Chang

=C2=A0


--000000000000cf6e090573dc3cef-- From nobody Mon Aug 20 18:15:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2F1130E4D for ; Mon, 20 Aug 2018 18:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZfX7MAw4Ymb for ; Mon, 20 Aug 2018 18:15:42 -0700 (PDT) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.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 907A1124D68 for ; Mon, 20 Aug 2018 18:15:42 -0700 (PDT) Received: from [67.219.246.102] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.us-east-1.aws.symcld.net id 92/D3-01620-8B76B7B5; Tue, 21 Aug 2018 01:15:36 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBJsWRWlGSWpSXmKPExsWS8eIhk+6O9Op og761XBYPf35ltGhd8Z7RgcnjxLIrrB6Pnr1hDmCKYs3MS8qvSGDNOPZiKXvB3Da2ivYNc5kb GF/9Zu1i5OIQEnjJKDFl0Tx2CGc6o8T2Wx8Zuxg5OdgEtCX2zfwHZosImEgs+d3GBGIzC+hLb D6xEywuLOAm0Xm+gx2ixl1ix+sVrBC2k8TppVvBalgEVCWWzTzNAmLzCvhITH01iwli2VFGiW 8tPWBDOQUCJWYsWgM2iFFAVmLao/tQy8Ql5k6bBTZUQkBE4uHF02wQtqjEy8f/gOIcQLa8xJZ ZgiAzmQU6GSXWv4VZJihxcuYTlgmMwrOQjJqFrG4WkjqIojyJn5+WMs4CmsssoCmxfpc+RFhR Ykr3Q3YIW0Oidc5cdkxxHYnf37rYYOK3r06F2rWEUaJz5ixmiJk6EnffCSDrXcDIu4rRLKkoM z2jJDcxM0fX0MBA19DQSNdI19DCSC+xSjdJr7RYNzWxuETXUC+xvFivuDI3OSdFLy+1ZBMjMB 0wAMEOxoU/Ug4xSnIwKYnynkurjhbiS8pPqcxILM6ILyrNSS0+xCjDwaEkwVsCkhMsSk1PrUj LzAEmJpi0BAePkggvG0iat7ggMbc4Mx0idYrRm2PNvSmTmDmOgMkLYHLWlqlA8s97EHmne9ok ZiGWvPy8VClxXjeQEQIgIzJK8+AWwBLsJUZZKWFeRqCThXgKUotyM0tQ5V8xinMwKgnz3gGZw pOZVwJ3xyugE5mATmRnqwQ5sSQRISXVwKhyyG3v7eKvV1er/j80IWbm3EV7P3V/nvDVbm3mFs uo3OXpFqUCAoobA+L6fvmeORh7Oidr4vnW/XNqSi88Wr5sntzjjszeH5eaPtyY9WBTzGJ2VuP ARv4+wwUv7n8/7O7GWuz23GPrseDT1TrOZe+sRDt+WPPO09v/6ZnKy/cuB9bzTr2YE3hLiaU4 I9FQi7moOBEALnmfTKsDAAA= X-Env-Sender: changzhi2@lenovo.com X-Msg-Ref: server-34.tower-386.messagelabs.com!1534814136!691899!1 X-Originating-IP: [104.232.225.2] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30584 invoked from network); 21 Aug 2018 01:15:36 -0000 Received: from unknown (HELO maesmtp01.lenovo.com) (104.232.225.2) by server-34.tower-386.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 21 Aug 2018 01:15:36 -0000 Received: from CNMAILCH02.lenovo.com (unknown [10.96.97.130]) by maesmtp01.lenovo.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 70c0_7661_d4f071d2_e6f6_4add_8a5b_2831958db00a; Tue, 21 Aug 2018 01:15:30 +0000 Received: from CNMAILEX03.lenovo.com ([169.254.11.183]) by CNMAILCH02.lenovo.com ([::1]) with mapi id 14.03.0389.001; Tue, 21 Aug 2018 09:15:28 +0800 From: Zhi Zhi2 Chang To: Ian Swett CC: "quic@ietfa.amsl.com" Subject: RE: [External] Re: Same packet number in a QUIC connection ? Thread-Topic: [External] Re: Same packet number in a QUIC connection ? Thread-Index: AdQ19DPcZrzOeqm3R6SZpqdlxcdaWAAjCmCPAG1waAAALXN/MA== Date: Tue, 21 Aug 2018 01:15:27 +0000 Message-ID: <7335E3E9AC2DE240988251CF62CAE90A0A236CE0@CNMAILEX03.lenovo.com> References: <7335E3E9AC2DE240988251CF62CAE90A0A236086@CNMAILEX03.lenovo.com> <5DFAC0AB-2135-4792-A3A3-54D7D35B942A@lenovo.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.96.19.89] Content-Type: multipart/related; boundary="_004_7335E3E9AC2DE240988251CF62CAE90A0A236CE0CNMAILEX03lenov_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 01:15:45 -0000 --_004_7335E3E9AC2DE240988251CF62CAE90A0A236CE0CNMAILEX03lenov_ Content-Type: multipart/alternative; boundary="_000_7335E3E9AC2DE240988251CF62CAE90A0A236CE0CNMAILEX03lenov_" --_000_7335E3E9AC2DE240988251CF62CAE90A0A236CE0CNMAILEX03lenov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIElhbi4NCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBJIHN0aWxsIGhhdmUgYSBxdWVzdGlv biBhYm91dCB0aGF0Lg0KDQpJbiBXaXJlU2hhcmssIEkgc3RpbGwgZmluZCB0aGUgc2VydmVyIHRv IGNsaWVudCBwYWNrZXQgaGF2ZSBhIENJRC4gTGlrZSB0aGlzOg0KW2NpZDppbWFnZTAwMS5wbmdA MDFENDM5MkYuN0ZBN0RBNjBdDQoNClRoaXMgaXMgcmVqZWN0aW9uIHBhY2tldCB3aGljaCBpcyBz ZXJ2ZXIgdG8gY2xpZW50Lg0KDQpXaHkgdGhpcyBzZXJ2ZXIgdG8gY2xpZW50IHBhY2tldCBoYXMg YSBDSUQ/IEJlY2F1c2UgdGhpcyBpcyBhIHNlcnZlciB0byBjbGllbnQgcmVqZWN0aW9uIHBhY2tl dCA/DQoNCg0KVGhhbmtzDQpaaGkgQ2hhbmcNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElhbiBTd2V0dA0KU2VudDogTW9uZGF5LCBBdWd1 c3QgMjAsIDIwMTggNzozMCBQTQ0KVG86IFpoaSBaaGkyIENoYW5nDQpDYzogcXVpY0BpZXRmYS5h bXNsLmNvbQ0KU3ViamVjdDogW0V4dGVybmFsXSBSZTogU2FtZSBwYWNrZXQgbnVtYmVyIGluIGEg UVVJQyBjb25uZWN0aW9uID8NCg0KWWVzLCB0aGUgY2xpZW50IHRvIHNlcnZlciBwYWNrZXRzIGhh dmUgYSBDSUQsIGFuZCB0aGUgc2VydmVyIHRvIGNsaWVudCBwYWNrZXRzIGRvIG5vdCBoYXZlIG9u ZS4NCg0KQm90aCBjbGllbnQgYW5kIHNlcnZlciBzZW5kIHRoZWlyIG93biBwYWNrZXRzIG51bWJl cmVkIDEsIDIsIDMsIGV0Yywgc28gc2VlaW5nIHR3byBwYWNrZXRzIHdpdGggdGhlIHNhbWUgbnVt YmVyIGlzIG5vcm1hbCBhcyBsb25nIGFzIHRoZXkncmUgZ29pbmcgaW4gb3Bwb3NpdGUgZGlyZWN0 aW9ucy4NCg0KV2lyZXNoYXJrIHZlcnkgaGVscGZ1bGx5IHBhcnNlcyB0aGUgZmxhZyBpbmRpY2F0 aW5nIHdoZXRoZXIgQ0lEIGlzIHByZXNlbnQsIGFuZCBpZiBzbyBkaXNwbGF5cyBpdC4NCg0KT24g RnJpLCBBdWcgMTcsIDIwMTggYXQgNzoxNyBQTSBaaGkgWmhpMiBDaGFuZyA8Y2hhbmd6aGkyQGxl bm92by5jb208bWFpbHRvOmNoYW5nemhpMkBsZW5vdm8uY29tPj4gd3JvdGU6DQpIaSwgSSBoYXZl IGEgcXVlc3Rpb24gYWJvdXQgIiBwYWNrZXQgbnVtYmVyICIuDQoNCkkgc2V0IHVwIGFuIGVudmly b25tZW50IGFib3V0IFFVSUMgYW5kIEkgY2FwdHVyZSBzb21lIFFVSUMgcGFja2V0cyBieSB3aXJl c2hhcmsuIEkgZmluZCBhbiBpbnN0ZXJlc3RpbmcgcGhlbm9tZW5vbiBieSB3YXRjaGluZyB0aGVz ZSBwYWNrZXRzLiBQbGVhc2Ugd2F0Y2ggdGhpcyBwaWN0dXJlOg0K6ZSZ6K+vIeacquaMh+WumuaW h+S7tuWQjeOAgg0KDQpJbiBteSBlbnZpcm9ubWVudCwgdGhlIHNlcnZlciBpcyAxMC4xMjEuMjIy LjIzMCBhbmQgdGhlIGNsaWVudCBpcyAxMC4xMTYuNDcuMTkyLiBXaHkgdGhlcmUgYXJlIHR3byBp ZGVudGljYWwgcGFja2V0IHdoaWNoIHRoZSBQS04gKCBwYWNrZXQgbnVtYmVyICkgaXMgdGhlIHNh bWUgPyBKdXN0IGxpa2UgdHdvICIgUEtOOiAyICIgcGFja2V0cywgdHdvICIgUEtOOiAzICIgcGFj a2V0cy4NCg0KQWZ0ZXIgbXkgY29uc2lkZXJhdGlvbiwgSSBmaW5kIHRoYXQgdGhlIHBhY2tldCB3 aGljaCBjbGllbnQgdG8gc2VydmVyIGhhcyAiIENJRCAiIGFuZCB0aGUgcGFja2V0IHdoaWNoIHNl cnZlciB0byBjbGllbnQgaGFzIG5vICIgQ0lEICIsIGZvciBleGFtcGxlICAiIFBLTjogMiAiLg0K DQpUaGlzIGlzIGEgcGFpciBvZiBwYWNrZXRzIHdoaWNoIGNsaWVudCB0byBzZXJ2ZXIoIFBLTjog MiApIGFuZCBzZXJ2ZXIgdG8gY2xpZW50ICggUEtOOiAyICksIGlzbid0IHJpZ2h0PyBBbmQgdGhl IHBhY2tldCBjbGllbnQgdG8gc2VydmVyIGhhcyBDSUQgYW5kIHRoZSBzZXJ2ZXIgdG8gY2xpZW50 IHBhY2tldCBoYXMgbm8gQ0lEID8NCg0KQW0gSSByaWdodCA/DQoNCg0KSG9wZSBmb3IgcmVwbHku DQoNCg0KVGhhbmtzDQpaaGkgQ2hhbmcNCg0KDQo= --_000_7335E3E9AC2DE240988251CF62CAE90A0A236CE0CNMAILEX03lenov_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrnrYnnur87DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOetiee6 vyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlQm9keTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAg MCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAuTXNvQWNldGF0 ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseTrnrYnnur87DQoJY29sb3I6IzQ0NTQ2QTt9DQpzcGFuLkNoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseTrnrYnnur87fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjojNDQ1NDZBIj5IaSwgSWFu LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6 IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 Ouetiee6vztjb2xvcjojNDQ1NDZBIj5UaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgc3RpbGwgaGF2 ZSBhIHF1ZXN0aW9uIGFib3V0IHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Ouetiee6vztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPkluIFdpcmVTaGFy aywgSSBzdGlsbCBmaW5kIHRoZSBzZXJ2ZXIgdG8gY2xpZW50IHBhY2tldCBoYXZlIGEgQ0lELiBM aWtlIHRoaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxpbWcgd2lkdGg9IjEzMzIiIGhlaWdodD0iMzMzIiBpZD0i5Zu+54mH X3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDAxLnBuZ0AwMUQ0MzkyRi43RkE3REE2MCI+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrn rYnnur87Y29sb3I6IzQ0NTQ2QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Ouetiee6vztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPlRoaXMgaXMgcmVqZWN0 aW9uIHBhY2tldCB3aGljaCBpcyBzZXJ2ZXIgdG8gY2xpZW50Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0 NkEiPldoeSB0aGlzIHNlcnZlciB0byBjbGllbnQgcGFja2V0IGhhcyBhIENJRD8gQmVjYXVzZSB0 aGlzIGlzIGEgc2VydmVyIHRvIGNsaWVudCByZWplY3Rpb24gcGFja2V0ID88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6 IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 Ouetiee6vztjb2xvcjojNDQ1NDZBIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPlpoaSBDaGFuZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6IzQ0NTQ2QSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUVVJQyBbbWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgQXVndXN0IDIwLCAyMDE4IDc6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IFpo aSBaaGkyIENoYW5nPGJyPg0KPGI+Q2M6PC9iPiBxdWljQGlldGZhLmFtc2wuY29tPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtFeHRlcm5hbF0gUmU6IFNhbWUgcGFja2V0IG51bWJlciBpbiBhIFFVSUMg Y29ubmVjdGlvbiA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WWVzLCB0aGUgY2xpZW50IHRv IHNlcnZlciBwYWNrZXRzIGhhdmUgYSBDSUQsIGFuZCB0aGUgc2VydmVyIHRvIGNsaWVudCBwYWNr ZXRzIGRvIG5vdCBoYXZlIG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5Cb3RoIGNsaWVudCBhbmQgc2VydmVyIHNlbmQgdGhlaXIgb3duIHBhY2tldHMgbnVtYmVy ZWQgMSwgMiwgMywgZXRjLCBzbyBzZWVpbmcgdHdvIHBhY2tldHMgd2l0aCB0aGUgc2FtZSBudW1i ZXIgaXMgbm9ybWFsIGFzIGxvbmcgYXMgdGhleSdyZSBnb2luZyBpbiBvcHBvc2l0ZSBkaXJlY3Rp b25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2ly ZXNoYXJrIHZlcnkgaGVscGZ1bGx5IHBhcnNlcyB0aGUgZmxhZyBpbmRpY2F0aW5nIHdoZXRoZXIg Q0lEIGlzIHByZXNlbnQsIGFuZCBpZiBzbyBkaXNwbGF5cyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIEZyaSwgQXVnIDE3LCAyMDE4IGF0IDc6 MTcgUE0gWmhpIFpoaTIgQ2hhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaGFuZ3poaTJAbGVub3Zv LmNvbSI+Y2hhbmd6aGkyQGxlbm92by5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O3RleHQtYWxpZ246c3RhcnQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhp LCBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCAmcXVvdDsgcGFja2V0IG51bWJlciAmcXVvdDsuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87dGV4dC1hbGlnbjpzdGFydCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpzdGFydCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9k eSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SSBzZXQgdXAgYW4gZW52aXJvbm1lbnQgYWJvdXQg UVVJQyBhbmQgSSBjYXB0dXJlIHNvbWUgUVVJQyBwYWNrZXRzIGJ5IHdpcmVzaGFyay4gSSBmaW5k IGFuIGluc3RlcmVzdGluZyBwaGVub21lbm9uIGJ5IHdhdGNoaW5nIHRoZXNlIHBhY2tldHMuIFBs ZWFzZSB3YXRjaCB0aGlzIHBpY3R1cmU6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+6ZSZ6K+vPHNw YW4gbGFuZz0iRU4tVVMiPiE8L3NwYW4+5pyq5oyH5a6a5paH5Lu25ZCN44CCPC9iPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JbiBteSBlbnZpcm9ubWVudCwgdGhlIHNlcnZlciBpcyAx MC4xMjEuMjIyLjIzMCBhbmQgdGhlIGNsaWVudCBpcyAxMC4xMTYuNDcuMTkyLiBXaHkgdGhlcmUg YXJlIHR3byBpZGVudGljYWwgcGFja2V0IHdoaWNoIHRoZSBQS04gKCBwYWNrZXQgbnVtYmVyICkg aXMgdGhlIHNhbWUgPyBKdXN0IGxpa2UgdHdvICZxdW90OyBQS046IDIgJnF1b3Q7DQogcGFja2V0 cywgdHdvICZxdW90OyBQS046IDMgJnF1b3Q7IHBhY2tldHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1h bGlnbjpzdGFydCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87dGV4dC1hbGlnbjpzdGFydCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+QWZ0ZXIgbXkgY29uc2lkZXJhdGlvbiwgSSBmaW5kIHRoYXQgdGhlIHBhY2tldCB3 aGljaCBjbGllbnQgdG8gc2VydmVyIGhhcyAmcXVvdDsgQ0lEICZxdW90OyBhbmQgdGhlIHBhY2tl dCB3aGljaCBzZXJ2ZXIgdG8gY2xpZW50IGhhcyBubyAmcXVvdDsgQ0lEICZxdW90OywgZm9yIGV4 YW1wbGUgJm5ic3A7JnF1b3Q7IFBLTjogMiAmcXVvdDsuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGln bjpzdGFydCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJ Q1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87dGV4dC1hbGlnbjpzdGFydCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+VGhpcyBpcyBhIHBhaXIgb2YgcGFja2V0cyB3aGljaCBjbGllbnQgdG8gc2VydmVyKCBQ S046IDIgKSBhbmQgc2VydmVyIHRvIGNsaWVudCAoIFBLTjogMiApLCBpc24ndCByaWdodD8gQW5k IHRoZSBwYWNrZXQgY2xpZW50IHRvIHNlcnZlciBoYXMgQ0lEIGFuZCB0aGUgc2VydmVyIHRvIGNs aWVudCBwYWNrZXQgaGFzIG5vIENJRA0KID88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRU ZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5B bSBJIHJpZ2h0ID88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0 YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZv bnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5Ib3BlIGZvciByZXBseS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVC b2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5UaGFua3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5aaGkgQ2hhbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_7335E3E9AC2DE240988251CF62CAE90A0A236CE0CNMAILEX03lenov_-- --_004_7335E3E9AC2DE240988251CF62CAE90A0A236CE0CNMAILEX03lenov_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=58220; creation-date="Tue, 21 Aug 2018 01:15:27 GMT"; modification-date="Tue, 21 Aug 2018 01:15:27 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABTQAAAFNCAIAAACxF3dDAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAA4xFJREFUeF7t/Qt0Hdl534nu1stSrmUntmI7kngAEJBg3LHTiT1W2CJMik7D g1CgkSznkgzD6UYvYyTRvAsKxDBux2AzTcJuJlwUOmdCU9EgIdjD8DYZe/nCgBjIoE2CBrt7FCcj erwujBbQAEFZseLEz7Etyeruux/12FX17apdr3NOHfyPuWR2cT++77e//e3Xt6se+cM//EOm/X7v 936PP/nV//ytV35x480332D8D3vzzTdfF/8j/s6fvPmWt7x598ZHf+s3f+MHfuAH9Lz631977bXv /d7v/epXv2pKwJ9/93d/92//9m/v3LmTTPMnf/Inf/7nf/5nf/Znr776qkrwlre85f3vf39nZ+cf /MEf8PL/9E//lD/cv38//3utVoupaHl5+Tu+4zs+9KEP3b1796WXXlpZWeHKdHV17d69e9++fb/x G7/xR3/0R/39/WQJDx8+3LFjB/lP3/ztf/CdHYOKifhf9qbCpf73d19b+p6de/n/vuuv3zDJxuXh 8n/jG9/gan7bt33b1772Nf6XN9544z3veQ//u1KZ/+edO3f27NljKuQzn734u//19776X3/vmX86 9r29nX/8x3/2R3/4J2+88XpH5/v++I//9L/999//Z5P/8tu/7d3vf+97P/Gx4zGF/NTJn/z61//s j/7oT77ru/5KqBDe9O94x9u/+Rev//y/vkYWEkPJVONTH/v4axubb3/72/7d5cvf/d3fFdN80X/6 kz/543e/+9tSZTHYWOpy3njjm5b1vuUtb0tMydvuH3/qp9761rfylF//xtf/13/1L/+Xn/h4Yq5Q At4RfvGXbvxw/97XX3/9C//xlb83/Pff9a53mQqZ+e13/I33vO7961//jq+HUn71D/782L+896d/ /k1u0/z3CGP/j3e97dInd3/1zb+sUn7xv7115Hu/wf+iN3pisSZ5fvP3vyWmWHsU/+7F65df+N95 V/qWb/mWX5n/5Uce4YKn/jWyEN2QZl64fOTwkXe8w0Hx2el//bFR3wxsDCm1qsgAAiAAAiAAAiAA AiDQegQeCS3Ov/SlL/E188qDt2995U/ffEMsyPmPLzf538X/l0tP9sabP/7R7t/64vIP/dAP8dUj qdT9+/ff/e53J+rLV+CPPvoomey//tf/+u3f/u1f//rX1SJc/3GRvP/s6OjgMvMVe/x0nK/wv/zl L/f19fHl/Tvf+U6enRfLn/DdAb6w/+AHP2gSNWbZ+Re//Q/e0/Gj5Mqcr9V/d/3Xv6f7h/n/vuvR hMW5rg4Xg/+nTvWb3/zmrVu34hfnP3XyE+zNv/BVePN13l6PiCXfI/z/eIHf+Po3/+W/+t+TFufZ C8mwOH/45S//zOl/9r6/9t6fPfPPTFaUaD+NT7Dn8R+1rPTurV9JTPmrv7b4pTVn74kn7uv7f+79 4X2JuaIJfv8Pfv/u3Ttvecsje/fs+/Zv/8sxJdisojd/90+env6N//vPxQr8W9/1jnOj/2Pn97w7 fhUdKnbs8N+21KL+4q+qlOSa37IQlewX/7+z/9u/+bd7frj/n/6Tk6ky6okbVohuSP+vv7d/9nOL 3/iG04WPHBy+dmPWk8rGkDLri4wgAAIgAAIgAAIgAAKtQyC8OOeLan5erY7y+NI8Kqh6yFfCv//7 v/+DP/iDf/Wv/tWSlOEr57/4i7/Ql9y6PPpzftrMF9jf+q3fGi8J3wjY2triYvPlLk/5tre9jR+n 84zxmwhxi/OVww4hEVYgKhf/T/yf2sN4k6+M33zLu/7S918xCcZPzi3pxS/OLQuJX5znKSTD4tyy ulZLVuzJeWbt/peP/4Rl3v/tX/8bPaXtKvpt3/K2zr/DM35z8z+wb4rT9fhVtM2anxS4qJNzSxpI BgIgAAIgAAIgAAIgAAItSyC8OG9ZQSEYCIBAfgKhVXSGAr0j7pg1f1HFZigHWUAABEAABEAABEAA BECgogSwOK9ow0FsEMhCgC/Os2QL5lF3zkOL8zKKzV8mSgABEAABEAABEAABEACBqhDA4rwqLQU5 QQAEQAAEQAAEQAAEQAAEQAAE2pYA/Tq3tlUXioEACIAACIAACIAACIAACIAACIBA6xF45POf/3zr SQWJQAAEQAAEQAAEQAAEQAAEQAAEQGAbEXiEfCX7NgIAVUEABEAABEAABEAABEAABEAABECg2QRw 57zZLYD6QQAEQAAEQAAEQAAEQAAEQAAEtj0B3Dnf9iYAACAAAiAAAiAAAiAAAiAAAiAAAs0m4Jyc //Ef//Hc3Nxv/dZvNVse1A8CIAACIAACIAACIAACIAACIAAC6Qg89thj73vf+77/+7//He8o4OPB 6eouKLWzOL969epf+kt/6amnnkpV7E/+5E/+/M//fKosSAwCIAACIAACIAACIAACIAACIAACxRL4 9V//9f/wH/7D+9///n/4D/9hsSU3rDRncf7TP/3T+jL7yp3N3/2Dr73BXxb3JpP/I/73vd/xrp/4 2zt1ybA4b1g7oSIQAAEQAAEQAAEQAAEQAAEQaH0C//2///f19fW/+Iu/iBc19GLyN954w0vPj74/ 8IEPfOd3fmcGZfkS9bnnnsuQsRWy0HfOv/L7f/46x/PGm/zP62+++Tr/3zfY1u/9WStIDBlAAARA AARAAARAAARAAARAAARak8Brr70WvzIXp7/i/Nf5iXWntjLnT7/xjW+8+uqrDdDuL//lv0zWEn1u SqlnV2lsUppUoxfncjXu/HGW6G+8wZ8UDuifub/CS/YKVDXo/5mqrsIljJGn8LpSaVpe4gx66U1W nmAoGQRAAARAAARAAARAAARAoFgCfGltKjBxWc4zqrX617/+9WKlSlXaH/7hH2ZeY+fJa1icv+4v zr/5+pvfdBfqiSqlXVOFVqqJ5WdIkFakUBXFSugtU0mpiq0rA6uYLJ7A8SqQJaTVy0ufs+2KJYDS QAAEQAAEQAAEQAAEQAAEshEgl+Xf933f9zf/5t9817vepcqMHqFnqys+F191ez+eMvSfXl6+xs5c e+a8hsW5E8ouluj85rkIbn+DlXFynlnhzBlbZL2nr3UTdWm6zPpqmTwGL0nCtKv6RJJIAAIgAAIg AAIgAAIgAAIg0EgCMafl3/Ed3/Hud7/7B3/wB7/ru74rFNlenoR85ez9eC2h/wzVSy7jQ0t6U5oM KiSEtfMzc/fk3DasvaR1WgbdkMUjoK9yTX834TKtkEtq6GjYf0kVwTxAAARAAARAAARAAARAAATK I8CX5fxsvD/426P9VNVvectbvvd7v7e3t5f/RT2JOUL/b//tv/3zf/Hc2Z894/3h/8kfptIifjmt /yu5jA8t6U1pVDlKMNPfQ2InhLWrC+f8j3Zj36g4uayKLgXjj0Ptl442x6qJK71QkLZ9zHaG5a5a ZNorqEBHc5kKsQGSympDFZnyhiQMHbOTuXTOiWInJkirFNKDAAiAAAiAAAiAAAiAAAiUR8A7Lf/2 b/92y1r+2l/7a48++mhiZPt73vOewcH9v/3bK//X//Wb/M/Kyv/v8cd/lD+0rEUlMy2n9X9NVWBh iZVkx44dUwTV7x9f+eKJmf/zU5fDf/Q0/O+hXKdPn+YP1f+qn/f3mL+EspC5QvXmSaOLF63aVLIp V7xeMWJHEdk/ISsNSRitOtuTRFyhhvb+MyqPjYSmNDZ5symIXCAAAiAAAiAAAiAAAiAAAgUS4N8b 936piuXL0l/VfjF5v3j/i0eOHv4H//DQb/yn3wgl40tUPVI99PfEVXTMUbm+qo/eKldPYqq2+Sf6 5NzyqDyqm3eImqh2zgTkzecMZWYrJ1uuDOKZskQPk0uK/c58al2gPJllKBA4igIBEAABEAABEAAB EAABELAnoM7A7V+N9l/+y3/54he/qMpPPD9/9K8/evIf/5N/cvKnfvAHftBepOjqOrqijikt9Bp2 tdj2ykwlhikxvTjPXHQh6yib2PICl8cZiopmsZE5M9VoxgwyZ67d1KYFLr+VbGRFhVhUZt2REQRA AARAAARAAARAAARAIBUBfWn9m7/5m3fl7w7185biv83j1FdWXn/99cRluSfJ33j0b/I/qQTTE/NL 4NGNA/LzaXrK0Po8VHv8v9qI+oiS6ad/+qd//ud/3stwYuaL8u/8w+aP8P/3yCNM3Tm/MPI39EJ/ 8id/0suln5lHr0l7C7nQX0ILPP0/E1dlocSktqYCo/Lw7KFj/9B/qvJjMqp/jVmyRgW2pGGiF6qx 8NWyjtRTzZ4AmVJnGGqyKL1EG7AxcaQBARAAARAAARAAARAAARBoGAG+FNfrIl/Drh7y76i99a1v 5cvyP/3TP40me/zxxzPIzJeozz33XHxGtQj3Fudq+R1arpMPeS4ymVedKZelIvGLc/aD3X+FF/Sf 1v9AFRezOCfry7zcauKqLHPVmTNaNlV7JwO99m5faAcCIAACIAACIAACILBNCHiL85hleeLqnSco Y3HuLctDq2jLlXm0BfXDdrXaD638UzV6XFh7z/d866HdNf6H/yVVoSpx9OSZPIsOlawWaaUeAsfo YiNhNHtzZc7QNC2YpVkt3oIoIBIIgAAIgAAIgAAIgAAIVJfAO97xDjI6PfowJoj9ne98ZxkEvIvi ahXtHZ6rk3O1rvaeew/VP3k/lUb99Ne8KYHtr9lHFXROzmdnZ7u6un74h39YpfhX/+FLr7/x5scG ut/1jrfy//zzb7z+2cX1t77lkf/33/mAXoQe1l4GO5QJAiAAAiAAAiAAAiAAAiAAAiBQIQL8q+Nf +tKXvv71r3syR4/QyUN1Lz1fmff19X3nd35nWq35of3Gxsbf/bt/N23GFknvLM7/03/6T7du3frZ n/3ZR/j9cusfFufWqJAQBEAABEAABEAABEAABEAABECgLAJ8Zf4Lv/ALhw4d+r7v+76y6ii5XGdx /o1vfOPf//t//1u/9VslV4fiQQAEQAAEQAAEQAAEQAAEQAAEQKBgAn/rb/2t7u7u7//+7y+43AYW 5yzOG1gjqgIBEAABEAABEAABEAABEAABEAABEAgQKPg756ALAiAAAiAAAiAAAiAAAiAAAiAAAiCQ lsAjn//859PmQXoQAAEQAAEQAAEQAAEQAAEQAAEQAIECCTxy5rnnCywORYEACIAACIAACIAACIAA CIAACIAACKQlIBbnp57+ZNpsMem/8pWvvPe97y2wQBQVTwDA28lCqtKaVZHT3jbaTyNS922ipn27 50zZfjyhUU6TaEB2tFEDIKMKEAABECiPwOc+97kPfvijpvJx57w88igZBEAABEAABEAABEAABEAA BEAABKwIYHFuhQmJQAAEQAAEQAAEQAAEQAAEQAAEQKA8Alicl8cWJYMACIAACIAACIAACIAACIAA CICAFQEszq0wIREIgAAIgAAIgAAIgAAIgAAIgAAIlEcgsDh/xP2VVx9KrhYBbhGFCFxUOYUIg0Is CbSCQ1AyWAqMZM0lUFRLFVVOc2mgdhAAgQYQwBjRAMioAgRAoJEEAovzN+Wv8Oq9KT6mXIWzjRYI 2g2A3LAqmtua9g6hvGV8GR7JsvmaCL9hVTesIkvmRSVrol6hqvX/VCNgE2XLgDcqrd7ZQ9rFL5M8 9TOIUXiWkMsi/1NVGqNjYlPqQEpaQ5LN4UnucfNqT2yjmPaNWq+p9kQy8Q0a7TWm9DylGqcwvSy8 j6BAEACBZhGwCmvP4/U819nESXaz4DalXsU523AVbehsrVZUOU0B2FKVFtua5anmyVlIFXkcTiEC qDmo6kTZukBOMRrW7sVWlI1VGe6iWL3sWzNqNp4J6X/J7KLtJSkqZZRkqLPr/5nNAIoS1b4cr5m8 RazX2ZU1hhTRXYHXjjYuIlqOvZCWKaPMyVbQH5qaidTI1Nz8uUofktN7nsd5RntNIo2q2F6iIkgA AiAAAlaL86IwwXsWRRLlgAAINIwAHFfDULdTRW1vNt7azHLhp/a8vP9tVlvrS8qi2qiocgpnknmj M7Qmj25YWIrasmQs5UcyEAABEGg8AbE4j3ff3miqJ7MP0FLbqNEq9Ife32P+4u1wh0qzl6TxcFuq RpJbqBWUMXiNlZhFbxRP2ajBWBoAmtJkMIqMmuVE+4hlK4QatzEdKmpO0VZWT3S9oqI23jZawXHp 7R5tZdISor0vmxdK7PuJ3TzUrLp/8DyMvlozuR2T4jYm0USA2bC3bC6SZKp1VxUP2AtsDs+BW3bk /FWHalSr6+hDvSKT04sKE7WHbOXYq0n6E9Ld2XgG+3qREgRAAAQaT0AszpVHNtXtjaneSKz8e3yu kKcOJQ6V4JUc+ouXzBvPQoFSaSVpPN8WqZEEpWCGmEefeCrolqDPpEPGEDWY6ByONIBURtUiYBsj RrRRTF3DaxebbhsqRK2UCmwFm1bWZQhN33WzKVAq+yaLVtpgxxXv7hSfUCNG291eX339HNW9iu6i WQAzMG/xLCGSidOGFldHXyHHTH5K0oJ0I1FvnKp2NcWKDrWpClHNqoqKzxiqKFq7ZTn24pHTD5th zr4KpAQBEACBFiGQfHIeFVQ54kT3Hcpo4/GjWUhM+sCQQZIWQd9gMUKgsjViUcbQYN3br7r8kzCd SbGl6SUndk/PDsuTIWfrt7jjKonb9nEXJQHMaXWVyJ6qa3iHnFy1tJOHkmh4SzslUklSkZSi1ZVh hzpzpaNlk9kkKypNSY2LYkEABECgugSck/NUA0OqLd4yBjy9TLVBm0r+6rZWHsmjoArZ205lDHnk R97yCBTeSb0CE7tny9pP4UxCa5JEMuU1t03JcBc2lOLTlGFC+aVqVgn6Sri54zW5qsw5Gia2dUjl xnT/tFOjRC0sjaeociyrQzIQAAEQaDMCzsm5t8Ma+ounrb7R6x12WW6Bq7xqFq4K9EqIPlFlhnZ8 E3NhMNBbymMYxeuB8holZNB6Q0f33fUWV/9qMoaYcqIGQFbUZj0tmzrRjmDZNVR1ZLe16YYqjd4T 47uY7je8lJ5t6DLrFqhbQqj8kBMI5coGM22uJjoum1Ym00TbPV5rveHayV00DGAIr27zpk5EMk9r nA1Ln+iCyN7dMPGyVRSageijmMk9Rp1htK0thYl3jJaFhEZ8PZfu9kmHEOPMo07PZhoQqt0bO3je bBsxUdoxYsQPc2l5Ij0IgAAINJ1A4OTc280NbbiaTlFs9mX1MnVto3lDtZOFx+RqOsoWESAeuD7z iGlWpUsogf6fekNEa4zJ6FEiS/AqbRGYTRcjsY1InmTzkWxNHSpUQmJPj3beqAyk/ajZm/rpq3qv RpPVld00zXVc0XbXeZraN/45Saxd3UXDAEapmrxf1KQ9b1y2MecpP94Fkf3UVJ3St0W0Dvk07z/1 hatpmPNUMJlZiEBU5ahby4xFbwJ91I4K6fE31UV6A5M9h2YIeuEmr2Jvh3oJoZL1gSxGYPu6kBIE QAAEWo1AQz+l1mrKQx4QAIHmEuCzq+hZTXNFQu0gAALbk0Boxb49IUBrEAABEACB5hLA4ry5/FE7 CGx3ApanT9sdE/QHARAAARAAARAAARBodwJYnLd7C0M/EAABEAABEAABEAABEAABEACBlieAxXnL NxEEBAEQAAEQAAEQAAEQAAEQAAEQaHcCWJy3ewtDPxAAARAAARAAARAAARAAARAAgZYn8MiZ554/ /PFPtrycEBAEQAAEQAAEQAAEQAAEQAAEQAAEKkzg1Zc+N7TcbVIAi/MKNy1EBwEQAAEQAAEQAAEQ AAEQAAEQqAoBvjj/4Ic/apIWYe1VaUfICQIgAAIgAAIgAAIgAAIgAAIg0LYEsDhv26aFYiAAAiAA AiAAAiDQBgTunX1012Piz+RyUJutmaeiD5unMCmnUfjmyYmaQQAEWpaAWJxf23LFkz5Our/DCQ9T KLR5bSTiT8mK6DKp7Ix8yNjyhPLdu0ZmPJ1Mkm5dPex7eS+jo37E+wdKoWr3S5i45yVOoWYKoElJ SwBOK2Johah89nZlT4xK6Y1/hRpwEu9y/92BHJiU+Lq7hsrNz7d5kUVOX5YmXXuW2X3LpEGVq0iB pROGR2uUs1eG/UmgLXadXXJVKstHFYgsvqiAM/RGA91DMlZxm2kYS0tjMNiS2QGG28jeqZK9oGE8 GlqR3ZAU9Z9cSNsBxeQEGqpn61VmPeuwHuKjDmf3qfuvvDw71lus9t5wGVssPcLSWUg5SxA+ML67 Gxb8oTvQe3sW0gM8dXVTimunb1gzu55lRhhpTWpyEpiHaxPpFA1eFfcblTPViGCpptPcxH4Wd3jB 8d1fPfG5oje30VvEeZhmFrSNhp4UNmqZVCzOFw+pbrA0eWiq+zx3f/dfuT4Y+9CycLU8eJqdCflT siKyTEN2okxpatM9N7jw/M/MSC1exuWJg7d6hjwv3z8pcjl/6kOsb6cxPyUSd4In2QWV/Tw74SyT Nq89szYqH944zurPJO8X2GM1pywDOKkIWREpF5nd/qF9mUyOfyHg9sZWBP6Cy+B+cLjeXfeMc6I/ 1E/H109q+2jh2vdOCBrcng9I45zc7Y7NJ5hX5otHErpKwSrlLo42PKLp8/VKkz8ZUh6S/zm1V+pS mo/KTcq2gJAzVNkiD6nOZVvDtkmXwhg4E8KWiCGYbA7SrVFOle4FbdkglkOSjs7zn/QwYbL5SMO1 JU97pexnHZbDsVgApBikaiOXX74vB8ft9lMjO5+xR2cCDmoHS28fu3Un8cjKgM+yZ5ngk61JTk4Y 6x1Xc/gbx9dOaMcJdu1aFfdr5Gk3ItiraW648Pi+NOktYfiM8eYleTpLPhRNYTUL2kZDj515pkwl FucrbO42P2dbXpzvHX9COrituwtxD1PUwXtgZPZPVkSXSWVn5MOlFy6ysTNJa3KnFm5za2NnRndS lW5dvTS//5h5xULVvrW2sn9ArnwY6x8YWl1YFpbdeWRGLYdYrbOHra49TMEtc9IygJOKkK1Aik1m t39oX2YwZXeXWHWmMLbMzEvLuDxdXz1wwVkEOrUI+3T7KauNjO5fWby7mUKCrTuLkTJTZG9+UgvD U02fq1fa+5OSfFTDQJPOMM5DCskUYfzCBOyNgWJndFaR5qBTUk6V7gVt2XIWnkGcF1H+02aYgM0b rcZ61mHDWbjuFIMUHS5OBEeII+Vr8rTQO0aWh4fD9VU2fzISMWrZRcgoDMu8QlMvWDU+WjOpxNpH BnpXXtMW3/fOjq0fn9U2LAZHH194IXQdQEyQxKF6+JqAlVtLEsn79zSt6WWqHT031js37Zz255HT yi2IehvnfnOKZD/KmCqKju8dOz3agsNgvxjgyYdku9svi6zNZtsnFIvzsf1sfXNza3NNTbm4szt4 azDmYU5oZEU5y2RbG+u9gx13A57XVKZ0W+cMy285KX9SnYml+d1cVNHsYuyP5BMqe6v3NKUWkrZA 4DkVIbPbPyRpBLM7sVLcgG/INW2BuhfSFqkK8VRTAUhqEH24saIvjXZ09a1sPLAvVuy79fbssM9Q mZThpheCZ+6VZn+SYxqXwkc1jDrpDA0ekiLcMEHbsaKQLZmcVbQ5Et1awCvG9oJ25BqnE+k/zTxp m8/uBLYN7jzzyVSDFBUuzg+NnaBFHjjG/OCyufrGMRneeGDl4jSfsNWOvqji5N2TwNg4stWpg841 MbGelz9TRXbNzFfmhxYGrpuOvu0KUanEPr4W77k8weMOLh/t1IvYsWdw/bZ3FStN4fnSpmpNrarO DuNHpvIJ5OZuQfdrKVJO/anxnW/s3h/dGBbzzNsDbugx+VBUbusAMfTkaCqxOO/Q8vOVuYgmmhlJ fJijUpGVrChXmatT0+ycjDitd1982r8zHyqUcltekqRjc4OA/ZMyCEcsn06zwaFIjQcv9oTOP3Np milzAcB5JEweRcjs9g9JrcPZVazU/VdG1w4Gr1hHrToTxeZk8uYQzam+GrVGmj5nryT8iRir/HsT zm2gNHQsfVSaInOlJZ2h0UPSnSuXANs3s9GWwo7aPGAZXbruFeN7wfblT2hO8YzafG4nsJ2YN2w+ GYDKt1bZnJqP7XpsTDssccPQaj19GVrBjbj2770bK7IqXaxavSBNGQSnH31bFeGpyUNBr3s7C3Mn Ts71delTeFkYr4KpcGXtJ290VuBGQMFytqD7tRbJzjKMqegBxb96cIGNuS8wIh9aO0AMPflaSizO H6yz7s5OEXp9c2y6a1bepdyMeZivRhnjHakoZ5kie+/4s85O4d59Rje3eW16jtcuvbYbzuS9SWtr 5nS2Y3NnC1ZM3C/vYeusp8MN+hRnnuIuhxPfXoCa6YsoBHhORcjs9g9JpeNE4pcL2NqDrdKMLX0r ZMghGm59IzSY8qNy/SE/CCKGYXNlDbxhkUHjIrK4TS9mI+JgJGuvjPUntT2DfdLA0v2sfFS6InOk Jp3hpy/GeEhVmUY4R+3I6hDwbIly1IwcsJh5DI16RVMv2J4NQPrP5CGSsvmMTmB7cM8zn8w7SPGr HP5Cmvv/0t6r0rCKjDbj3jkP6Mgfzg7cGnbfAOdn3r2vp37lToMNMGtrOmuQsqVtQfcbK1JnPiCG FZB29WD3qfrQ6pS4AUE+1KpPdIAYevI0llic83ut+/hVczH89A3skW0vL7uaHorhny9oxW0Z/jIq sbkS9QJxMpEVqQxWF2CosvmVGybtif+2ZqZvBiJ8tEs1/q6PH87kvj3u3pUpfyPTqySdSPyVPFPs +Ki6as5BiaPmpq7MhRy5gadTJEKMzG7/kDSMBJG8azMxuufpN43JK95fMHXau3YlKxUOUblO2V9O 3JR9lh8FOG86cFyq6Lzkr3+UX+U64b9pvDGaNLAW/8aUV2n6XhnjT2Spwlc497KsVUsq07qgohKS zvBTx93ogKiHdComCBcl0nYsx7clwlkZBiyDW4v1in4vyDuCV7mVaP+ZOExQNp/FCVQZXTrZreeT RLE5Byk5bhL3q2kFRPg0v9eZTjuVOl1F4RqEKTpv3oqftWYQjfsNHkA6HL5MzsGuLyzq5aWb30Yk scmeqTXvneWHZ3INon42FWXgpA/ljXK/iWLGjgiJueMTxKyA3MMGEQ/iLaDIh04V1g4wMAHLqcD2 yf7Imeeef+PvfNK5gC3uwEytCO37/CCZyEMxA+B3es+w0+LCzDn2zPDi47Oh+y0uQX5lSw8rEnd7 RAgNWZGzml1x0ogiyOyJZbq1SCHkfEUv02tc8Srs10bdkB7n/k94kzWSnaxdvlVbXkPyhfd1dGrU 9CrPwBLhaC1rCbzmWYWuiKGiaJkkB7JMuiKqEWm2mkh849x7Y7/B2Mprg0JL1jm7bccHqpNzsha/ NZWhBh+G2ohvqKsIDqrMQoUus7Akn+A3fb5eqdmY23P9AsVLZR0DS5JHsoj4vYCPKhOXZdlBZ+hk 0h8aOpdl8dslmb0xkLZkHBklv+iAFRysaa9I9II0I3iFWs44JIV1oPwnNSchbd7QcBXiVLyoaWYd tsNxdJDSyPtOlXyo9yP5AnDhq3mBi/vUCChk4JfS3XhGG5G4zfCPATk+X+uJeqdzKkojJ2mKjoT8 rKjufhOEbDNNI//fQ2rys6LZy53TvvCyRn8uGvpP2jbMPUupnyAnOeWgJic+Da/VXIGyy5kwY9eG 8ga5X8O6xn5EsB9l4l1iYEDRJpD+5IR6aD8LoiZgxTufCpf46kuf++CHP2pSQCzOD3/8kxXWD6KD wHYkwN3upZ3+NbPtiAA6gwAIgEAmAvCfmbAhU4MIiGUVU0dZLf2ripwtDRHCbU8C8YtzEdaOHwiA QNUI7J0431M/pN55M6G+FIAfCIAACICABQH4TwtISNIMAvLjLKEPoTVDjqQ6qyJnkh74dxBoRQI4 OW/FVoFMIAACIAACIAACIAACIAACIAACbUYAJ+dt1qBQBwRAAARAAARAAARAAARAAARAoN0IIKy9 3VoU+oAACIAACIAACIAACIAACIAACFSOABbnlWsyCAwCIAACIAACIAACIAACIAACINBuBLA4b7cW hT4gAAIgAAIgAAIgAAIgAAIgAAKVI4DFeeWaDAKDAAiAAAiAAAiAAAiAAAiAAAi0GwEsztutRaEP CIAACIAACIAACGxPAvfOqo+MPjq5nA/A1sxTdl8q5TXmrSufpLly62ryv4/MbOUqDplBAATyEhCL 811nl0QxyxPKnXl/pK/ZvDaiPVQp0/2cEgKeS/gCVezhawlugMruShX2hp4KFs5FfqTR9ae07iY9 KZH8ErSPTqdQMx3T2NQlAKcVIZuGEo3Mbv+Q1JbK7g3JAbtqTisU1aCBDugYvK+RZsC+zYssMuXS ZKBH+5ZJgypK5GaUY9AojfeIih32JyZnmKaWND6qYSADztCtNfSw/WymHLyWxmCwJbOzCreRvf8k x6ZylG9yqdV29U2G10rVB0auDIve3afuv/Ly7Fhvg3TiffMEq0/0O9VprpJPcbUJYYPE8SYAmeqr jYx2Tx3MMtUPTznchuOt6UKQPVQ8l07pqaubUsRMAufu7JERjZovBZYG2ZqyKiNCVM5Ug5Slmv6i Mtqvw2OcDt8zSOJhmolZdUZDsTgfunlJrJD7J195mXs09ac+xPp21py+PXTefX5qb8ruzs39aXYm 5CWXJg9Ndasyrw8uHoqxeEN2okwm2nW654aSf2bEld0g7/LEwVs9Q57vNuseyU+JxN3ESXZBVX2e nXCWSZvXnlkblQ9vHGf1ZxqzGVkGcFIRsiKSNpnd/qF9mUwOySHg9saW0rQbkZw7neF6d93rmHL4 1zUaXz8Zs721d8LpywekcU7udgdCPpNwy3zxSEJXaYSe+eugm550PpT3iApg8icRZ1iaj8oPxbKE kDNUuSIPKcKWFWyfZCmMQYy84YHV7KzCzUGmpJwqPTa1ZYs0ZcBtS5KtoJQas/gUMX6MawFRt2ZO X+y5EJwb+13bGXZbQE5rEXafqjuLAussWsKYhnO8lrOL0dvHbt3JekSfs7OL5VxkFkTOlxjrHVfL ihvH106k3mqpyohgnM/bDVL2apoXDtExzltV8QWpWqXy2S/xUFif1cSsUqOhWJzP9w72ByfoW1cv ze8/VsSsnZt7ZPa/vDjfO/6E3GXcuruwwuZuG0OPqOyMfLj0wkU2diZpTe64EN7Aa2NnRndSridJ d6r2rbWV/QNy5cP3OAaGVheWhRl1HplRyyFW6+xhq2sPs3i6tHnKAE4qQrYCKS2Z3f6hfZnBlN1d wqhTGFta1OWnX56urx4IjfrCPt3uw/gm9/6VxbubKUTZurMYKTNF9kokVU1POwpLu7X3JyX5qIaB Jp1hnIcUkjmEGyZkVSqyNwZKI6OzijQHnZJyqvTYVBWeqeRsyoCbSkIkTk+g9pGB3pXX5BpOP5FW x25iCzUYMuYexlIVRSPOqDJluW5o56GplSSR712ZYsdHnemfMbE4Pb4mozW1E+OQUs4xlYiQv+rF loqHBjWJMuXZ43B9lc2fDIamUrqb1dz7BD9PupIhTlbTX2s49fTe2bH147NefAFjg6OPL7wQnfzL s82kcIl8nT3TLKh29NxY79y0c9rvHP4nyVmVEcFyXmSaUduraaooOuXo2OnRFuOdWqWSD8leZ79S S+rhTfp3sTiPnDPLiemT/iF5uJ/nk3Vrc03N7bgPOnhrcGw/W9/czFck914b672DHXcJ3xctWfqI c4ath7DutoLdXOQ+VI4Wl+YjeYTK3urdtsTC0hUIPKciZHb7hySRYHYnMInb1Q25k12g7oW1h3VB nmoq2keNWA83VvSl0Y6uvpWNB9ZFyu2w3p4d9hkqkzLc9LkEN/uT7M4wjY/KJXyazKQzNHjIQgmn EbJd04ZsyeSsos2R6NYCXjF2bGpLtjnHqbZkUlWlxA61E8XpBe/I43Sxaq0dPeaehfDBXuw7jx7t pDXlq9NDCwPXw6fx0TJDsWl9CeCWbt/sG9gTrtTt2o9qewdz9Y1jMrjywMrFaTVd5HNg7fzWOcvh z+dvsWflae2F/eLsyqymW+b1cXbxaX60WDv6oorndw8S1dkYP7J2ojh5VCxzou0CIXghNWt7Bvtc v5HRcrSGEyUsT3BNLwdbZ8eewfXb+bYA1Bwv5ew66yyos6M7IwzLbC04IliKZKmgKRk15eD7L/dH N4bF1Pf2gLtKJR+KUm0nZtUZDeWd8+AN7eDRsWDhhwrHhaCnax3HK82MdKTLZ069OjXNzqmY/G7p p+gf5SO8lEnH5oYy+ydlxItYPp1mg0OhVDxaIxL1VJTS9uUUADynImR2+4ekquHsKjDp/iujawe1 AKQCdLcHXUJKb8Qtoey2KZJu+uzqEf4ktzO09FHZhU6Zk3SGRg9ZNOGUwrZXcqMthZ2VecAyujXd K8aPTe3F1NEm5zjVlkyqp9ScmlDt4kGO193oS+++qH+gvXefGzvGV1wxJ9hiPeZFg8qIM3Ua779r yStTC0uxw9bTEbka5gfZ+lcs3SC4Wo+7EhYLe/0YzKtuaNQJAuV7B/Ko2aSmV6YfX0DIzPeFmcvz sTHn9ChezVpXN1t7kCXonGo4XvvJub6uyGSfNwRT4craT14y1Q7YYxuhiZ09lZzJltSCI4K1SMna JTRidONGvYlAbV1dYGPuKpV8aD0xq9Ro+MiZ555fm/m37LzbGZz9ReomquGfuvY/lrNpkB0EQAAE QAAEQAAEQAAEQAAEQKBdCWzc/P/wtym9NqpWnfLNSqtBXfk9/zPstAj3UOEkPGpvTKxSazz+JfLQ fRGjSBhepYrC3YqCVYiUXlHNIf3qS5/74Ic/aqpbnJyva+9+4/dn/P3FYCbxTzLu37kAIy6x8JdR bTZHLdQKAiAAAiAAAiAAAiAAAiAAAiBQPQL+ubd/I8OJN3FjN0Toh/eGcvKho7a3Sk3CwF8oaPOq iKRiyvx3sTjvPu+ek2/NTIfDbPyX1J9YH7+R+Bb0MmVF2SAAAiAAAiAAAiAAAiAAAiAAApUjoL+z 0PhGvdrIs/ythIfk3RbxeS+5SiUfah/81lap6hU5/ssRg58GF8fpoTcgtBpGEdZ++OOfzCOWF9a+ cfPlPOUgLwiAgDUB7nou7fQu41lnQ0IQAAEQAAEQaB8C/C46/4xus46OGhYfG1aTzwEW95XyqTZy duGGFutRxK1oQ1WRsxXZlSoTloohvMlh7aW2BwoHARAogcDeifM9zrZi6m9vliAOigQBEAABEACB RhPgH2Ga896g1ujKeX3iNG/txNm8bx1PkrxxavJXZ4c+pSy/FxP6EFqSvM3496rI2Qw2qLNiBERY O34gAALVIyBfFir/+J9gqZ4WkBgEQAAEQAAE0hOQXz5v/qKRf06Fv1A66ZPX6dVzczRUTfl5iFfk l2i9n/xeTKuHAYt9korImd0UkHPbEEBY+7ZpaigKAiAAAiAAAiAAAiAAAiAAAg0kgLD2EGyEtTfQ +lAVCIAACIAACIAACIAACIAACIAACKQnIE7Ov//Hc70QbugJ5zvn8y/ghXDpWwA5QAAEQAAEQAAE QAAEQAAEQKAdCWCpGGrVt7+a9J3zdjQD6AQCIAACIAACIAACIAACIAACIAAClSGAF8JVpqkgKAiA AAiAAAiAAAiAAAiAAAiAQLsSwOK8XVsWeoEACIAACIAACIBAuxP4nZmzBx69/IXi1Cy8wOJEQ0kg AAJtT0Aszj//OwE1v/qLh38i5Oa+MMGfiD//aOarqZFsfv4fibwBvykdnyzzcKj2SPH22amUpLRk 7fYPrcu8P6V0DKqZQvfUrGUGe2Jk+SRGA9s0hhGwKy+jwyd+WKVq90uYuO/pUTrbbC2SJ5ejuzIk pxP5arpPOA2/b4osMuXSZRevzO6Doi0zj5gNzUvYA61RbiMhnCFjoYcVh8lYuBcHTO4nprzv95bl GRpqO6VXZknJANnswcKmaD9gkb2gdA5NqcB6DtAU6VCpLQF95EqcItoWakjnDZc5y8mQPTBAuzNk /tAdqb0NAtmFz/7ipjfBS78NkbdrRIY5anYRmNdpE7MUbKriP6NypnLplmoa5vOSZ3hE0OF7ozbx MM34vo3GjhQ22pikYnF+47y25P7CxD/99Z7+br92YQHXen5u7v6/4X+eH/nudHLxDvw0Ozl7UCtQ rBk+MfX+U7LAzwx+4RMxfZjMvvn582s/JuX5uRFPeDKlYfFJZCfLJB/al8keHZc6huS01T0daDd1 GcBptukMI2RXH5pUZOSfej/re+/7TPpStfNB6ywbU9lPsbqzLrVvr2xsG5+Lu9HhGx11j9VTH+Iy 6N1n/MtnY+Yue59y8B6QrCYfFRoI11xnXpkv/k9G8o3X16ZG2hqJvpbfSCLOUMgXeUh1cxtFWiKN qRf3K//M/4yrD94aHAvh3uWkIfuQ0RJYsgqRghKvgoBsGh3CVkeOoZQDpHtBVv1aOp/9HKCl1YBw kkDfwc+E5k6xYN43cmruvhwfC/oVXiAtlxqa+Uw4OpQ7fdxRqruP/fqd9GdjqtacXYOcM5CzC8a6 x9Vi4edG1uraeYBdq1TFfxp52rl0ezXNDRcdEbwpMZ9R/9oleeq5dJl4KJrCanzfRmOHnXk2NpUM a19f+12nVt6WawdPjr7XF2Lp5gw7eDLtmtzLzztwZPb/hcXl7vH90o1+9ZWFTTb3n43BSFR21vk/ Pa+WGey7d/S4wpMpSZZkdvuH9mUGU3Z0iX2NFLpnM4QygJNsUxlG1K587b76i5eWf+SYeYlI1f47 a5s/MqBsgH1ooH994YvCE5GNmA1ja+T6wvSN9QNjzurIEUngcrsPe9/Ij/3Iyhde2Uwh7u/c+UKk zBTZm5/UoqervpbXSEijjbNkwUZVXZmffS8msef3DJUhZSeoPSWqPOPoELE6OiXlAOleYKdNxVJZ eIaKaQRx2XfvGuz0JqjRkDE3TjAQWSacvxebGQjK045/xZmQPHscvrHOls8GIhy9ZIZ4T69Mccr9 eRlqqp1sZ2q1933kQ90rX9GCWO9PjX15ZFbbbhj8sR9euBmdKsuzzaSD9HxdI9Oc4bt//NzB7rlf dk77nfisTHJaC984/5lTJPthwlRRdB7S8V6PtuAw+DfEoQv5kLRP+2l2JvNGpvQE5OLcXedId3Au sEz6nY0vdw9+zytFeB9XuK8+XFNTWO4B/+mvDx78Efblh2lWF5qSoihvkZZeeTK7/UOywmB2J/KH q/lzcolVoO726pZSaRrDIOzKl14uDw6q07k0v19bVNHsYrEayZfTMNLIUWJaTwsVv6TG4N/dWtFX gN9T69vcemAvhNgO6+75HvsMlUkZ7mtC8BxGQhqtwZKpqivBzdyLQ7PVFNqk8Qwpim3HpCHIJkcd tbpElx5wgLG9oB25Qqf2IXD/xpS7Ec9Pkp2QSR5tx5yQMb4hpWJ89PBMMqWYcGohY+KA57t//EWV 0T1IdE6SZDBUMN6Tr/Y/sfAheZgfPOWeu7F1TEbwHdicmfZv2KVtAbERr8UPfmGCi3rqxzv1Yr5n 1+CX73mXjNJWkD191jlD5/d0ZK/UJmcL+k9LkWy0i0lDzUNER/ixrWExUbw34MY4kw9FwbbjO8aO nE2VI7tYnDtHc5Q7ECWvT/0yO6fCj98/83TSFXFbWRxH+fxI9nUCj+uY6QmdK9pWz9OR2e0fkjWF s6vIn/v/5sjaPw3e+BWDRB7dU+jpJC0AeKhSS8Mw2ZUsLenY3KDnhyZl0JRYr36WDfaHUuU0jPRs y87hzSHKrqjK5Uf6Wh4jIY3WaMl0N68GTKIXe/NdeW8o7tqRQUVLz1ANQCVJaYQcdtRm/2l06boD jO8FJSmHYkEgL4GVG58Q43v9wbg62GB814/NqUH/Jw6MRXfk/QrplEv/+df6shwDqIkK39T24vtk wJp7yu2Gtr2vpzOLyq5GPGT1M16Q6Vz97FxnLbK05fUyFa6s/eQNwSLj+bNoYZGnYDlb0H9ai2RB Ky4JPSL4Vw/G2Jj7BiLyofX4jrEjZ0vlyy4W585N1Gtz7NfGpONz43zUVd7u8Y85G3h7f8B3Sdmr FbHovzb2y7VZeZtx83cfsPfvSO3WxFmiuE3hxLenlYbMbv+QrC5OJB56zdZ+93dkHH5u3dMqW1al Voax+XmTXYnhduaz2Y7NnT1vsfFxahf7Muv5HvfidE7DSMu21PSi4R5shK6Z8aNy/SE/SCdGcbNY 2k2QUmVvXuFuX+MSyE2NDEZCGu2nfyHGkpW6WtXN0z9lzbG9WMSUSseV7mflGdIV2capPciUo2ak /2TmcSTqAE29oI2RQrXqE5B3zj8z3rk+9VkVGs0vaLj3maVXN78txT5l8zG5d84D6vCHsx/69WH3 DXC+lI/u7rlx406Dpc46Z8g4t0+rXQv6z1iRUi92gkAMM2rt6sGj4/X+9SlxA4J8qBWXOL5j7Ehr jQWm9z6l5u+m+HE+/PVv/CYMk80snOPML/+aCLwRwz9ft4tbPfxlVNJvpvqJKWzfh3ZJG5W3an/A e42H1f0ZIYA4M7dcmUfKJLPbP5Rih+/5JIjkXQKJ0T0Vw1SJcwMnaqMMw0kWgGOwK5lURqxFbpvb 2YArEn8H0hQbGVX3z9MZRiqGTUksrtO7UxNXAHkHz+2SfA/112RX4tv2zsV7xyP7fSok+YdG+U2w uv8K7qYoVmal/oUrr5a0RkIa7af+vhM/6UQ8ikjI0AsyiarL1DR/2TG92Ouhzu0168qSyrQuaLsk FG5QQSYctcF/Glx6rAP0e0FoBOdviIwuA7YLfejZygTeN/KxkT4nXFyOhsSl66j8dEp+/3blxo1o WLiIvk68WSmGXeclW/5MOI5cumlMtCTe8Xmk6nD4kjYfvh8sBC6e56zIJnumOcP9KX7Il3pun8EY G+8/E4WMFSkxd3yCmBm1u40uIke8KxLkQ6cKX84EoQIzqJwKILslgUfOPPf88zP/lk80tcAY8Y7o rxxxn4jLNlObsjyVTMwA+CXqk+yz4hLOuf/1p/+Bqmz+hZcjtfLbmIEAJKciv0y+P+rvgMq5xYom DJX9fb48qjqZ3lCRs2DTytTU8bOTZdIViUxhOckydZH4jq83jzfobtlgSclKAG5iGzEMJVukET2R o3bF7Se8/21lAx+SrzFf921S/I1uhSRgrf7veoO6nYUPqGfnpOB+91Hcgg9DxsD341WkCVVmq3Pw 5CMtXHvo97VCjCRotI4U+kOy6srQ1HuN63h9buLVu47jSsLuu+JATwyOLNXBklFSe0okZB1dYGSU 4pjGZTcl7QCJXhAawdn54S/88GzogmtGAM3MZpwDNFMo1J2FAG/KS+915gaiWfmr0YR96hauz6ni eod8f7jjxLROx7zRMNrp9GTaHIMYdrlsiz+gRlUhG78S78ZyKlF/pO5+7YKkoGX3/z1UJj97mD21 Y1p8/0JpIcXw/WroP2na5q5hJSc5Z6BmFz4iHbuUKbucpPDN9J/BGZRnIfYi2Q8T8T4tMCJoM0Bn pcYlox7aj+/UDCpLd3byDD3xmPobtVTMUW5ls7791c998MMfNYkvFuff/+OfzKMdiOehh7wgkImA Pn3JVAAygQAIgAAIgEA7ECB3UZuomFhWscChVxOFiam6KnK2Jj1IlYIAloohWPGLcy+sPQViJAUB EGg2gb1PnepRr8z5idRfE2227KgfBEAABEAABIoiELogWVSxmcqRX1cJfQgtU0ElZ6qKnCVjQPEg 0IoEcHLeiq0CmUAABEAABEAABEAABIwEDHfrQAwEQKDVCODkPNQiODlvNROFPCAAAiAAAiAAAiAA AjkIvG/klPpabSU+J5ZDUWQFARDYVgQQ1r6tmhvKggAIgAAIgAAIgAAIgAAIgAAItCIBEdZ++OO5 XgjXtd95BV8r6geZQAAEQAAEQAAEQAAEQAAEQAAEmkpg42b0w15NFahJlb/6Utzb2nFy3qRmQbUg AAIgAAIgAAIgAAIgAAIgAAIg4BLA4hy2AAIgAAIgAAIgAAIgAAIgAAIgAAJNJlBAWHuTNUD1IAAC IAACIAACIAAC7Uvg3tlHT9wU6g2dvz/Rr+m5NfPUoanu0MPmcSDlNArfPDlRMwiAQBMJJIe139Ol W57Y9dij4s/IzJZ6zh2fevLY4WvOo1TqbF4bEdknl4PO1LZMKjsjHzIWFd4s6dbVw75UXkZHqqC0 4UKo2v0SJnyeedGl4uwlLgE4rYihFaJSk9ntH5IYqOx8/HOsV7fV5rRCtraL5nIgK72cTuRr5D7h 5ud1WNk7ZMqlSdeeZXbfMmlQRYlcejmE4dEa5eyVYX8SaItdZ5dcRcvyUaWDdCsIOEPDw4rbTMNY WhqDwZbMzircRvb+k+wFDePRwIpsTTTqPw3zHKpAkxNooJ6tWJX1rMN6OI7C333q/isvz471Fqu/ N1zGFkuPsHQWUs4ShA+M7+4Emz90B3qJWjyXHuCpq5tSXDt9g5rZ9iwzwkgJ1OQkMA/XJtIpGrwq 7jcqZ6oRwVJNp7nD6y/JMzyg6PC9uQ3xMM0saNsMPSks1DqpCGs/4U7rRWtN99x4mXvA+6/MjNRU T35mbVQ+uXGc1Z9xV+y2FfAe+DQ7E/KnS5Nym1PUcn1w8VBMJzRkJ8qUphYW3izl8sTBWz1Dnpfv nxTCOH/qQ6xvp1Se+lEicSd4kl1Q2c97PHOis0UcTFcGcFIRsiJSZjK7/UP7Mpkc/0K2am9s2YCX mov7weF6d90zTnlcoGs0vn4yZsts74Sgwe35gDTOyd3u2HyCeWW+eMRo6qWqlrlw2vCIps/XK03+ hB/aOM1xaq/UoTQflZlQ2owhZ6iyRx5SnSttTW2fPoUxcBaELZlGxnBzkG6Ncqp0L2jPhrAzUdJ/ 0sOEqcBIw7UnT2ut7GcdlsOxWACkGKRqI5dfDp6lW4te8YRqZOcT6ehMwEHthBj09rFbd7IcrklA dj3LxJJsTXJywljvuFqA3Di+dkI7TrBrpqq4X+Pk2W5EsFfTPEuPDijeEobPGG9ekgexS5PEQ9EU VrOg7TT02NlnulRicT60urAsW+KFi2zsjFqTe7/OIzNqTs9qnT1sde1huvJ5D4zM/pcX53vHn5BR SVt3F1bY3G39UD1QPpWdkQ9J4U2ycptbGzszupP6962rl+b3HzOvWKjat9ZW9g8oSqx/wOWZE106 0G7qMoCTipCtQMpMZrd/aF9mMGV3l7DkFMaWDXiZuZan66sHLjiLQKciYZ9u92G1kdH9K4t3N1MI sXVnMVJmiuzNT2pheKrpc/VKe39Sko9qGGjSGcZ5SCGZIoxfmIC9MVDsjM4q0hx0Ssqp0r1gG7Sc wURp/2kzTMDmjVZjPeuw4Sxcd4pByjuSNcRmelGQ4kj5moyX9I6R5eHhcH2VzZ/MGhxKRmHYd6+c 2b2Kah8Z6F15TVt83zs7tn58Vgv+Hxx9fOGF6Exbnm0G0CUKn7YjpGlNX6Gj58Z656ad037n8D9J zqq4X4s5jAJB9xd7NU0VRcf3jp0ebVHpYL8Y4MmHpH3YL4sSzQsJHAJicT6v/r61sd472HE34Lx0 Tluba8xbguYAKMqR3Zt71YO3Bsf2s/XNzRzlWQmvly/d1jnD8ltOyp9UZ2JpfjcXVTS7GPsj+YpC l0YgP22BwHMqQma3f0iqH8zuxEpxu7oh17QF6p4Nfp5cnmoqAEkNog83VvSl0Y6uvpWNB/a1iO2w 3p4d9hkqkzLc9ELwzL3S7AxzTOMSHGxTSJPO0OAhKcJNEbpdKg3ZkslZRZsj0a0FvGJsL2gXlkqP ZBMl/aeZJ11gdifQXrhjtCGRJtqtKjDVIEWFi/NDYyfekweOMT+4bK6+cUyGNx5YuTjNJ2y1oy+q OHn3JDA2jmx16qBzTUys5x17oyuya2ZxVX5h4Lrp6NuuEJVK7ONr8Z7LEzzu4PLRTr2IHXsG1297 V7HSFG7Xs0wlpmpNrZDOju60QqZL34Lu11KkdHpGUlPjO9/YvT+6MSzmmbcH3Lhp8qEoztYBbqOh J2ebENnlybn3fHVqmp2TQZv17otPB26Y8yiIiz2hQ7w84ojXY/DY2pmRjjyl6HljhNeTUW7L+/ek Y3ODrP2TMghHLJ9Os0Gfp+M3C0aXDVgBwHPaAJnd/iGpdji7ipW6/8ro2sHgFeuCjS1bG2TN5c0h shawHfJFmj5nryT8iRir/HsTcfdxDMAtfVTDmot0hkYPSXeuhgnbXhUZbSnsqM0DltGl614xvhe0 F1MmouoI/2+pJcUzWmBuJ2ApTVskI020gKlIPBy+tcrm1Hxs12Nj2mGJG4ZW6+nLgNeNuPbvvRsr sipdrFq9IE0ZBKcffVsV4anJQ0GvezsLcydOzvV1RWbWvAqmwpW1n7zRGXi7Hl1xrp5lp0tsKls5 LatqQfdrLZKliqZk9IDiXz24wMbcFxiRD60d4PYaenK2CpFdLM7XWU+HClLsHX/W2Wzbu0/zFOLg Ttw9cOLbc0ohwuNvjk13zb4izjY3H6yz7s7OnGXGCB8sefPa9ByvXXptN5xJe/Xd6WzH5s4WrJgW XN6j8VQvXSgOXTZKhQDPqQiZ3f4hqXicSPxyAVt7sCXvYpRhbNlaImUuIfz6Rmgw5Ufl+kN+EEQM w+aKMl1OSSl3c5O7Tc+lkJsaWXulwRkq5Wp7BvukgaX7xZaZrqgCUpPO8NMXYzykqlQjXIAU274I z5YoZ8XIAYuZ3VrUK5p6QTuDN5so6T+ThwmqwIxOoJ25+7qRSJM5K++a5QalhpVf5fAX0tz/l/Ze lYZVZLQZ9855QEf+cHbg1rD7Bjg/8+59PfUrd3IZYHrnn7U1i1saxCrcgu43VqTOXM3HXyJGju/a 1YPdp+pDq1PiBgT5UKs+0QFux6EnX/PoueV3zo+PivvS/NYKk03Cf1sz0zedIBk+2Iszc21lLoZ/ vqAVt2X4y6jE5krUC8RJKLp338AeaWTyVu0+76sYGS7AqJoMwssq9Es1/q6PH87kvPqO3bsy5W9k egqkE4m/kmfK4SlX5iF0xTVcmpJyA0+nSIQYmd3+YaQRpYXGs/WuzcTongZhc9KK9xdMnfauXSlL 58tC5TqlbZ+4KbsSPwpw3hzhuFS/T4VE7x/lV7lO+G8ab45mJdbq35jyKknfK2P8iSxV+ArnXpa1 KkllWhdUVELSGX7quBsdEPWQTsUE4aJE2o7l+LZEOCvDgGVwa7Fe0e8FeUfw1m8ls4nS/jNxmKAK zOIEWh9dURKSSBM5q9pzDlJy3CTuV9OqifDpjDcr01UUrl6YovPmrcCUW43sqa+CB4rnfoNHvw6H L2lzsOsLi3rKtBWFOoJN9kytee8sPzwrYmmQZM+Nd79JEmmzC8v+kliinyBmBeQeNoh4EO+KBPnQ Kc7aAQYmYCmE3d5Jg985l5+LXJFEnC9Jak8UKP78ic3D4k7vGXZaXJg5x54ZXnx8NnS/xaXKr2zp YUXRYvu0aBy14lrRPmJJZk8sM/AZzEiZXoOLV2G/NuqG9Dj3f8KbrHYiybdqy2tIvvAUOovwoZz2 mAgnPfCabxWeDUz0Gypyls1aI5IcyDLpikSd4Vag2Woi8Y1zd89FfAvQseqA7jlBNyq7ztmVn4+I J+ekAL5GClHwYaiN+Ia6Cn6hymyUPrnrSfIJftPn65VRZyg+QuPeNvRrSZLH4E7Dn+rNzSVfAUFn 6JSlPzR0rny1tl1ue2MgbUl+uNTorKIDlhqsXSdAe0WiFwhfYTuCV6iJrE2U8p8UebJAQ8NViFPx oqaZddgOx9FBSiPvO1Xyod6P5AvAxWSAF7i4T42AQgZ+Kd0NBbURidsM/xiQ9w0jb+qodzqnojRy kqboSMjPiuoyvNT00zTyk4TU5GdFs5c7p33hZY3+6BP6T7oqc89S6ifISU45qMmJT8NrNVegtHL6 FkIaZzPdb3ACJgSVzWEvkv0oY5ylSzyBAUWbQPqrGOqh/SyImoAV73wqXGL8d86Di/MKqwnRQWBb EeBu99JO/5rZttIdyoIACIBAHgLwn3noIW/ZBMSyiok1W9kV5Sy/KnLmVBPZQaB4AvGLcxnWjh8I gEDFCOydON9TP6TeeTOhvhSAHwiAAAiAgAUB+E8LSEjSDALy4yyhD6E1Q46kOqsiZ5Ie+HcQaEUC ODlvxVaBTCAAAiAAAiAAAiAAAiAAAiAAAm1GACfnbdagUAcEQAAEQAAEQAAEQAAEQAAEQKDdCCCs vd1aFPqAAAiAAAiAAAiAAAiAAAiAAAhUjgAW55VrMggMAiAAAiAAAiAAAiAAAiAAAiDQbgSwOG+3 FoU+IAACIAACIAACIAACIAACIAAClSOAxXnlmgwCgwAIgAAIgAAIgAAIgAAIgAAItBsBLM7brUWh DwiAAAiAAAiAAAhsTwL3zqqPjD46uZwPwNbMU3ZfKuU15q0rn6S5cutq8r+PzGzlKg6ZQQAE8hIg Fufy64VBR7M8oTzdriyddvPaSMRLCl+gvOfhawlugMrOyIeMpZEzoKaX0ZEq3s9StfslaB+dTqFm 3obU8pcAnFbE0ApRVcjs9g9JNlR2b0gO2FVzWqGoBnUgB6YavkauoXLz8/umyCInCkuTrj2HPodO gypK5GaUY9v0qXp62J8E2mLX2SVX0bJ8VMNAEj6fsdDD9rOZcvBaGoPBlszOKtxG9v6THJvKUb4V SiWNuRUEgwzWBAIjV4ZF7+5T9195eXas17rCfAm5yZ1g9Yl+pxTNVfIprjYhzFeLdW5vAmCdQ09Y Gxntnjroj26pCiEbjj90IUivJRpUOqWnrm7K0rMLnKezR0Y0ar4UmDBka8qqjAhROVMNUpZqOs1N bpyFW1OH7xkk8TDNxKw6o2Fkcb48cfBWz5Dm1ASv6Z4bL3Nnd/+VmZFaqq4qlgdPszMhL7k0eWiq +7ws8Prg4qEYizdkJ8qUU0l7OUNq9k8KYZw/9SHWt9OoJyUS9zgn2QWV/Tw74SyTNq89szYqH944 zurPNGYzsgzgpCJkRaRxkNntH9qXyeSQHAJub2zpLLshqbnTGa531z3jlMO/rtH4+smY7a29E4IG t+cD0jgnd7sDIZ9JuGW+eCRll26I4qkrsW16655u8idDynHxP6f2SilL81GpGWTNEPH5oqDIQ4pw 1hrbNl8KY+AMCFsyjYzh5iDdGuVU6bGpbRsgarftq2p7a6bGLD5FjB/jWgDC1szpiz0XnOHAkcfv 2s6w2wJyWouw+1R96OalpGMzU3ExDed4LWcXo7eP3bqT64ieHLms1BTLucgsiJwvMdY7rpY/N46v nUi91VKVEcE4n7cbpOzVNC8comOct6rik1jHIJcmiYeiya0mZpUaDUOLc6752tiZ0Z2+fS+9cJGN nUm7Jvfyc3OPzP6XF+d7x5+Qu4xbdxdW2NxtY+gRlZ2RD1PJGVXTV3jr6qX5/cfMKxaq9q21lf0D cuXDWP/A0OrCsnA5nUdm1HKI1Tp72OraQyuvkTNRGcBJRchWIIUns9s/tC8zmLK7S6w6UxhbTvIl ZF+erq8eCI36wj7d7sP4Jvf+lcW7mynq3rqzGCkzRfZKJLVr+tiebu9PSvJRDQNNOsM4DykkU4Tx CxOwNwaKndFZRZqDTkk5VXpsateWS7LbdtW7jfWqfWSgd+U1uYbTT6TVcbrYQg2GjLmHsRSRaMQZ VaYs1w3tPDS1ksT23pUpdnzUmf4ZE4vT42syKFU7MQ4p5RxTiQj5q15sqXhoUJMoU549DtdX2fzJ YGgqpbtZzb1P8POkK15oWBIC8t+1hlP/fu/s2PrxWS++gLHB0ccXXohO/uXZpkW4RI7OnmkWVDt6 bqx3bto57XcO/5PkrMqIYD2fp4ceezVNFUVbs2OnR1tUOtgv5hzkQ9L+7Fdqmcy7/EyBxbnsPOcC 69KtjfXewY67hE/JLNvW5pqa23EfdPDW4Nh+tr65mbk0J2MaOQk1/erlpPxJdSaW5ndzkftQOVpc mo/kEyp7q/c0pRaStkDgORUhs9s/JGkEszuBSdyubsid7AJ1L6QtUhXiqaaifdSI9XBjRV8a7ejq W9l4YF+s2A7r7dlhn6EyKdM2fWxPN/uT8KTHnk8aH2Vfas6UpDM0eMgw4ZxVI3vIlkzOKtociW4t 4BVjx6Z2aoXYkb2dFN1OuogdaieS0QvekcfpYtVaO3rMPQvhg73Ydx492knT4avTQwsD18On8dEy Q7FpfQmwl27f7BvYE67U7dr6VdC5+sYxGVx5YOXitJou8jmwdn7rnOXw5/O32LPytPbCfnF2ZVbT LfP6OLv4ND/rrh19UcXzuweJ6myMH1k7UZw8ko450XaBELyQmrU9g32u38hobVrDiRKWJ7iml4Ot s2PP4PrtjFsAeTp71llQZ0d3RhiW2VpwRLAUyVJBUzKqNfle8/3RjWEx9b094EZtkw9FqbYTs+qM htrinOo8QunVqWl2TkZy1rtl/y/k53ilmZGOQoqzl9OkphQj6djcIGv/pIx4Ecun02xwKJSKR2tE op6KUtq+nAKA51SEzG7/kFQ1nF0FJt1/ZXTtoBaAVIDu9qBLSOmNuCWU3TZFpmv65J5O+D0xMPj3 JuLu4xioluNLszch6QyNHpImnL32bZ3TaEthZ2UesIxuTfeK8WNTOzVB7MjeTopuD13m1IRqF4/l vO5GX3r3Rf0D7b373NgxvuKKOcEW6zEvIlJGnKnTeP9FRV6Z2tmgHeqejkgckR9k618FdYPgaj3u Slgs7MmjoKFRJ1iV7x3Io2aTml6ZfnwBITPfF2Yuz8fGnNOjeDVrXd1s7UGW2T7VcLz2k3N9XZHJ Pm8IFomfl1fPtAN2qhFaobPbyGlnQDJVC44I1iKlUNO+Nf2rBxfYmBsgQz60nphVajT0Fueb16bn 2M0xeUDnRsWoeKHe8Wed7S7hIByPlqMxRIz3zbHprll5aXPzwTrr7uzMUZ6b1UpOs5q8GHF3KNOx udjB5RuWYuJ+eQ9bZ76zFmee4o6EvydagKYpiygEeE5FyOz2D0mN40Tilwvk0FKI7il5F5ZcCL++ ERof+VG5/pAfpBNjnlmEBt6wKIxDuoJsmt6mp8f6E3GwkGHuYuWj0qmbIzXpDD990TQQeDW5hHNU jaw+Ac+WKGfFyHGZmcfQqFc0jU3t1QaxI3t7qbo9tHGvLvv3ImXgq3v07Z307n5yXF5d5pFQPcZj cyMyuswWJJxLTX63xb04Laeppb5oJtpwHCd/ODtwazh66WD3vp76lTspgeft7FlnQcWtVmIVbsER IVaknMs3Q2tqVw/ESxBWp8QNCPKhBjNxYlah0dBbnPt7D35UDN/z4/dGmIQi167TN0V8kXMBRlxi 4S+jEjsZcfd8olYo5nZuIJC8VbvPfcul2sVMusVB2TUlp5MuUKZBTZmU3x3y91a9StKJxF/J419A 4qDEmXlTV+ZCj9zA0ykSIUZmt38oVLAr07cM745KjO4pB4QmJBfvL5g67d1xkhII76P8lMRyQsXU 8c14500Hjv/y+1RI7v5Rfm/qRMZ3sTaBQeoqLZqe7ul6TTH+xPMVziUoawGTyrQuqKiEpDP81HE3 OiAwEOh1+hfAipJkW5cjrFHZEuGsDAOWwa3FOmp/bMo7grdic8WN7K0oL2RKS0Ac/zo/0WW87OLt 4gvLVxfnY28Oyjht95DWncoyskx/MBVdJvHOOcuwS+sIzy/Qrthe7Y5XMzCRFtHXgbuiciIRvt0d r6YgE4wISDcTjrYu76E89nY4PL3nE5L1hcXA+JK4Cojt7DZyZpoF3TvLjy2LWK0kWX7jR4QkieTi yDhIJeaOTxDTmm7shrBG7y3d5EPNM1hNzAIrtZwKlJRdLM5j18OdR87w6z0yvki8SDbtlpu6pui/ oEL2zL0T4iXtXsySf6osbsoFfmR28qFRzkiZBpLSX0dDjOxE8l7lP/za6H3nXo04neOO3YsmyrTp kLrZSwBOK0JWJMQNEyOz2z+UBKzK1L8cxt/b74STGY0tNdomZOCBxGI8c+NZpHuqjVw+f8C5YOOF /NVGnuVvcFF9StysU31KtREPY1NGqN43I8bIISdGxuZbhk1QO32V2kdQEpve0NODlZL+xP9ix4n1 cdfACvBR6fVtfA6ScOPFaPEa7Y2BtCV7Z0WlpB01NTa1OEWIBwJRAjIWXY1x013j+uVBcfp6cW5o n/eqIGXzwWmnGDd7tCFSTmXJMv3BlE/n+LdO4n9+wLmezr9zHvd+bz4Wz46tq3jV5I+uRdTkFeox 5P5EWhyzO9MG9TEX7i7cabz3ReRYNeUtAPclx0oxGY0/n/WKuCzCESN4mNd5ZLRnZbU4i7eSk5wF kfMlcbH3oGwgMeinPmmryohAymk/SNmraVw4hC0gMKd1157kQ/fT2k4bOTP/eI20lVpxpldsSY+c ee75wx//ZLGFojQQAIGSCXDXc2mndxmv5MpQPAiAAAiAAAi0IgF+WOrvyTZcQPGqOf66tfKvLobV 5HOAxX2l1EvOLvjDMXY+6TZ4w/FHKqyKnM0nBQmaS+DVlz73wQ9/1CRD5DvnzRUWtYMACFgR2Dvh nQOk/vamVQVIBAIgAAIgAAKtTYDfG5/z3qDWBFHFad5a+TfFGqcmf3V26HPC8nsxoQ+hNYF0YpVV kTNRESQAAZycwwZAAARAAARAAARAAASqREB8sOAm6zs+G/pGV+N14JLc3lfWqbJBzXJOzvn5PP9y lfwSLX4gAALlEYg/OcfivDzyKBkEQAAEQAAEQAAEQAAEQAAEQAAEHAIIa4cpgAAIgAAIgAAIgAAI gAAIgAAIgEBLExAn5z/yP+OFcC3dSBAOBEAABEAABEAABEAABEAABECg6gT+8It4IVzV2xDygwAI gAAIgAAIgAAIgAAIgAAItDUBvK29rZsXyoEACIAACIAACIAACIAACIAACFSBABbnVWglyAgCIAAC IAACIAACIJBE4D/+80d/7G+LP/WXk5LG//vDmRN/e+I/WpTBa8xbl0UtZSXR1eR//8TMV8qqCeWC AAhYERCL8x/zu+LmL32C8mgvTyhPp6W0Kl0mosoUvkB5z8O/9DC+KPvsBuGjxZO12z8k5aWyeyNE QM0UuttD1lPaEyPLJzEWYBhfuX7YHyw9i3LMIH5go2r3S9DGztLZZmuRPLkc3QNTDV9NlxunEezF cqKwVHfxyuw+KNoy84jZ0LyEPdAa5TaSgNG6OoYeVhwmY2H3HjC5H/vnS67eZXmGhtoOKmtjAm3o /9u4tWJUC4xcGRa9P/RT93/5V2ef+kCD6PER4Syrjz3mVKeNCIFht0HSyCl3BmiOeDtGDndNfcJ3 +6mkJhuOP3TnHrKHCtnkoHPi+qa3RkgtMDp7qpZB4qoREIvzX/7MyHuF3LwLPc1+JuzRxEz0Ss9n fpU7u/tuSnstyTKX6iNTHZOywJnB5ZGYjUky++Yv/ezaYSnPZz7GLv+s2uSjhacEJbPbPzQsaAmR mBwhInLa6m4PWU9ZBvAiDOPliU/c7nncGywfm1Rk5J/646xvx/tN+lK1c788wU6p7JPsrLMuJRsx G8YWycVH2eHLXXWPlRz+9e4z/mAiZntr75iD94BkNflDQi0xcvOZhFvmi39vR4soaykGbY1EX8tv JCGjVQJGHlLd3FKX5iczuffHlX/mf35KffDW4FiKHzKazwQSVJNA+/n/arZDMVKrMYtPEePHuGIq y1XKw5kLn+055fhJpyTffzrDbq4aGpz5h36q/vivXEo6NjMJFdNwztTF2cX4QB+7fSfrET06e4ON AtU1moAe1s6n8tGZ+tIvfJY99TNq9Z7hR5X58uKtD4z/fbnL+JWXFr7E5l42hh6RInX+vc+oZQZ7 b62HfWntd8RfyZSkwGR2+4f2ZQZTdnUJhil0z0DbwCFFpSTG/IaxVJ9Ye+pnRsll4FeuX7r1o8fM S0Sq9i+vfelHB5QNsMcGHv/Swv8h4i/IRsyGsTVyvTx9+UsHQqO+wOV2H8Y3uX90ZfmlzRTiPryz HCkzRfbmJ7Xo6aqv5TUS0mjjLFmwUVVX5mfv3kvyDJUhBUFbnkDb+f+WJ94IAXd8pP8DKw+/LKrS T6TVQavYWwyGjLmHsZRo0YgzqkyR00s5MvWlJCX/47Up9rFRZzZiTCxOj39JBg9qJ8YhpZxjKhEh f92LLRUPDWoSZcqoruHLX2K3JoKhqZTuZjX3/n1+7nXNi5lKQkD+u9Zw6t//4z8fe/CxWS++gLHB w/sWfiE6+ZeH6kkH6ejsmRoFmapDQCzOY93ZxoMPDL7/JcKnZNbxK1tragrLfdAnbg8+9aPswdZm ttJEUd4iLX0RZHb7h2SFwexOkA9X8zNyY7VA3e3VLaXShykMQzrlc4blt1weHFGnc2l+v7KoboKJ xWokX07DSCNHiWk9LVQctRqxfmdzRV8Bvq+z70ubD+yFENthH+h5n32GyqQM9zUheA4jIY3WYMlU 1ZXgZu7F4bmdvTppPIN9qUgJAvYE2sP/2+vbzinFDrUTWOfFKMnjdLFqfe+hY+7WPF9Ri33nw4c6 aRp8dTqy0D8TPo2PlhmKTUsKjV96+Vf6+j8crtT1n/pV0LnLm8dkrN+BL312Ws1e+BxYi2Jzzpz4 81u32QkZOHDqR8XZlVlNt8yZcfbZp/lZ93sPvaji+d2je3Xexo+snWhTHqjInGi7QAheSM33fnjw A+7omdG6tIYTJbw8wTW9EGyd93148MHdfFsAalKdYxWQUTtkA4GSCYjFeYfs1cbfl6ZeZOdU+HFC yjSyOl7pMyPGcObE0nh8aSSaKDGTn4DMbv+QrCmcXcUV3//lJ9c+EbzxKzxyHt1T6OkkLQB4qFJL w6CcsldS0rG5Qc/HJj/zsbWzcr16gQ0+HkqV0zDSsy07hzfill1RlcuP9LU8RkIardGS6W5eDZhE L+aHEtp9nLhrRwYVLT1DNQBByqoRaDv/X7UGKETeOTW+/xiPuZtxIzq9t2P4B9p7H3Njx/i+c8wJ ttiV9gL0ZMSZOo3337jhlalFGtpp0vP+SEygH9buXBrlJblBcO/vcVfCYmFPnkw8/qQTrMr3DuRR s0lNt8zIMXVAcr5hylyef3vMOcyIV3NHVwdb+3LCC6FIPFTD8don5j7Q2RHOwBuCReLn5Z1H7YA9 thHQ2e1sFKkqR0Aszrl3c/wUKf4Hxk84213CQcSltNNexKL/ytiLnbPyNuPmlzdYR63TLqufSpwl ilvH/l5jqhLI7PYPybriROKh19LTFaJ7Kk154rIqtTKMzV+6MsebWx78utFWXhyauKyV6dhcbJnz HWKxhLjwYfaA+aNjTsNIy7bU9KLhNjZCl7L4Ubn+kB+kE2OeWSztJkipsjevcLevCcvPaCSk0X76 SowlK3W1qpunf8qaY3uxOD/JMEWz8gwp5URyELAg0E7+30LdNk7iXl3271rKK0Xu0bd30vtDR8bl 1WUegtdjPDY3cqLLbEGsudTkN7w+MO68N0rMmkp90Uy04ThO/nC2//ZwNEr3h/b0XL52JxtwdPZs 3JCrEgTE4vzFXzG/jotvyLEp51rIwxmV0rkAIy6x8JdRifdLxQXGRzGIKawbCCRv1T7mvuVS7WIm 3TYRAogzc8uVeaRMMrv9Q6GQXZm+6mKTcvBv8e3VGN3Ls5fcwAnRKMNwkgXg+KdwfrSVu5fML2v5 m9leHXY24Cbn7wXxb3ylM4zygBdVsrhOP3XBeaOpU6hYL33J7ZL8LFfF1PHNeOfivRPd5/epkDCP jT71gbmzGd/FWpRiZZbj9TW/krRGQhrtp550z5OjluxavtvNy9SvyLJjerGsRvRQ5bjsf0ll2peE lCCQikC7+f9Uyrd9YnH86/yEX/L0FW8XX/g/ri/eio1tlnHa7iGtO5VlZJn+YCoGjsQ75yzD9qUj fMeOD6zYXu2OVzMwke58f1fwrqicSIRvd8erKcgEIwLSTcyi5shHVR57Oxye3vMJycbCsp7criJ0 9rbv8dtcwUfOPPf8b/V80nkLtBfxIqnwyBzxXNzVcTyUeiJ6Bb9E/TPsgrjDc4797PDyvtnQZRIX K7+N6UbR0GX2+TFL8r0Xn/jsilOvSE9lf78vj6pFpjdUFC1TU8fPTpZJVyQyheUky9RF4tuWXnST nzige0GGWAJwE9uIYSgVIo3oaSbePf7wSTdgybkDFt7EtbKBx+RrzOWw6VsL3QoFcW1aMXqDugbD R6+JOSmRb0KKW/BhyBj47rWKNKHKbJqCaSsmLVx76Pe1QowkaLSOsPpDsuq0SjUvPdGLfW7Mh5mE nXbvWvdsnoqoeVsQaE//vy2aLqIk9zaLj0VOX8TVvF8RaT/wsfGOz675CeSAqM0bNQ+m+yVq3CTL 9AbTxyf5DW1CEl1gXgKPA9UnwF6ZMpkadjWNhKHyG+Dex1OcmYybUlxEf3kPFdcdVtM8jkcnmXrv cL16jJrin/gNef0V9KqEH60HHoZbjmy4kO78NGX2Qm1afARKzYpDeoXVpLoAOvv2dAztpfUffvFz H/zwR006icX5j/zPn2wvlaENCLQ9AT7gXdrhXcZre3WhIAiAAAiAAAhECfDlnLfSazyfwGK7zOrD atJbGEVIQM4uxF4AUyd2+IEACOQmEL841z+llrsqFAACINAgAnvHJnsuj6jPpTifYGlQzagGBEAA BEAABFqCAL83Pue9Qa0JEu0YOcFfT1v6TbHGqck/ShL6uq38XkzoQ2hNII0qQWD7EMDJ+fZpa2gK AiAAAiAAAiAAAu1AQAWQf4CHSZu+oNYoLY2x6EUIYFCznJNzfj5/dyA2dr0IlVAGCGx7Aghr3/Ym AAAgAAIgAAIgAAIgAAIgAAIgAALNJoCw9ma3AOoHARAAARAAARAAARAAARAAARAAgVgCIqz98Mfx QjiYCQiAAAiAAAiAAAiAAAiAAAiAAAiUSODVl+Le1o4XwpWIHkWDAAiAAAiAAAiAAAiAAAiAAAiA gA0BLM5tKCENCIAACIAACIAACIAACIAACIAACJRIAIvzEuGiaBAAARAAARAAARAAgYYRuHf20V2P iT+Ty/nq3Jp56rGJexZl8Brz1mVRS1lJdDX530dmtsqqCeWCAAhYERCL811uV/Q82q7HDl/zeufy hHJz4s/ZJatSA4k2r41EvKTwBapMrSK6aCo7Ix8y5olq4Vy2rh72fbeuY7JPp2r3S9BceQo103M1 5igBOK2IoRWigpHZ7R+SmlLZaQNuTisU1aAO5MBUw9fInRBw8/NtXmSRE4WlSa/nir/4lkmDKkrk FinH1Knt7SHsTwJtoTnDsnxUw0AGnKFba+jhtrCZAohbGoPBlszGGW4je/9Jjk0FaNpqRZi6Z6vJ CXkSCQRGrgyL3t2n7r/y8uxYb2JFxSTgffMEq0/0O6VprjIw7BZTWXIp3gQgOSmRojYy2j11MMtU PzzlcBuOt6Y795BeSzyXTumpq5tSgAwCF9DZIyMaNV8KzCKstmkiSKsyIkTlTDVIWarpNDe5cRYe 48i1J/EwzcSsOqOhWJy/MjNSkwYlPZr4c+M4qz+jNs+WJk+yC/LhKy/Xh25e8hftVh2fm/vT7EzI Sy5NHprqPi/LvD64eCjG4g3ZiTKZaNfpnhtKVFcjo4zLEwdv9Qx5vrt/UinuqMn6dioixI8SiXsc j9J5dsJZJm1ee2ZtNMzTilqORGUAJxUhKyIFJ7PbP7Qv02DAtsaWg3pZWbnTGa531z3jlMO/3n3G 10/GbG/tnVDdlh2QXXhytzsQ8pmEW+aLR4ymXpZWDSqX7tS2vdLkT4aU4+J/Tu2VipTmoxqEScyT As5Q1Rt5SI0ODROxKhWlMAauEmFLJmcVbg5yDKVsmx6bqsIztZwRpKlLQIbWIKDGLD5FjB/jWkDY rZnTF3suOMOBI49vh86w2wJyWouw+1SGqb5XekzDOV7L2cXo7WO37uQ5os/R2cVyLjILIudLjPWO q2XFjeNrJ+zCKDTSVRkRjPN5u0HKXk3zwiE6xhFrT+OC1GpiVqnR0BzW3t0lJ+0dO3vnptX+1vLi fO9gf7qpPDf3yOxflDP+hNxl3Lq7sMLmbhtDj6jsjHy49MJFNnbG2WVI8kK8gdfGzozupNJtXb00 v/+YecVC1b61trJ/QK58GOsfGFpdWBYup/PIjFoOsVpnD1tde5gkVhH/XgZwUhGyFUgNyOz2D+3L DKZUBpzC2IrAX2wZy9P11QOhUV/Yp9t9GN/k3r+yeFd2T8vf1p3FSJmWWaubTOvUlr3S3p+U5KMa Bpt0hnEeUkjmjA4NE7IqFdkbA6WR0VlFmoNOSdk2PTZVhSfk3PYEah8Z6F15Ta7h9BNpdSortlCD IWPuYSzFLRpxRpUpy3VDOw9NrSS1wL0rU+z4qDP9MyYWp8fXZLSmdmIcUso5phIR8le92FLx0KAm UaY8exyur7L5k8HQVEp3s5p7n+Dnc1cyxMlq+msNp57eOzu2fnzWiy9gbHD08YUXopN/ebaZIVwi qaG0f880C6odPTfmrYZ4YVZyVmVEsJ7P00OPvZqmiqJTDnLtab8gtV+ppTCcRiYVi3PNnTlxHQdv Dd5wNgL5eH9/dGNY+JTbA8kn0hayb22uqbkd90G8orH9bH1z0yJfbJKtjfXewY67hO+LZpM+4pxh +S0n5U+qM7E0v5uL6mKSWAZE8gmVvdV7mlILSVsg8JyKkNntH5I0gtnDBlyg7oW0RapCPNVUtI8a sR5urOhLox1dfSsbD+yLFdthvT077DO0Q0q6U8cZs9mfhCc99nzS+Cj7UnOmJJ2hwUNGR4eclW/3 7CFbMjmraHMkurWAbceOTW3WBtm7Z5uBaBt1xA61E8noBe/I43Sxaq0dPeaehfC5l9h3Hj3aSavO V6eHFgauh0/jo2WGYtP6Ekgu3b7ZN7AnXKlrh49qewdz9Y1jIhbg/IGVi9NqusjnwNr5rXOWw5/P 32LPytPaC/vF2ZVZTbfM6+Ps4tM8rLV29EUVz+8eJKqzMX5k7URx8kg65kTbBULwQmrW9gz2uX4j oylpDSdKWJ7gml4Ots6OPYPrt7NvAWTu7FlnQZ0d3RlhWGZrwRHBUiRLBU3JqCkHufY0LkhtjaE6 o6FYnHfLXi1/Kq7j/iujawed+A0//OMCG9McTc62cL3SzEhH3pLc/KtT0+ycikvXNIqUTvkIL1HS sblB1v5JGfEilk+n2eBQKBWP1ohEPRWltH05zjCQB3hORcjs9g9JVcPZowasDYF5dLcHXUJKb8Qt oez2L5Lu1InGTPgTMTD4F3/i7uMYqFr6qIa1CekMjR6S7lwNE7a9KjLaUthRmwcso0vXbTt+bGor prm7Z1vRqLoyc2pCtYsHOV53oy+9+6L+gfbefW7sGF9xxZxgi/WYFxEpI87Uabz/oiKvTO1s0A5i T0ckntQPsvWvWLpBcLUedyUsFvbkUdDQqH/VVB41m9T0yvTjCwiZ+b4wc3k+NuacHsWrWevqZmsP sgSdUw3Haz8519cVmezzhmCRq7LyPpp2wE42Qgt0dis57SxIpGrBEcFaJHstDdP46MaNehOB2rrS 1p7kQ2tjqNRoKBbn3Ls5fsoDx2OzVc/Uwj/ERZTVKSIKJWXDiBjvm2PTXbPy0ubmg3XW3dmZsgwq ee/4s862nHBkYY2cHJvXpud47fIc0g3+8cKixN2hTMfmYgeXb1iKifvlPWyd+c5anHmKixP+nmgB mqYsohDgORUhs9s/JDWOE8k14EJ0T8m7sORC+PWN0PjIj8r1h/wgnRjzzCI08IZFYRxyFUR1aitj jvUn4mAhw9zFykflUjdNZtIZfvpijIdUpXujQ5rKkNZEwLMlylkxcsBi5jE0atumsamNWyRj92xj ItVTzb267N+LlIGv7tG3d9K7+8lxeXWZh0f1GI/NjerTZbYgrVxq8rst7sVpOU0t9UUz0YbjOPnD 2YFbw9FLB7v39dSv3MkDPENnzzoLKm61EqtwC44IsSLlXL4ZFmXk2jNpQZpoDBUaDcXifPpm5P1n gevl7v6Z2H4TKZ0LMOISC38ZldjJiLvnE7VCMbdzA4Hkrdp97lsu7W5xUHbN77cwd+NgayagUeBm iL/F4gf/uFub/O6Qv7fqVWJ1scRLzV/J419A4qDEmXlTV+buZDoX8HSKRIiR2e0fChXsyvQtwzPg GGPLMyA0Jq94f8HUaeeNpk6Vwvt4e2T8VE3F1PHNeOdNB86Gmt+nQqL2j/J7Uycyvou1MWoXWUu0 U1sZc4w/kdKJYtO+gCOpzCLVtiqLdIafOu5GB0Q9pFNqlpePWAm0PRP5tkQ4K8OAZXBrsbbtj015 R/CWb6cs3bPlldruAor5p/MT7evhEG8XX1i+ujgfe3NQxmm7h7TeFJEs0x9MRZdJvHPOMuzSOsLz C7Qrtle749UMTKRF9HXgrqicSITP1eLVFGSCEQHpZsJRa+WujMe0Docvk/MJyfrCop48ZUXhzm6T PdMs6N5Zfp5XxGolqSc3fkRIkkib8BQ/o45ZlIXXnlJO8qHmGawmZoGVWqL6TUnwyJnnnl/7Hz7p vAXai3jh22zuklWO946D4rE6PKV4wi+ln2GnxR2ec+yZ4cXHZ0OXSVxl+DVFN4pGPlIliBdROEFE fX7MknzvBa/LSSOSk9kTy3RrkTVGyvQ4i1dhvzbqxs84V5LCe4p2Ism3aq9qCoqKPR2dGjW9ymvr RDjpgddIRQwVRYGTHMgy6YqoRqTZaiJpBmwytvLaoNCSdc5u2/Hh5+ScrMVvTa2feg9DbcR3r1UE B1VmoUK3SmHRTm3fK7WUbs/1u7l4g6vjIQvwUS2AK+gMHYH0h4bO1QKit5II9sZA2pJxZJQ6Rgcs tXJw+ztt28TYlGYEbyW6CbIYkFZIA4jqEOD9aHFf5FRD3OO4KS3++Hj3xTU/gRwQtfmVZgmyQOef qHGTLNMbTIfO8xvahCR6Q/ESeByoPgH2ypTJ1LCraST6Kb8B7n08xZk6uinFlc/b+6i47rCa5nE8 OsHWnYM7eMWoKf6J35DXX0GvSthfDzwMWyzZcCHd+fHV7OXOafFxJTWGhvQKq0n2CnNnt5KTnAVR 8yXfZuRr2/XvQFnJWY0RwbDUsh+k7NU0LhyiY1x07cnTUA/tJ2bUSq15XvfVlz73wQ9/1FS/WJwf /vgnmyceagYBEMhAgPu4Szu9y3gZCkAWEAABEAABEKg6Ab5M8lZ6jdclsNgus/qwmvQWRhESkLML saxi6nStpX9VkbOlIUK4BhCIX5ybP6XWANFQBQiAQEYCeyfO99QPqc+lOJ9gyVgSsoEACIAACIBA JQnwe+Nz3hvUmqBBbeRZ/j7g0m+KNU5N/urs0OeE5fdiQh9CawLpxCqrImeiIkgAAjg5hw2AAAiA AAiAAAiAAAhUiYAKIO/jYdKmL6g1ShtjLHoRAhjULOfknJ/P868m6wHtRaiAMkAABEIEENYOkwAB EAABEAABEAABEAABEAABEACBJhNAWHuTGwDVgwAIgAAIgAAIgAAIgAAIgAAIgEA8Adw5h4WAAAiA AAiAAAiAAAiAAAiAAAiAQJMJYHHe5AZA9SAAAiAAAiAAAiAAAiAAAiAAAiCAxTlsAARAAARAAARA AARAAARAAARAAASaTACL8yY3AKoHARAAARAAARAAARAohAB/vbn8yOijk8v5yuPfMLf7UimvMW9d +STNlVtXk/99ZGYrV3HIDAIgkJeAWJxf8zqi6KLKqR1OeJii3s1rIxEvSVZEl2mfnUpJlmmvpr2c VEpvhCiUZyJ6e2JkUSRGA1v+1Q1lMBbeXH6C0h3AvIyOvcUPbFTtfgnaV77t2yuRYqskcHQPTDV8 NTWefhOILHKiwD+14sxRQp9Dpy2zVVQuSA6TjaUxkoDRunKFHlYeZrgXB0xul//93rI8Q0HtjWK2 O4HK98Tt3oCe/oGRK8Oid/ep+6+8PDvW2yCgfEQ4weoT/U51mh3y8VebnzRIHG8CkKm+2sho99TB jJ9tJxuOP3QhyMFXNKgcdJ66uilFzCIwOnum1kWmyhAQi/P6M2qfbGny0FT3ee7U7r9yfXDxkOpO 5EN79Xi3fJqdCXlJ+zLJ7JvXnlkb5UK+fP/GcU14oiLD4pPITpZJPrQvk8kRIiInAdmeZ2LKMoCT ZTKxRJnuuSEVfGVmpBYv2vLEwVs9Q95g2T+pyMg/9SHWt9OYn6qdu/iT7ILKfp6dcNal9u2ViLFF EvBBa7jeXfdYyeFf7z7j6ye1fbSw1HsnHLwHJKvJ3e5AyGcSbpkvHklouRZBkV4M2sbSGEnIaJUI kYdUN08vbZNymHrxkBoI+B/ng7cGx0J53XSeoUmKo9r2I1Dpnth+zZFPIzVm8blo/BiXr5JCcm/N nL7YcyH4YXDffzrDbiE1NaiQ3afqQzcv+edz6aqNaThn6uLsYvT2sVt3Mh/Ro7OnaxakrhoBGdbe 3SXm58uL873jT8jNv627Cyts7rbY36IeplCSLw8is/8UZVLZWeeRGbXMYLXOHra69lD8lUxJCkpm t39oX2YwZQzkFDwTk5YBnGS79MJFNnYmaU3uyLs0eXJt7MzoTkr8rauX5vcfMy8Rqdq31lb2Dygb YP0DQ6sLy8LHk42YSKyFEyxP11cPhEZ9gcvtp4xvcu9fWby7mUKHrTuLkTJTZK9mUs3G7I2ENNo4 S/Z9aWUo2fdi0gnk9wyVIQVBK0ZADbj4VZ1A7SMDvSuvyTWcfiKtjtPFPmAwZMw9jCWnGl5kqB+p Fy1TluumPDS1kgTw3pUpdnzUmY0YE4vT42syeFA7MQ4p5Rwviwj5q56o4qFBTaJMGdU1XF9l8yeD MbDRaLs4Nfc+wc+9riwlqR7771rDqXT3zo6tH5/14gsYGxx9fOGF6L0DeaieLlwCnT1XUyFzKxIQ i/Mbcs9va3NNrdK5azh4a3BsP1vf3CQf5tSjwDJFUd4iLb1YZHb7h2SFwexOkA/nGQM5veDpchQI 3K94a2O9d7DjLjHYRIWTTvmcYfktlwdPCgtM97u5KCM7+Lh1aT6SM6dhpJOktNSeFiqOWo1YDzdW nN00We+Orr6VjQf2Ioh9t96eHfYZ2iElbWPxRkIarcGSw928MszMvTg8t7NXKY1nsC8VKUHAgkBl e6KFbts0idihdgLrvMNSeZwuVq21o8fcrXk+FRD7zqNHO2lQfHV6aGHgevg0PlpmKDatL4H70u2b fQN7wpW6/lO/8TdX3zgmY/0OrFycVrMXPtnWoticMyf+fP4We1YGDlzYLw7JzGq6ZV4fZxef5mfd taMvqnh+9+henY3xI2sn2pQHKjIn2i4QghdSs7ZnsM+dYmU0PK3hRAnLE1zTy8HW2bFncP125i0A dPaMLYNslSAgFucHtVsxjrOYGenQxCcf5lSvgDJ5fGkkmiiFVGR2+4dkTeHsKq74/iuja4mQU0ie KWkBwEP1rk5Ns3MqLr1bDgz0j3LKXsqkY3NDmf2TN46vnZDr1dNscCiUKqdhZMJbaiZvxC21lnYt nLaxeCMhjdZoyXQ3rwZPohfz4ALtPo5zvymNNpaeIU2RSAsCFgSq3BMt1NtOSebU+L6Lx9xdd6Mv vbdj+Afae/e5sWN83znmBFvsSnsBejLiTJ3Gq8vP4o9XphbaaQe8pyMSpOGHtfs3/twguFqPuxIW C3vyZGJo1IlJ5HsH8qjZpKZXph9fQMjMN0yZy/OxMecwI17NWlc3W3uQJeicajhe+8m5vi59VSHF 5A3BIvHz8j6adsBuagR0djvzRKpqEhCL8yHZCUWI+M2x6a5Zeclw88E66+7sJB/m1LSQMsVZorh1 7O81ppKKzG7/kKwrTiQeem2GnEryDIkLAU7U2zv+rLMPKkYOZ6gLp9u8Nj3H7UqOf260lReHJi5r ZTo2F1vmfIdYLCEu72HrzB8dcxpGBrzlZRENt74RGh/5Ubn+kB+kE2OeWSbtJkh5grdSyZSNJRkJ abSfvhhjyUpjt5u3kv5JssT2YnF+kmGKZuUZkgTDv4NAZgJV7ImZlW3PjO7VZf9epLxS5B59eye9 u58cl1eXeXhUj/HY3IiILrMFieZSk18D7B13Xg8kZk2lvmgm2nAcJ384O3BrOHrpYPe+nvqVO7mA o7PnwofMLUpALM7newf7+c6fMHE3Pkdedt3Hd+yoh84FGHGJhb+MSrxoMe6eT1RxsiKVzO62CRdA nJlbrswjZZLZ7R+SciaIJDYpzZDLto3cwAkB+YUiNuXcF9qamb6pvdEtANw/hfOjrdy9ZH5Zy9/M 9uqwswE3OX+/l3/jK51hlI09f/niOv3UaeeNpk5xYr206pLnZ7kqpo5vxjsX753oPtF5yV//6Fjv 3ImM72LNr1KjS4jamIWRkEb7qePueXLUkh2tvG7eaC2z1hfTi2WRgp5yXPa/pDLtS0JKEMhIoHI9 MaOe2ymbOP51fsIveaqLt4svLF9dnI+94SjjtN1DWm/GQpbpD6ZidpF455xl2L50hO/Y2btie7U7 Xk1vxi5K7uzoFpdSfeOQE4nw7e54NQWZYERAuolZ1DL5qMpDLIfDl8n5hGR9YVFPnrYidPbt5Aa2 j67yzrmzWNo7IV7S7oUSqUNp8qE9H3UtxH9BheyZxjLFLdDAj8oujsK4w/SidPSvRoUqEmWFyySz 2z+U4lmVqX/Iir/VPA6yPc/ElCUAdxQJse08cobf+3LiwbrP+3uxkUY0yCwHyGhMl5UNyG9vqNP4 10bvOxeZaMNIJNbKCXjglhjP3LgDuQNSG7l8/oBzpc0L+auNPMvf4KI6r7hZpzqvMgYexqY6i3rf jBgjh5xYhuBHE1uZRDbZojZWvJFoH4/xu3k2cRufi+zF/qfUTqyPu46LdCzkQ6NnaLx6qHE7Eah0 T9xODZVNVxmLrsa46a5x/S6bOH29ODe0z3tzjfJgwRmLGDd7tCFSzljIMv3BlM8u+Kdk4n9+wLme zr9zHvcpNT4Wz46tq7jC5I+uRdTkFeox5H4YqThmd6YN6mMufMrtzta8D9/GqilvAbjv3FWKyWj8 +exXxH0xgod5nUdGe1ZW09oEOntaYkhfMQKPnHnu+cMf/2TFpIa4ILDdCfDB6dJO7zLedqcB/UEA BEAABLYlAX7W2sSNUfGqOf66tYxXLFM0WFhNPgdY3FdKveTsgj8cY+dtboOn0AlJQWDbEnj1pc99 8MMfNakvP6WGHwiAQMUI7J3wzgHi9uYrphXEBQEQAAEQAAFrAvze+Jz3BjXrXMUlFEfQa+XfFGuc mvyjJKGv28rvxYQ+hFYcQJQEAiAQIYDFOYwCBKpJQL7UVP4pf8++moQgNQiAAAiAQLsSkF8pb/6i kb+e9gIbS/dp7jRN0lA15UdJ5Guh/Z96/27oQ2hpNEBaEACBdAQQ1p6OF1KDAAiAAAiAAAiAAAiA AAiAAAiAQAYCCGvPAA1ZQAAEQAAEQAAEQAAEQAAEQAAEQKBxBBDW3jjWqAkEQAAEQAAEQAAEQAAE QAAEQAAESAJYnMMwQAAEQAAEQAAEQAAEQAAEQAAEQKDJBLA4b3IDoHoQAAEQAAEQAAEQAAEQAAEQ AAEQwOIcNgACIAACIAACIAACINAOBOTrzcWfvG9Q598wt/tSKa8xb11NBK+ryf8+MrPVRGFQNQiA AGNicX5N74jLE8qp7fL6p/fEzklFqG5eG4l4SeELlPc8HKidaBL77FRKso3J2u0fWpfpjRABNVPo ns1C7YmR5ZMYDWyj1mIWWX4q0x3AfKOyGUSp2kmzLJ1tthbJk8vRPTDV8NXUePoDqsgiJwpLk04v U5An7rmC0JaZR8wWzGuysTRGEjBaV8fQw8rDDPfigMntOrvk6l2WZ2hB24FI1SVA9tnqqrMtJQ+M XBkWvbtP8S+Mzo71NggeNzn++bGJfqc6bUQIDLsNkoZ5E4BMFdZGRrunDvpuP1UhZMPxh+7cQw6+ okHloPPU1U1ZenaB0dlTNQ8SV4iAWJzXn3H2yYShT/fcUB9Pnhmp8X/jfekku6CenGcnUu+o8W75 NDsT8pJLk4emus/LMq8PLh7y1wwRcGT2zWvPrI1KkW4c94QnUxoWn0R2skzyoX2ZTI4QETltdc9m RWUAp9kS1hIj8vLEwVs9Q95g6X+jm/OpD7G+ncLayB9VO22W9u2VjW3jc/FBa7jeXXe/Z35fDv96 9xlfPxmzvbV3Qpgfx3tAdmH1OXQxEIoPmTrfSH/xiJF84/UttEbaxtIYScholXSRh1Q3L1SRMgsz 9eIh5Z/5H+eDtwbHQrh3ls4zlKkdyt52BMg+u+0otIHCasziU8T4Ma4FNN2aOX2x50Lww+C+/3SG 3RaQ01qE3afqQzcvJR2bmYqLaThn6uLsYvT2sVt3ch3Ro7NbtykSVo6ADGvv7pLz86UXLrKxM3JN 7v221lb2D8g5PWP9A0OrC8vpOhNfHkRm/8uL873jT8hdxq27Cyts7rY45SN/VHbWeWRGLTNYrbOH ra49FH8lU5JlktntH9qXGUypIKfQPZstlQGcZEtZi1HkpcmTa2NnRndSCbauXprff8y8RKRqp82S bMRsGFsj1/J0ffVAaNQXuNzuw/gm9/6VxbubKcTdurMYKTNF9mom1WzM3khIo42zZMHG8aVVwWTf i0knkN8zVAUU5KwEgaTuWQklIKROoPaRgd6V1+S0Uz+RVsfpYh8wGDLmHsaSUw0vYNMPQY+WKct1 Ux6aWklqjntXptjxUWeSHDMFemzimgwe1E6MQ0o5x1QiQv6qJ6p4aFBTnEiHypQnycP1VTZ/Mhia Go22i1Nz7xP83OuKFzOVhID8d63h1L/fOzu2fnzWiy9gbHD08YUXopN/eahuES6Bzp6pXZCpIgTE 4vyG2vPb2ljvHey4G3EfNxdVNKyY4Bah1dbmmprCch908Nbg2H62vrmZrWBRlLd3kL4IMrv9Q7LC YHYnyIerqSAXqLu9uqVUarIWSizplM8Zlt9yefCktMBUv1izzGkYqQQpL7GnhYrdUiPWw40VfQW4 o6tvZeOBvQxiO6y3Z4d9hnZISdtYvJGQRmuw5HA3rwwzcy8Oz+3sVUrjGexLRUoQSCQQO9Ak5kaC liQgdqidwDovRkkep4tVa+3oMf/ESO47jx7tpNXgq9NDCwPXw6fx0TJDsWl9CVSWbt/sG9gTrtT1 n9r9UDZX3zgmQ1APrFycVpNqPgfWoticMyf+fP4We1YGDlzYL86uzGq6ZV4fZxef5mfdtaMvqnh+ 9+henY3xI2sn2pRH0jEn2i4QghdSs7ZnsM+dYmU0C63hRAnLE1zTy8HW2bFncP12xi0AdPaM7YJs FSEgFucHvQshq1PT7JyMZqx3y67O+idvHF87IRcGp9ngUHFaOV5pZqQjc5k8piUSTZSiMDK7/UOy pnB2FVd8/5XRNR+y55Hz6J5CTydpAcBDlUatxcAk6pS9hEnH5gY9480yp2GkZ1t2Dm/ELbuitiyf trF4I6FmEuT0QhKju3k1YBK9mAcXaPdx4q4dGVS09AzVAAQpK0KA7LMVkR1iRgjMqWnnLh5zd92N vvTejuEfaO/d58aO8X3nmBNssSvtBejJiDN1Gq8uP4s/XplaeKNdu/R0RK6G+WHt6n6o+LlBcLUe dyUsFvbkycTQqJOL7x3Io2aTml6ZfnwBITPfMGUuz8fGnDO2eDVrXd1s7UG6OFlVM9Vw/OHJub6u yGSfNwSLxM/L+2jaATvVCOjsdqaJVNUlIBbnQ14n7B1/1tnZEr5AOS+5MBBztct72Doj3FBa5UUs +s2x6a5ZeZtx88E66+7sTFuIOEsUl+H9vcZUJZDZ7R+SdcWJxG8ESMiF6J5KU9GCRQAnKqWsJZJs 89r0HG9uOf650VZeHJq4rJXp2NxsljkNIy3bUtOLhlvfCI2P/Khcf8gP0okxzyyWdhOkVNlbpnDK xpKMhDTaT1+MsWSlrtvNW0Z5C0Fie7E4P8kwRbPyDBayIQkI2BKIHWhsC0G61iHgXl3270XKMGb3 6Ns76d395Li8uszDo3qMx+ZGtegyW4eCJ0kuNfk1wN5x52VSYjJf6otmog3HleAPZwduDUcvHeze 11O/ciclcHT2lMCQvIIExOJ8vnewn2/u8SsibMq5AbI1M30z9I4u/iIl52qNcwFGXGLhL6MS75eK u+cThSKmsG4gkLxVu899y6XaxUy8bcIFEGfmlivzSJlkdvuHQiG7Mn3VxSalhByje3nWkxs4IVqM tQTg+KdwfrSVu5fML2v5m9leHXY24Cb3zZI/SWcY5QEvqmTxloep084bTZ1CxXpp1e2nfP9YxdTx zXjvfRAyus/vUyFh+kfHeudOZHwXa1GKNa6cqI1ZGAlptJ867p4nRy3Z0cfr5o3TL19NCT6fCXrK cdn/ksq0LwkpQcCaQNxAY10IErYwAXH86/yEX/IkFW8XX1i+ujgfe8NRxmm7h7Te/JYs0x9Mxewi 8c45y7B96QjfsbN3xfZqd7yagYl0Z0d38K6onEiEb3fHqynIBI/i0k3MoobEeygPyB0OT+/5hGR9 YVFPnlwROnsL91OIVhABeefcWSx1HjnDb/I4ET7d59XumvdZneHXRu+HboxYyKBuY/ovqJA9c++E eEm7F7Pkn36LW6CBH5VdHIVxh+lF6ehfjQpVJMoKl0lmt38oxbMqU/+QFX8HvgPZqLsFTJskJQB3 FAmxJa2FgmOSWg6Q0ZguKxsgzZI2DBtoLZuGx0uL8cyNO5D7ZbWRy+cPOFfavJC/2siz/A0uqk+J m3WqTylj4GFsqrOo982IMXLIiWWw+ZZhy8KxECxqY8UbifbxGL+bW8jWEkniff6jJ9bHXcdFOhby odEztITGEAIEQKCKBGQsuhrjprvG9SuW4vT14tzQPu/NNWrWGpyxiHGzRxsi5fyWLNMfTPmkl3/r JP7nB5zr6fw753FfIOZj8ezYuoorTP7oWkRNXqEeQ+5PpMUxuzNtUB9z4dNOd27vfSY5Vk15C8B9 FbRSTEbjz2e9Ii6LcMQIHuZ1HhntWVmtokVCZhAokcAjZ557/vDHP1liDSgaBECgeAJ8XXRpp3cZ r/jyUSIIgAAIgAAItDwBftbaxI1R8ao5/rq1jFcsU8ANq8nnAIv7SqmXnF3wh2PsfNJt8BT6ICkI bGsCr770uQ9++KMmBPJTaviBAAhUjMDeCe8cIG5vvmJaQVwQAAEQAAEQsCbA743PeW9Qs85VXEJx BL1W/k2xxqnJX4Qe+rqt/F5M6ENoxQFESSAAAhECWJzDKECgmgTkS03ln/L37KtJCFKDAAiAAAi0 KwH5lfLmLxr5W5MvsLHElyVlboWGqilfhC7f1uz/1Guh019rzawxMoLAdieAsPbtbgHQHwRAAARA AARAAARAAARAAARAoAEEENbeAMioAgRAAARAAARAAARAAARAAARAAASyE0BYe3Z2yAkCIAACIAAC IAACIAACIAACIAAChRDA4rwQjCgEBEAABEAABEAABEAABEAABEAABLITwOI8OzvkBAEQAAEQAAEQ AAEQAAEQAAEQAIFCCGBxXghGFAICIAACIAACIAACINBkAvL15uJP3jeo82+Y232plNeYt64mMtPV 5H8fmdlqojCoGgRAgLHg4nx5Qnm0XZ4/8p9kdnab10YiXlL4AlXg4WsJbsA+O5WSbGOydvuH1mV6 I0RAzRS6Z7NQe2Jk+SRGA1vPPCy8ufxUpjuApbMrqvaorXJtSmebrUXy5HJ0D0w1fDU1nn4TiCxy orA06fSyYKdmjLbMPGI2P6+d3aYzPBYwWlfH0MPKwwz34oDJ7Tq75OptR1ilTuMZmm87kKAdCJjs th1022Y6BEauDIve3af4F0Znx3obhI2PCPzzYxP9TnXaiKDNpRskC6/GmwBkqrI2Mto9ddB3+6kK IRuOP5y4p4qRUxfRoHKAeOrqpnyaQWB09lTtgsTVI6Atznm3OckuqC8nn2cn1Fzf/5Yyf14fYn07 a6mU5N3yaXYm5CWXJg9NdZ+XFV0fXDzk9luiYDL75rVn1kalnDeOs/ozapOPTEmKSma3f2hfJpMj REROW91TcfYSlwGcZiuWKNM9N5TBzIwk2MXyxMFbPUPeYJnCrqjaSVvlLp4wjGwYWyQXH4GG6911 93vm9+Xwr3ef8fWTMdtbeydE6/Bue0D2a/U5dDGqiQ+ZOt9If/FIuh7dImRCYhjMPup8UhiemEAE jFbVGXlIdfPWpERIZerFQ8o/8z/OB2+tCfMJWCrPUBlUELQCBCJ2WwGZISJFQI1ZfIoYP8a1ALyt mdMXey4EPwzu26Ez7LaAnNYi7D5VH7p5KenYzFRcTMM5UxdnF6O3j926k+eIHp3dukmRsHoE9MX5 2sr+ATl952vygaHVheVgv9m6eml+/7GUU3m+PIjM/pcX53vHn5C7jFt3F1bY3G1xykf+qOys88iM WmawWmcPW117KP5KpiTLJLPbP7QvM5iyu0ssglLons2YygBOsl164SIbO5O0JneUWJo8uTZ2ZnQn pVOSXVG1b5G2SjZiNoytkWt5ur56IDTqC1xu92F8k3v/yuLdzRTibt1ZjJSZInuLJiVNNMEnJBke abRxlizYqG5emZ99L7YnbF9mZTBBUBAAgeYQqH1koHflNTkX1U+k1XG62AcMhoy5h7HkVMML2PRD 0KNlynLdlIemVpLUvndlih0fdWbOxsTi9PiaDB7UToxDSjnHVCJC/qonqnhoUJMoU0Z1DddX2fzJ YGhqNNouTs29T/BzrytezFQSAvLftYZT/37v7Nj68VkvvoCxwdHHF16ITv7loXqGcIlMUiITCLQo gWBY+81FFXwipq1hgeWU68m9+fXY2lxTU1jugw7eGhzbz9Y3N7MVK4ryNhTSF0Fmt39IVhjM7gT5 cDVvyI3VAnW3V7eUSrc21nsHO+4Sg01UMOmUzxm2dbLaVZytSs45DMOebakpPS1UHLUasR5urOgr wB1dfSsbD+zFENthvT077DO0bcoEwyON1mDJ4W5eGWbmXhye29mrlMYz2JeKlCBgQyC73dqUjjSN JyB2qJ2ATS9GSR6ni1Vr7egx/xhJ7juPHu2kZeSr00MLA9fDp/HRMkOxaX0JKi/dvtk3sCdcqWuH j2p7B3P1jWMyLvXAysVpNdPmc2Atis05c+LP52+xZ2XgwIX94uzKrKZb5vVxdvFpftZdO/qiiud3 T5XV2Rg/snaiTXkkHXOi7QIheCE1a3sG+9wpVsY21xpOlLA8wTW9HGydHXsG129n3wJAZ8/YNMhW BQLa4rx/8sbxtRNyDXCaDQ4FpU86ZUqtq+OVZkY6Umd1M/D40kg0UYrCyOz2D8mawtlVXPH9V0bX DmqvFSlA9xR6OkmLr3R1apqdk7Gv9W45MNA/yil7KTPaVaytisDjPIaRnm3ZObwRt+yKtk/5CYZH Gq3RkuluXg2YRC/mESjafZy4a0cGFS09QzUAQcqqEMhtt1VRdFvIOafmort4zN11N/rSe5OFf6C9 d58bO8b3nWNOsMWutBf4KSPO1Gm8/3YMr0wtvNGOdE9HJFzKj7j2b/y5QXC1HnclLBb25InX0KgT k8j3DuRRs0lNr0w/voCQmW+YMpfnY2POwVu8mrWubrb2IEvQOdVwvPaTc31dkck+bwgWiZ+XV8+0 A3ayEdDZ7WwTqSpLIHByLtcAYlp2eQ9bZ5rHEZdqijk256BELPrNsemuWXmbcfPBOuvu7EwLUJwl ihvy/l5jqhLI7PYPybriROLXBKSnK0T3VJoWBZyotHf8WWcfVIwczlAXTrd5bXqON7c8+HWjrbw4 tBx2ZbLVnIaRlm2p6YW1rG+Exkd+VK4/5AfpxJhnFku7CVKq7K1deILhkUb76YsxlqzUdbt5aysf lC62F4vzkwxTNCvPUCVIkLVaBDLabbWUbHNp3avL/r1IeaXIPfr2Tnp3Pzkury7zSKge47G5kRVd ZguizaUmvwbYO+68HkjM8Et90Uy04ThO/nB24NZw9NLB7n099St38gBHZ89DD3lblgD5KTX+Yq3A LRp+qcbfdPQuwIhLLPxlVOL9UnH3fKKqiymsGwgkb9Xuc99yqXYxE2+b8AWYOBq1XJlHyiSz2z8U CtmV6asuNikH+/n2aozu5dlIbuCEaPxCEZty7gttzUzf1N4UGIDjb3D60VbuXnLIrpxa7GzAFSlg q+kMozzgRZUsXv0wddp5o6lTqBiKVl3y/CxXxdTxzXjvJREyus/vUyFh+kfHeudOZHwXa1GKNbkc 2vB8oUij/dRx9zw5asmu6brdvMn6WVcf04tlGQKUclz2v6Qy7UtCShDIRiCL3WarCbkaRkAc/zo/ 0b5eveLt4gvLVxfnYy+yyTht95DWm7GQZfqDqZhdJN45Zxm2Lx3hO3b2rthe7Y5XMzCR7uzoDt4V lROJ8O3ueDUFmWBEQLqJWdQs+KjKQyyHw9N7PiFZX1jUk6esCJ29YV0QFTWSgFicu+th7+MEw6+N 3vcvh0hHlvW2ubqN6b+gQvbMvRPiJe1ezJJ/+i0u2QZ+VHZx6sUdphelo381KlSRKCtcJpnd/qEU z6pM/UNW/K3mzorUqHtBrV4CcEeRENvOI2f4vS/ZiOL98/5ebKQRDZoZ7MrKBuQrx9VpvG+rtGEU xLU5xfB4aTGeuXEHcgekNnL5/AHntpUX8lcbeZa/wUX1KXGzTvUpZQw8jE11FvW+GTFGDjmxDDbf MmyO5ilrJc2efChe9pPDoUXl0j4e43fzlOI3LTnZi/2v1JxYH3cdlz1ho2dompaoeFsQIO12W2i+ LZSUsehqjJvuGtfvXYrT14tzQ/u8NyIpSwjOWMS42aMNkXLGQpbpD6Z8dsG/dRL/8wPO9XT+nfO4 z6TzsXh2bF3FFSZ/dC2iJq9QjyH3J9LimN2ZNqiPufBppztb4xWp0MVYNeUtAPf90EoxGY0/n+OK uCdG8DCv88hoz8pqWhNGZ09LDOkrRuCRM889f/jjn6yY1BAXBLY7Ab5YurTTu4y33WlAfxAAARAA gW1JgJ+1NnFjVLxqjr9uLeMVyxQNFlaTzwEW95VSLzm74A/H2PnE2+ApFEJSENjOBF596XMf/PBH TQTIsPbtjAu6g0AlCOyd8M4B4vbmK6ELhAQBEAABEACBDAT4vfE57w1qGfLnzSKOoNfKvynWODX5 R0lCX02W34sJfQgtLzbkBwEQiCGAxTnMAwSqSUC+1FT+KX/PvpqEIDUIgAAIgEC7EpBfKW/+opG/ nvYCG0t8WVLmVmiomvKjJPJtzf5PvX839CG0zOogIwiAQCIBhLUnIkICEAABEAABEAABEAABEAAB EAABEMhLAGHteQkiPwiAAAiAAAiAAAiAAAiAAAiAAAiUSgBh7aXiReEgAAIgAAIgAAIgAAIgAAIg AAIgkEwAi/NkRkgBAiAAAiAAAiAAAiAAAiAAAiAAAqUSwOK8VLwoHARAAARAAARAAARAAARAAARA AASSCWBxnswIKUAABEAABEAABEAABFqfgHy9ufiT9w3q/Bvmdl8q5TXmrauJWHU1+d9HZraaKAyq BgEQYCyyOF+eUE5tl9c/Rb9Vnu7wtSxddvPaSMRLpijTPjuVkmxjsnb7h9ZleiNEAF0K3bNZqD0x snwSo4Ft1FrMIstPZboDmJfRMa34gY2q3S9h4p5Xaelss7VInlyO7oGphq+mxtMfUEUWOVFYmnTx yuw+KNoy84jZ9Lzmpg8YHpczjZGE80o1Qw8rDzPciwMmt+vsktu2ZXmGptsOBGgfAmmGpPbRut00 CYxcGRa9u0/xL4zOjvU2iAsfEfjnxyb6neq0ESEw7DZIGuZNADJVWBsZ7Z466Lv9VIWQDccfunMP OfiKBpX99Kmrm7L0rAKjs6dqHCSuFIHA4lxMOqd7bqiPJ8+M1FS3eWZtVD65cZzVn0m7o8a75dPs TMhLLk0emuo+L2u5Prh4SFtchdmR2UmRyJRkU5DZ7R/al8nkCBFCZ697NjsqAzjNlrIWs8zLEwdv 9Qx5g6X/jW7Opz7E+nZKa6N+VO3cxZ9kF5ShnmcnnHVpTlvNBrzUXHzQGq53193vmd+Xw79uQuPr J2O2zPZOCEQc7wHJSn0OXQyE4kOmzjfSXzxiJF+qasUWbm76kOEF6MU7HzGBCBitEjnykOrmxWpX YmmmXjyk/DP/43zw1uBYCPcuNy/C40iJKqBoEFAEYHhtZAlqzOJTxPgxrgU03po5fbHnQvDD4L7/ dIbdFpDTWoTdp+pDNy9lOorjdcQ0nDN1cXYxevvYrTtZzvvQ2a2bEgmrS0BfnC+9cJGNnVFrcu/X eWRGzelZrbOHra49TKcrXx5EZv/Li/O940/IXcatuwsrbO62OOUjf1R2RopEpiTLJLPbP7QvM5iy u0uATaF7OtBu6jKAk2xJazHJvDR5cm3szOhO6t+3rl6a33/MvESkat9aW9k/oMyS9Q8MrS4sCx+f 01azAS8z1/J0ffVAaNQXuNzuw/gm9/6VxbubKYTYurMYKTNF9hZNamr6iOGl6ICk0cZZsmCjunll fva9mHQC+T1DZUhB0JYnYG/MLa8KBPQI1D4y0LvymlzD6SfS6jhdbMcEQ8bcw1hyquEFgfqRetEy ZbluykNTK0ltce/KFDs+6sxGjInF6fE1GTyonRiHlHKOqUSE/FVPVPHQoCZRpozqGq6vsvmTwXDX aLRdnJp7n+BHcVe8mKkkBOS/aw2n/v3e2bH147NefAFjg6OPL7wQnfzL8/CkcAl09kyNgkzVIaAt zrc21nsHO+4S7kOps7W5xrwVUQ4NRTlyCst90MFbg2P72frmZrbycopEZrd/SMoczO4E+XA1b8iN 1QJ1tydWSqVJ1qKLJ53yOcPyWzrZJwWcdL+biyqaXSxWIzlzGkY6SUpL7Wmh4qjViPVwY0VfAe7o 6lvZeGAvgtgO6+3ZYZ+hain1po8ann1fII3WYMnhbl4ZZuZeHJ7b2auUxjPYl4qUIJBAAIbXliYi dqidwDovRkkep4tVa+3oMXdrnk8FxL7z6NFOGgNfnR5aGLgePo2PlhmKTetLoLp0+2bfwJ5wpa7/ 1O6Hsrn6xjEZ63dg5eK0mr3wObAWxeYcg/Hn87fYszJw4MJ+cXZlVtMt8/o4u/g0P+uuHX1RxfO7 R/fqbIwfWTsBsDySjjnRdoEQvJCatT2Dfe4UK6NZaQ0nSlie4JpeDrbOjj2D67czbQGgs2dsFWSr DIHgnfPVqWl2TkYz1rtlV/d/PJgzErqTR0vHK82MdGQuJadIZHb7h6TY4ewqrvj+K6NrB4M3foVH zqN7emgFAA9VGmMtekrKKXv/nnRsbtCzf/LG8bUTcr16mg0OhVLlNIz0bMvO4Y24ZVdU+fL1pjcb XnJfIPMaC6S7eTVgEr2YhyFo93Hirh0ZVLT0DNUABCmrQwCGV522SpJ0To3vu3jM3XU3+tK7Y+wf aO/d58aO8X3nmBNssSvtBejJiDN1Gq8uP4s/XpladFWSkOrfezoi4VJ+WLtzP5Qnc4Pgaj3uSlgs 7MmTiaFRJ4KV7x3Io2aTml6ZfnwBITNfyjKX52NjzmFGvJq1rm629iBL0DnVcLz2k3N9XZHJPm8I Fomfl3cetQN2jDJ2ZohU7UUguDjvHX/W2dkSvsBxXiqoRlzx9Tf28kAQ4fE3x6a7ZuVtxs0H66y7 szNtgTlFIrPbPySljROJh15LT1eI7mlZlVWpwVqC4m1em57jzS3HPzfaSnvX4Olsx+Ziy5zvEIsl xOU9bF0bHXMaRlq2paYXDbe+ERof+VG5/pAfpBNjnlmsTJdTStWysMKDTU8bHrNyPmTeT1+MsWSl hNvNC1OpAQXF9mJxfpJhimblGRqgG6rYZgRgeO3T4O7VZf9epLxS5B59eye9u58cl1eXeQhej/HY 3IiFLrMFKeZSk18D7B13XiYlZk2lvmgm2nByY+Ll2YFbw9FLB7v39dSv3MkCHJ09CzXkqQwBbXHO r4iwKecGyNbM9E0nlIhPecWZubYydy7AiEss/GVU4v1Scfd8oijEFNYNBJK3ave5b7lUu5hJt03E ZkFIpDjekTLJ7PYPRV12ZfpSiU3KwX6+vRqje3k2kxs4IZrBWiJw/FM4P9rK3Uvml7X8zWyvDjsb cJPzN4H5N77SGUZ5wIsqWVynnzrtvNHUKVSsl1bdfsrPclVMHd+Mdy7eO9F9fp8KCdM/OtY7dyLj u1iLUqz4ciJNbzA8qw5I5v3Ucfc8OWrJjj5eNy9ev3JKjOnFskLRQ5Xjsv8llWlfElKCQAoCMLwU sCqYVBz/Oj/hlzwNxNvFF5avLs7HXrqUcdruIa03vyXL9AdTMbtIvHPOMmxfOsJ37Oxdsb3aHa9m YCLd2dEdvCsqJxLh293xagoywYiAdBOzqIHxUZUH5A6Hp/d8QrK+sKgnt6kInb2CPRgipyIgFufu erjzyBl+k8eJ8Ok+L3fXxIsouXfyQmKSV87B6tVtTP8FFbJn7p0QL2n3Ypb8A3lxIzTwo7LTIpEV ibLCZZLZ7R9K8azK1D9kxd9d7KxIjbqnajZz4hKAO4qEGpGyFhKOSVY5QEZjuqxsQL5yXJ3GvzZ6 37nIlNdWC2qBIovh8dJiPHPjDuR+WW3k8vkDzpU2L+SvNvIsf4OL6lPiZp3qU8oYeBib6r/qfTNi jBxyYhkyfx+xSCULKCtF0xfeAbWPx/jdvACdGlIE2Yv9T6mdWB93HRfpWMiHRs/QEI1QybYlAMNr 66aXsehqjJvuGtfvsonT14tzQ/u8N9coDxacsYhxs0cbIuX8lizTH0z57IJ/6yT+5wec6+n8O+dx n0nnY/Hs2LqKK0z+6FpETV6hHkPuT6TFMbszbVAfc+Gjnju39z6THKumvAXgvnNXKSaj8eezXRF3 0DhiBA/zOo+M9qyspjVddPa0xJC+YgQeOfPc84c//smKSQ1xQWC7E+Droks7vct4250G9AcBEAAB ENiWBPhZaxM3RsWr5vjr1oq59RnXfmE1+RxgcV8p9ZKzC/5wjJ23uA2+LW0QSoNAWgKvvvS5D374 o6ZcwTvnactGehAAgeYQ2DvhnQPE7c03RzjUCgIgAAIgAALlE+D3xue8N6iVX12kBnEEvVb+TbHG qck/ShL6uq38XkzoQ2hNII0qQWD7EMDifPu0NTRtLwLypabyT/l79u1FDtqAAAiAAAhUnYD8Snnz F4389bQX2Fjiy5Iy026omvKjJPJtzf5PvX839CG0zOogIwiAQCIBhLUnIkICEAABEAABEAABEAAB EAABEAABEMhLAGHteQkiPwiAAAiAAAiAAAiAAAiAAAiAAAiUSgBh7aXiReEgAAIgAAIgAAIgAAIg AAIgAAIgkEwAi/NkRkgBAiAAAiAAAiAAAiAAAiAAAiAAAqUSwOK8VLwoHARAAARAAARAAARAAARA AARAAASSCWBxnswIKUAABEAABEAABEAABFqfgHy9ufiT9w3q/Bvmdl8q5TXmrauJWHU1+d9HZraa KAyqBgEQYEwszq85HXHz2ojj0YRfO7vk8FmeUG5ul52TilB1ig14LuELVJmH3dpNrUFlZ+RDxjxR LZyL/HKj6099HW18OlU7SSmFmgUaYwnAaUUMrRBVhcxu/5BkQ2X3huSAXTWnFYpq0ECvdDqRr5Fm wL7Niywy5dKk08vC/ZcGVZTILVKOqVPb20PYnxg8JO2OCvBRDQMZcIZuraGH28JmCiBuOWAZbMls nOE2svefeUfwAqA0rog0c4DGSYWa0hEIjFwZFr27T/EvjM6O9aarNXNq3jf558cm+p0CNFeZedqc WRae0ZsAZCqkNjLaPXXQm/+nK4NsOP5w4p4qR3ot0aCynz51dVM+zSpwvs4eGdGo+VJgFuFqkY5J VUaEqJypBilLNZ3mJjfOwmOcDp9YkHqr1DQTs+qMhmJxXn/G3ycbOq++nHzf+c4h70sn2QX15Dw7 YbHoDdotN/en2ZmQl1yaPDTVrSq6Prh4KMbiDdmJMplo1+meG0rUmZFafP9Znjh4q2fI893+J6N5 9voQ69tpzE+JRFPavPbM2qiU58bxAOR0XTtd6jKAk4qQFZGyktntH9qXyeSQHAJub2zpQDckNXc6 w/Xuuvs98/ty+Nc1Gl8/GbO9tXdC0OD2fEB2YfU5dOHIxIdMnW+kv3gkoas0RNEyKqE7tW2vNPmT sIcUOyCUi8vvo8pgQpYZcoYqTeQh1bkaJmJVKkphDFwlwpZMI2O4OUi3Rtl23hG8KuTlzD/VHKBK mm1DWdWYxaeI8WNcC5DZmjl9sedC8MPgftd2ht0WkNNahN2n6kM3LyUdm5mKi2k4x2s5uxi9fezW ncxH9Pk6OzkLIudLjPWOq2XFjeNrJ1KfUFZlRDDO5+0GKXs1zQuH6BjnrT35JNYxyKVJ4qEwRauJ WaVGQxnWvrr20NTRttZW9g/IOT1j/QNDqwvL6ToTN/fI7H95cb53/Am5y7h1d2GFzd0Wp3zkj8rO yIdLL1xkY2eS1uROJbyB18bOjO6k6ty6eml+/zHzioWqnabUeWRGLYdYrbMnDrK107RIWAZwUhGy FUgByez2D+3LDKbs7hKrzhTGZkG3wUmWp+urB0KjvrBPt/swvsm9f2Xx7mYKubbuLEbKTJG9mkm1 Tm3ZK+39SUk+qmGgSWcY5yGFZKpz4RcmYG8MFDujs4o0B52Ssu28I3iF2ti+z1ZIqW0vau0jA70r r8lpp34irY7TxQotGDLmHsaSczsvYNMPQY+WKct1Ux6aWklqgXtXptjxUWeSbEwsTo+vyWhN7cQ4 pJRzTCUi5K96ooqHBjWJMuXZ43B9lc2fDIamRqPt4tTc+wQ/T7riBs8mEaD/XWs4leDe2bH147Ne fAFjg6OPL7wQnfzLs82kcIl8nT3TLKh29NxY79y0c9rvHP4nyVmVEcF6Pk8PPfZqmiqKTjk6dnq0 RaWD/WLOQT4kDdB+pZbNvkvPJRfn3vKbRbo0/9ebiyoiRUxwi5Bna3NNze24Dzp4a3BsP1vf3Mxb 8NbGeu9gx13C90VLlj7inGH5Lfv8k3tTyxNLSaisQU5deL4MBQLPqQiZ3f4hiSGY3QlM4nZ1Q+5k F6h7vkbIkttTTUX7qBHr4caKvjTa0dW3svHAvnSxHdbbs8M+QzukpDt1nDGb/Ul40mPPJ42Psi81 Z0rSGRo8ZLhz5awa2UO2ZHJW0eZIdGsB2y56BG/RhmvJ/tWirCokltihdiIZveAdeZwuVq21o8f8 EyO54ho92kkrx1enhxYGrodP46NlhmLT+hJYLd2+2TewJ1yp27Uf1fYO5uobx2QI6oGVi9NqUs3n wFoUm3OWw5/P32LPytPaC/vF2ZVZTbfM6+Ps4tP8rLt29EUVz+8eJKqzMX5k7URx8kg65kTbBULw QmrW9gz2uX4jo7FoDSdKWJ7gml4Ots6OPYPrtzNtAeTr7FlnQZ0d3RlhWGZrwRHBUiRLBU3JqCkH 32u+P7oxLKa+twfcaGjyoSjVdmJWndFQLM7dozmhth8VrKLN+ydlLIdYGJxmg0M5W0DL7nilmZGO ospcnZpm56T89W7pp+gf5SO8lEnH5oYy4ynxaI1I1FNRStuXUwDwnIqQ2e0fkqqGs6vApPuvjK4d 1AKQCtDdHnQJKb0Rt4Sy279IulMnGjPhTygPmYqfpY9KVWaexKQzNHpIunPlqX8b5zXaUthZmQcs o1vTbbu0EbwV267V+lcrMqqKTHNq2rmLBzled6Mvvfui/oH23n1u7BhfccWcYIv1mBcRKSPO1Gm8 /6Iir0ztbNAOVk9HJI7ID7L1r1i6QXC1HnclLBb25FHQ0KgTBMr3DuRRs0lNr0w/voCQmS9lmcvz sTHnjC1ezVpXN1t7kC5OVtVMNRx/eHKurysy2ecNwSLx8/I+mnbAbmiEpnd2SzntbIixFhwRrEWy 1THVosy/enCBjbmbXORD64lZpUZDsTiPBuSIbTO3Z8qFgVjwXN7D1hnhhtK2i4jxvjk23TUrr7Vv Plhn3Z2daQsh0veOP+tsywlH5njecLrNa9NzvHZ5DukG/3hhUeLuUKZjc7GDS1MSZ57ijoS/J1qA pimLKAR4TkXI7PYPSY3jROJXMKQBF6J7St6FJRfCr2+Exkd+VK4/5AfpxJhnFqGBNywK45CrIKpT WxlzrD/RPWQK8ax8VIry8iUlneGnL8Z4SFWf27ny1Y7cDgHPlihnxcgBi5nH0KhtFz6Ct27LtVb/ al1OVZDMvbrs34uUga/u0bd30rv7yXF5dZmHR/UYj82NCtNltiCfXGryuy3uxWk5mS/1RTPRhuM4 +cPZgVvD0UsHu/f11K/cyQI8R2fPOgsqbrUSq3ALjgixIuVcvhkWZdrVA/EShNUpcQOCfKjBTJyY VWg0pD+lxm/RrDgh/p7e/GUzztUa5wKMuMTCX0YldjLi7vlErVDM7dxAIHmrdp/7lku1i5l0i4Oy a36/hcnG47+tmemb2hvdAmX6Wyx+8I+7tSm0jt42TyeST0kIcvWwODNv6srcnUznAp5OkQgxMrv9 Q6GCXZm+ZXh3VGKMLcuA0Ng84i0PU6e9O06ycuF9lJ+SWE6omDq+Ge+9D0L6L79PhUTuH+X3pk5k fBdrY9UvorZop7Yy5hh/IqWiPGSSuEllJuUv/N9JZ/ip4278VNRDOhL4F8AKF2k7FujbEuGsDAOW wa3F2nZxI3hrtlLL9a/WxFRZqcTxr/MTXcbTQ7xdfGH56uJ87M1BGaftHtJ6U0SyTH8wFV0m8c45 y3jCzBXgF2hXbK92x6sZmEiL6OvAXVE5kQjf7o5XU5AJHsWlmwlHzYy7Mh7TOhye3vMJyfrCop7c piLbCb/B2jPNgu6d5ed5RaxWkrpg40eEJIm0CU/xM+qYRZkbuyGs0VvTkQ81zxBeupLKBVZqieo3 JcEjZ557/vmZf8uDcCb65auhV6UYfJvNWbL6D2Ua8Y9iBsDv9J5hp8UdnnPsmeHFx2dDl0lcZfg1 RTeKRj5yChH3f5TX6/NjlpzV7IpXkfwWVDR7YpluLbJGOV/Ry/Q4C9VeG3XjZ5wrSeE9xUh2snaC kninSPBtIppe5bV1Ipz0wGukIoaKosBJDmSZdEVUI9JsNZF8A5Yvd6GMrbw2KLRknbPbdnz0Ojkn a/FbUxlq8GGojfjutYrgoMosVOhWKSzaqe17pZbS7bmkhyzAR7UArqAzdATSHxo6VwuI3koi2BsD aUvxzio6YAXHUNq2c47grUQ3URaizybmQYIWJMD70eK+yKmGuMdxUw57x8e7L675CeSAqM2vtM6l TzupcZMs0xtMh87zG9qEJDoyXgKPA9UnwF6ZMpkadjWNhJXyG+Dex1PcWbeTUlxEv72PiusOq2ke x6NzHt05uLOjGDXFP/Eb8vor6FUJ++uBh2HbIRsupDs/5Ju93DktPq6kVhkhvcJqGuzT1Nmt5CRn QdR8ybcZfVkkRbKSsxojgmGpZT9I2atpXDhIpoExTpvT+ms66qH9xIxaqTXP/7360uc++OGPmuoX i/PDH/9k88RDzSAAAhkIcB93aad3GS9DAcgCAiAAAiAAAlUnwJdJ3kqv8boEFttlVh9Wk97CKEIC cnYhllXMPaIropaSyqiKnCWpj2IrQyB+cU6HtVdGOQgKAtuUwN6J8z31Q+pzKc4nWLYpCagNAiAA AiCwTQnwe+Nz3hvUmsCgNvIsf2ty6TfFGqcmf3V26HPC8nsxoQ+hNYF0YpVVkTNRESQAAZycwwZA AARAAARAAARAAASqREAFkPfxMGnTF9QapY0xFr0IAQxqlnNyzs/n+Zer9ID2IlRAGSAAAiECCGuH SYAACIAACIAACIAACIAACIAACIBAkwkgrL3JDYDqQQAEQAAEQAAEQAAEQAAEQAAEQCCeAO6cw0JA AARAAARAAARAAARAAARAAARAoMkEsDhvcgOgehAAARAAARAAARAAARAAARAAARDA4hw2AAIgAAIg AAIgAAIgAAIgAAIgAAJNJoDFeZMbANWDAAiAAAiAAAiAAAgUQoC/3lx+ZPTRyeV85fFvmNt9qZTX mLeufJLmyq2ryf8+MrOVqzhkBgEQyEtALM6veR2Rf0RBerTAl5P9h4/uyvItx81rIxEvKXyBquiw Xzuti312KiVZJlm7/UPrMr0RIqBmCt2zta49MbJ8EqOBrWcbFt5cfoLSHcB0o0oeRKnaSVstnW22 FsmTy9E9MNXw1dR4+k0gssiJAv/UijNHCXVq2jLziNn8vNZmn8ZIAkbr6hh6WHmY4V4cMDnN55fl GZpvO5CgDQikG1PaQOE2ViEwcmVY9O4+df+Vl2fHehuEiI8IJ1h9ot+pThsRgnPpBonjTQAy1Vcb Ge2eOphlqh+ecrgNx1tz4p6SRQ6+4rnsrU9d3ZRP0wuMzp6pbZGpQgTE4rz+jNwn493mJLvwMndq 9185z044c/2lSe/hy/Whm5eS1tIh3Xm3fJqdCXnJpclDU93nZUXXBxcPuf2WwEZm37z2zNqolPPG cVd4sQ6JVmRYfBLZyTLJh/ZlMjlCROS01T2bFZUBnGYrlijTPTeUwcyM1OLlXZ44eKtnyBss+ycV GfmnPsT6dhrzU7XTtmrfXtnYNj4XH7SG6911j5Uc/vXuM75+MmZ7a++Eg/eA7NeTu92BkM8k3DJf PJLQco3XOkON9o4ijZGEjFbJFXlIdfMMKjQni6kXDyn/zP84H7w1OBbK66bzDM3RG7W2HYEUY0rb 6d6GCqkxi08R48e4FtB8a+b0xZ4LwQ+D+/7TGXZbQE5rEXafyjDV90qPaThn6uLsYvT2sVt3Mh7R o7NbtyYSVpSADGtfXXvI/3drbWX/gJy+M9Y/MLS6sCz6TcfO3rlptb+1vDjfO9ifbirPlweR2b8o Z/wJucu4dXdhhc3dNoYeUdlZ55EZtcxgtc4eR3hGpiQbhcxu/9C+zGDK7i5BLoXu2SyqDOAk26UX LrKxM0lrckcJvsWzNnZmdCel09bVS/P7j5mXiFTttK2SjZgNY2vkWp6urx4IjfoCl9t9GN/k3r+y eFd2T8vf1p3FSJmWWVs4mb2jsDcS0mjjLFnwUd28Mj/7XkwSzu8ZKkMKglaIQNKYUiFVtr2otY8M 9K68Jtdw+om0OpUV+4DBkDH3MJacangBm34IerRMWa6b8tDUSlIL3LsyxY6POjNnY2JxenxNBg9q J8YhpZxjKhEhf9UTVTw0qEmUKaO6huurbP5kMDQ1Gm0Xp+beJ/i515WlJNVj/11rOJXu3tmx9eOz XnwBY4Ojjy+8EJ38y1Nx+3AJdPZczYTMrUpALs69NfnNRRV8IszdkZjPZe+PbgwLn3J7IPmA1ELP rc01NYXlPujgrcGx/Wx9c9MiH5FEFOUJn74IMrv9Q7LCYHYnOoureUNurBaou726pVS6tbHeO9hx lxhsooJJp3zOsPyWy4MnBZx0P8JW/QJyGkY6SUpL7Wmh4qjViPVwY0VfAe7o6lvZeGAvgtgO6+3Z YZ+hLVJm6NSk0RosOdzNK8PM3IvDczt7ldJ4BvtSkRIErAlkHVOsK0DCxhEQO9ROYJ0XoySP08Wq tXb0mHuMxGdXYt959GgnLRtfnR5aGLgePo2PlhmKTetLUHXp9s2+gT3hSl3/+ai2dzBX3zgm41IP rFycVjNtPgfWoticMyf+fP4We1YGDlzYL86uzGq6ZV4fZxef5mGttaMvqnh+9+henY3xI2sn2pQH KjIn2i4QghdSs7ZnsM+dYmVsa63hRAnLE1zTy8HW2bFncP12vi0Ahs6esX2QrcUJiMW5czTXP3nj +NoJuQY4zQaHHMHFbRDlPi6wMc3R5NXL8UozIx2ZS+LxpZFoohSFkdntH5I1hbOruOL7r4yuHdRe K1KA7in0dJIWX+nq1DQ7p+LSu+XAQP8op+ylzLjrSduqW2pOw0jPtuwc3ohbdkXtWX6GTk0ardGS 6W5eDZhELxYbsv59nLhrRwYVLT1DNQBByooRyDimVEzLthd3Ts1Fd/GYu+tu9KV309g/0N67z40d 4/vOMSfYYlfaC9CTEWfqNF5dfhZ/vDK18EY7yj0dkXApP6zdv/HnBsHVetyVsFjYkycTQ6NOTCLf O5BHzSY1vTL9+AJCZr5hylyej405B2/xata6utnagyxB51TD8dpPzvV1RSb7vCFY5KqsDFnXDtjj GgGd3c5Ekap6BMTi3AvIkWsAMS27vIetM+lxtCBYcRFldYqIQkmptYhFvzk23TUrbzNuPlhn3Z2d KcuQcT7iMry/15iqBDK7/UOyrjiR+DUB6ekK0T2VpjxxWZX2jj/r7IOKkcMZ6sLCbV6bnuPNLcc/ N9rKi0MTl7UyHZuLLfOIrcqqcxpGWralphcNt74RGh/5Ubn+kB+kE2OeWSztJkipsrdK4Zk6NWm0 n74YY8lKXbebt4ryNnLE9mJxfpJhimblGWyEQxoQSEkgx5iSsiYkL5WAe3XZvxcprxS5R9/eSe/u J8fl1WV+gtpjPDY3SkqXWapi2QrPpSa/Btg77rweSMzwS33RTLThuMb84ezAreHopYPd+3rqV+5k Y8JvH2SeQGasEdlAoFEEyE+p8Xcm6bdo3P0zsf0m4oucCzDiEgt/GZU4Wo+75xPVRExh3UAgeat2 n/uWS7WLmXjbhAsgzswtV+aRMsns9g+FQnZl+qp71/VjdC+vyXMDJ0TjF4qYu1OzNTN9U3ujWwCO fwrnR1u5e8n8spa/me3VYWcDbvKAraYzjPKAF1WyePXD1GnnjaZOoWK95O2R8bNcFVPHN+Odl0Q4 G2p+nwoJ0z861jt3IuO7WItSrEHlpOvUvlCk0X7quHueHLVkJ2uWt3I0CAVdTUwvlhlED037npGk MpuqMCpvcwL0mNLmSm8P9cT80/mJVvaUFm8XX1i+ujgfe8NRxmm7h7TejIUs0x9Mxewi8c45y7B9 6QjP3+i0Ynu1O17NwES6s6M7eFdUTiTC52rxagoywYiAdBOzqE3yUZWHWA6Hp/d8QrK+sKgnt64I nX179PxtqqVYnLvrYe8LOsOvjd53LofURp7lb4Y45IT9dJ9Pu+WmbmP6L6iQPXPvhHhJuxez5J9+ i6uhgR+VXeyWcYfpRenoX40KVSTKCpdJZrd/KMWzKlP/kBV/q7mzIjXqXpABlgDcUSTEtvPIGX7v izCMSCMaNJMDZDSmy8oG5Lc31Gm8b6u0YRTEtTnF8HhpMZ65cQdyB6Q2cvn8AedKmxfyF+in/Gad 6lPKGHgYm+os6n0zYowccmIZbL5l2BzNU9Zq7SiKNxLtqz9+N08pftOSk73Y/5TaifVx13GRjoV8 aPQMTdMSFW8TAoYxZZto3+Zqylh0NRed7hp3710KpcXp68W5oX3em2uUBwvOWMS42eNOZfkQKaey ZJn+YMpnF/xTMvE/P+BcT+ffOY/7TDofi2fH1lVcYfJH1yJq8gr1GHJ/Ii2O2Z1pg/qYC592urM1 XpEKXYxVU94CcN8PrRST0fjzua6IO2IED/M6j4z2rKymN1509vTMkKNCBB4589zzhz/+yQpJDFFB AATkwvvSTu8yHoiAAAiAAAiAwDYkwM9am7gxKl41x1+3lvGKZYrmCqvJ5wCL+0qpl5xd8Idj7Lzt bfAUeiEpCGxLAq++9LkPfvijJtXJsPZtyQlKg0CVCOyd8M4B4vbmq6QSZAUBEAABEACBNAT4vfE5 7w1qaTIWlFYcQa+Vf1OscWryj5KEvm4rvxcT+hBaQfRQDAiAAEUAi3PYBQhUk4B8qan8U/6efTUJ QWoQAAEQAIF2JSC/Ut78RSN/PS3/mFHiy5Iyt0JD1ZQfJZFva/Z/6v27oQ+hZVYHGUEABBIJIKw9 ERESgAAIgAAIgAAIgAAIgAAIgAAIgEBeAghrz0sQ+UEABEAABEAABEAABEAABEAABECgVAIIay8V LwoHARAAARAAARAAARAAARAAARAAgWQCWJwnM0IKEAABEAABEAABEAABEAABEAABECiVABbnpeJF 4SAAAiAAAiAAAiAAAiAAAiAAAiCQTACL82RGSAECIAACIAACIAACIND6BOTrzcWfvG9Q598wt/tS Ka8xb11NxKqryf8+MrPVRGFQNQiAAGNicX7N64jLE8qj7dL9kei36uFhP2UKdpvXRiJeMkWZVHZG PmTMk9/CucgvN7r+1FfcxqdTtZeCLgVlLWkJwOn2MrRCVGoyu/1DEgOV3RuSA7aawtiyAS81lwM5 MNXwNdIM2Ld5kUVOFJYmnZ4b7tQ0qFL1aHzhpk5tbw9hfxJoi11nl1ydyvJRDWMWcIZuraGH28Jm CiBuaQwGWzIbZ7iN7P0nOTYVoGmLFZFuEG8x4SFOgEBg5Mqw6N19in9hdHast0FYed/knx+b6Heq 01xlcC7dIHG8CUCm+mojo91TB/3RLVUhZMPxhxP3VDHSa4kGlb31qaub8ml6gYvo7JERjZovBSpy tUiFhF6tRIeJpo8IOUWyHPic5iY3zsJjnA7fM0jiYZqJWXVGQ7E4XzwkbY53m5Psgvpy8nl2wpnr b157Zm1UPrxxnNWfSbujxs39aXYm5CWXJg9NdZ+XFV0fdGqnzd2QnSiTiXad7rmh5J8ZqcX3n+WJ g7d6hjzf7X8ymmevD7G+ncb8lEiloEvnANzUZQAnbYCsiJSZzG7/0L5MJofkkK3aG1s24KXm4k5n uN5dd79nfl8O/7pG4+snY7bM9k4IGtyeD8h+rT6HLhyZ+JCp8430F48kdJVSFSyzcLpT2zo0kz8Z Uo6L/3G+BFuajyqTTaDskDNU/xZ5SHWuholYlYpSGANXibAl08gYbg7SrVG2TY9NVeGZRs4Ug3ia YpG2OQTUmMWniPFjXHOEC9S6NXP6Ys+F4IfB/a7tDLstIKe1CLtP1YduXsp0FMfriGk4x2s5uxi9 fezWnYxH9Hk7OzkLIudLjPWOq2XFjeNrJ+zCKDTSVRkRjPN5u0HKXk3zwiE6xnkLUj6JdQxyaZJ4 KHhbTcwqNRqKxfkKm7vNt7K21lb2D8jpO2P9A0OrC8ui33QemVFzelbr7GGraw+te7hMyM09Mvtf XpzvHX9C7jJu3V1waqeLpbKTZbKlFy6ysTNJa3KnFt7Aa2NnRndSlW5dvTS//5h5xUKJVAq6dKDd 1GUAJ22AbBpSZjK7/UP7MoMpu7vEqjOFsWUDXmau5en66oHQqC/s0+0+jG9y719ZvLuZQoitO4uR MlNkr2ZSrVNbOjR7f1KSj2oYaNIZxnlIIZnqXPiFCdgbA8XO6KwizUGnpGybHpvavOWSBvE2V7+t 1Kt9ZKB35TW5htNPpNVxuthCDYaMuYex5NzOCwL1Q9CjZcpy3ZSHplaSaN67MsWOjzozZ2NicXp8 TUZraifGIaWcg1kRIX/VE1U8NKhJlCnPHofrq2z+ZDDcNRptF6fm3if4UdwVLzQsCQH571rDqX+/ d3Zs/fisF1/A2ODo4wsvyHYM/OTZpn24RJbOnmkWVDt6bqx3bto57XcO/5PkrMqIYD2fp4ceezVN FUWnHB07Pdqi0sF+MecgH5L2Z79Sy2Te5WcSi/Ox/Wx9c1PUdXNRBZ8Ic4/UvbW5xrzVew7JRDly bsd90MFbg37tOcpkWxvrvYMddwnfFy1V+ohzhuW3nJQ/uTe1LA1Bl1oq1ZrFAc9pA2R2+4ek+sHs TmASt6sbcie7QN2zwc+Ty1NNRfuoEevhxoq+NNrR1bey8cC+FrEd1tuzwz5DO6SkO3WcMZv9SXjS Y88njY+yLzVnStIZGjxkuHPlrBrZQ7ZkclbR5kh0awHbjh2b2rEVsg7i7cii8jqJHWonktEL3pHH 6WLVWjt6zD1G4oO92HcePdpJq8xXp4cWBq6HT+OjZYZi0/oSCC7dvtk3sCdcqdu1H9X2DubqG8dk XOqBlYvTaqbN58BaFJtzDMafz99iz8rT2gv7xcmZWU23zOvj7OLT/Ky7dvRFFc/vHiSqszF+ZO0E wPJIOuZE2wVC8EJq1vYM9rl+I6MJaQ0nSlie4JpeDrbOjj2D67fzbQGoY7mUM/ass6DOju6MMCyz teCIYCmSpYKmZNSUg+813x/dGBZT39sDbjQ0+VCUajsxq85oKBbnHQpY/6QM2xBrgNNscChEkYcc REJ38rSH45VmRpza85Sl8q5OTbNzMuK03i39FP2jfISXMssmXMPRZUNVAPCcNkBmt39Iqh3OrgKT 7r8yunZQC0AqQPds0AvK5Y24BZW3vYqhO3WiMRP+RAwM/r0JdRso1c/SR6UqM09i0hkaPSTdufLU v43zGm0p7KzMA5bRrem2HT+st2MDZBzE2xFFlXWaU3PRXTzI8bobfendF/UPtPfuc2PH+Ior5gRb rMe8iEgZcaZO4/0XFXllameDdgB7OiJxRH6QrX/F0g2Cq/W4K2GxsCcXlkOjThAo3zuQR80mNb0y /fgCQma+L8xcno+NOQdv8WrWurrZ2oMsQedUw/HaT871dUUm+7whWCR+XoasawfscY3QzM6eRk4L Q2rBEcFaJAv14pLQY5x/9eACG3M3uciH1hOzSo2GYnH+YJ11d3byv8g1gJh9Xt7D1pnvccTBnQj0 9zf28rSFCI+/OTbdNSsvbW56tecpU+TtHX/W2ZYTjszxvOFCN69Nz/Ha5TmkG/zjhUWJu0OpN+FU DY1Blw1RIcBz2gCZ3f4hqXicSPxehhxaCtE9G/b8uYTw6xuh8ZEflesP+UE6MeaZ6850OSW/Ks0r gerUVsYc60/EwUKGuYuVj2oYK9IZfvpijIdUormdq2GCtndFni1RzoqRAxYzj6FR2zaNTe1JNccg 3p5AqqqVe3XZvxcpA1/do2/vpHf3k+Py6jI/Qe0xHpsbIdBltiCzXGryuy3uxWk5wy/1RTPRhuM4 +cPZgVvD0UsHu/f11K/cyQg8a2fPOgsqbrUSq3ALjgixInVmbD4nm2FRpl09EC9BWJ0SNyDIh1r1 iROzCo2GYnHO77Xuc98zKdXk75Xxb9HwwV6cmWsrc+cCjLjEwl9GJXYy4u75RNtNzO3cQCB5q9av PeVtE79sfr+Fycbjv62Z6ZvaG90CZfpbLH7wj7u1ye8O+XurXtHpREpAl8+Is+bODTxqA3GiRIiR 2e0firrsyvSl8u6oxOieFWfj8olXP0yd9u44yYqF91F+SmI5oWLq+Ga885IIx38Fe7Qmcv8ovzd1 IuO7WBunelE1RTu1lTHH+BMpmSjWuQRlLWlSmdYFFZWQdIafOu5GB0Q9pFOxfwGsKEm2dTm+LRHO yjBgGdxarG37Y1PeEbyFm4sexFtYYIhmS0Ac/zo/0cpeNvF28YXlq4vzsZcuZZy2e0jrTRHJMv3B VHSZxDvnLMMurSM8v0C7Ynu1O17NwERaRF87N1VVRXIiEb7dHa+mIBOMCEg3E462KndlPKZ1OHxJ m09I1hcW9eTWFWWfsWeaBd07y8/zilitJFl840eEJIm0CU/xM+qYRZkbuyGs0VvTkQ81z2A1MQus 1BLVb0oCeef8uv8aZ3Wk/NrofedyiNia4t7JC4lJ8Z4GqY+6pui/oEL2zL0T4iXtXsySfyAvbsoF fmR28mHnkTP8GpIsU7zw1t8ajJRp4Cz9dTTEyE4k71X+BaLLZg8lAKdtgKxIyBwmRma3fygxWJWp fzmMv7ff2XMxGls2vo3NxQOJxXjmBnpI91QbuXz+gHPBxgv5q408y9/govqUuFmn+pRqIx7Gpvqv CsMWY+SQEzyS+fuIjcWQubZop7Z1aKQ/8b/YcWJ93DWwAnxUZv0amFH7zIzfuRpYfzWqsjcG0pbs nRWVkrZtamyqBsz0UhoG8fQFIUfrEZCx6GqMm+4a1+9ditPXi3ND+7xXBSmbD047xbjZow2RcopI lukPpnw6x791Ev/zA871dP6d87j3e/OxeHZsXQVyJn90LaImr1CPIfcn0uKY3Zk2qI+5cHfhTo95 RSpWNFZNeQvAfT+0UkxG48/nuiLuiBE8zOs8Mtqzspre3kyd3UpOchZEzpfEhdmDsoHEoJ86fLgq IwIpp/0gZa+mceEQtoDAnNZd05EP3Y/VOW3kzPzjNdJWaulNrzE5Hjnz3POHP/7JxlSGWkAABAoi wF3PpZ3eZbyCCkUxIAACIAACIFAlAvystYk7huJVc/x1a8Xc+ozDHlaTzwEW95VSLzm74A/H2Hnb 2+DNs5+qyNk8Qqi5NQi8+tLnPvjhj5pkESfn+IEACFSNwN4J7xwg9bc3q6Yr5AUBEAABEAABggC/ Nz7nvUGtCYTEad5a+TfFGqcmf3V26HPC8nsxoQ+hNYF0YpVVkTNRESQAAZycwwZAAARAAARAAARA AASqREB8sOAm6zs+G/pGV+N14JLc3lfWqbJBzXJOzvn5PP9ylfwSLX4gAALlEYg/OcfivDzyKBkE QAAEQAAEQAAEQAAEQAAEQAAEHAIIa4cpgAAIgAAIgAAIgAAIgAAIgAAIgEBLE8Cd85ZuHggHAiAA AiAAAiAAAiAAAiAAAiCwHQhgcb4dWhk6ggAIgAAIgAAIgAAIgAAIgAAItDQBLM5bunkgHAiAAAiA AAiAAAiAAAiAAAiAwHYggMX5dmhl6AgCIAACIAACIAAC7U+Av95812Piz+RyPmX5N8ztvlTKa8xb Vz5Jc+XW1eR/H5nZylUcMoMACOQlIBbn17yOKLqocmqHvYeem9Mfpql289pIxEtSFRnKpLIz8iFj /CMQSn4L5yK/iOj6Uy+jo368n6Vq90uYuOdpkkLNNEQT0pYAnFbE0ApR8cjs9g9Jfe1ttTmtUFSD OpADUw1fI82AfZsXWeREgX9qxZmjyOy+Zebu1EVpV2A5UWsMoNt1dklVlkL3sD+hC2S0OyrARxVI J76ogDN0k4YepuDWMLlbsSLLActgS2ZnFW4je/9Jjk2tiC63TPo47vb33IWigMYTCIxcGRa9u0/d f+Xl2bHeBknO++YJVp/od6rTXGVg2G2QNHI8ygDNEa82Mto9dTBj9yEbjj905x7SawnZZFd96uqm rDSTwLk7e2REo+ZLgaWBNrdP0ZZVGRFsZ1AsxXLAUneHZniMI5uYeJhmYlad0VAszuvPqH2yzWvP rI2+zJ3a/RvHvYdMurnwQ2vL5Ob+NDsT8pJLk4emus/LYq8PLh6KsXhDdqJMJtp1uueGFPWVmZFa vIjLEwdv9Qx5vrt/Uuko/9SHWN9OY35KJG6sJ9kFlf08O+Esk2ie1uiyJSwDOKkIWREpM5nd/qF9 maSt2htbNuCl5uJOZ7jeXfeMUw7/ukbj6yf9fbSIKHsnHHs+II1zcrc7EPKZhFvmi0cSukqpChZV uNEah5Sf4X/cD7daOjSTP4kUWJqPKopNYjkhZ6jSRx5ackusra0TpDAGzoGwJdPIGG4O0q1RTpUe m9qyEZYmvVGYD+I3L/mnDm2pbpsrpcYsPkWMH+NagMLWzOmLPReCHwb3u7Yz7LaAnNYi7D6Vp/vE NJzjtZxdjN4+dutO1iP6nJ1dLOcisyByvsRY77haVtw4vnbCLoxCI12VEcF+BkUOPfZqmhcO0TGO 8OfGdreamFVqNJRh7atrD8X/6zwyo6bvrNbZ4z4MdujurpQzeW7ukdn/8uJ87/gTcpdx6+7CCpu7 bQw9orIz8uHSCxfZ2JmkNbmjDW/gtbEzozspb7V19dL8/mPmFQtV+9bayv4BhY71DwytLiwLl2PB 09pdWicsAzipCNkKpJhkdvuH9mVStprC2KwZNyzh8nR99UBo1Bf26XYfxje5968s3t1MIdHWncVI mSmyt2hSe2u0dGj2/qQkH9Uw0KQzjPOQQrLUA0HD1GluRfbGQMlpdFaR5qBTUk6VHpuaS6mk2jt2 9s5Nq7M4wWewP+VkpSSxUGwuArWPDPSuvCbXcPqJtDoZFluowZAx9zCWqjMacUaVKct1Y0gPTa0k SX/vyhQ7PupM/4yJxenxNRmtqZ0Yh5RyjqlEhPxVL4hVPDSoSZQpzx6H66ts/mQwBpbS3azm3if4 +dwVJ9YsCYDh37WGUynunR1bPz7rxRcwNjj6+MIL0cm/PNtMOvnP19kzzYJqR8+NeR5GOBkbOasy IljPoOihx15NU0XRKQfZxPbtbr9Sy2jgZWeTi3NvYenWtrW5pj10gj0O3hq8EdwdzCacKFzO7bgP 4mWO7Wfrm3JAzfPb2ljvHey4S/i+aKnSR5wzLL/lpPzJvallubmootnF2imSOcgzddk5MxQIPKci ZHb7hySHeFstUPecrZAhu6eaivZRI9bDjRV9abSjq29l44F94WI7rLdnh32GiqcMz1GEOhYOzexP qALtGKXxUXYlFpCKdIYGD2nBrQCJtlERIVsyOatocyS6tYBXjB2b2gg335u4P7oxLFzl7YHk6Lk2 0rydVRE71E4koxe8I4/Txaq1dvSYexbC515i33n0aCdNg69ODy0MXA+fxkfLDMWm9SXAXbp9s29g T7hSt2vrVyzn6hvHZHDlgZWL02q6yOfA2vmtczbGn8/fYs/K09oL+8XZlVlNt8zr4+zi0zxUpHb0 RRXP7x4kqrMxftrpRMXyyFDmRNsFQvBCatb2DPa5fiOjdWkNJ0pYnuCaXg62zo49g+u3s20B5Ors WWdBnR3dGWFYZmvBEcFSJEsFTcmoKQfZxMZ2t52YVWc0FIvz0NGcCGgMROmoYI/7r4yuHUwd1GFs MscrzYx05GxVL/vq1DQ7p+LSu6Wfon+Uj/BSJh2bG8rsn5QRL2L5dJoNDoVShXkWpXC6cgoAnlMR Mrv9Q1JdO1stQPd0sAtO7Y24BZfb5sUJP+5fyfGvz9g5NMKfmAq05mjpo6zLy5uQdIZGD2nHLa9M 2yS/0ZbCzso8YBndmu4V48emtoLth6peYGM2751pK+3bTZk5NaHaxYMcr7vRl959Uf9Ae+8+N3aM r7hiTrDFesyLiJQRZ+o03n9RkVemdjZoB7WnIxKj4QfZ+lcs3SC4Wo+7EhYLe/IoaGjUCQLlewfy qNmkplemH19AyMz3hZnL87Ex5/QoXs1aVzdbe5Al6JxqOF77ybm+rshknzcEi1w/kZdMtQN2shFa oLNbyWlnQSJVC44I1iLZa2mYxkc3btSbCNTWlebPyYfWE7NKjYZica4H5IgzOhHo7+/h+TB5wHbG 7hpoEBEzf3NsumtW3gLdfLDOujs7czauyN47/qyzLSccmeN5w+VuXpue47XLc0g3+McLixJ3hzId m4sdXL5hKVYCl/ewdeY76zieBehsVUQhwHMqQma3f0jqaWOrhehuRbmEREL49Y3Q+MiPyvWH/CCd GPPMwhhvrJQgf+sUKc4Bor4r3qHF+hO6wESFrXxUYilFJSCd4acvxnhIVXNBA0FRalS9HM+WKGfF yAGLmcfQqFc0jU1V5xaWXwtVFZdmV6eIiNl207mN9XGvLvv3ImXgq3v07Z307n5yXF5d5jGPPcZj cyMnuswWxJpLTX63xb04Laeppb5oJtpwHCd/ODtwazh66WD3vp76lTupgefr7FlnQcWtVmIVbsER IVaknMs3w6KMbOKkdk+cmFVoNAx8So2P6+LM3PQGC/cel3MBRlxi4S+jEjsZcfd8olYo5nZuIJC8 VbvPfcul3S0Oyq75/RbmDsZbM9M3tTe6BW6G+FssfvCPu7XJ7w75e6teJVYXS7zU/JU8/gWkBJ6p HVLWDLmBp1MkQozMbv9QqG1Xpg/Iu3MYo3tWnI3LJ95fMHXaeaOpU63wPt68k5+qqZg6vhnvvOnA ie7z+1RI3P5Rfm/qRMZ3sTZO9WJrEl07egc15mJqjD+RktEFxgudVGaxKluURjrDTx13ww2iHtIp Exd6LeDaJ/FtiXBWhgHL4NZiHbU/NuUdwe11a3RK96xPHBXGvNW10WKhvgIIiDZ1fqLLeCWKt4sv LF9dnI9cz9QrlXHa7iGtN0Uky/QHU9FlEu+cs+xHVvwC7Yrt1e54NQMTaRF9HbgrKicS4b2qeDUF mWBEQLqZcLTBuSvjMa3D4cvkfEKyvrCoJ7etyNDZbbJnmgXdO8vP84pYrSR1hsaPCEkSaROe4mfU MYsysonjnLz1xCywUktUvykJHjnz3PPPz/xbHoQzUeN3cgKeSDzs5/cM3TAYvvcm17FiBsDvn59h p8UdnnPsmeHFx2dDl0lcZbTs8pEsU75vw6mrz49ZUiVfXHHSiORk9sQy3VpkjZEyPc7iVdivjbrx M86VpPCeop1I8q3aq5qComKSZ9mtnAgnPfBEw9BbNgqc5ECWSVdENSLNlrBVmZk2trJboqDy9QZ1 244PPyfnZPl+aypDDT4MGQPfvVYRMVSZBYnbpGJIs/d7pXjhqrMHZzCSqNyajbkeKalAvyMkdsOA j2oSNL3aoDN0/kV/aM2tBZRpngj2AxZpS/HOKjpgqfHadQK0VyTGpjQjePNYpq9Z84Gt1r/SK7Ot c/B+tLgvckok7nHclBZ/fLz74pqfQA6I2rxR61z65IQaN8kyPUMaOs9vaBOS6I3DS+BxoPoE2CtT JlPDrqaR6Kf8Brj38RRn6uimFBfRb++j4rrDaprH8eicR3cO+kxezhmiagoC/Ia8/pIpVcL+euBh 2ErJhgvpzo+vZi93TouPK6lBOaRXWE26Jxg7u5Wc5CyImi/5NiNf265/B8pKzmqMCIallv0gZa+m YWpETDmctZv6F693U+1uPzGjVmrN87SvvvS5D374o6b6xeL88Mc/2TzxUDMIgEAGAtzHXdrpXcbL UACygAAIgAAIgEDVCfBlkrfSa7wugcV2mdWH1aS3MIqQgJxdiGUVU6drLf2ripwtDRHCNYBA/OI8 ENbeAGlQBQiAQBEE9k6c76kfUp9LcT7BUkSxKAMEQAAEQAAEqkKA3xuf896g1gShayPP8vcBl35T rHFq8ldnhz4nLL8XE/oQWhNIJ1ZZFTkTFUECEMDJOWwABEAABEAABEAABECgSgRUAHkfD5M2fUGt UdoYY9GLEMCgZjkn5/x8nn+JsIivJhehOsoAgbYlgLD2tm1aKAYCIAACIAACIAACIAACIAACIFAV Aghrr0pLQU4QAAEQAAEQAAEQAAEQAAEQAIFtSgB3zrdpw0NtEAABEAABEAABEAABEAABEACB1iGA xXnrtAUkAQEQAAEQAAEQAAEQAAEQAAEQ2KYEsDjfpg0PtUEABEAABEAABEAABEAABEAABFqHABbn rdMWkAQEQAAEQAAEQAAEQCA7Af56c/mR0Ucnl7MXInLyb5jbfamU15i3rnyS5sqtq8n/PjKzlas4 ZAYBEMhLQCzOdzlfaNy8NuJ4NOHXvM82in6rnh++lqXLOsUGPFeKMu2zUylJPmTt9g+ty/RGiAC6 FLpna117YmT5JEYDW/7VDWUbFt5cfoLSHcC8jI5pxQ9sVO1+CdpXvktnm61F8uQK9EqnE/lqajz9 JhBZZEr+qRWtR2uTDNoy84jZ/LzWdpvGSAJG6+oYelh5mOFebBgImDVhDiqNZ2i+7UCC9iCgDyul f3e6PZC1phaBkSvDonf3qfuvvDw71tsg7fiIcILVJ/qd6rQRgY+/2vykQeJ4E4BM9dVGRrunDmbs PmTD8YcuBDn4igaVXfWpq5tSxEwCo7Nnal5kqgoBsTgfunnJW3UPnedOTf5xvnO4NHloqls9vD64 eCito+Hd8ml2JuQl7csks29ee2ZtVAp54zirP6M2+ciUhsUnkZ0sk3xoXyaTI0REzlw8E+2qDOA0 W7FEme65oaxlZqQWL9ryxMFbPUPeYNk/6ZiZyF4fYn07jfmp2rmLP8kuqKrPsxPOutS+vRIxtkgC PmgN17vrHis5/OvdZ3z9ZMyW2d4JB+8ByWpytzsQ8pmEW+aLRxJarkVQxIthMPtczkdMIAJGq0SI PKS6eSWgCSFNvZgYCEiYxENjmZWBAkErSWBp0hsU+JiizWoqqc12F1qNWXzaGT/GtQCmrZnTF3su BD8M7vtPZ9htATmtRdh9Kk/3iWk4Z+ri7GL09rFbd7Kc96kJPzq7dYMiYRUJiMX5fO9gv2mCvrw4 3zv+hNwR3Lq7sMLmbqcLE+LLg8jsP0WZVHbWeWRGLTNYrbOHra49FH8lU5ItQma3f2hfZjBld5dg nEL3bOZUBnCS7dILF9nYmaQ1uaME96RrY2dGd1I6bV29NL//mHmJSNW+tbayf0DZAOsfGFpdWBY+ nmzEbBhbI9fydH31QGjUF7jcLsn4Jvf+lcW7mynE3bqzGCkzRfYWTUqaaM6+QBptnCULNqqbV+Zn 34utCTP7MiuDCYJWgUDHzt65aXUWJ8ZZ86ymCspARodA7SMDvSuvyTWcfiKtjtPF3mIwZMw9jCWn Gl4QqB+pFy1TluumPDS1ktQS965MseOjzmzEmFicHl+TwYPaiXFIKefoS0TIX/VEFQ8NahJlyqiu 4foqmz8ZDHeNRtvFqbn3CX7udWUpSfXYf9caTqW7d3Zs/fisF1/A2ODo4wsvRBcU8kg8KVwCnT1X 4yBz6xMQi3P92DPUpbc219R0k/uLg7cGx/az9U05+OX4FVimKMpbpKUXicxu/5CsMJjdCfLh6G7I jdUCdbdXt5RKtzbWewc77hKDTVQw6ZTPGZbfcir/pICT7ndzkQ9aAilfrEZy5jSMdJKUltrTQsVR qxHr4caKvgLc0dW3svHAXgSxxdbbs8M+Q3ultO8LpNEaLDnczSvDzNyLw3M7e5XSeAb7UpESBJII 8M3Z+6Mbw8JV3h5IDuZKKg7/3hIExA61E1jnxSjJ43Sxaq0dPeZuzfOpgNh3Hj3aSYvNV6eHFgau h0/jo2WGYtP6Eigs3b7ZN7AnXKnrP/Ubf3P1jWMy1u/AysVpNXvh82otis05c+LP52+xZ2XgwIX9 4jzMrKZb5vVxdvFpHgBbO/qiiud3j+7V2Rg/snaiTXmgInOi7QIheCE1a3sG+9wpVkYz0BpOlLA8 wTW9HGydHXsG129n2wJAZ8/YLMhWFQLyzrmz9SjM3Q/D1iLYHQ8yM9JRnFoFlMnjSyPRRCkEJLPb PyRrCmdXccX3XxldOxi88Ss8cqE8ExUvAHiojtWpaXZOGky9Ww4M9I9yyl7KpGNzQ5n9kzeOr52Q 69XTbHAolCqnYSSibHgCb8RteM3tWWFyXyCN1mjJdDevBjuiFxsHAluNLD2DbXFIBwI2BMTNVbXU ucDGbF6DYlMo0jSJwJwa33fxmLvrbvSld83YP9Deu8+NHeP7zjEn2GJX2gvQkxFn6jTefzuGV6YW 3mine09HJFzKD2v3b/y5QXC1HnclLBb25MnE0KgTk8j3DuRRs0lNr0w/voCQmW+YMpfnY2POYUa8 mrWubrb2IEvQOdVwvPaTc31dkQUEbwjmX6p1JJd3HrUDdrIR0NntbBOpKktA3jlfnQrFlohtM9kz Rdz4zbHprll5BX3zwTrr7uzMqWwhZYqzRHHnxN9rTCUVmd3+IVlXnEg89Lo0nomKFwKcqKV3/Fln H1SMHM5QF063eW16jpuQPPh1o628ODRxWSvTsbnYMuc7xGLj4/Iets780TGnYSTCbGQC0XDrG6Hx kR+V6w/5QTox5pml1G6CNFKVVqnLri+QRvvpizGWrPRzu3mraGsjR2wv9gYCm5L8NFaeIV2RSA0C CQS0Czvi0mxkVgOAlSLgXl3270XKK0Xu0bd30rv7yXF5dZmH4PUYj82NmtNltiCoXGrya4C9487r gcSsqdQXzUQbjuPkD2cHbg1HLx3s3tdTv3InNXB09tTIkKFiBMTifD3yOi5+i2ZFXdkS0003aEfe gN3X716AEZdY+MuoxA5W3D2fKBCqTCeV1W0TIYA4M7dcmUfKJLPbPxSi2pXpq+5dgYvRvTzLyQ2c EI1fKGLuns7WzPRN7Y1uATj+KZwfbeXuJQszi942t7MBVyT+Ejj/xlc6wygPeFEli+v0U6edN5o6 hYr1kjfv5Ge5KqaOb8Y7F++d6D7eT+lf/+hY79yJjO9iLUqx5pVj1QFJo/3UcTewKGrJrvuq2k3X mF4sVfIHAvsWSyrTviSkBIGUBNyzPnFUGPOS0ZSlInkrEBBt6vyEX/JEEm8XX1i+ujgfe8NRxmm7 h7TejIUs0x9Mxewi8c45y3jCzBXgF6dXbK92x6vpTs4llc6O7uD9UzmRCN/ujldTkAlGBKSbmEUt ho+qPMRyOHyZnE9I1hcW9eS2FaGzt0K3hAxlERCL8+7zaiPN/4LOifXxG84Kau+EeEm7F1+U9qRa 3cb0X1Ahe6axTHEjNPCjsovjVu4wvSgd/atRoYpEWeEyyez2D6V4VmXqH7LibzUvhmeiHZQA3FEk xLbzyBl+70sahnj/vL8XG2lEg8xygIzGdFnZgG+rw6+N3ncuMtGGkUislRPweGkxnrlxB3K6WRu5 fP6Ac6XNC/mrjTzL3+Ci+qm4Waf6qTIGHsamOot634wYI4ecWIbM30dsNWik2afrC1lV0j4e43fz rIU1Oh/Zi8mBwJ6w0TM0WjnUt60IBHxgYEjaVhjaVlkZi67GuOmucf0umzh9vTg3tM97c43yYMEZ ixg3e7QhUs5YyDJ9Q+KzC/4pmfifH3Cup/PvnMd9So2PxbNj6yquMPmjaxE1eYV6DLk/ORfH7M60 QX3MhU+53dma9+HbWDXlLQD3nbtKMRmNP5/xirgqwhEjeJjXeWS0Z2U1pdmis6cEhuSVI/DImeee P/zxT1ZObggMAtubAF8sXdrpXcbb3iygPQiAAAiAwDYlwM9am7gxKl41x1+3lvbgKn1bhdXkc4DF faXUS84u+MMxdj7xNnh6vZADBLYlgVdf+twHP/xRk+ri5Bw/EACBqhHYO+GdA8TtzVdNLcgLAiAA AiAAArYE+L3xOe8NaraZCkwnTnHXyr8p1jg1+UdJQl+3ld+LCX0IrUCCKAoEQCBMAItz2AQIVJOA fKmp/FP+nn01CUFqEAABEACBdiUgv1Le/EUjfz0t/0BA0qe5szdCQ9WUHyWRb4D2f+r9u6EPoWXX BzlBAASSCCCsPYkQ/h0EQAAEQAAEQKBdCLzlwcbbf2X+bfylV1/72puMPfLII6k0e/PNN0WGd77z m13df/GjQ290dKXKjsQgAAIgAALbnEB8WPtb9z0++H3/465tzgjqgwAIgAAIgAAItD2Bt7/863+p /i/eurb6yNe+9shffOORr38t/Z+vv+Ub33jk//6Tt65/6e2vLL/5nu96Y0fkG85tzxEKggAIgAAI ZCXw3x9+6Tt3fNCUG2HtWbkiHwiAAAiAAAiAQHUIvHVr81suf+bNb36Tfdu3v/mOd7z5trext789 wx+ekWfnhbBvfpMXyIutDgNICgIgAAIg0HwCH/grzPQHi/PmNw8kAAEQAAEQAAEQKJsAj2Z/5M/+ lEek89D0/HWJQt75Tl4gLzZ/aSgBBEAABEAABDgBLM5hBiAAAiAAAiAAAu1P4K2vrbFveSdLXJkn JvBQ8ZTf8k5RLH4gAAIgAAIgUAQBLM6LoIgyQAAEQAAEQAAEWpwAfwNczOvfXn+dqT9vvOH8hf89 aaEuCvza11pc720lnny9ufiT9w3q/Bvmdl8q5TXmrauJLaSryf8+MrPVRGFQNQiAgDo5v+Z1xOUJ 5dF26f7If/jorrNL6aFtXhuJeEnhC1RFh/3a6aLts1MpyTLJ2u0fWpfpjRABNVPonh62yGFPjCyf xGhg69mGhTeXn8p0BzDdqJIHUap20lZLZ5utRfLkcnQPTDV8NTWefhOILHKisDTp9LJwp6YtM4+Y Tc9rbvqA4XE50xhJOK9UM/Sw8jDDvThgcprPL8szNN12IECbECAHhZBuppU5X4Hzdfi3fivr72cf +xg7cYL9o3/EhodZR4ezUI9nlPJ9720CvCw1AiNXhkXv7lP8C6OzY71lyRcql48I/PNjE/3OY21E CM6lGySONwHIVF9tZLR76mCWqX54yuE2HG/NiXtKFjn4iueyqz51dVM+zSSwTWfPBACZQKAVCIjF +eIh2XN4tznJLqgvJ59nJ5y5/tKk9/Dl+tDNS0lr6ZBSvFs+zc6EvOTS5KGp7vOyouuDTu00DDL7 5rVn1kalnDeOs/ozapOPTEkWSma3f2hfJpMjREROW92zmUcZwGm2Yoky3XNDGczMSC1e3uWJg7d6 hrzB0v9GN89eH2J9O435qdppWyUbMRvGFsnFB63henfd/Z75fTn8691nfP1kzPbW3gnROhzvAdmv 1efQxUAoPmTqfCP9xSMJLdciKOLFMDd9yPAC9OKdj5hABIxWiRB5SHXzSkCTkyVDLx5S/pn/cT54 a3AshHs3llkZKBC0igToQcFOE35Ozv/s3cv+xb9gx469+QM/8OZ73vNmVxc7eJD93M+xj3+cvfvd YumOX+MIqDGLTxHjx7jGCWSsaWvm9MWeC8EPg/v+0xl2W0BOaxF2n8ow1fdKj2k4Z+ri7GL09rFb dzIe0efp7NYckBAEmkhALM5X2NxtvpW1tbayf0BO3xnrHxhaXVgW/aZjZ+/ctNrfWl6c7x3sTzeV 58uDyOxflDP+hNxl3Lq74NROM6Cys84jM2qZwWqdPWx17aH4K5mSLJTMbv/Qvsxgyu4uQS6F7tms ogzgJNulFy6ysTNJa3JHCb7FszZ2ZnQnpdPW1Uvz+4+Zl4hU7bStko2YDWNr5Fqerq8eCI36Apfb fRjf5N6/snhXdk/L39adxUiZlllbOJmp6SOGl6IDkkYbZ8mCj+rmlfnZ92LSCeT3DJUhBUFbnQA9 KFhIzc/M+Z9Dh/iB+Ztf/eo3z59//VOfev1nfub1kye/+VM/9frNm2zPHvYzP8O+8zuwPregWXSS 2kcGeldek2s4/URancqKvcVgyJh7GEtONbyATT8EPVqmLNdNeWhqJUmhe1em2PFRZ+ZsTCxOj6/J 4EHtxDiklHO8LCLkr3qiiocGNYkyZVTXcH2VzZ8MhqZGo+3i1Nz7BD/3upIhTlbTX2s49fTe2bH1 47NefAFjg6OPL7wg2zHwk0fiCeESmTt7Umvi30GgRQiIxfnYfra+uSkEurmogk/EAsARkM96749u DAufcnsg+YDUQq2tzTU1heU+6OCtQb92i7yhJKIob0OhoOxkmfYVBVM60VlczRtyY7VA3e3VLaXS rY313sGOu8RgExVMOuVzhuW3XB48KeCk+xG26hdg317pKm1sak8LFUetRqyHGyv6CnBHV9/KxgN7 ucR2WG/PDvsMVUupN33U8Oz7Amm0BksOd/PKMDP34vDczl6lNJ7BvlSkBIFkArGDgjE7PzPny+8f +7E3bt9+/ezZt3zxi2/7sz972xtvvO0b33jrl7/M/t2/48t19v73s49/gr31reKAHb9GEhA71E5g nRejJI/Txaq1dvSYe4zEZ1di33n0aCctHV+dHloYuB4+jY+WGYpN60tQdun2zb6BPeFKXf/5qLZ3 MFffOCbjUg+sXJxWM20+B9ai2JwzJ/58/hZ7VgYOXNgvTs7MarplXh9nF5/mYa21oy+qeH736F6d jfEjayfalEfSMSfaLhCCF1Kztmewz+1NGVtbazhRwvIE1/RysHV27Blcv511CyBbZ8+oDLKBQKMJ /P8BFl8PCBK7weoAAAAASUVORK5CYII= --_004_7335E3E9AC2DE240988251CF62CAE90A0A236CE0CNMAILEX03lenov_-- From nobody Tue Aug 21 05:34:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28D9130DDF; Tue, 21 Aug 2018 05:34:49 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains application/pgp-encrypted,.asc X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENCRYPTED_MESSAGE=-1, 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 y4FDIIf13mxG; Tue, 21 Aug 2018 05:34:48 -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 9B9EE130DE9; Tue, 21 Aug 2018 05:34:47 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 1A45D340F3A; Tue, 21 Aug 2018 14:34:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.17111); Tue, 21 Aug 2018 14:34:44 +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; Tue, 21 Aug 2018 14:34:43 +0200 (CEST) Received: from [193.224.45.73] (account ietf@trammell.ch HELO forclaz.vigado.local) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 64779757; Tue, 21 Aug 2018 14:34:43 +0200 Content-Type: multipart/encrypted; boundary="Apple-Mail=_F6CD56F8-6403-44A7-8FC3-77F48A1CC83F"; protocol="application/pgp-encrypted" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: ***UNCHECKED*** Why measure RTT passively? To: tsvwg , QUIC WG , IETF IPPM WG X-Apple-Base-Url: x-msg://38/ X-Apple-Mail-Remote-Attachments: YES From: "Brian Trammell (IETF)" X-Should-Pgp-Sign: YES Date: Tue, 21 Aug 2018 12:04:11 +0200 Message-Id: <618E26AF-35A2-448C-8082-DDB427269138@trammell.ch> X-Should-Pgp-Encrypt: NO X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 12:34:50 -0000 This is an OpenPGP/MIME encrypted message (RFC 2440 and 3156) --Apple-Mail=_F6CD56F8-6403-44A7-8FC3-77F48A1CC83F Content-Transfer-Encoding: 7bit Content-Type: application/pgp-encrypted Content-Description: PGP/MIME Versions Identification Version: 1 --Apple-Mail=_F6CD56F8-6403-44A7-8FC3-77F48A1CC83F Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=encrypted.asc Content-Type: application/octet-stream; name=encrypted.asc Content-Description: OpenPGP encrypted message -----BEGIN PGP MESSAGE----- hQIMA7MdurcgXtzeARAAiTFas0wHGVg4tibSbQNhvWTr8tTffSgKY6mpXAhhwECo wLOx8DlgGtrQaWlpB4ipeu/uOfGM4y3fzgjqMDs8EW8BV5Rf36wHDehZtPwpmcZR hUYc34O/dZWcubp4QWIazhAmMl+vWmUnDcMMMLdL2w4b7xclW4v5f0hlF2Fr7FKc Fq+2/rPVbS5tk98K0KeUCHqo7bHSCzbXHj9JpyaPk3AzRO4MaWfE9zmSGOU+Rrst skyyOe160SQqwXBS8aq3Ge5z6VRQgAxrC340rzW84B7nftxwWg2oD6XWJ7g3kpby SWqgaPIeHrJERUQL9yVOsfRPdbfEBT8N+mpbYbZCGmswyPoomkLNSoP39a6950eV Ry9s5Ui3azzxnRnZ+zCfEtziAgJin6PKc7G3mad81dmURBUe+nSTVpt85NU+blg7 29VApnJUSiwA4gNuTUHDyitc8hwJjQUQYYmk40zwwsoL1F07edZ4Vq3PiLiG4hQy 3NyyZ00BmNBD+/SgX6LVIAb/GxikLA46LsKmFwAVIEG8Ihct+NU57ykcfBoRoApN QvpfiaJNOpTi4+zHKCXbW1GvUf3ai1JyRBWD8IMW9XdnqGfou4mkZ3hqGK+tcWpS anOhAww/L8X9S7ys+JzostpCNeMil304VSM0+0T4frQMZsxh6mO3dYxLBJ1cVxzS 6gGQlu35taRbXO67kIkBOcnU4BAbuyYxvimcCtKWE4KIO7tpPeHY2Xnt/wGHdz01 wMaSo6sE7Vk47bxVTsUfLp1z6urKQTHBiroehRF+maHQNghpZSI1TI9Z46sLzvh1 bxSefgfQDS/SJj4IV92W1xcjUhmJfsmcTDJwE9j3HcWbvAU1zf8Brq/AjH0nH4YT kgB6E3/mCZLNL8Qvqwwk0ZTZrQ0iN7TlY7nX9CNpeEc9sMVDgHTiWegkS4+yC1v9 DPjd5tPFbprYRBdDv/Yj3cOwC1VJ0EN6goTmhRAqeeo7v5fpOdXPfUGh8SJtJt6u N8NochNfF1AHh9TuIi7XDV3FbMgAoW1sHJWMUFCDDnEoYgGjHPDwsIeiLe3fr5wb UT+Gy+ND4rS+iARjLR7llCHVYmHALk34Cv5FKqaT1aMeg53VBcFYYyOgOJF3tbEK E/VOnUafQOio80yY1GGYURJYcxU4yEHomHek6owEHHOmNydx70c/LXbaOZpBmmfq o/2tdVQBQ1XHa690euFqMt0tQRRSlynEzbBX6YbaC8AQhCejO5GNq/1KQooXy/wa quDe5SVj58r/ach3lUFowz4U2Sn+dV8rPu5gXqaTKJy4g4k1vEwextGknJ/wXPsC nx+c0epn1Pw7LcMjr4Dqhdru+PWXWubQrG+NPIOesEjzkkTjwE0yEWqoXjvLpVAb VimPxtFHtF2Fs/ohf1UGTvhzBVk90tTSv/jvy9iQXDFkOILld7RmVVVY8VLB648e Uu/Z8zntGhRL2dBZdWceosyWKHScdJSkk1OvzJgeSzDW0cXV+z2kMxsWj21O3pM2 c7ksDmJ+jlxAQrEUY5rvPSo+OVSWKU5jdduOfA8btWc9epeZ9l948EhVyRDWsO0Y l/TU6TJKXNZhfN6AAyjLcfe76Fdd3KU8TAb/EkUn/SifbJOvOCAC3l/rQ0PFh4BY 8OziNwpytGkO94rnvQHj/fIrANN0eSMljcAipHwWz8IrV7Y75sTfS2UG7wRuuweE 9dZ2D046+Y/IMH27Dquu5IbrvFSSYMKvgkWxe/Ompxf1RLpvE3cfh+RLNhxT+hj+ iv5eNDWJyl8WpKq2NoBYrhAevMf87Uat8B0km0YsFzYxhaqdof85hv1I+ODcXgtW U75hN6TcXHyWsxW/aie5WcHdYolEYsitZtO3iz9ajCnEEwFr86jOdmly4H2qdFyh fjl4bBrcXBSOHSwvqdS+CAfb/D9Rbg9Si6IRcJgXTc3leqoi6Gslxc24tQ92p9hs 63K+dQl3ZrvxpIXXAJ0dXbRi+3DRn4Q0b7fJwCB/Yxx2J+Jtb5U7QdKSTPV97yic QXPviQq8CN+ye+rtL9+AppUsqv+jj1i5VeT9WaCjOAA2qrz60pf4yOuKyKacrsVV UgWqfi9te0D4Lgce1+4= =h9yu -----END PGP MESSAGE----- --Apple-Mail=_F6CD56F8-6403-44A7-8FC3-77F48A1CC83F-- From nobody Tue Aug 21 05:43:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E278130DDF; Tue, 21 Aug 2018 05:43:04 -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 xMppxXFnQDQE; Tue, 21 Aug 2018 05:43:02 -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 C47F0130DDD; Tue, 21 Aug 2018 05:43:01 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 443F7340F6C; Tue, 21 Aug 2018 14:43:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.20476); Tue, 21 Aug 2018 14:43:00 +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; Tue, 21 Aug 2018 14:43:00 +0200 (CEST) Received: from [193.224.45.73] (account ietf@trammell.ch HELO forclaz.vigado.local) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 64780943; Tue, 21 Aug 2018 14:43:00 +0200 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_2E6684CA-F227-4B66-9E65-F7546DCC9C3C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Why measure RTT passively? Message-Id: Date: Tue, 21 Aug 2018 14:42:58 +0200 To: tsvwg , QUIC WG , IETF IPPM WG X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 12:43:05 -0000 --Apple-Mail=_2E6684CA-F227-4B66-9E65-F7546DCC9C3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, TSVWG, QUIC, and IPPM, I've just submitted a new I-D, "Why do we need passive measurement of = round trip time?" = (https://tools.ietf.org/html/draft-trammell-why-measure-rtt-00), which = may be of some interest to each of these WGs. :) It presents a set of = use cases for on-path passive RTT measurement, both generally, and = specific to the facility described in "A Transport-Independent Explicit = Signal for Hybrid RTT Measurement" = (https://tools.ietf.org/html/draft-trammell-tsvwg-spin-00), or the "spin = bit". - For QUIC, this draft addresses the second half of the risk/utility = question raised by the spin bit and spin+VEC latency signal -- much of = the content comes from the original QUIC spin bit document, but there = are new sections on using VEC for loss/reordering proxy metrics and = exploiting correlations between RTT and other metrics to drive intraflow = diagnostics from only RTT signals. In particular, I'll talk about = ongoing experimentation along the lines of section 3 at the interim in = New York. - For TSVWG and tsvarea, it addresses some of the "why design wire = images" questions raised in the tsvarea meeting in Montreal, with = respect to the specific tasks for which RTT data is useful. - And for IPPM, it gives a bit more background on the "passive RTT" = metric in the initial registry document. Feedback is much appreciated. :) Thanks, cheers, Brian (as an individual contributor) P.S. apologies for the resend: the previous message was not an obscure = joke about ubiquitous encryption: apparently the interaction among my = MUA, its bolt-on GPG, and the somewhat underprovisioned network in = SIGCOMM led to an encrypted draft being posted to the list. :/ --Apple-Mail=_2E6684CA-F227-4B66-9E65-F7546DCC9C3C 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlt8CNIACgkQihK3vwvq RqMRexAAq3lkEF35Bd08h2eF6u0Kvo8TIuGHv8Vhh1sbVBzrailDcbZC4gO3aPyc G6UdHpRj60+bWo7oMRkG/3zih4AEY7QgWdkjkshAg+aWdSvjb9x3x+X5XPVlhbSl sxmrzsMyWfvY4bJxmmhLdED81C34XFGg+4VUXtXdodUMUwkA5d4KrVtos2IYPkWp Fb8saTizc5REf72U45XMWvWPTv4wFsddu9wWSd8dY6f+SYLQrHAzZjPV9eJocVXS WphvdbovLd93pRgXytbevIDVcCnPrK4as6STiVxBJnHxC8/Ze9QY1i7+l8uE0ya3 cq7/Wy5Vz68W+2aJ1hwQKALfLZocO0fnnmjQFBhppaAjzSwAKVvcZ6fvNIzfCybF aXyCcGJ/SCKC68k3NmZFwuVAA1+h8twedDvqp2zvgMXwIClR8EP1jlu6qIzGviI6 dx8crvj5JwMmcKjdbdgC97GltCv89mp1L2PQidJ12jlrqxMjh8lFRdjLN+RMmCWO 2ItiBEUP1XRxU8GMNKYzsV/W5HF/vox48YTTMBXJsF1uxL8hV25MojXrtq7GSCnb Q72QYnblbjVGTz43k4xsuQ5uBn8gt+PUDuNx/FAAEKAA5qv5V5fHrE9Y3OTz1lFA 3V0EkRNOsx5CRPml+GTHTIFGArYz8Lk8ZucJ4f0nXNQcjy13pGw= =J4d3 -----END PGP SIGNATURE----- --Apple-Mail=_2E6684CA-F227-4B66-9E65-F7546DCC9C3C-- From nobody Tue Aug 21 06:44:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5922B130DE6 for ; Tue, 21 Aug 2018 06:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.953 X-Spam-Level: X-Spam-Status: No, score=-16.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWrO17ig2186 for ; Tue, 21 Aug 2018 06:44:38 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28821129385 for ; Tue, 21 Aug 2018 06:44:38 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id y20-v6so3224045ybi.13 for ; Tue, 21 Aug 2018 06:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H/RPH3sJuM3MrAxI1/aqrMHzCGeTSFmfBMClzdD2LFI=; b=k4Wf7N69FIIedb6qZD74KKS0NaOeMrxahUOlx9vHNg/lrBIpxfxdkjv2Ck8Ct44Yl0 ucMp5zQgaqiOujow6e2nUUiw1Iu8+2f1ydRRcsb3Yw47JQXh8lDxduTkUkfE53CLmicT RfL77s4re86fYaiPyeKldDv1WVtc7Eg537d14/DqkDNozAG3dSyiZAfCFAiv7S0v7cPx 4bPYCzIB9cYA2weDHVpxYonwwpq+F0Qj5nwfRKlA/WFcVkb1ZacIQwTUqK+kBnq4AF2G jx8iY2i7U3RuH4BIIalEszm90f6GTUZQpcjypzPfns89x9F3LGxWeNTUNrRqIBkN0R1G x5VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H/RPH3sJuM3MrAxI1/aqrMHzCGeTSFmfBMClzdD2LFI=; b=otWPukqcLD6wrzVR0OroEmwBrzyc0LgXHxTUI5e/tGcYJF4e1zgb35CTp08o8EUPp/ n3/GX/Vb63jaeWduLI4E2zt8JOaZiYVtzDRI9ShLV8o8hAHzNeBQoEVs72/Vhl+62uJA gfAoZWQqZ+loHUyOrAV1ixBAMr/IuGReY9Kw1oKS08MqxKYl/JWH8JAcDFAMea6Fjtm4 Le7wnwkX+7KA+Uwg4KlyLJ7DpzZTBeqjlpSB7MzRLvnxSHfg5K9pR2BQ7aVm+1rtZ5Aa u9gy3Dj3wy+JByZ2ailSdxgQ0ApIFZ4uB2I3iZLOfLe1hE/ewjd/1eVtF7qPeVhczLGS rt6w== X-Gm-Message-State: AOUpUlGWNfNHLKhzERT6G7ZbCbwsLRB+HI09xzBYtgrt8U2T3Qvz+o7I H/siv5X0VeYw7mTJ0ocNLF5bYiRlRwULUl5PrffBDQ== X-Google-Smtp-Source: AA+uWPwpTWFQw053fsFa9dg86fRT7r9ZJPty3Y6IfpXqBJIvKU9FELoMg4z49mCsmUorHrxHwraC70/8J5NkhBrnINo= X-Received: by 2002:a25:4f55:: with SMTP id d82-v6mr21918730ybb.6.1534859076385; Tue, 21 Aug 2018 06:44:36 -0700 (PDT) MIME-Version: 1.0 References: <7335E3E9AC2DE240988251CF62CAE90A0A236086@CNMAILEX03.lenovo.com> <5DFAC0AB-2135-4792-A3A3-54D7D35B942A@lenovo.com> <7335E3E9AC2DE240988251CF62CAE90A0A236CE0@CNMAILEX03.lenovo.com> In-Reply-To: <7335E3E9AC2DE240988251CF62CAE90A0A236CE0@CNMAILEX03.lenovo.com> From: Ian Swett Date: Tue, 21 Aug 2018 09:43:33 -0400 Message-ID: Subject: Re: [External] Re: Same packet number in a QUIC connection ? To: changzhi2@lenovo.com Cc: quic@ietfa.amsl.com Content-Type: multipart/related; boundary="0000000000000830be0573f23aa3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 13:44:41 -0000 --0000000000000830be0573f23aa3 Content-Type: multipart/alternative; boundary="0000000000000830ba0573f23aa2" --0000000000000830ba0573f23aa2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The CID from server to client is only dropped after handshake completion in the current gQUIC implementation. On Mon, Aug 20, 2018 at 9:15 PM Zhi Zhi2 Chang wrote= : > Hi, Ian. > > > > Thanks for your reply. I still have a question about that. > > > > In WireShark, I still find the server to client packet have a CID. Like > this: > > > > This is rejection packet which is server to client. > > > > Why this server to client packet has a CID? Because this is a server to > client rejection packet ? > > > > > > Thanks > > Zhi Chang > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Monday, August 20, 2018 7:30 PM > *To:* Zhi Zhi2 Chang > *Cc:* quic@ietfa.amsl.com > *Subject:* [External] Re: Same packet number in a QUIC connection ? > > > > Yes, the client to server packets have a CID, and the server to client > packets do not have one. > > > > Both client and server send their own packets numbered 1, 2, 3, etc, so > seeing two packets with the same number is normal as long as they're goin= g > in opposite directions. > > > > Wireshark very helpfully parses the flag indicating whether CID is > present, and if so displays it. > > > > On Fri, Aug 17, 2018 at 7:17 PM Zhi Zhi2 Chang > wrote: > > Hi, I have a question about " packet number ". > > > > I set up an environment about QUIC and I capture some QUIC packets by > wireshark. I find an insteresting phenomenon by watching these packets. > Please watch this picture: > > *=E9=94=99=E8=AF=AF!=E6=9C=AA=E6=8C=87=E5=AE=9A=E6=96=87=E4=BB=B6=E5=90= =8D=E3=80=82* > > > > In my environment, the server is 10.121.222.230 and the client is > 10.116.47.192. Why there are two identical packet which the PKN ( packet > number ) is the same ? Just like two " PKN: 2 " packets, two " PKN: 3 " > packets. > > > > After my consideration, I find that the packet which client to server has > " CID " and the packet which server to client has no " CID ", for example > " PKN: 2 ". > > > > This is a pair of packets which client to server( PKN: 2 ) and server to > client ( PKN: 2 ), isn't right? And the packet client to server has CID a= nd > the server to client packet has no CID ? > > > > Am I right ? > > > > > > Hope for reply. > > > > > > Thanks > > Zhi Chang > > > > > > --0000000000000830ba0573f23aa2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The CID from server to client is only dropped after handsh= ake completion in the current gQUIC implementation.

On Mon, Aug 20, 2018 at 9:15 PM Zhi Zhi2 Chan= g <changzhi2@lenovo.com> = wrote:

Hi, Ian.

=C2=A0

Thanks for your reply. I still hav= e a question about that.

=C2=A0

In WireShark, I still find the ser= ver to client packet have a CID. Like this:

<= /p>

=C2=A0

This is rejection packet which is = server to client.

=C2=A0

Why this server to client packet h= as a CID? Because this is a server to client rejection packet ?

=C2=A0

=C2=A0

Thanks

Zhi Chang

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Monday, August 20, 2018 7:30 PM
To: Zhi Zhi2 Chang
Cc: quic@ie= tfa.amsl.com
Subject: [External] Re: Same packet number in a QUIC connection ?=

=C2=A0

Yes, the client to server packe= ts have a CID, and the server to client packets do not have one.<= /u>

=C2=A0

Both client and server send the= ir own packets numbered 1, 2, 3, etc, so seeing two packets with the same n= umber is normal as long as they're going in opposite directions.=

=C2=A0

Wireshark very helpfully parses= the flag indicating whether CID is present, and if so displays it.<= u>

=C2=A0

On Fri, Aug 17, 2018 at 7:17 PM= Zhi Zhi2 Chang <changzhi2@lenovo.com> wrote:

Hi, I have a question about " packet number "= .

=C2=A0=

I set up an environment about QUIC and I capture some Q= UIC packets by wireshark. I find an insteresting phenomenon by watching the= se packets. Please watch this picture:

=E9=94=99=E8=AF=AF!= =E6=9C=AA=E6=8C=87=E5=AE=9A=E6=96=87=E4=BB=B6=E5=90=8D=E3=80=82

=C2=A0=

In my environment, the server is 10.121.222.230 and the= client is 10.116.47.192. Why there are two identical packet which the PKN = ( packet number ) is the same ? Just like two " PKN: 2 " packets, two " PKN: 3 " packets.<= /u>

=C2=A0=

After my consideration, I find that the packet which cl= ient to server has " CID " and the packet which server to client = has no " CID ", for example =C2=A0" PKN: 2 ".

=C2=A0=

This is a pair of packets which client to server( PKN: = 2 ) and server to client ( PKN: 2 ), isn't right? And the packet client= to server has CID and the server to client packet has no CID ?

=C2=A0=

Am I right ?<= /span>

=C2=A0=

=C2=A0=

Hope for reply.

=C2=A0=

=C2=A0=

Thanks=

Zhi Chang

=C2=A0=

=C2=A0

--0000000000000830ba0573f23aa2-- --0000000000000830be0573f23aa3 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <1655cb997894cff311> X-Attachment-Id: 1655cb997894cff311 iVBORw0KGgoAAAANSUhEUgAABTQAAAFNCAIAAACxF3dDAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAA4xFJREFUeF7t/Qt0Hdl534nu1stSrmUntmI7kngAEJBg3LHTiT1W2CJMik7D g1CgkSznkgzD6UYvYyTRvAsKxDBux2AzTcJuJlwUOmdCU9EgIdjD8DYZe/nCgBjIoE2CBrt7FCcj erwujBbQAEFZseLEz7Etyeruux/12FX17apdr3NOHfyPuWR2cT++77e//e3Xt6se+cM//EOm/X7v 936PP/nV//ytV35x480332D8D3vzzTdfF/8j/s6fvPmWt7x598ZHf+s3f+MHfuAH9Lz631977bXv /d7v/epXv2pKwJ9/93d/92//9m/v3LmTTPMnf/Inf/7nf/5nf/Znr776qkrwlre85f3vf39nZ+cf /MEf8PL/9E//lD/cv38//3utVoupaHl5+Tu+4zs+9KEP3b1796WXXlpZWeHKdHV17d69e9++fb/x G7/xR3/0R/39/WQJDx8+3LFjB/lP3/ztf/CdHYOKifhf9qbCpf73d19b+p6de/n/vuuv3zDJxuXh 8n/jG9/gan7bt33b1772Nf6XN9544z3veQ//u1KZ/+edO3f27NljKuQzn734u//19776X3/vmX86 9r29nX/8x3/2R3/4J2+88XpH5/v++I//9L/999//Z5P/8tu/7d3vf+97P/Gx4zGF/NTJn/z61//s j/7oT77ru/5KqBDe9O94x9u/+Rev//y/vkYWEkPJVONTH/v4axubb3/72/7d5cvf/d3fFdN80X/6 kz/543e/+9tSZTHYWOpy3njjm5b1vuUtb0tMydvuH3/qp9761rfylF//xtf/13/1L/+Xn/h4Yq5Q At4RfvGXbvxw/97XX3/9C//xlb83/Pff9a53mQqZ+e13/I33vO7961//jq+HUn71D/782L+896d/ /k1u0/z3CGP/j3e97dInd3/1zb+sUn7xv7115Hu/wf+iN3pisSZ5fvP3vyWmWHsU/+7F65df+N95 V/qWb/mWX5n/5Uce4YKn/jWyEN2QZl64fOTwkXe8w0Hx2el//bFR3wxsDCm1qsgAAiAAAiAAAiAA AiDQegQeCS3Ov/SlL/E188qDt2995U/ffEMsyPmPLzf538X/l0tP9sabP/7R7t/64vIP/dAP8dUj qdT9+/ff/e53J+rLV+CPPvoomey//tf/+u3f/u1f//rX1SJc/3GRvP/s6OjgMvMVe/x0nK/wv/zl L/f19fHl/Tvf+U6enRfLn/DdAb6w/+AHP2gSNWbZ+Re//Q/e0/Gj5Mqcr9V/d/3Xv6f7h/n/vuvR hMW5rg4Xg/+nTvWb3/zmrVu34hfnP3XyE+zNv/BVePN13l6PiCXfI/z/eIHf+Po3/+W/+t+TFufZ C8mwOH/45S//zOl/9r6/9t6fPfPPTFaUaD+NT7Dn8R+1rPTurV9JTPmrv7b4pTVn74kn7uv7f+79 4X2JuaIJfv8Pfv/u3Ttvecsje/fs+/Zv/8sxJdisojd/90+env6N//vPxQr8W9/1jnOj/2Pn97w7 fhUdKnbs8N+21KL+4q+qlOSa37IQlewX/7+z/9u/+bd7frj/n/6Tk6ky6okbVohuSP+vv7d/9nOL 3/iG04WPHBy+dmPWk8rGkDLri4wgAAIgAAIgAAIgAAKtQyC8OOeLan5erY7y+NI8Kqh6yFfCv//7 v/+DP/iDf/Wv/tWSlOEr57/4i7/Ql9y6PPpzftrMF9jf+q3fGi8J3wjY2triYvPlLk/5tre9jR+n 84zxmwhxi/OVww4hEVYgKhf/T/yf2sN4k6+M33zLu/7S918xCcZPzi3pxS/OLQuJX5znKSTD4tyy ulZLVuzJeWbt/peP/4Rl3v/tX/8bPaXtKvpt3/K2zr/DM35z8z+wb4rT9fhVtM2anxS4qJNzSxpI BgIgAAIgAAIgAAIgAAItSyC8OG9ZQSEYCIBAfgKhVXSGAr0j7pg1f1HFZigHWUAABEAABEAABEAA BECgogSwOK9ow0FsEMhCgC/Os2QL5lF3zkOL8zKKzV8mSgABEAABEAABEAABEACBqhDA4rwqLQU5 QQAEQAAEQAAEQAAEQAAEQAAE2pYA/Tq3tlUXioEACIAACIAACIAACIAACIAACIBA6xF45POf/3zr SQWJQAAEQAAEQAAEQAAEQAAEQAAEQGAbEXiEfCX7NgIAVUEABEAABEAABEAABEAABEAABECg2QRw 57zZLYD6QQAEQAAEQAAEQAAEQAAEQAAEtj0B3Dnf9iYAACAAAiAAAiAAAiAAAiAAAiAAAs0m4Jyc //Ef//Hc3Nxv/dZvNVse1A8CIAACIAACIAACIAACIAACIAAC6Qg89thj73vf+77/+7//He8o4OPB 6eouKLWzOL969epf+kt/6amnnkpV7E/+5E/+/M//fKosSAwCIAACIAACIAACIAACIAACIAACxRL4 9V//9f/wH/7D+9///n/4D/9hsSU3rDRncf7TP/3T+jL7yp3N3/2Dr73BXxb3JpP/I/73vd/xrp/4 2zt1ybA4b1g7oSIQAAEQAAEQAAEQAAEQAAEQaH0C//2///f19fW/+Iu/iBc19GLyN954w0vPj74/ 8IEPfOd3fmcGZfkS9bnnnsuQsRWy0HfOv/L7f/46x/PGm/zP62+++Tr/3zfY1u/9WStIDBlAAARA AARAAARAAARAAARAAARak8Brr70WvzIXp7/i/Nf5iXWntjLnT7/xjW+8+uqrDdDuL//lv0zWEn1u SqlnV2lsUppUoxfncjXu/HGW6G+8wZ8UDuifub/CS/YKVDXo/5mqrsIljJGn8LpSaVpe4gx66U1W nmAoGQRAAARAAARAAARAAARAoFgCfGltKjBxWc4zqrX617/+9WKlSlXaH/7hH2ZeY+fJa1icv+4v zr/5+pvfdBfqiSqlXVOFVqqJ5WdIkFakUBXFSugtU0mpiq0rA6uYLJ7A8SqQJaTVy0ufs+2KJYDS QAAEQAAEQAAEQAAEQAAEshEgl+Xf933f9zf/5t9817vepcqMHqFnqys+F191ez+eMvSfXl6+xs5c e+a8hsW5E8ouluj85rkIbn+DlXFynlnhzBlbZL2nr3UTdWm6zPpqmTwGL0nCtKv6RJJIAAIgAAIg AAIgAAIgAAIg0EgCMafl3/Ed3/Hud7/7B3/wB7/ru74rFNlenoR85ez9eC2h/wzVSy7jQ0t6U5oM KiSEtfMzc/fk3DasvaR1WgbdkMUjoK9yTX834TKtkEtq6GjYf0kVwTxAAARAAARAAARAAARAAATK I8CX5fxsvD/426P9VNVvectbvvd7v7e3t5f/RT2JOUL/b//tv/3zf/Hc2Z894/3h/8kfptIifjmt /yu5jA8t6U1pVDlKMNPfQ2InhLWrC+f8j3Zj36g4uayKLgXjj0Ptl442x6qJK71QkLZ9zHaG5a5a ZNorqEBHc5kKsQGSympDFZnyhiQMHbOTuXTOiWInJkirFNKDAAiAAAiAAAiAAAiAAAiUR8A7Lf/2 b/92y1r+2l/7a48++mhiZPt73vOewcH9v/3bK//X//Wb/M/Kyv/v8cd/lD+0rEUlMy2n9X9NVWBh iZVkx44dUwTV7x9f+eKJmf/zU5fDf/Q0/O+hXKdPn+YP1f+qn/f3mL+EspC5QvXmSaOLF63aVLIp V7xeMWJHEdk/ISsNSRitOtuTRFyhhvb+MyqPjYSmNDZ5symIXCAAAiAAAiAAAiAAAiAAAgUS4N8b 936piuXL0l/VfjF5v3j/i0eOHv4H//DQb/yn3wgl40tUPVI99PfEVXTMUbm+qo/eKldPYqq2+Sf6 5NzyqDyqm3eImqh2zgTkzecMZWYrJ1uuDOKZskQPk0uK/c58al2gPJllKBA4igIBEAABEAABEAAB EAABELAnoM7A7V+N9l/+y3/54he/qMpPPD9/9K8/evIf/5N/cvKnfvAHftBepOjqOrqijikt9Bp2 tdj2ykwlhikxvTjPXHQh6yib2PICl8cZiopmsZE5M9VoxgwyZ67d1KYFLr+VbGRFhVhUZt2REQRA AARAAARAAARAAARAIBUBfWn9m7/5m3fl7w7185biv83j1FdWXn/99cRluSfJ33j0b/I/qQTTE/NL 4NGNA/LzaXrK0Po8VHv8v9qI+oiS6ad/+qd//ud/3stwYuaL8u/8w+aP8P/3yCNM3Tm/MPI39EJ/ 8id/0suln5lHr0l7C7nQX0ILPP0/E1dlocSktqYCo/Lw7KFj/9B/qvJjMqp/jVmyRgW2pGGiF6qx 8NWyjtRTzZ4AmVJnGGqyKL1EG7AxcaQBARAAARAAARAAARAAARBoGAG+FNfrIl/Drh7y76i99a1v 5cvyP/3TP40me/zxxzPIzJeozz33XHxGtQj3Fudq+R1arpMPeS4ymVedKZelIvGLc/aD3X+FF/Sf 1v9AFRezOCfry7zcauKqLHPVmTNaNlV7JwO99m5faAcCIAACIAACIAACILBNCHiL85hleeLqnSco Y3HuLctDq2jLlXm0BfXDdrXaD638UzV6XFh7z/d866HdNf6H/yVVoSpx9OSZPIsOlawWaaUeAsfo YiNhNHtzZc7QNC2YpVkt3oIoIBIIgAAIgAAIgAAIgAAIVJfAO97xDjI6PfowJoj9ne98ZxkEvIvi ahXtHZ6rk3O1rvaeew/VP3k/lUb99Ne8KYHtr9lHFXROzmdnZ7u6un74h39YpfhX/+FLr7/x5scG ut/1jrfy//zzb7z+2cX1t77lkf/33/mAXoQe1l4GO5QJAiAAAiAAAiAAAiAAAiAAAiBQIQL8q+Nf +tKXvv71r3syR4/QyUN1Lz1fmff19X3nd35nWq35of3Gxsbf/bt/N23GFknvLM7/03/6T7du3frZ n/3ZR/j9cusfFufWqJAQBEAABEAABEAABEAABEAABECgLAJ8Zf4Lv/ALhw4d+r7v+76y6ii5XGdx /o1vfOPf//t//1u/9VslV4fiQQAEQAAEQAAEQAAEQAAEQAAEQKBgAn/rb/2t7u7u7//+7y+43AYW 5yzOG1gjqgIBEAABEAABEAABEAABEAABEAABEAgQKPg756ALAiAAAiAAAiAAAiAAAiAAAiAAAiCQ lsAjn//859PmQXoQAAEQAAEQAAEQAAEQAAEQAAEQAIECCTxy5rnnCywORYEACIAACIAACIAACIAA CIAACIAACKQlIBbnp57+ZNpsMem/8pWvvPe97y2wQBQVTwDA28lCqtKaVZHT3jbaTyNS922ipn27 50zZfjyhUU6TaEB2tFEDIKMKEAABECiPwOc+97kPfvijpvJx57w88igZBEAABEAABEAABEAABEAA BEAABKwIYHFuhQmJQAAEQAAEQAAEQAAEQAAEQAAEQKA8Alicl8cWJYMACIAACIAACIAACIAACIAA CICAFQEszq0wIREIgAAIgAAIgAAIgAAIgAAIgAAIlEcgsDh/xP2VVx9KrhYBbhGFCFxUOYUIg0Is CbSCQ1AyWAqMZM0lUFRLFVVOc2mgdhAAgQYQwBjRAMioAgRAoJEEAovzN+Wv8Oq9KT6mXIWzjRYI 2g2A3LAqmtua9g6hvGV8GR7JsvmaCL9hVTesIkvmRSVrol6hqvX/VCNgE2XLgDcqrd7ZQ9rFL5M8 9TOIUXiWkMsi/1NVGqNjYlPqQEpaQ5LN4UnucfNqT2yjmPaNWq+p9kQy8Q0a7TWm9DylGqcwvSy8 j6BAEACBZhGwCmvP4/U819nESXaz4DalXsU523AVbehsrVZUOU0B2FKVFtua5anmyVlIFXkcTiEC qDmo6kTZukBOMRrW7sVWlI1VGe6iWL3sWzNqNp4J6X/J7KLtJSkqZZRkqLPr/5nNAIoS1b4cr5m8 RazX2ZU1hhTRXYHXjjYuIlqOvZCWKaPMyVbQH5qaidTI1Nz8uUofktN7nsd5RntNIo2q2F6iIkgA AiAAAlaL86IwwXsWRRLlgAAINIwAHFfDULdTRW1vNt7azHLhp/a8vP9tVlvrS8qi2qiocgpnknmj M7Qmj25YWIrasmQs5UcyEAABEGg8AbE4j3ff3miqJ7MP0FLbqNEq9Ife32P+4u1wh0qzl6TxcFuq RpJbqBWUMXiNlZhFbxRP2ajBWBoAmtJkMIqMmuVE+4hlK4QatzEdKmpO0VZWT3S9oqI23jZawXHp 7R5tZdISor0vmxdK7PuJ3TzUrLp/8DyMvlozuR2T4jYm0USA2bC3bC6SZKp1VxUP2AtsDs+BW3bk /FWHalSr6+hDvSKT04sKE7WHbOXYq0n6E9Ld2XgG+3qREgRAAAQaT0AszpVHNtXtjaneSKz8e3yu kKcOJQ6V4JUc+ouXzBvPQoFSaSVpPN8WqZEEpWCGmEefeCrolqDPpEPGEDWY6ByONIBURtUiYBsj RrRRTF3DaxebbhsqRK2UCmwFm1bWZQhN33WzKVAq+yaLVtpgxxXv7hSfUCNG291eX339HNW9iu6i WQAzMG/xLCGSidOGFldHXyHHTH5K0oJ0I1FvnKp2NcWKDrWpClHNqoqKzxiqKFq7ZTn24pHTD5th zr4KpAQBEACBFiGQfHIeFVQ54kT3Hcpo4/GjWUhM+sCQQZIWQd9gMUKgsjViUcbQYN3br7r8kzCd SbGl6SUndk/PDsuTIWfrt7jjKonb9nEXJQHMaXWVyJ6qa3iHnFy1tJOHkmh4SzslUklSkZSi1ZVh hzpzpaNlk9kkKypNSY2LYkEABECgugSck/NUA0OqLd4yBjy9TLVBm0r+6rZWHsmjoArZ205lDHnk R97yCBTeSb0CE7tny9pP4UxCa5JEMuU1t03JcBc2lOLTlGFC+aVqVgn6Sri54zW5qsw5Gia2dUjl xnT/tFOjRC0sjaeociyrQzIQAAEQaDMCzsm5t8Ma+ounrb7R6x12WW6Bq7xqFq4K9EqIPlFlhnZ8 E3NhMNBbymMYxeuB8holZNB6Q0f33fUWV/9qMoaYcqIGQFbUZj0tmzrRjmDZNVR1ZLe16YYqjd4T 47uY7je8lJ5t6DLrFqhbQqj8kBMI5coGM22uJjoum1Ym00TbPV5rveHayV00DGAIr27zpk5EMk9r nA1Ln+iCyN7dMPGyVRSageijmMk9Rp1htK0thYl3jJaFhEZ8PZfu9kmHEOPMo07PZhoQqt0bO3je bBsxUdoxYsQPc2l5Ij0IgAAINJ1A4OTc280NbbiaTlFs9mX1MnVto3lDtZOFx+RqOsoWESAeuD7z iGlWpUsogf6fekNEa4zJ6FEiS/AqbRGYTRcjsY1InmTzkWxNHSpUQmJPj3beqAyk/ajZm/rpq3qv RpPVld00zXVc0XbXeZraN/45Saxd3UXDAEapmrxf1KQ9b1y2MecpP94Fkf3UVJ3St0W0Dvk07z/1 hatpmPNUMJlZiEBU5ahby4xFbwJ91I4K6fE31UV6A5M9h2YIeuEmr2Jvh3oJoZL1gSxGYPu6kBIE QAAEWo1AQz+l1mrKQx4QAIHmEuCzq+hZTXNFQu0gAALbk0Boxb49IUBrEAABEACB5hLA4ry5/FE7 CGx3ApanT9sdE/QHARAAARAAARAAARBodwJYnLd7C0M/EAABEAABEAABEAABEAABEACBlieAxXnL NxEEBAEQAAEQAAEQAAEQAAEQAAEQaHcCWJy3ewtDPxAAARAAARAAARAAARAAARAAgZYn8MiZ554/ /PFPtrycEBAEQAAEQAAEQAAEQAAEQAAEQAAEKkzg1Zc+N7TcbVIAi/MKNy1EBwEQAAEQAAEQAAEQ AAEQAAEQqAoBvjj/4Ic/apIWYe1VaUfICQIgAAIgAAIgAAIgAAIgAAIg0LYEsDhv26aFYiAAAiAA AiAAAiDQBgTunX1012Piz+RyUJutmaeiD5unMCmnUfjmyYmaQQAEWpaAWJxf23LFkz5Our/DCQ9T KLR5bSTiT8mK6DKp7Ix8yNjyhPLdu0ZmPJ1Mkm5dPex7eS+jo37E+wdKoWr3S5i45yVOoWYKoElJ SwBOK2Johah89nZlT4xK6Y1/hRpwEu9y/92BHJiU+Lq7hsrNz7d5kUVOX5YmXXuW2X3LpEGVq0iB pROGR2uUs1eG/UmgLXadXXJVKstHFYgsvqiAM/RGA91DMlZxm2kYS0tjMNiS2QGG28jeqZK9oGE8 GlqR3ZAU9Z9cSNsBxeQEGqpn61VmPeuwHuKjDmf3qfuvvDw71lus9t5wGVssPcLSWUg5SxA+ML67 Gxb8oTvQe3sW0gM8dXVTimunb1gzu55lRhhpTWpyEpiHaxPpFA1eFfcblTPViGCpptPcxH4Wd3jB 8d1fPfG5oje30VvEeZhmFrSNhp4UNmqZVCzOFw+pbrA0eWiq+zx3f/dfuT4Y+9CycLU8eJqdCflT siKyTEN2okxpatM9N7jw/M/MSC1exuWJg7d6hjwv3z8pcjl/6kOsb6cxPyUSd4In2QWV/Tw74SyT Nq89szYqH944zurPJO8X2GM1pywDOKkIWREpF5nd/qF9mUyOfyHg9sZWBP6Cy+B+cLjeXfeMc6I/ 1E/H109q+2jh2vdOCBrcng9I45zc7Y7NJ5hX5otHErpKwSrlLo42PKLp8/VKkz8ZUh6S/zm1V+pS mo/KTcq2gJAzVNkiD6nOZVvDtkmXwhg4E8KWiCGYbA7SrVFOle4FbdkglkOSjs7zn/QwYbL5SMO1 JU97pexnHZbDsVgApBikaiOXX74vB8ft9lMjO5+xR2cCDmoHS28fu3Un8cjKgM+yZ5ngk61JTk4Y 6x1Xc/gbx9dOaMcJdu1aFfdr5Gk3ItiraW648Pi+NOktYfiM8eYleTpLPhRNYTUL2kZDj515pkwl FucrbO42P2dbXpzvHX9COrituwtxD1PUwXtgZPZPVkSXSWVn5MOlFy6ysTNJa3KnFm5za2NnRndS lW5dvTS//5h5xULVvrW2sn9ArnwY6x8YWl1YFpbdeWRGLYdYrbOHra49TMEtc9IygJOKkK1Aik1m t39oX2YwZXeXWHWmMLbMzEvLuDxdXz1wwVkEOrUI+3T7KauNjO5fWby7mUKCrTuLkTJTZG9+UgvD U02fq1fa+5OSfFTDQJPOMM5DCskUYfzCBOyNgWJndFaR5qBTUk6V7gVt2XIWnkGcF1H+02aYgM0b rcZ61mHDWbjuFIMUHS5OBEeII+Vr8rTQO0aWh4fD9VU2fzISMWrZRcgoDMu8QlMvWDU+WjOpxNpH BnpXXtMW3/fOjq0fn9U2LAZHH194IXQdQEyQxKF6+JqAlVtLEsn79zSt6WWqHT031js37Zz255HT yi2IehvnfnOKZD/KmCqKju8dOz3agsNgvxjgyYdku9svi6zNZtsnFIvzsf1sfXNza3NNTbm4szt4 azDmYU5oZEU5y2RbG+u9gx13A57XVKZ0W+cMy285KX9SnYml+d1cVNHsYuyP5BMqe6v3NKUWkrZA 4DkVIbPbPyRpBLM7sVLcgG/INW2BuhfSFqkK8VRTAUhqEH24saIvjXZ09a1sPLAvVuy79fbssM9Q mZThpheCZ+6VZn+SYxqXwkc1jDrpDA0ekiLcMEHbsaKQLZmcVbQ5Et1awCvG9oJ25BqnE+k/zTxp m8/uBLYN7jzzyVSDFBUuzg+NnaBFHjjG/OCyufrGMRneeGDl4jSfsNWOvqji5N2TwNg4stWpg841 MbGelz9TRXbNzFfmhxYGrpuOvu0KUanEPr4W77k8weMOLh/t1IvYsWdw/bZ3FStN4fnSpmpNrarO DuNHpvIJ5OZuQfdrKVJO/anxnW/s3h/dGBbzzNsDbugx+VBUbusAMfTkaCqxOO/Q8vOVuYgmmhlJ fJijUpGVrChXmatT0+ycjDitd1982r8zHyqUcltekqRjc4OA/ZMyCEcsn06zwaFIjQcv9oTOP3Np milzAcB5JEweRcjs9g9JrcPZVazU/VdG1w4Gr1hHrToTxeZk8uYQzam+GrVGmj5nryT8iRir/HsT zm2gNHQsfVSaInOlJZ2h0UPSnSuXANs3s9GWwo7aPGAZXbruFeN7wfblT2hO8YzafG4nsJ2YN2w+ GYDKt1bZnJqP7XpsTDssccPQaj19GVrBjbj2770bK7IqXaxavSBNGQSnH31bFeGpyUNBr3s7C3Mn Ts71delTeFkYr4KpcGXtJ290VuBGQMFytqD7tRbJzjKMqegBxb96cIGNuS8wIh9aO0AMPflaSizO H6yz7s5OEXp9c2y6a1bepdyMeZivRhnjHakoZ5kie+/4s85O4d59Rje3eW16jtcuvbYbzuS9SWtr 5nS2Y3NnC1ZM3C/vYeusp8MN+hRnnuIuhxPfXoCa6YsoBHhORcjs9g9JpeNE4pcL2NqDrdKMLX0r ZMghGm59IzSY8qNy/SE/CCKGYXNlDbxhkUHjIrK4TS9mI+JgJGuvjPUntT2DfdLA0v2sfFS6InOk Jp3hpy/GeEhVmUY4R+3I6hDwbIly1IwcsJh5DI16RVMv2J4NQPrP5CGSsvmMTmB7cM8zn8w7SPGr HP5Cmvv/0t6r0rCKjDbj3jkP6Mgfzg7cGnbfAOdn3r2vp37lToMNMGtrOmuQsqVtQfcbK1JnPiCG FZB29WD3qfrQ6pS4AUE+1KpPdIAYevI0llic83ut+/hVczH89A3skW0vL7uaHorhny9oxW0Z/jIq sbkS9QJxMpEVqQxWF2CosvmVGybtif+2ZqZvBiJ8tEs1/q6PH87kvj3u3pUpfyPTqySdSPyVPFPs +Ki6as5BiaPmpq7MhRy5gadTJEKMzG7/kDSMBJG8azMxuufpN43JK95fMHXau3YlKxUOUblO2V9O 3JR9lh8FOG86cFyq6Lzkr3+UX+U64b9pvDGaNLAW/8aUV2n6XhnjT2Spwlc497KsVUsq07qgohKS zvBTx93ogKiHdComCBcl0nYsx7clwlkZBiyDW4v1in4vyDuCV7mVaP+ZOExQNp/FCVQZXTrZreeT RLE5Byk5bhL3q2kFRPg0v9eZTjuVOl1F4RqEKTpv3oqftWYQjfsNHkA6HL5MzsGuLyzq5aWb30Yk scmeqTXvneWHZ3INon42FWXgpA/ljXK/iWLGjgiJueMTxKyA3MMGEQ/iLaDIh04V1g4wMAHLqcD2 yf7Imeeef+PvfNK5gC3uwEytCO37/CCZyEMxA+B3es+w0+LCzDn2zPDi47Oh+y0uQX5lSw8rEnd7 RAgNWZGzml1x0ogiyOyJZbq1SCHkfEUv02tc8Srs10bdkB7n/k94kzWSnaxdvlVbXkPyhfd1dGrU 9CrPwBLhaC1rCbzmWYWuiKGiaJkkB7JMuiKqEWm2mkh849x7Y7/B2Mprg0JL1jm7bccHqpNzsha/ NZWhBh+G2ohvqKsIDqrMQoUus7Akn+A3fb5eqdmY23P9AsVLZR0DS5JHsoj4vYCPKhOXZdlBZ+hk 0h8aOpdl8dslmb0xkLZkHBklv+iAFRysaa9I9II0I3iFWs44JIV1oPwnNSchbd7QcBXiVLyoaWYd tsNxdJDSyPtOlXyo9yP5AnDhq3mBi/vUCChk4JfS3XhGG5G4zfCPATk+X+uJeqdzKkojJ2mKjoT8 rKjufhOEbDNNI//fQ2rys6LZy53TvvCyRn8uGvpP2jbMPUupnyAnOeWgJic+Da/VXIGyy5kwY9eG 8ga5X8O6xn5EsB9l4l1iYEDRJpD+5IR6aD8LoiZgxTufCpf46kuf++CHP2pSQCzOD3/8kxXWD6KD wHYkwN3upZ3+NbPtiAA6gwAIgEAmAvCfmbAhU4MIiGUVU0dZLf2ripwtDRHCbU8C8YtzEdaOHwiA QNUI7J0431M/pN55M6G+FIAfCIAACICABQH4TwtISNIMAvLjLKEPoTVDjqQ6qyJnkh74dxBoRQI4 OW/FVoFMIAACIAACIAACIAACIAACIAACbUYAJ+dt1qBQBwRAAARAAARAAARAAARAAARAoN0IIKy9 3VoU+oAACIAACIAACIAACIAACIAACFSOABbnlWsyCAwCIAACIAACIAACIAACIAACINBuBLA4b7cW hT4gAAIgAAIgAAIgAAIgAAIgAAKVI4DFeeWaDAKDAAiAAAiAAAiAAAiAAAiAAAi0GwEsztutRaEP CIAACIAACIAACGxPAvfOqo+MPjq5nA/A1sxTdl8q5TXmrSufpLly62ryv4/MbOUqDplBAATyEhCL 811nl0QxyxPKnXl/pK/ZvDaiPVQp0/2cEgKeS/gCVezhawlugMruShX2hp4KFs5FfqTR9ae07iY9 KZH8ErSPTqdQMx3T2NQlAKcVIZuGEo3Mbv+Q1JbK7g3JAbtqTisU1aCBDugYvK+RZsC+zYssMuXS ZKBH+5ZJgypK5GaUY9AojfeIih32JyZnmKaWND6qYSADztCtNfSw/WymHLyWxmCwJbOzCreRvf8k x6ZylG9yqdV29U2G10rVB0auDIve3afuv/Ly7Fhvg3TiffMEq0/0O9VprpJPcbUJYYPE8SYAmeqr jYx2Tx3MMtUPTznchuOt6UKQPVQ8l07pqaubUsRMAufu7JERjZovBZYG2ZqyKiNCVM5Ug5Slmv6i Mtqvw2OcDt8zSOJhmolZdUZDsTgfunlJrJD7J195mXs09ac+xPp21py+PXTefX5qb8ruzs39aXYm 5CWXJg9Ndasyrw8uHoqxeEN2okwm2nW654aSf2bEld0g7/LEwVs9Q57vNuseyU+JxN3ESXZBVX2e nXCWSZvXnlkblQ9vHGf1ZxqzGVkGcFIRsiKSNpnd/qF9mUwOySHg9saW0rQbkZw7neF6d93rmHL4 1zUaXz8Zs721d8LpywekcU7udgdCPpNwy3zxSEJXaYSe+eugm550PpT3iApg8icRZ1iaj8oPxbKE kDNUuSIPKcKWFWyfZCmMQYy84YHV7KzCzUGmpJwqPTa1ZYs0ZcBtS5KtoJQas/gUMX6MawFRt2ZO X+y5EJwb+13bGXZbQE5rEXafqjuLAussWsKYhnO8lrOL0dvHbt3JekSfs7OL5VxkFkTOlxjrHVfL ihvH106k3mqpyohgnM/bDVL2apoXDtExzltV8QWpWqXy2S/xUFif1cSsUqOhWJzP9w72ByfoW1cv ze8/VsSsnZt7ZPa/vDjfO/6E3GXcuruwwuZuG0OPqOyMfLj0wkU2diZpTe64EN7Aa2NnRndSridJ d6r2rbWV/QNy5cP3OAaGVheWhRl1HplRyyFW6+xhq2sPs3i6tHnKAE4qQrYCKS2Z3f6hfZnBlN1d wqhTGFta1OWnX56urx4IjfrCPt3uw/gm9/6VxbubKUTZurMYKTNF9kokVU1POwpLu7X3JyX5qIaB Jp1hnIcUkjmEGyZkVSqyNwZKI6OzijQHnZJyqvTYVBWeqeRsyoCbSkIkTk+g9pGB3pXX5BpOP5FW x25iCzUYMuYexlIVRSPOqDJluW5o56GplSSR712ZYsdHnemfMbE4Pb4mozW1E+OQUs4xlYiQv+rF loqHBjWJMuXZ43B9lc2fDIamUrqb1dz7BD9PupIhTlbTX2s49fTe2bH147NefAFjg6OPL7wQnfzL s82kcIl8nT3TLKh29NxY79y0c9rvHP4nyVmVEcFyXmSaUduraaooOuXo2OnRFuOdWqWSD8leZ79S S+rhTfp3sTiPnDPLiemT/iF5uJ/nk3Vrc03N7bgPOnhrcGw/W9/czFck914b672DHXcJ3xctWfqI c4ath7DutoLdXOQ+VI4Wl+YjeYTK3urdtsTC0hUIPKciZHb7hySRYHYnMInb1Q25k12g7oW1h3VB nmoq2keNWA83VvSl0Y6uvpWNB9ZFyu2w3p4d9hkqkzLc9LkEN/uT7M4wjY/KJXyazKQzNHjIQgmn EbJd04ZsyeSsos2R6NYCXjF2bGpLtjnHqbZkUlWlxA61E8XpBe/I43Sxaq0dPeaehfDBXuw7jx7t pDXlq9NDCwPXw6fx0TJDsWl9CeCWbt/sG9gTrtTt2o9qewdz9Y1jMrjywMrFaTVd5HNg7fzWOcvh z+dvsWflae2F/eLsyqymW+b1cXbxaX60WDv6oorndw8S1dkYP7J2ojh5VCxzou0CIXghNWt7Bvtc v5HRcrSGEyUsT3BNLwdbZ8eewfXb+bYA1Bwv5ew66yyos6M7IwzLbC04IliKZKmgKRk15eD7L/dH N4bF1Pf2gLtKJR+KUm0nZtUZDeWd8+AN7eDRsWDhhwrHhaCnax3HK82MdKTLZ069OjXNzqmY/G7p p+gf5SO8lEnH5oYy+ydlxItYPp1mg0OhVDxaIxL1VJTS9uUUADynImR2+4ekquHsKjDp/iujawe1 AKQCdLcHXUJKb8Qtoey2KZJu+uzqEf4ktzO09FHZhU6Zk3SGRg9ZNOGUwrZXcqMthZ2VecAyujXd K8aPTe3F1NEm5zjVlkyqp9ScmlDt4kGO193oS+++qH+gvXefGzvGV1wxJ9hiPeZFg8qIM3Ua779r yStTC0uxw9bTEbka5gfZ+lcs3SC4Wo+7EhYLe/0YzKtuaNQJAuV7B/Ko2aSmV6YfX0DIzPeFmcvz sTHn9ChezVpXN1t7kCXonGo4XvvJub6uyGSfNwRT4craT14y1Q7YYxuhiZ09lZzJltSCI4K1SMna JTRidONGvYlAbV1dYGPuKpV8aD0xq9Ro+MiZ555fm/m37LzbGZz9ReomquGfuvY/lrNpkB0EQAAE QAAEQAAEQAAEQAAEQKBdCWzc/P/wtym9NqpWnfLNSqtBXfk9/zPstAj3UOEkPGpvTKxSazz+JfLQ fRGjSBhepYrC3YqCVYiUXlHNIf3qS5/74Ic/aqpbnJyva+9+4/dn/P3FYCbxTzLu37kAIy6x8JdR bTZHLdQKAiAAAiAAAiAAAiAAAiAAAiBQPQL+ubd/I8OJN3FjN0Toh/eGcvKho7a3Sk3CwF8oaPOq iKRiyvx3sTjvPu+ek2/NTIfDbPyX1J9YH7+R+Bb0MmVF2SAAAiAAAiAAAiAAAiAAAiAAApUjoL+z 0PhGvdrIs/ythIfk3RbxeS+5SiUfah/81lap6hU5/ssRg58GF8fpoTcgtBpGEdZ++OOfzCOWF9a+ cfPlPOUgLwiAgDUB7nou7fQu41lnQ0IQAAEQAAEQaB8C/C46/4xus46OGhYfG1aTzwEW95XyqTZy duGGFutRxK1oQ1WRsxXZlSoTloohvMlh7aW2BwoHARAogcDeifM9zrZi6m9vliAOigQBEAABEACB RhPgH2Ga896g1ujKeX3iNG/txNm8bx1PkrxxavJXZ4c+pSy/FxP6EFqSvM3496rI2Qw2qLNiBERY O34gAALVIyBfFir/+J9gqZ4WkBgEQAAEQAAE0hOQXz5v/qKRf06Fv1A66ZPX6dVzczRUTfl5iFfk l2i9n/xeTKuHAYt9korImd0UkHPbEEBY+7ZpaigKAiAAAiAAAiAAAiAAAiAAAg0kgLD2EGyEtTfQ +lAVCIAACIAACIAACIAACIAACIAACKQnIE7Ov//Hc70QbugJ5zvn8y/ghXDpWwA5QAAEQAAEQAAE QAAEQAAEQKAdCWCpGGrVt7+a9J3zdjQD6AQCIAACIAACIAACIAACIAACIAAClSGAF8JVpqkgKAiA AAiAAAiAAAiAAAiAAAiAQLsSwOK8XVsWeoEACIAACIAACIBAuxP4nZmzBx69/IXi1Cy8wOJEQ0kg AAJtT0Aszj//OwE1v/qLh38i5Oa+MMGfiD//aOarqZFsfv4fibwBvykdnyzzcKj2SPH22amUpLRk 7fYPrcu8P6V0DKqZQvfUrGUGe2Jk+SRGA9s0hhGwKy+jwyd+WKVq90uYuO/pUTrbbC2SJ5ejuzIk pxP5arpPOA2/b4osMuXSZRevzO6Doi0zj5gNzUvYA61RbiMhnCFjoYcVh8lYuBcHTO4nprzv95bl GRpqO6VXZknJANnswcKmaD9gkb2gdA5NqcB6DtAU6VCpLQF95EqcItoWakjnDZc5y8mQPTBAuzNk /tAdqb0NAtmFz/7ipjfBS78NkbdrRIY5anYRmNdpE7MUbKriP6NypnLplmoa5vOSZ3hE0OF7ozbx MM34vo3GjhQ22pikYnF+47y25P7CxD/99Z7+br92YQHXen5u7v6/4X+eH/nudHLxDvw0Ozl7UCtQ rBk+MfX+U7LAzwx+4RMxfZjMvvn582s/JuX5uRFPeDKlYfFJZCfLJB/al8keHZc6huS01T0daDd1 GcBptukMI2RXH5pUZOSfej/re+/7TPpStfNB6ywbU9lPsbqzLrVvr2xsG5+Lu9HhGx11j9VTH+Iy 6N1n/MtnY+Yue59y8B6QrCYfFRoI11xnXpkv/k9G8o3X16ZG2hqJvpbfSCLOUMgXeUh1cxtFWiKN qRf3K//M/4yrD94aHAvh3uWkIfuQ0RJYsgqRghKvgoBsGh3CVkeOoZQDpHtBVv1aOp/9HKCl1YBw kkDfwc+E5k6xYN43cmruvhwfC/oVXiAtlxqa+Uw4OpQ7fdxRqruP/fqd9GdjqtacXYOcM5CzC8a6 x9Vi4edG1uraeYBdq1TFfxp52rl0ezXNDRcdEbwpMZ9R/9oleeq5dJl4KJrCanzfRmOHnXk2NpUM a19f+12nVt6WawdPjr7XF2Lp5gw7eDLtmtzLzztwZPb/hcXl7vH90o1+9ZWFTTb3n43BSFR21vk/ Pa+WGey7d/S4wpMpSZZkdvuH9mUGU3Z0iX2NFLpnM4QygJNsUxlG1K587b76i5eWf+SYeYlI1f47 a5s/MqBsgH1ooH994YvCE5GNmA1ja+T6wvSN9QNjzurIEUngcrsPe9/Ij/3Iyhde2Uwh7u/c+UKk zBTZm5/UoqervpbXSEijjbNkwUZVXZmffS8msef3DJUhZSeoPSWqPOPoELE6OiXlAOleYKdNxVJZ eIaKaQRx2XfvGuz0JqjRkDE3TjAQWSacvxebGQjK045/xZmQPHscvrHOls8GIhy9ZIZ4T69Mccr9 eRlqqp1sZ2q1933kQ90rX9GCWO9PjX15ZFbbbhj8sR9euBmdKsuzzaSD9HxdI9Oc4bt//NzB7rlf dk77nfisTHJaC984/5lTJPthwlRRdB7S8V6PtuAw+DfEoQv5kLRP+2l2JvNGpvQE5OLcXedId3Au sEz6nY0vdw9+zytFeB9XuK8+XFNTWO4B/+mvDx78Efblh2lWF5qSoihvkZZeeTK7/UOywmB2J/KH q/lzcolVoO726pZSaRrDIOzKl14uDw6q07k0v19bVNHsYrEayZfTMNLIUWJaTwsVv6TG4N/dWtFX gN9T69vcemAvhNgO6+75HvsMlUkZ7mtC8BxGQhqtwZKpqivBzdyLQ7PVFNqk8Qwpim3HpCHIJkcd tbpElx5wgLG9oB25Qqf2IXD/xpS7Ec9Pkp2QSR5tx5yQMb4hpWJ89PBMMqWYcGohY+KA57t//EWV 0T1IdE6SZDBUMN6Tr/Y/sfAheZgfPOWeu7F1TEbwHdicmfZv2KVtAbERr8UPfmGCi3rqxzv1Yr5n 1+CX73mXjNJWkD191jlD5/d0ZK/UJmcL+k9LkWy0i0lDzUNER/ixrWExUbw34MY4kw9FwbbjO8aO nE2VI7tYnDtHc5Q7ECWvT/0yO6fCj98/83TSFXFbWRxH+fxI9nUCj+uY6QmdK9pWz9OR2e0fkjWF s6vIn/v/5sjaPw3e+BWDRB7dU+jpJC0AeKhSS8Mw2ZUsLenY3KDnhyZl0JRYr36WDfaHUuU0jPRs y87hzSHKrqjK5Uf6Wh4jIY3WaMl0N68GTKIXe/NdeW8o7tqRQUVLz1ANQCVJaYQcdtRm/2l06boD jO8FJSmHYkEgL4GVG58Q43v9wbg62GB814/NqUH/Jw6MRXfk/QrplEv/+df6shwDqIkK39T24vtk wJp7yu2Gtr2vpzOLyq5GPGT1M16Q6Vz97FxnLbK05fUyFa6s/eQNwSLj+bNoYZGnYDlb0H9ai2RB Ky4JPSL4Vw/G2Jj7BiLyofX4jrEjZ0vlyy4W585N1Gtz7NfGpONz43zUVd7u8Y85G3h7f8B3Sdmr FbHovzb2y7VZeZtx83cfsPfvSO3WxFmiuE3hxLenlYbMbv+QrC5OJB56zdZ+93dkHH5u3dMqW1al Voax+XmTXYnhduaz2Y7NnT1vsfFxahf7Muv5HvfidE7DSMu21PSi4R5shK6Z8aNy/SE/SCdGcbNY 2k2QUmVvXuFuX+MSyE2NDEZCGu2nfyHGkpW6WtXN0z9lzbG9WMSUSseV7mflGdIV2capPciUo2ak /2TmcSTqAE29oI2RQrXqE5B3zj8z3rk+9VkVGs0vaLj3maVXN78txT5l8zG5d84D6vCHsx/69WH3 DXC+lI/u7rlx406Dpc46Z8g4t0+rXQv6z1iRUi92gkAMM2rt6sGj4/X+9SlxA4J8qBWXOL5j7Ehr jQWm9z6l5u+m+HE+/PVv/CYMk80snOPML/+aCLwRwz9ft4tbPfxlVNJvpvqJKWzfh3ZJG5W3an/A e42H1f0ZIYA4M7dcmUfKJLPbP5Rih+/5JIjkXQKJ0T0Vw1SJcwMnaqMMw0kWgGOwK5lURqxFbpvb 2YArEn8H0hQbGVX3z9MZRiqGTUksrtO7UxNXAHkHz+2SfA/112RX4tv2zsV7xyP7fSok+YdG+U2w uv8K7qYoVmal/oUrr5a0RkIa7af+vhM/6UQ8ikjI0AsyiarL1DR/2TG92Ouhzu0168qSyrQuaLsk FG5QQSYctcF/Glx6rAP0e0FoBOdviIwuA7YLfejZygTeN/KxkT4nXFyOhsSl66j8dEp+/3blxo1o WLiIvk68WSmGXeclW/5MOI5cumlMtCTe8Xmk6nD4kjYfvh8sBC6e56zIJnumOcP9KX7Il3pun8EY G+8/E4WMFSkxd3yCmBm1u40uIke8KxLkQ6cKX84EoQIzqJwKILslgUfOPPf88zP/lk80tcAY8Y7o rxxxn4jLNlObsjyVTMwA+CXqk+yz4hLOuf/1p/+Bqmz+hZcjtfLbmIEAJKciv0y+P+rvgMq5xYom DJX9fb48qjqZ3lCRs2DTytTU8bOTZdIViUxhOckydZH4jq83jzfobtlgSclKAG5iGzEMJVukET2R o3bF7Se8/21lAx+SrzFf921S/I1uhSRgrf7veoO6nYUPqGfnpOB+91Hcgg9DxsD341WkCVVmq3Pw 5CMtXHvo97VCjCRotI4U+kOy6srQ1HuN63h9buLVu47jSsLuu+JATwyOLNXBklFSe0okZB1dYGSU 4pjGZTcl7QCJXhAawdn54S/88GzogmtGAM3MZpwDNFMo1J2FAG/KS+915gaiWfmr0YR96hauz6ni eod8f7jjxLROx7zRMNrp9GTaHIMYdrlsiz+gRlUhG78S78ZyKlF/pO5+7YKkoGX3/z1UJj97mD21 Y1p8/0JpIcXw/WroP2na5q5hJSc5Z6BmFz4iHbuUKbucpPDN9J/BGZRnIfYi2Q8T8T4tMCJoM0Bn pcYlox7aj+/UDCpLd3byDD3xmPobtVTMUW5ls7791c998MMfNYkvFuff/+OfzKMdiOehh7wgkImA Pn3JVAAygQAIgAAIgEA7ECB3UZuomFhWscChVxOFiam6KnK2Jj1IlYIAloohWPGLcy+sPQViJAUB EGg2gb1PnepRr8z5idRfE2227KgfBEAABEAABIoiELogWVSxmcqRX1cJfQgtU0ElZ6qKnCVjQPEg 0IoEcHLeiq0CmUAABEAABEAABEAABIwEDHfrQAwEQKDVCODkPNQiODlvNROFPCAAAiAAAiAAAiAA AjkIvG/klPpabSU+J5ZDUWQFARDYVgQQ1r6tmhvKggAIgAAIgAAIgAAIgAAIgAAItCIBEdZ++OO5 XgjXtd95BV8r6geZQAAEQAAEQAAEQAAEQAAEQAAEmkpg42b0w15NFahJlb/6Utzb2nFy3qRmQbUg AAIgAAIgAAIgAAIgAAIgAAIg4BLA4hy2AAIgAAIgAAIgAAIgAAIgAAIgAAJNJlBAWHuTNUD1IAAC IAACIAACIAAC7Uvg3tlHT9wU6g2dvz/Rr+m5NfPUoanu0MPmcSDlNArfPDlRMwiAQBMJJIe139Ol W57Y9dij4s/IzJZ6zh2fevLY4WvOo1TqbF4bEdknl4PO1LZMKjsjHzIWFd4s6dbVw75UXkZHqqC0 4UKo2v0SJnyeedGl4uwlLgE4rYihFaJSk9ntH5IYqOx8/HOsV7fV5rRCtraL5nIgK72cTuRr5D7h 5ud1WNk7ZMqlSdeeZXbfMmlQRYlcejmE4dEa5eyVYX8SaItdZ5dcRcvyUaWDdCsIOEPDw4rbTMNY WhqDwZbMzircRvb+k+wFDePRwIpsTTTqPw3zHKpAkxNooJ6tWJX1rMN6OI7C333q/isvz471Fqu/ N1zGFkuPsHQWUs4ShA+M7+4Emz90B3qJWjyXHuCpq5tSXDt9g5rZ9iwzwkgJ1OQkMA/XJtIpGrwq 7jcqZ6oRwVJNp7nD6y/JMzyg6PC9uQ3xMM0saNsMPSks1DqpCGs/4U7rRWtN99x4mXvA+6/MjNRU T35mbVQ+uXGc1Z9xV+y2FfAe+DQ7E/KnS5Nym1PUcn1w8VBMJzRkJ8qUphYW3izl8sTBWz1Dnpfv nxTCOH/qQ6xvp1Se+lEicSd4kl1Q2c97PHOis0UcTFcGcFIRsiJSZjK7/UP7Mpkc/0K2am9s2YCX mov7weF6d90zTnlcoGs0vn4yZsts74Sgwe35gDTOyd3u2HyCeWW+eMRo6qWqlrlw2vCIps/XK03+ hB/aOM1xaq/UoTQflZlQ2owhZ6iyRx5SnSttTW2fPoUxcBaELZlGxnBzkG6Ncqp0L2jPhrAzUdJ/ 0sOEqcBIw7UnT2ut7GcdlsOxWACkGKRqI5dfDp6lW4te8YRqZOcT6ehMwEHthBj09rFbd7IcrklA dj3LxJJsTXJywljvuFqA3Di+dkI7TrBrpqq4X+Pk2W5EsFfTPEuPDijeEobPGG9ekgexS5PEQ9EU VrOg7TT02NlnulRicT60urAsW+KFi2zsjFqTe7/OIzNqTs9qnT1sde1huvJ5D4zM/pcX53vHn5BR SVt3F1bY3G39UD1QPpWdkQ9J4U2ycptbGzszupP6962rl+b3HzOvWKjat9ZW9g8oSqx/wOWZE106 0G7qMoCTipCtQMpMZrd/aF9mMGV3l7DkFMaWDXiZuZan66sHLjiLQKciYZ9u92G1kdH9K4t3N1MI sXVnMVJmiuzNT2pheKrpc/VKe39Sko9qGGjSGcZ5SCGZIoxfmIC9MVDsjM4q0hx0Ssqp0r1gG7Sc wURp/2kzTMDmjVZjPeuw4Sxcd4pByjuSNcRmelGQ4kj5moyX9I6R5eHhcH2VzZ/MGhxKRmHYd6+c 2b2Kah8Z6F15TVt83zs7tn58Vgv+Hxx9fOGF6Exbnm0G0CUKn7YjpGlNX6Gj58Z656ad037n8D9J zqq4X4s5jAJB9xd7NU0VRcf3jp0ebVHpYL8Y4MmHpH3YL4sSzQsJHAJicT6v/r61sd472HE34Lx0 Tluba8xbguYAKMqR3Zt71YO3Bsf2s/XNzRzlWQmvly/d1jnD8ltOyp9UZ2JpfjcXVTS7GPsj+YpC l0YgP22BwHMqQma3f0iqH8zuxEpxu7oh17QF6p4Nfp5cnmoqAEkNog83VvSl0Y6uvpWNB/a1iO2w 3p4d9hkqkzLc9ELwzL3S7AxzTOMSHGxTSJPO0OAhKcJNEbpdKg3ZkslZRZsj0a0FvGJsL2gXlkqP ZBMl/aeZJ11gdifQXrhjtCGRJtqtKjDVIEWFi/NDYyfekweOMT+4bK6+cUyGNx5YuTjNJ2y1oy+q OHn3JDA2jmx16qBzTUys5x17oyuya2ZxVX5h4Lrp6NuuEJVK7ONr8Z7LEzzu4PLRTr2IHXsG1297 V7HSFG7Xs0wlpmpNrZDOju60QqZL34Lu11KkdHpGUlPjO9/YvT+6MSzmmbcH3Lhp8qEoztYBbqOh J2ebENnlybn3fHVqmp2TQZv17otPB26Y8yiIiz2hQ7w84ojXY/DY2pmRjjyl6HljhNeTUW7L+/ek Y3ODrP2TMghHLJ9Os0Gfp+M3C0aXDVgBwHPaAJnd/iGpdji7ipW6/8ro2sHgFeuCjS1bG2TN5c0h shawHfJFmj5nryT8iRir/HsTcfdxDMAtfVTDmot0hkYPSXeuhgnbXhUZbSnsqM0DltGl614xvhe0 F1MmouoI/2+pJcUzWmBuJ2ApTVskI020gKlIPBy+tcrm1Hxs12Nj2mGJG4ZW6+nLgNeNuPbvvRsr sipdrFq9IE0ZBKcffVsV4anJQ0GvezsLcydOzvV1RWbWvAqmwpW1n7zRGXi7Hl1xrp5lp0tsKls5 LatqQfdrLZKliqZk9IDiXz24wMbcFxiRD60d4PYaenK2CpFdLM7XWU+HClLsHX/W2Wzbu0/zFOLg Ttw9cOLbc0ohwuNvjk13zb4izjY3H6yz7s7OnGXGCB8sefPa9ByvXXptN5xJe/Xd6WzH5s4WrJgW XN6j8VQvXSgOXTZKhQDPqQiZ3f4hqXicSPxyAVt7sCXvYpRhbNlaImUuIfz6Rmgw5Ufl+kN+EEQM w+aKMl1OSSl3c5O7Tc+lkJsaWXulwRkq5Wp7BvukgaX7xZaZrqgCUpPO8NMXYzykqlQjXIAU274I z5YoZ8XIAYuZ3VrUK5p6QTuDN5so6T+ThwmqwIxOoJ25+7qRSJM5K++a5QalhpVf5fAX0tz/l/Ze lYZVZLQZ9855QEf+cHbg1rD7Bjg/8+59PfUrd3IZYHrnn7U1i1saxCrcgu43VqTOXM3HXyJGju/a 1YPdp+pDq1PiBgT5UKs+0QFux6EnX/PoueV3zo+PivvS/NYKk03Cf1sz0zedIBk+2Iszc21lLoZ/ vqAVt2X4y6jE5krUC8RJKLp338AeaWTyVu0+76sYGS7AqJoMwssq9Es1/q6PH87kvPqO3bsy5W9k egqkE4m/kmfK4SlX5iF0xTVcmpJyA0+nSIQYmd3+YaQRpYXGs/WuzcTongZhc9KK9xdMnfauXSlL 58tC5TqlbZ+4KbsSPwpw3hzhuFS/T4VE7x/lV7lO+G8ab45mJdbq35jyKknfK2P8iSxV+ArnXpa1 KkllWhdUVELSGX7quBsdEPWQTsUE4aJE2o7l+LZEOCvDgGVwa7Fe0e8FeUfw1m8ls4nS/jNxmKAK zOIEWh9dURKSSBM5q9pzDlJy3CTuV9OqifDpjDcr01UUrl6YovPmrcCUW43sqa+CB4rnfoNHvw6H L2lzsOsLi3rKtBWFOoJN9kytee8sPzwrYmmQZM+Nd79JEmmzC8v+kliinyBmBeQeNoh4EO+KBPnQ Kc7aAQYmYCmE3d5Jg985l5+LXJFEnC9Jak8UKP78ic3D4k7vGXZaXJg5x54ZXnx8NnS/xaXKr2zp YUXRYvu0aBy14lrRPmJJZk8sM/AZzEiZXoOLV2G/NuqG9Dj3f8KbrHYiybdqy2tIvvAUOovwoZz2 mAgnPfCabxWeDUz0Gypyls1aI5IcyDLpikSd4Vag2Woi8Y1zd89FfAvQseqA7jlBNyq7ztmVn4+I J+ekAL5GClHwYaiN+Ia6Cn6hymyUPrnrSfIJftPn65VRZyg+QuPeNvRrSZLH4E7Dn+rNzSVfAUFn 6JSlPzR0rny1tl1ue2MgbUl+uNTorKIDlhqsXSdAe0WiFwhfYTuCV6iJrE2U8p8UebJAQ8NViFPx oqaZddgOx9FBSiPvO1Xyod6P5AvAxWSAF7i4T42AQgZ+Kd0NBbURidsM/xiQ9w0jb+qodzqnojRy kqboSMjPiuoyvNT00zTyk4TU5GdFs5c7p33hZY3+6BP6T7oqc89S6ifISU45qMmJT8NrNVegtHL6 FkIaZzPdb3ACJgSVzWEvkv0oY5ylSzyBAUWbQPqrGOqh/SyImoAV73wqXGL8d86Di/MKqwnRQWBb EeBu99JO/5rZttIdyoIACIBAHgLwn3noIW/ZBMSyiok1W9kV5Sy/KnLmVBPZQaB4AvGLcxnWjh8I gEDFCOydON9TP6TeeTOhvhSAHwiAAAiAgAUB+E8LSEjSDALy4yyhD6E1Q46kOqsiZ5Ie+HcQaEUC ODlvxVaBTCAAAiAAAiAAAiAAAiAAAiAAAm1GACfnbdagUAcEQAAEQAAEQAAEQAAEQAAEQKDdCCCs vd1aFPqAAAiAAAiAAAiAAAiAAAiAAAhUjgAW55VrMggMAiAAAiAAAiAAAiAAAiAAAiDQbgSwOG+3 FoU+IAACIAACIAACIAACIAACIAAClSOAxXnlmgwCgwAIgAAIgAAIgAAIgAAIgAAItBsBLM7brUWh DwiAAAiAAAiAAAhsTwL3zqqPjD46uZwPwNbMU3ZfKuU15q0rn6S5cutq8r+PzGzlKg6ZQQAE8hIg Fufy64VBR7M8oTzdriyddvPaSMRLCl+gvOfhawlugMrOyIeMpZEzoKaX0ZEq3s9StfslaB+dTqFm 3obU8pcAnFbE0ApRVcjs9g9JNlR2b0gO2FVzWqGoBnUgB6YavkauoXLz8/umyCInCkuTrj2HPodO gypK5GaUY9v0qXp62J8E2mLX2SVX0bJ8VMNAEj6fsdDD9rOZcvBaGoPBlszOKtxG9v6THJvKUb4V SiWNuRUEgwzWBAIjV4ZF7+5T9195eXas17rCfAm5yZ1g9Yl+pxTNVfIprjYhzFeLdW5vAmCdQ09Y Gxntnjroj26pCiEbjj90IUivJRpUOqWnrm7K0rMLnKezR0Y0ar4UmDBka8qqjAhROVMNUpZqOs1N bpyFW1OH7xkk8TDNxKw6o2Fkcb48cfBWz5Dm1ASv6Z4bL3Nnd/+VmZFaqq4qlgdPszMhL7k0eWiq +7ws8Prg4qEYizdkJ8qUU0l7OUNq9k8KYZw/9SHWt9OoJyUS9zgn2QWV/Tw74SyTNq89szYqH944 zurPNGYzsgzgpCJkRaRxkNntH9qXyeSQHAJub2zpLLshqbnTGa531z3jlMO/rtH4+smY7a29E4IG t+cD0jgnd7sDIZ9JuGW+eCRll26I4qkrsW16655u8idDynHxP6f2SilL81GpGWTNEPH5oqDIQ4pw 1hrbNl8KY+AMCFsyjYzh5iDdGuVU6bGpbRsgarftq2p7a6bGLD5FjB/jWgDC1szpiz0XnOHAkcfv 2s6w2wJyWouw+1R96OalpGMzU3ExDed4LWcXo7eP3bqT64ieHLms1BTLucgsiJwvMdY7rpY/N46v nUi91VKVEcE4n7cbpOzVNC8comOct6rik1jHIJcmiYeiya0mZpUaDUOLc6752tiZ0Z2+fS+9cJGN nUm7Jvfyc3OPzP6XF+d7x5+Qu4xbdxdW2NxtY+gRlZ2RD1PJGVXTV3jr6qX5/cfMKxaq9q21lf0D cuXDWP/A0OrCsnA5nUdm1HKI1Tp72OraQyuvkTNRGcBJRchWIIUns9s/tC8zmLK7S6w6UxhbTvIl ZF+erq8eCI36wj7d7sP4Jvf+lcW7mynq3rqzGCkzRfZKJLVr+tiebu9PSvJRDQNNOsM4DykkU4Tx CxOwNwaKndFZRZqDTkk5VXpsateWS7LbdtW7jfWqfWSgd+U1uYbTT6TVcbrYQg2GjLmHsRSRaMQZ VaYs1w3tPDS1ksT23pUpdnzUmf4ZE4vT42syKFU7MQ4p5RxTiQj5q15sqXhoUJMoU549DtdX2fzJ YGgqpbtZzb1P8POkK15oWBIC8t+1hlP/fu/s2PrxWS++gLHB0ccXXohO/uXZpkW4RI7OnmkWVDt6 bqx3bto57XcO/5PkrMqIYD2fp4ceezVNFUVbs2OnR1tUOtgv5hzkQ9L+7Fdqmcy7/EyBxbnsPOcC 69KtjfXewY67hE/JLNvW5pqa23EfdPDW4Nh+tr65mbk0J2MaOQk1/erlpPxJdSaW5ndzkftQOVpc mo/kEyp7q/c0pRaStkDgORUhs9s/JGkEszuBSdyubsid7AJ1L6QtUhXiqaaifdSI9XBjRV8a7ejq W9l4YF+s2A7r7dlhn6EyKdM2fWxPN/uT8KTHnk8aH2Vfas6UpDM0eMgw4ZxVI3vIlkzOKtociW4t 4BVjx6Z2aoXYkb2dFN1OuogdaieS0QvekcfpYtVaO3rMPQvhg73Ydx492knT4avTQwsD18On8dEy Q7FpfQmwl27f7BvYE67U7dr6VdC5+sYxGVx5YOXitJou8jmwdn7rnOXw5/O32LPytPbCfnF2ZVbT LfP6OLv4ND/rrh19UcXzuweJ6myMH1k7UZw8ko450XaBELyQmrU9g32u38hobVrDiRKWJ7iml4Ot s2PP4PrtjFsAeTp71llQZ0d3RhiW2VpwRLAUyVJBUzKqNfle8/3RjWEx9b094EZtkw9FqbYTs+qM htrinOo8QunVqWl2TkZy1rtl/y/k53ilmZGOQoqzl9OkphQj6djcIGv/pIx4Ecun02xwKJSKR2tE op6KUtq+nAKA51SEzG7/kFQ1nF0FJt1/ZXTtoBaAVIDu9qBLSOmNuCWU3TZFpmv65J5O+D0xMPj3 JuLu4xioluNLszch6QyNHpImnL32bZ3TaEthZ2UesIxuTfeK8WNTOzVB7MjeTopuD13m1IRqF4/l vO5GX3r3Rf0D7b373NgxvuKKOcEW6zEvIlJGnKnTeP9FRV6Z2tmgHeqejkgckR9k618FdYPgaj3u Slgs7MmjoKFRJ1iV7x3Io2aTml6ZfnwBITPfF2Yuz8fGnNOjeDVrXd1s7UGW2T7VcLz2k3N9XZHJ Pm8IFomfl1fPtAN2qhFaobPbyGlnQDJVC44I1iKlUNO+Nf2rBxfYmBsgQz60nphVajT0Fueb16bn 2M0xeUDnRsWoeKHe8Wed7S7hIByPlqMxRIz3zbHprll5aXPzwTrr7uzMUZ6b1UpOs5q8GHF3KNOx udjB5RuWYuJ+eQ9bZ76zFmee4o6EvydagKYpiygEeE5FyOz2D0mN40Tilwvk0FKI7il5F5ZcCL++ ERof+VG5/pAfpBNjnlmEBt6wKIxDuoJsmt6mp8f6E3GwkGHuYuWj0qmbIzXpDD990TQQeDW5hHNU jaw+Ac+WKGfFyHGZmcfQqFc0jU3t1QaxI3t7qbo9tHGvLvv3ImXgq3v07Z307n5yXF5d5pFQPcZj cyMyuswWJJxLTX63xb04Laeppb5oJtpwHCd/ODtwazh66WD3vp76lTspgeft7FlnQcWtVmIVbsER IVaknMs3Q2tqVw/ESxBWp8QNCPKhBjNxYlah0dBbnPt7D35UDN/z4/dGmIQi167TN0V8kXMBRlxi 4S+jEjsZcfd8olYo5nZuIJC8VbvPfcul2sVMusVB2TUlp5MuUKZBTZmU3x3y91a9StKJxF/J419A 4qDEmXlTV+ZCj9zA0ykSIUZmt38oVLAr07cM745KjO4pB4QmJBfvL5g67d1xkhII76P8lMRyQsXU 8c14500Hjv/y+1RI7v5Rfm/qRMZ3sTaBQeoqLZqe7ul6TTH+xPMVziUoawGTyrQuqKiEpDP81HE3 OiAwEOh1+hfAipJkW5cjrFHZEuGsDAOWwa3FOmp/bMo7grdic8WN7K0oL2RKS0Ac/zo/0WW87OLt 4gvLVxfnY28Oyjht95DWncoyskx/MBVdJvHOOcuwS+sIzy/Qrthe7Y5XMzCRFtHXgbuiciIRvt0d r6YgE4wISDcTjrYu76E89nY4PL3nE5L1hcXA+JK4Cojt7DZyZpoF3TvLjy2LWK0kWX7jR4QkieTi yDhIJeaOTxDTmm7shrBG7y3d5EPNM1hNzAIrtZwKlJRdLM5j18OdR87w6z0yvki8SDbtlpu6pui/ oEL2zL0T4iXtXsySf6osbsoFfmR28qFRzkiZBpLSX0dDjOxE8l7lP/za6H3nXo04neOO3YsmyrTp kLrZSwBOK0JWJMQNEyOz2z+UBKzK1L8cxt/b74STGY0tNdomZOCBxGI8c+NZpHuqjVw+f8C5YOOF /NVGnuVvcFF9StysU31KtREPY1NGqN43I8bIISdGxuZbhk1QO32V2kdQEpve0NODlZL+xP9ix4n1 cdfACvBR6fVtfA6ScOPFaPEa7Y2BtCV7Z0WlpB01NTa1OEWIBwJRAjIWXY1x013j+uVBcfp6cW5o n/eqIGXzwWmnGDd7tCFSTmXJMv3BlE/n+LdO4n9+wLmezr9zHvd+bz4Wz46tq3jV5I+uRdTkFeox 5P5EWhyzO9MG9TEX7i7cabz3ReRYNeUtAPclx0oxGY0/n/WKuCzCESN4mNd5ZLRnZbU4i7eSk5wF kfMlcbH3oGwgMeinPmmryohAymk/SNmraVw4hC0gMKd1157kQ/fT2k4bOTP/eI20lVpxpldsSY+c ee75wx//ZLGFojQQAIGSCXDXc2mndxmv5MpQPAiAAAiAAAi0IgF+WOrvyTZcQPGqOf66tfKvLobV 5HOAxX2l1EvOLvjDMXY+6TZ4w/FHKqyKnM0nBQmaS+DVlz73wQ9/1CRD5DvnzRUWtYMACFgR2Dvh nQOk/vamVQVIBAIgAAIgAAKtTYDfG5/z3qDWBFHFad5a+TfFGqcmf3V26HPC8nsxoQ+hNYF0YpVV kTNRESQAAZycwwZAAARAAARAAARAAASqREB8sOAm6zs+G/pGV+N14JLc3lfWqbJBzXJOzvn5PP9y lfwSLX4gAALlEYg/OcfivDzyKBkEQAAEQAAEQAAEQAAEQAAEQAAEHAIIa4cpgAAIgAAIgAAIgAAI gAAIgAAIgEBLExAn5z/yP+OFcC3dSBAOBEAABEAABEAABEAABEAABECg6gT+8It4IVzV2xDygwAI gAAIgAAIgAAIgAAIgAAItDUBvK29rZsXyoEACIAACIAACIAACIAACIAACFSBABbnVWglyAgCIAAC IAACIAACIJBE4D/+80d/7G+LP/WXk5LG//vDmRN/e+I/WpTBa8xbl0UtZSXR1eR//8TMV8qqCeWC AAhYERCL8x/zu+LmL32C8mgvTyhPp6W0Kl0mosoUvkB5z8O/9DC+KPvsBuGjxZO12z8k5aWyeyNE QM0UuttD1lPaEyPLJzEWYBhfuX7YHyw9i3LMIH5go2r3S9DGztLZZmuRPLkc3QNTDV9NlxunEezF cqKwVHfxyuw+KNoy84jZ0LyEPdAa5TaSgNG6OoYeVhwmY2H3HjC5H/vnS67eZXmGhtoOKmtjAm3o /9u4tWJUC4xcGRa9P/RT93/5V2ef+kCD6PER4Syrjz3mVKeNCIFht0HSyCl3BmiOeDtGDndNfcJ3 +6mkJhuOP3TnHrKHCtnkoHPi+qa3RkgtMDp7qpZB4qoREIvzX/7MyHuF3LwLPc1+JuzRxEz0Ss9n fpU7u/tuSnstyTKX6iNTHZOywJnB5ZGYjUky++Yv/ezaYSnPZz7GLv+s2uSjhacEJbPbPzQsaAmR mBwhInLa6m4PWU9ZBvAiDOPliU/c7nncGywfm1Rk5J/646xvx/tN+lK1c788wU6p7JPsrLMuJRsx G8YWycVH2eHLXXWPlRz+9e4z/mAiZntr75iD94BkNflDQi0xcvOZhFvmi39vR4soaykGbY1EX8tv JCGjVQJGHlLd3FKX5iczuffHlX/mf35KffDW4FiKHzKazwQSVJNA+/n/arZDMVKrMYtPEePHuGIq y1XKw5kLn+055fhJpyTffzrDbq4aGpz5h36q/vivXEo6NjMJFdNwztTF2cX4QB+7fSfrET06e4ON AtU1moAe1s6n8tGZ+tIvfJY99TNq9Z7hR5X58uKtD4z/fbnL+JWXFr7E5l42hh6RInX+vc+oZQZ7 b62HfWntd8RfyZSkwGR2+4f2ZQZTdnUJhil0z0DbwCFFpSTG/IaxVJ9Ye+pnRsll4FeuX7r1o8fM S0Sq9i+vfelHB5QNsMcGHv/Swv8h4i/IRsyGsTVyvTx9+UsHQqO+wOV2H8Y3uX90ZfmlzRTiPryz HCkzRfbmJ7Xo6aqv5TUS0mjjLFmwUVVX5mfv3kvyDJUhBUFbnkDb+f+WJ94IAXd8pP8DKw+/LKrS T6TVQavYWwyGjLmHsZRo0YgzqkyR00s5MvWlJCX/47Up9rFRZzZiTCxOj39JBg9qJ8YhpZxjKhEh f92LLRUPDWoSZcqoruHLX2K3JoKhqZTuZjX3/n1+7nXNi5lKQkD+u9Zw6t//4z8fe/CxWS++gLHB w/sWfiE6+ZeH6kkH6ejsmRoFmapDQCzOY93ZxoMPDL7/JcKnZNbxK1tragrLfdAnbg8+9aPswdZm ttJEUd4iLX0RZHb7h2SFwexOkA9X8zNyY7VA3e3VLaXShykMQzrlc4blt1weHFGnc2l+v7KoboKJ xWokX07DSCNHiWk9LVQctRqxfmdzRV8Bvq+z70ubD+yFENthH+h5n32GyqQM9zUheA4jIY3WYMlU 1ZXgZu7F4bmdvTppPIN9qUgJAvYE2sP/2+vbzinFDrUTWOfFKMnjdLFqfe+hY+7WPF9Ri33nw4c6 aRp8dTqy0D8TPo2PlhmKTUsKjV96+Vf6+j8crtT1n/pV0LnLm8dkrN+BL312Ws1e+BxYi2Jzzpz4 81u32QkZOHDqR8XZlVlNt8yZcfbZp/lZ93sPvaji+d2je3Xexo+snWhTHqjInGi7QAheSM33fnjw A+7omdG6tIYTJbw8wTW9EGyd93148MHdfFsAalKdYxWQUTtkA4GSCYjFeYfs1cbfl6ZeZOdU+HFC yjSyOl7pMyPGcObE0nh8aSSaKDGTn4DMbv+QrCmcXcUV3//lJ9c+EbzxKzxyHt1T6OkkLQB4qFJL w6CcsldS0rG5Qc/HJj/zsbWzcr16gQ0+HkqV0zDSsy07hzfill1RlcuP9LU8RkIardGS6W5eDZhE L+aHEtp9nLhrRwYVLT1DNQBByqoRaDv/X7UGKETeOTW+/xiPuZtxIzq9t2P4B9p7H3Njx/i+c8wJ ttiV9gL0ZMSZOo3337jhlalFGtpp0vP+SEygH9buXBrlJblBcO/vcVfCYmFPnkw8/qQTrMr3DuRR s0lNt8zIMXVAcr5hylyef3vMOcyIV3NHVwdb+3LCC6FIPFTD8don5j7Q2RHOwBuCReLn5Z1H7YA9 thHQ2e1sFKkqR0Aszrl3c/wUKf4Hxk84213CQcSltNNexKL/ytiLnbPyNuPmlzdYR63TLqufSpwl ilvH/l5jqhLI7PYPybriROKh19LTFaJ7Kk154rIqtTKMzV+6MsebWx78utFWXhyauKyV6dhcbJnz HWKxhLjwYfaA+aNjTsNIy7bU9KLhNjZCl7L4Ubn+kB+kE2OeWSztJkipsjevcLevCcvPaCSk0X76 SowlK3W1qpunf8qaY3uxOD/JMEWz8gwp5URyELAg0E7+30LdNk7iXl3271rKK0Xu0bd30vtDR8bl 1WUegtdjPDY3cqLLbEGsudTkN7w+MO68N0rMmkp90Uy04ThO/nC2//ZwNEr3h/b0XL52JxtwdPZs 3JCrEgTE4vzFXzG/jotvyLEp51rIwxmV0rkAIy6x8JdRifdLxQXGRzGIKawbCCRv1T7mvuVS7WIm 3TYRAogzc8uVeaRMMrv9Q6GQXZm+6mKTcvBv8e3VGN3Ls5fcwAnRKMNwkgXg+KdwfrSVu5fML2v5 m9leHXY24Cbn7wXxb3ylM4zygBdVsrhOP3XBeaOpU6hYL33J7ZL8LFfF1PHNeOfivRPd5/epkDCP jT71gbmzGd/FWpRiZZbj9TW/krRGQhrtp550z5OjluxavtvNy9SvyLJjerGsRvRQ5bjsf0ll2peE lCCQikC7+f9Uyrd9YnH86/yEX/L0FW8XX/g/ri/eio1tlnHa7iGtO5VlZJn+YCoGjsQ75yzD9qUj fMeOD6zYXu2OVzMwke58f1fwrqicSIRvd8erKcgEIwLSTcyi5shHVR57Oxye3vMJycbCsp7criJ0 9rbv8dtcwUfOPPf8b/V80nkLtBfxIqnwyBzxXNzVcTyUeiJ6Bb9E/TPsgrjDc4797PDyvtnQZRIX K7+N6UbR0GX2+TFL8r0Xn/jsilOvSE9lf78vj6pFpjdUFC1TU8fPTpZJVyQyheUky9RF4tuWXnST nzige0GGWAJwE9uIYSgVIo3oaSbePf7wSTdgybkDFt7EtbKBx+RrzOWw6VsL3QoFcW1aMXqDugbD R6+JOSmRb0KKW/BhyBj47rWKNKHKbJqCaSsmLVx76Pe1QowkaLSOsPpDsuq0SjUvPdGLfW7Mh5mE nXbvWvdsnoqoeVsQaE//vy2aLqIk9zaLj0VOX8TVvF8RaT/wsfGOz675CeSAqM0bNQ+m+yVq3CTL 9AbTxyf5DW1CEl1gXgKPA9UnwF6ZMpkadjWNhKHyG+Dex1OcmYybUlxEf3kPFdcdVtM8jkcnmXrv cL16jJrin/gNef0V9KqEH60HHoZbjmy4kO78NGX2Qm1afARKzYpDeoXVpLoAOvv2dAztpfUffvFz H/zwR006icX5j/zPn2wvlaENCLQ9AT7gXdrhXcZre3WhIAiAAAiAAAhECfDlnLfSazyfwGK7zOrD atJbGEVIQM4uxF4AUyd2+IEACOQmEL841z+llrsqFAACINAgAnvHJnsuj6jPpTifYGlQzagGBEAA BEAABFqCAL83Pue9Qa0JEu0YOcFfT1v6TbHGqck/ShL6uq38XkzoQ2hNII0qQWD7EMDJ+fZpa2gK AiAAAiAAAiAAAu1AQAWQf4CHSZu+oNYoLY2x6EUIYFCznJNzfj5/dyA2dr0IlVAGCGx7Aghr3/Ym AAAgAAIgAAIgAAIgAAIgAAIgAALNJoCw9ma3AOoHARAAARAAARAAARAAARAAARAAgVgCIqz98Mfx QjiYCQiAAAiAAAiAAAiAAAiAAAiAAAiUSODVl+Le1o4XwpWIHkWDAAiAAAiAAAiAAAiAAAiAAAiA gA0BLM5tKCENCIAACIAACIAACIAACIAACIAACJRIAIvzEuGiaBAAARAAARAAARAAgYYRuHf20V2P iT+Ty/nq3Jp56rGJexZl8Brz1mVRS1lJdDX530dmtsqqCeWCAAhYERCL811uV/Q82q7HDl/zeufy hHJz4s/ZJatSA4k2r41EvKTwBapMrSK6aCo7Ix8y5olq4Vy2rh72fbeuY7JPp2r3S9BceQo103M1 5igBOK2IoRWigpHZ7R+SmlLZaQNuTisU1aAO5MBUw9fInRBw8/NtXmSRE4WlSa/nir/4lkmDKkrk FinH1Knt7SHsTwJtoTnDsnxUw0AGnKFba+jhtrCZAohbGoPBlszGGW4je/9Jjk0FaNpqRZi6Z6vJ CXkSCQRGrgyL3t2n7r/y8uxYb2JFxSTgffMEq0/0O6VprjIw7BZTWXIp3gQgOSmRojYy2j11MMtU PzzlcBuOt6Y795BeSzyXTumpq5tSgAwCF9DZIyMaNV8KzCKstmkiSKsyIkTlTDVIWarpNDe5cRYe 48i1J/EwzcSsOqOhWJy/MjNSkwYlPZr4c+M4qz+jNs+WJk+yC/LhKy/Xh25e8hftVh2fm/vT7EzI Sy5NHprqPi/LvD64eCjG4g3ZiTKZaNfpnhtKVFcjo4zLEwdv9Qx5vrt/UinuqMn6dioixI8SiXsc j9J5dsJZJm1ee2ZtNMzTilqORGUAJxUhKyIFJ7PbP7Qv02DAtsaWg3pZWbnTGa531z3jlMO/3n3G 10/GbG/tnVDdlh2QXXhytzsQ8pmEW+aLR4ymXpZWDSqX7tS2vdLkT4aU4+J/Tu2VipTmoxqEScyT As5Q1Rt5SI0ODROxKhWlMAauEmFLJmcVbg5yDKVsmx6bqsIztZwRpKlLQIbWIKDGLD5FjB/jWkDY rZnTF3suOMOBI49vh86w2wJyWouw+1SGqb5XekzDOV7L2cXo7WO37uQ5os/R2cVyLjILIudLjPWO q2XFjeNrJ+zCKDTSVRkRjPN5u0HKXk3zwiE6xhFrT+OC1GpiVqnR0BzW3t0lJ+0dO3vnptX+1vLi fO9gf7qpPDf3yOxflDP+hNxl3Lq7sMLmbhtDj6jsjHy49MJFNnbG2WVI8kK8gdfGzozupNJtXb00 v/+YecVC1b61trJ/QK58GOsfGFpdWBYup/PIjFoOsVpnD1tde5gkVhH/XgZwUhGyFUgNyOz2D+3L DKZUBpzC2IrAX2wZy9P11QOhUV/Yp9t9GN/k3r+yeFd2T8vf1p3FSJmWWaubTOvUlr3S3p+U5KMa Bpt0hnEeUkjmjA4NE7IqFdkbA6WR0VlFmoNOSdk2PTZVhSfk3PYEah8Z6F15Ta7h9BNpdSortlCD IWPuYSzFLRpxRpUpy3VDOw9NrSS1wL0rU+z4qDP9MyYWp8fXZLSmdmIcUso5phIR8le92FLx0KAm UaY8exyur7L5k8HQVEp3s5p7n+Dnc1cyxMlq+msNp57eOzu2fnzWiy9gbHD08YUXopN/ebaZIVwi qaG0f880C6odPTfmrYZ4YVZyVmVEsJ7P00OPvZqmiqJTDnLtab8gtV+ppTCcRiYVi3PNnTlxHQdv Dd5wNgL5eH9/dGNY+JTbA8kn0hayb22uqbkd90G8orH9bH1z0yJfbJKtjfXewY67hO+LZpM+4pxh +S0n5U+qM7E0v5uL6mKSWAZE8gmVvdV7mlILSVsg8JyKkNntH5I0gtnDBlyg7oW0RapCPNVUtI8a sR5urOhLox1dfSsbD+yLFdthvT077DO0Q0q6U8cZs9mfhCc99nzS+Cj7UnOmJJ2hwUNGR4eclW/3 7CFbMjmraHMkurWAbceOTW3WBtm7Z5uBaBt1xA61E8noBe/I43Sxaq0dPeaehfC5l9h3Hj3aSavO V6eHFgauh0/jo2WGYtP6Ekgu3b7ZN7AnXKlrh49qewdz9Y1jIhbg/IGVi9NqusjnwNr5rXOWw5/P 32LPytPaC/vF2ZVZTbfM6+Ps4tM8rLV29EUVz+8eJKqzMX5k7URx8kg65kTbBULwQmrW9gz2uX4j oylpDSdKWJ7gml4Ots6OPYPrt7NvAWTu7FlnQZ0d3RlhWGZrwRHBUiRLBU3JqCkHufY0LkhtjaE6 o6FYnHfLXi1/Kq7j/iujawed+A0//OMCG9McTc62cL3SzEhH3pLc/KtT0+ycikvXNIqUTvkIL1HS sblB1v5JGfEilk+n2eBQKBWP1ohEPRWltH05zjCQB3hORcjs9g9JVcPZowasDYF5dLcHXUJKb8Qt oez2L5Lu1InGTPgTMTD4F3/i7uMYqFr6qIa1CekMjR6S7lwNE7a9KjLaUthRmwcso0vXbTt+bGor prm7Z1vRqLoyc2pCtYsHOV53oy+9+6L+gfbefW7sGF9xxZxgi/WYFxEpI87Uabz/oiKvTO1s0A5i T0ckntQPsvWvWLpBcLUedyUsFvbkUdDQqH/VVB41m9T0yvTjCwiZ+b4wc3k+NuacHsWrWevqZmsP sgSdUw3Haz8519cVmezzhmCRq7LyPpp2wE42Qgt0dis57SxIpGrBEcFaJHstDdP46MaNehOB2rrS 1p7kQ2tjqNRoKBbn3Ls5fsoDx2OzVc/Uwj/ERZTVKSIKJWXDiBjvm2PTXbPy0ubmg3XW3dmZsgwq ee/4s862nHBkYY2cHJvXpud47fIc0g3+8cKixN2hTMfmYgeXb1iKifvlPWyd+c5anHmKixP+nmgB mqYsohDgORUhs9s/JDWOE8k14EJ0T8m7sORC+PWN0PjIj8r1h/wgnRjzzCI08IZFYRxyFUR1aitj jvUn4mAhw9zFykflUjdNZtIZfvpijIdUpXujQ5rKkNZEwLMlylkxcsBi5jE0atumsamNWyRj92xj ItVTzb267N+LlIGv7tG3d9K7+8lxeXWZh0f1GI/NjerTZbYgrVxq8rst7sVpOU0t9UUz0YbjOPnD 2YFbw9FLB7v39dSv3MkDPENnzzoLKm61EqtwC44IsSLlXL4ZFmXk2jNpQZpoDBUaDcXifPpm5P1n gevl7v6Z2H4TKZ0LMOISC38ZldjJiLvnE7VCMbdzA4Hkrdp97lsu7W5xUHbN77cwd+NgayagUeBm iL/F4gf/uFub/O6Qv7fqVWJ1scRLzV/J419A4qDEmXlTV+buZDoX8HSKRIiR2e0fChXsyvQtwzPg GGPLMyA0Jq94f8HUaeeNpk6Vwvt4e2T8VE3F1PHNeOdNB86Gmt+nQqL2j/J7Uycyvou1MWoXWUu0 U1sZc4w/kdKJYtO+gCOpzCLVtiqLdIafOu5GB0Q9pFNqlpePWAm0PRP5tkQ4K8OAZXBrsbbtj015 R/CWb6cs3bPlldruAor5p/MT7evhEG8XX1i+ujgfe3NQxmm7h7TeFJEs0x9MRZdJvHPOMuzSOsLz C7Qrtle749UMTKRF9HXgrqicSITP1eLVFGSCEQHpZsJRa+WujMe0Docvk/MJyfrCop48ZUXhzm6T PdMs6N5Zfp5XxGolqSc3fkRIkkib8BQ/o45ZlIXXnlJO8qHmGawmZoGVWqL6TUnwyJnnnl/7Hz7p vAXai3jh22zuklWO946D4rE6PKV4wi+ln2GnxR2ec+yZ4cXHZ0OXSVxl+DVFN4pGPlIliBdROEFE fX7MknzvBa/LSSOSk9kTy3RrkTVGyvQ4i1dhvzbqxs84V5LCe4p2Ism3aq9qCoqKPR2dGjW9ymvr RDjpgddIRQwVRYGTHMgy6YqoRqTZaiJpBmwytvLaoNCSdc5u2/Hh5+ScrMVvTa2feg9DbcR3r1UE B1VmoUK3SmHRTm3fK7WUbs/1u7l4g6vjIQvwUS2AK+gMHYH0h4bO1QKit5II9sZA2pJxZJQ6Rgcs tXJw+ztt28TYlGYEbyW6CbIYkFZIA4jqEOD9aHFf5FRD3OO4KS3++Hj3xTU/gRwQtfmVZgmyQOef qHGTLNMbTIfO8xvahCR6Q/ESeByoPgH2ypTJ1LCraST6Kb8B7n08xZk6uinFlc/b+6i47rCa5nE8 OsHWnYM7eMWoKf6J35DXX0GvSthfDzwMWyzZcCHd+fHV7OXOafFxJTWGhvQKq0n2CnNnt5KTnAVR 8yXfZuRr2/XvQFnJWY0RwbDUsh+k7NU0LhyiY1x07cnTUA/tJ2bUSq15XvfVlz73wQ9/1FS/WJwf /vgnmyceagYBEMhAgPu4Szu9y3gZCkAWEAABEAABEKg6Ab5M8lZ6jdclsNgus/qwmvQWRhESkLML saxi6nStpX9VkbOlIUK4BhCIX5ybP6XWANFQBQiAQEYCeyfO99QPqc+lOJ9gyVgSsoEACIAACIBA JQnwe+Nz3hvUmqBBbeRZ/j7g0m+KNU5N/urs0OeE5fdiQh9CawLpxCqrImeiIkgAAjg5hw2AAAiA AAiAAAiAAAhUiYAKIO/jYdKmL6g1ShtjLHoRAhjULOfknJ/P868m6wHtRaiAMkAABEIEENYOkwAB EAABEAABEAABEAABEAABEACBJhNAWHuTGwDVgwAIgAAIgAAIgAAIgAAIgAAIgEA8Adw5h4WAAAiA AAiAAAiAAAiAAAiAAAiAQJMJYHHe5AZA9SAAAiAAAiAAAiAAAiAAAiAAAiCAxTlsAARAAARAAARA AARAAARAAARAAASaTACL8yY3AKoHARAAARAAARAAARAohAB/vbn8yOijk8v5yuPfMLf7UimvMW9d +STNlVtXk/99ZGYrV3HIDAIgkJeAWJxf8zqi6KLKqR1OeJii3s1rIxEvSVZEl2mfnUpJlmmvpr2c VEpvhCiUZyJ6e2JkUSRGA1v+1Q1lMBbeXH6C0h3AvIyOvcUPbFTtfgnaV77t2yuRYqskcHQPTDV8 NTWefhOILHKiwD+14sxRQp9Dpy2zVVQuSA6TjaUxkoDRunKFHlYeZrgXB0xul//93rI8Q0HtjWK2 O4HK98Tt3oCe/oGRK8Oid/ep+6+8PDvW2yCgfEQ4weoT/U51mh3y8VebnzRIHG8CkKm+2sho99TB jJ9tJxuOP3QhyMFXNKgcdJ66uilFzCIwOnum1kWmyhAQi/P6M2qfbGny0FT3ee7U7r9yfXDxkOpO 5EN79Xi3fJqdCXlJ+zLJ7JvXnlkb5UK+fP/GcU14oiLD4pPITpZJPrQvk8kRIiInAdmeZ2LKMoCT ZTKxRJnuuSEVfGVmpBYv2vLEwVs9Q95g2T+pyMg/9SHWt9OYn6qdu/iT7ILKfp6dcNal9u2ViLFF EvBBa7jeXfdYyeFf7z7j6ye1fbSw1HsnHLwHJKvJ3e5AyGcSbpkvHklouRZBkV4M2sbSGEnIaJUI kYdUN08vbZNymHrxkBoI+B/ng7cGx0J53XSeoUmKo9r2I1Dpnth+zZFPIzVm8blo/BiXr5JCcm/N nL7YcyH4YXDffzrDbiE1NaiQ3afqQzcv+edz6aqNaThn6uLsYvT2sVt3Mh/Ro7OnaxakrhoBGdbe 3SXm58uL873jT8jNv627Cyts7rbY36IeplCSLw8is/8UZVLZWeeRGbXMYLXOHra69lD8lUxJCkpm t39oX2YwZQzkFDwTk5YBnGS79MJFNnYmaU3uyLs0eXJt7MzoTkr8rauX5vcfMy8Rqdq31lb2Dygb YP0DQ6sLy8LHk42YSKyFEyxP11cPhEZ9gcvtp4xvcu9fWby7mUKHrTuLkTJTZK9mUs3G7I2ENNo4 S/Z9aWUo2fdi0gnk9wyVIQVBK0ZADbj4VZ1A7SMDvSuvyTWcfiKtjtPFPmAwZMw9jCWnGl5kqB+p Fy1TluumPDS1kgTw3pUpdnzUmY0YE4vT42syeFA7MQ4p5Rwviwj5q56o4qFBTaJMGdU1XF9l8yeD MbDRaLs4Nfc+wc+9riwlqR7771rDqXT3zo6tH5/14gsYGxx9fOGF6L0DeaieLlwCnT1XUyFzKxIQ i/Mbcs9va3NNrdK5azh4a3BsP1vf3CQf5tSjwDJFUd4iLb1YZHb7h2SFwexOkA/nGQM5veDpchQI 3K94a2O9d7DjLjHYRIWTTvmcYfktlwdPCgtM97u5KCM7+Lh1aT6SM6dhpJOktNSeFiqOWo1YDzdW nN00We+Orr6VjQf2Ioh9t96eHfYZ2iElbWPxRkIarcGSw928MszMvTg8t7NXKY1nsC8VKUHAgkBl e6KFbts0idihdgLrvMNSeZwuVq21o8fcrXk+FRD7zqNHO2lQfHV6aGHgevg0PlpmKDatL4H70u2b fQN7wpW6/lO/8TdX3zgmY/0OrFycVrMXPtnWoticMyf+fP4We1YGDlzYLw7JzGq6ZV4fZxef5mfd taMvqnh+9+henY3xI2sn2pQHKjIn2i4QghdSs7ZnsM+dYmU0PK3hRAnLE1zTy8HW2bFncP125i0A dPaMLYNslSAgFucHtVsxjrOYGenQxCcf5lSvgDJ5fGkkmiiFVGR2+4dkTeHsKq74/iuja4mQU0ie KWkBwEP1rk5Ns3MqLr1bDgz0j3LKXsqkY3NDmf2TN46vnZDr1dNscCiUKqdhZMJbaiZvxC21lnYt nLaxeCMhjdZoyXQ3rwZPohfz4ALtPo5zvymNNpaeIU2RSAsCFgSq3BMt1NtOSebU+L6Lx9xdd6Mv vbdj+Afae/e5sWN83znmBFvsSnsBejLiTJ3Gq8vP4o9XphbaaQe8pyMSpOGHtfs3/twguFqPuxIW C3vyZGJo1IlJ5HsH8qjZpKZXph9fQMjMN0yZy/OxMecwI17NWlc3W3uQJeicajhe+8m5vi59VSHF 5A3BIvHz8j6adsBuagR0djvzRKpqEhCL8yHZCUWI+M2x6a5Zeclw88E66+7sJB/m1LSQMsVZorh1 7O81ppKKzG7/kKwrTiQeem2GnEryDIkLAU7U2zv+rLMPKkYOZ6gLp9u8Nj3H7UqOf260lReHJi5r ZTo2F1vmfIdYLCEu72HrzB8dcxpGBrzlZRENt74RGh/5Ubn+kB+kE2OeWSbtJkh5grdSyZSNJRkJ abSfvhhjyUpjt5u3kv5JssT2YnF+kmGKZuUZkgTDv4NAZgJV7ImZlW3PjO7VZf9epLxS5B59eye9 u58cl1eXeXhUj/HY3IiILrMFieZSk18D7B13Xg8kZk2lvmgm2nAcJ384O3BrOHrpYPe+nvqVO7mA o7PnwofMLUpALM7newf7+c6fMHE3Pkdedt3Hd+yoh84FGHGJhb+MSrxoMe6eT1RxsiKVzO62CRdA nJlbrswjZZLZ7R+SciaIJDYpzZDLto3cwAkB+YUiNuXcF9qamb6pvdEtANw/hfOjrdy9ZH5Zy9/M 9uqwswE3OX+/l3/jK51hlI09f/niOv3UaeeNpk5xYr206pLnZ7kqpo5vxjsX753oPtF5yV//6Fjv 3ImM72LNr1KjS4jamIWRkEb7qePueXLUkh2tvG7eaC2z1hfTi2WRgp5yXPa/pDLtS0JKEMhIoHI9 MaOe2ymbOP51fsIveaqLt4svLF9dnI+94SjjtN1DWm/GQpbpD6ZidpF455xl2L50hO/Y2btie7U7 Xk1vxi5K7uzoFpdSfeOQE4nw7e54NQWZYERAuolZ1DL5qMpDLIfDl8n5hGR9YVFPnrYidPbt5Aa2 j67yzrmzWNo7IV7S7oUSqUNp8qE9H3UtxH9BheyZxjLFLdDAj8oujsK4w/SidPSvRoUqEmWFyySz 2z+U4lmVqX/Iir/VPA6yPc/ElCUAdxQJse08cobf+3LiwbrP+3uxkUY0yCwHyGhMl5UNyG9vqNP4 10bvOxeZaMNIJNbKCXjglhjP3LgDuQNSG7l8/oBzpc0L+auNPMvf4KI6r7hZpzqvMgYexqY6i3rf jBgjh5xYhuBHE1uZRDbZojZWvJFoH4/xu3k2cRufi+zF/qfUTqyPu46LdCzkQ6NnaLx6qHE7Eah0 T9xODZVNVxmLrsa46a5x/S6bOH29ODe0z3tzjfJgwRmLGDd7tCFSzljIMv3BlM8u+Kdk4n9+wLme zr9zHvcpNT4Wz46tq7jC5I+uRdTkFeox5H4YqThmd6YN6mMufMrtzta8D9/GqilvAbjv3FWKyWj8 +exXxH0xgod5nUdGe1ZW09oEOntaYkhfMQKPnHnu+cMf/2TFpIa4ILDdCfDB6dJO7zLedqcB/UEA BEAABLYlAX7W2sSNUfGqOf66tYxXLFM0WFhNPgdY3FdKveTsgj8cY+dtboOn0AlJQWDbEnj1pc99 8MMfNakvP6WGHwiAQMUI7J3wzgHi9uYrphXEBQEQAAEQAAFrAvze+Jz3BjXrXMUlFEfQa+XfFGuc mvyjJKGv28rvxYQ+hFYcQJQEAiAQIYDFOYwCBKpJQL7UVP4pf8++moQgNQiAAAiAQLsSkF8pb/6i kb+e9gIbS/dp7jRN0lA15UdJ5Guh/Z96/27oQ2hpNEBaEACBdAQQ1p6OF1KDAAiAAAiAAAiAAAiA AAiAAAiAQAYCCGvPAA1ZQAAEQAAEQAAEQAAEQAAEQAAEQKBxBBDW3jjWqAkEQAAEQAAEQAAEQAAE QAAEQAAESAJYnMMwQAAEQAAEQAAEQAAEQAAEQAAEQKDJBLA4b3IDoHoQAAEQAAEQAAEQAAEQAAEQ AAEQwOIcNgACIAACIAACIAACINAOBOTrzcWfvG9Q598wt/tSKa8xb11NBK+ryf8+MrPVRGFQNQiA AGNicX5N74jLE8qp7fL6p/fEzklFqG5eG4l4SeELlPc8HKidaBL77FRKso3J2u0fWpfpjRABNVPo ns1C7YmR5ZMYDWyj1mIWWX4q0x3AfKOyGUSp2kmzLJ1tthbJk8vRPTDV8NXUePoDqsgiJwpLk04v U5An7rmC0JaZR8wWzGuysTRGEjBaV8fQw8rDDPfigMntOrvk6l2WZ2hB24FI1SVA9tnqqrMtJQ+M XBkWvbtP8S+Mzo71NggeNzn++bGJfqc6bUQIDLsNkoZ5E4BMFdZGRrunDvpuP1UhZMPxh+7cQw6+ okHloPPU1U1ZenaB0dlTNQ8SV4iAWJzXn3H2yYShT/fcUB9Pnhmp8X/jfekku6CenGcnUu+o8W75 NDsT8pJLk4emus/LMq8PLh7y1wwRcGT2zWvPrI1KkW4c94QnUxoWn0R2skzyoX2ZTI4QETltdc9m RWUAp9kS1hIj8vLEwVs9Q95g6X+jm/OpD7G+ncLayB9VO22W9u2VjW3jc/FBa7jeXXe/Z35fDv96 9xlfPxmzvbV3Qpgfx3tAdmH1OXQxEIoPmTrfSH/xiJF84/UttEbaxtIYScholXSRh1Q3L1SRMgsz 9eIh5Z/5H+eDtwbHQrh3ls4zlKkdyt52BMg+u+0otIHCasziU8T4Ma4FNN2aOX2x50Lww+C+/3SG 3RaQ01qE3afqQzcvJR2bmYqLaThn6uLsYvT2sVt3ch3Ro7NbtykSVo6ADGvv7pLz86UXLrKxM3JN 7v221lb2D8g5PWP9A0OrC8vpOhNfHkRm/8uL873jT8hdxq27Cyts7rY45SN/VHbWeWRGLTNYrbOH ra49FH8lU5JlktntH9qXGUypIKfQPZstlQGcZEtZi1HkpcmTa2NnRndSCbauXprff8y8RKRqp82S bMRsGFsj1/J0ffVAaNQXuNzuw/gm9/6VxbubKcTdurMYKTNF9mom1WzM3khIo42zZMHG8aVVwWTf i0knkN8zVAUU5KwEgaTuWQklIKROoPaRgd6V1+S0Uz+RVsfpYh8wGDLmHsaSUw0vYNMPQY+WKct1 Ux6aWklqjntXptjxUWeSHDMFemzimgwe1E6MQ0o5x1QiQv6qJ6p4aFBTnEiHypQnycP1VTZ/Mhia Go22i1Nz7xP83OuKFzOVhID8d63h1L/fOzu2fnzWiy9gbHD08YUXopN/eahuES6Bzp6pXZCpIgTE 4vyG2vPb2ljvHey4G3EfNxdVNKyY4Bah1dbmmprCch908Nbg2H62vrmZrWBRlLd3kL4IMrv9Q7LC YHYnyIerqSAXqLu9uqVUarIWSizplM8Zlt9yefCktMBUv1izzGkYqQQpL7GnhYrdUiPWw40VfQW4 o6tvZeOBvQxiO6y3Z4d9hnZISdtYvJGQRmuw5HA3rwwzcy8Oz+3sVUrjGexLRUoQSCQQO9Ak5kaC liQgdqidwDovRkkep4tVa+3oMf/ESO47jx7tpNXgq9NDCwPXw6fx0TJDsWl9CVSWbt/sG9gTrtT1 n9r9UDZX3zgmQ1APrFycVpNqPgfWoticMyf+fP4We1YGDlzYL86uzGq6ZV4fZxef5mfdtaMvqnh+ 9+henY3xI2sn2pRH0jEn2i4QghdSs7ZnsM+dYmU0C63hRAnLE1zTy8HW2bFncP12xi0AdPaM7YJs FSEgFucHvQshq1PT7JyMZqx3y67O+idvHF87IRcGp9ngUHFaOV5pZqQjc5k8piUSTZSiMDK7/UOy pnB2FVd8/5XRNR+y55Hz6J5CTydpAcBDlUatxcAk6pS9hEnH5gY9480yp2GkZ1t2Dm/ELbuitiyf trF4I6FmEuT0QhKju3k1YBK9mAcXaPdx4q4dGVS09AzVAAQpK0KA7LMVkR1iRgjMqWnnLh5zd92N vvTejuEfaO/d58aO8X3nmBNssSvtBejJiDN1Gq8uP4s/XplaeKNdu/R0RK6G+WHt6n6o+LlBcLUe dyUsFvbkycTQqJOL7x3Io2aTml6ZfnwBITPfMGUuz8fGnDO2eDVrXd1s7UG6OFlVM9Vw/OHJub6u yGSfNwSLxM/L+2jaATvVCOjsdqaJVNUlIBbnQ14n7B1/1tnZEr5AOS+5MBBztct72Doj3FBa5UUs +s2x6a5ZeZtx88E66+7sTFuIOEsUl+H9vcZUJZDZ7R+SdcWJxG8ESMiF6J5KU9GCRQAnKqWsJZJs 89r0HG9uOf650VZeHJq4rJXp2NxsljkNIy3bUtOLhlvfCI2P/Khcf8gP0okxzyyWdhOkVNlbpnDK xpKMhDTaT1+MsWSlrtvNW0Z5C0Fie7E4P8kwRbPyDBayIQkI2BKIHWhsC0G61iHgXl3270XKMGb3 6Ns76d395Li8uszDo3qMx+ZGtegyW4eCJ0kuNfk1wN5x52VSYjJf6otmog3HleAPZwduDUcvHeze 11O/ciclcHT2lMCQvIIExOJ8vnewn2/u8SsibMq5AbI1M30z9I4u/iIl52qNcwFGXGLhL6MS75eK u+cThSKmsG4gkLxVu899y6XaxUy8bcIFEGfmlivzSJlkdvuHQiG7Mn3VxSalhByje3nWkxs4IVqM tQTg+KdwfrSVu5fML2v5m9leHXY24Cb3zZI/SWcY5QEvqmTxloep084bTZ1CxXpp1e2nfP9YxdTx zXjvfRAyus/vUyFh+kfHeudOZHwXa1GKNa6cqI1ZGAlptJ867p4nRy3Z0cfr5o3TL19NCT6fCXrK cdn/ksq0LwkpQcCaQNxAY10IErYwAXH86/yEX/IkFW8XX1i+ujgfe8NRxmm7h7Te/JYs0x9Mxewi 8c45y7B96QjfsbN3xfZqd7yagYl0Z0d38K6onEiEb3fHqynIBI/i0k3MoobEeygPyB0OT+/5hGR9 YVFPnlwROnsL91OIVhABeefcWSx1HjnDb/I4ET7d59XumvdZneHXRu+HboxYyKBuY/ovqJA9c++E eEm7F7Pkn36LW6CBH5VdHIVxh+lF6ehfjQpVJMoKl0lmt38oxbMqU/+QFX8HvgPZqLsFTJskJQB3 FAmxJa2FgmOSWg6Q0ZguKxsgzZI2DBtoLZuGx0uL8cyNO5D7ZbWRy+cPOFfavJC/2siz/A0uqk+J m3WqTylj4GFsqrOo982IMXLIiWWw+ZZhy8KxECxqY8UbifbxGL+bW8jWEkniff6jJ9bHXcdFOhby odEztITGEAIEQKCKBGQsuhrjprvG9SuW4vT14tzQPu/NNWrWGpyxiHGzRxsi5fyWLNMfTPmkl3/r JP7nB5zr6fw753FfIOZj8ezYuoorTP7oWkRNXqEeQ+5PpMUxuzNtUB9z4dNOd27vfSY5Vk15C8B9 FbRSTEbjz2e9Ii6LcMQIHuZ1HhntWVmtokVCZhAokcAjZ557/vDHP1liDSgaBECgeAJ8XXRpp3cZ r/jyUSIIgAAIgAAItDwBftbaxI1R8ao5/rq1jFcsU8ANq8nnAIv7SqmXnF3wh2PsfNJt8BT6ICkI bGsCr770uQ9++KMmBPJTaviBAAhUjMDeCe8cIG5vvmJaQVwQAAEQAAEQsCbA743PeW9Qs85VXEJx BL1W/k2xxqnJX4Qe+rqt/F5M6ENoxQFESSAAAhECWJzDKECgmgTkS03ln/L37KtJCFKDAAiAAAi0 KwH5lfLmLxr5W5MvsLHElyVlboWGqilfhC7f1uz/1Guh019rzawxMoLAdieAsPbtbgHQHwRAAARA AARAAARAAARAAARAoAEEENbeAMioAgRAAARAAARAAARAAARAAARAAASyE0BYe3Z2yAkCIAACIAAC IAACIAACIAACIAAChRDA4rwQjCgEBEAABEAABEAABEAABEAABEAABLITwOI8OzvkBAEQAAEQAAEQ AAEQAAEQAAEQAIFCCGBxXghGFAICIAACIAACIAACINBkAvL15uJP3jeo82+Y232plNeYt64mMtPV 5H8fmdlqojCoGgRAgLHg4nx5Qnm0XZ4/8p9kdnab10YiXlL4AlXg4WsJbsA+O5WSbGOydvuH1mV6 I0RAzRS6Z7NQe2Jk+SRGA1vPPCy8ufxUpjuApbMrqvaorXJtSmebrUXy5HJ0D0w1fDU1nn4TiCxy orA06fSyYKdmjLbMPGI2P6+d3aYzPBYwWlfH0MPKwwz34oDJ7Tq75OptR1ilTuMZmm87kKAdCJjs th1022Y6BEauDIve3af4F0Znx3obhI2PCPzzYxP9TnXaiKDNpRskC6/GmwBkqrI2Mto9ddB3+6kK IRuOP5y4p4qRUxfRoHKAeOrqpnyaQWB09lTtgsTVI6Atznm3OckuqC8nn2cn1Fzf/5Yyf14fYn07 a6mU5N3yaXYm5CWXJg9NdZ+XFV0fXDzk9luiYDL75rVn1kalnDeOs/ozapOPTEmKSma3f2hfJpMj REROW91TcfYSlwGcZiuWKNM9N5TBzIwk2MXyxMFbPUPeYJnCrqjaSVvlLp4wjGwYWyQXH4GG6911 93vm9+Xwr3ef8fWTMdtbeydE6/Bue0D2a/U5dDGqiQ+ZOt9If/FIuh7dImRCYhjMPup8UhiemEAE jFbVGXlIdfPWpERIZerFQ8o/8z/OB2+tCfMJWCrPUBlUELQCBCJ2WwGZISJFQI1ZfIoYP8a1ALyt mdMXey4EPwzu26Ez7LaAnNYi7D5VH7p5KenYzFRcTMM5UxdnF6O3j926k+eIHp3dukmRsHoE9MX5 2sr+ATl952vygaHVheVgv9m6eml+/7GUU3m+PIjM/pcX53vHn5C7jFt3F1bY3G1xykf+qOys88iM WmawWmcPW117KP5KpiTLJLPbP7QvM5iyu0ssglLons2YygBOsl164SIbO5O0JneUWJo8uTZ2ZnQn pVOSXVG1b5G2SjZiNoytkWt5ur56IDTqC1xu92F8k3v/yuLdzRTibt1ZjJSZInuLJiVNNMEnJBke abRxlizYqG5emZ99L7YnbF9mZTBBUBAAgeYQqH1koHflNTkX1U+k1XG62AcMhoy5h7HkVMML2PRD 0KNlynLdlIemVpLUvndlih0fdWbOxsTi9PiaDB7UToxDSjnHVCJC/qonqnhoUJMoU0Z1DddX2fzJ YGhqNNouTs29T/BzrytezFQSAvLftYZT/37v7Nj68VkvvoCxwdHHF16ITv7loXqGcIlMUiITCLQo gWBY+81FFXwipq1hgeWU68m9+fXY2lxTU1jugw7eGhzbz9Y3N7MVK4ryNhTSF0Fmt39IVhjM7gT5 cDVvyI3VAnW3V7eUSrc21nsHO+4Sg01UMOmUzxm2dbLaVZytSs45DMOebakpPS1UHLUasR5urOgr wB1dfSsbD+zFENthvT077DO0bcoEwyON1mDJ4W5eGWbmXhye29mrlMYz2JeKlCBgQyC73dqUjjSN JyB2qJ2ATS9GSR6ni1Vr7egx/xhJ7juPHu2kZeSr00MLA9fDp/HRMkOxaX0JKi/dvtk3sCdcqWuH j2p7B3P1jWMyLvXAysVpNdPmc2Atis05c+LP52+xZ2XgwIX94uzKrKZb5vVxdvFpftZdO/qiiud3 T5XV2Rg/snaiTXkkHXOi7QIheCE1a3sG+9wpVsY21xpOlLA8wTW9HGydHXsG129n3wJAZ8/YNMhW BQLa4rx/8sbxtRNyDXCaDQ4FpU86ZUqtq+OVZkY6Umd1M/D40kg0UYrCyOz2D8mawtlVXPH9V0bX DmqvFSlA9xR6OkmLr3R1apqdk7Gv9W45MNA/yil7KTPaVaytisDjPIaRnm3ZObwRt+yKtk/5CYZH Gq3RkuluXg2YRC/mESjafZy4a0cGFS09QzUAQcqqEMhtt1VRdFvIOafmort4zN11N/rSe5OFf6C9 d58bO8b3nWNOsMWutBf4KSPO1Gm8/3YMr0wtvNGOdE9HJFzKj7j2b/y5QXC1HnclLBb25InX0KgT k8j3DuRRs0lNr0w/voCQmW+YMpfnY2POwVu8mrWubrb2IEvQOdVwvPaTc31dkck+bwgWiZ+XV8+0 A3ayEdDZ7WwTqSpLIHByLtcAYlp2eQ9bZ5rHEZdqijk256BELPrNsemuWXmbcfPBOuvu7EwLUJwl ihvy/l5jqhLI7PYPybriROLXBKSnK0T3VJoWBZyotHf8WWcfVIwczlAXTrd5bXqON7c8+HWjrbw4 tBx2ZbLVnIaRlm2p6YW1rG+Exkd+VK4/5AfpxJhnFku7CVKq7K1deILhkUb76YsxlqzUdbt5aysf lC62F4vzkwxTNCvPUCVIkLVaBDLabbWUbHNp3avL/r1IeaXIPfr2Tnp3Pzkury7zSKge47G5kRVd ZguizaUmvwbYO+68HkjM8Et90Uy04ThO/nB24NZw9NLB7n099St38gBHZ89DD3lblgD5KTX+Yq3A LRp+qcbfdPQuwIhLLPxlVOL9UnH3fKKqiymsGwgkb9Xuc99yqXYxE2+b8AWYOBq1XJlHyiSz2z8U CtmV6asuNikH+/n2aozu5dlIbuCEaPxCEZty7gttzUzf1N4UGIDjb3D60VbuXnLIrpxa7GzAFSlg q+kMozzgRZUsXv0wddp5o6lTqBiKVl3y/CxXxdTxzXjvJREyus/vUyFh+kfHeudOZHwXa1GKNbkc 2vB8oUij/dRx9zw5asmu6brdvMn6WVcf04tlGQKUclz2v6Qy7UtCShDIRiCL3WarCbkaRkAc/zo/ 0b5eveLt4gvLVxfnYy+yyTht95DWm7GQZfqDqZhdJN45Zxm2Lx3hO3b2rthe7Y5XMzCR7uzoDt4V lROJ8O3ueDUFmWBEQLqJWdQs+KjKQyyHw9N7PiFZX1jUk6esCJ29YV0QFTWSgFicu+th7+MEw6+N 3vcvh0hHlvW2ubqN6b+gQvbMvRPiJe1ezJJ/+i0u2QZ+VHZx6sUdphelo381KlSRKCtcJpnd/qEU z6pM/UNW/K3mzorUqHtBrV4CcEeRENvOI2f4vS/ZiOL98/5ebKQRDZoZ7MrKBuQrx9VpvG+rtGEU xLU5xfB4aTGeuXEHcgekNnL5/AHntpUX8lcbeZa/wUX1KXGzTvUpZQw8jE11FvW+GTFGDjmxDDbf MmyO5ilrJc2efChe9pPDoUXl0j4e43fzlOI3LTnZi/2v1JxYH3cdlz1ho2dompaoeFsQIO12W2i+ LZSUsehqjJvuGtfvXYrT14tzQ/u8NyIpSwjOWMS42aMNkXLGQpbpD6Z8dsG/dRL/8wPO9XT+nfO4 z6TzsXh2bF3FFSZ/dC2iJq9QjyH3J9LimN2ZNqiPufBppztb4xWp0MVYNeUtAPf90EoxGY0/n+OK uCdG8DCv88hoz8pqWhNGZ09LDOkrRuCRM889f/jjn6yY1BAXBLY7Ab5YurTTu4y33WlAfxAAARAA gW1JgJ+1NnFjVLxqjr9uLeMVyxQNFlaTzwEW95VSLzm74A/H2PnE2+ApFEJSENjOBF596XMf/PBH TQTIsPbtjAu6g0AlCOyd8M4B4vbmK6ELhAQBEAABEACBDAT4vfE57w1qGfLnzSKOoNfKvynWODX5 R0lCX02W34sJfQgtLzbkBwEQiCGAxTnMAwSqSUC+1FT+KX/PvpqEIDUIgAAIgEC7EpBfKW/+opG/ nvYCG0t8WVLmVmiomvKjJPJtzf5PvX839CG0zOogIwiAQCIBhLUnIkICEAABEAABEAABEAABEAAB EAABEMhLAGHteQkiPwiAAAiAAAiAAAiAAAiAAAiAAAiUSgBh7aXiReEgAAIgAAIgAAIgAAIgAAIg AAIgkEwAi/NkRkgBAiAAAiAAAiAAAiAAAiAAAiAAAqUSwOK8VLwoHARAAARAAARAAARAAARAAARA AASSCWBxnswIKUAABEAABEAABEAABFqfgHy9ufiT9w3q/Bvmdl8q5TXmrauJWHU1+d9HZraaKAyq BgEQYCyyOF+eUE5tl9c/Rb9Vnu7wtSxddvPaSMRLpijTPjuVkmxjsnb7h9ZleiNEAF0K3bNZqD0x snwSo4Ft1FrMIstPZboDmJfRMa34gY2q3S9h4p5Xaelss7VInlyO7oGphq+mxtMfUEUWOVFYmnTx yuw+KNoy84jZ9Lzmpg8YHpczjZGE80o1Qw8rDzPciwMmt+vsktu2ZXmGptsOBGgfAmmGpPbRut00 CYxcGRa9u0/xL4zOjvU2iAsfEfjnxyb6neq0ESEw7DZIGuZNADJVWBsZ7Z466Lv9VIWQDccfunMP OfiKBpX99Kmrm7L0rAKjs6dqHCSuFIHA4lxMOqd7bqiPJ8+M1FS3eWZtVD65cZzVn0m7o8a75dPs TMhLLk0emuo+L2u5Prh4SFtchdmR2UmRyJRkU5DZ7R/al8nkCBFCZ697NjsqAzjNlrIWs8zLEwdv 9Qx5g6X/jW7Opz7E+nZKa6N+VO3cxZ9kF5ShnmcnnHVpTlvNBrzUXHzQGq53193vmd+Xw79uQuPr J2O2zPZOCEQc7wHJSn0OXQyE4kOmzjfSXzxiJF+qasUWbm76kOEF6MU7HzGBCBitEjnykOrmxWpX YmmmXjyk/DP/43zw1uBYCPcuNy/C40iJKqBoEFAEYHhtZAlqzOJTxPgxrgU03po5fbHnQvDD4L7/ dIbdFpDTWoTdp+pDNy9lOorjdcQ0nDN1cXYxevvYrTtZzvvQ2a2bEgmrS0BfnC+9cJGNnVFrcu/X eWRGzelZrbOHra49TKcrXx5EZv/Li/O940/IXcatuwsrbO62OOUjf1R2RopEpiTLJLPbP7QvM5iy u0uATaF7OtBu6jKAk2xJazHJvDR5cm3szOhO6t+3rl6a33/MvESkat9aW9k/oMyS9Q8MrS4sCx+f 01azAS8z1/J0ffVAaNQXuNzuw/gm9/6VxbubKYTYurMYKTNF9hZNamr6iOGl6ICk0cZZsmCjunll fva9mHQC+T1DZUhB0JYnYG/MLa8KBPQI1D4y0LvymlzD6SfS6jhdbMcEQ8bcw1hyquEFgfqRetEy ZbluykNTK0ltce/KFDs+6sxGjInF6fE1GTyonRiHlHKOqUSE/FVPVPHQoCZRpozqGq6vsvmTwXDX aLRdnJp7n+BHcVe8mKkkBOS/aw2n/v3e2bH147NefAFjg6OPL7wQnfzL8/CkcAl09kyNgkzVIaAt zrc21nsHO+4S7kOps7W5xrwVUQ4NRTlyCst90MFbg2P72frmZrbycopEZrd/SMoczO4E+XA1b8iN 1QJ1tydWSqVJ1qKLJ53yOcPyWzrZJwWcdL+biyqaXSxWIzlzGkY6SUpL7Wmh4qjViPVwY0VfAe7o 6lvZeGAvgtgO6+3ZYZ+hain1po8ann1fII3WYMnhbl4ZZuZeHJ7b2auUxjPYl4qUIJBAAIbXliYi dqidwDovRkkep4tVa+3oMXdrnk8FxL7z6NFOGgNfnR5aGLgePo2PlhmKTetLoLp0+2bfwJ5wpa7/ 1O6Hsrn6xjEZ63dg5eK0mr3wObAWxeYcg/Hn87fYszJw4MJ+cXZlVtMt8/o4u/g0P+uuHX1RxfO7 R/fqbIwfWTsBsDySjjnRdoEQvJCatT2Dfe4UK6NZaQ0nSlie4JpeDrbOjj2D67czbQGgs2dsFWSr DIHgnfPVqWl2TkYz1rtlV/d/PJgzErqTR0vHK82MdGQuJadIZHb7h6TY4ewqrvj+K6NrB4M3foVH zqN7emgFAA9VGmMtekrKKXv/nnRsbtCzf/LG8bUTcr16mg0OhVLlNIz0bMvO4Y24ZVdU+fL1pjcb XnJfIPMaC6S7eTVgEr2YhyFo93Hirh0ZVLT0DNUABCmrQwCGV522SpJ0To3vu3jM3XU3+tK7Y+wf aO/d58aO8X3nmBNssSvtBejJiDN1Gq8uP4s/XpladFWSkOrfezoi4VJ+WLtzP5Qnc4Pgaj3uSlgs 7MmTiaFRJ4KV7x3Io2aTml6ZfnwBITNfyjKX52NjzmFGvJq1rm629iBL0DnVcLz2k3N9XZHJPm8I Fomfl3cetQN2jDJ2ZohU7UUguDjvHX/W2dkSvsBxXiqoRlzx9Tf28kAQ4fE3x6a7ZuVtxs0H66y7 szNtgTlFIrPbPySljROJh15LT1eI7mlZlVWpwVqC4m1em57jzS3HPzfaSnvX4Olsx+Ziy5zvEIsl xOU9bF0bHXMaRlq2paYXDbe+ERof+VG5/pAfpBNjnlmsTJdTStWysMKDTU8bHrNyPmTeT1+MsWSl hNvNC1OpAQXF9mJxfpJhimblGRqgG6rYZgRgeO3T4O7VZf9epLxS5B59eye9u58cl1eXeQhej/HY 3IiFLrMFKeZSk18D7B13XiYlZk2lvmgm2nByY+Ll2YFbw9FLB7v39dSv3MkCHJ09CzXkqQwBbXHO r4iwKecGyNbM9E0nlIhPecWZubYydy7AiEss/GVU4v1Scfd8oijEFNYNBJK3ave5b7lUu5hJt03E ZkFIpDjekTLJ7PYPRV12ZfpSiU3KwX6+vRqje3k2kxs4IZrBWiJw/FM4P9rK3Uvml7X8zWyvDjsb cJPzN4H5N77SGUZ5wIsqWVynnzrtvNHUKVSsl1bdfsrPclVMHd+Mdy7eO9F9fp8KCdM/OtY7dyLj u1iLUqz4ciJNbzA8qw5I5v3Ucfc8OWrJjj5eNy9ev3JKjOnFskLRQ5Xjsv8llWlfElKCQAoCMLwU sCqYVBz/Oj/hlzwNxNvFF5avLs7HXrqUcdruIa03vyXL9AdTMbtIvHPOMmxfOsJ37Oxdsb3aHa9m YCLd2dEdvCsqJxLh293xagoywYiAdBOzqIHxUZUH5A6Hp/d8QrK+sKgnt6kInb2CPRgipyIgFufu erjzyBl+k8eJ8Ok+L3fXxIsouXfyQmKSV87B6tVtTP8FFbJn7p0QL2n3Ypb8A3lxIzTwo7LTIpEV ibLCZZLZ7R9K8azK1D9kxd9d7KxIjbqnajZz4hKAO4qEGpGyFhKOSVY5QEZjuqxsQL5yXJ3GvzZ6 37nIlNdWC2qBIovh8dJiPHPjDuR+WW3k8vkDzpU2L+SvNvIsf4OL6lPiZp3qU8oYeBib6r/qfTNi jBxyYhkyfx+xSCULKCtF0xfeAbWPx/jdvACdGlIE2Yv9T6mdWB93HRfpWMiHRs/QEI1QybYlAMNr 66aXsehqjJvuGtfvsonT14tzQ/u8N9coDxacsYhxs0cbIuX8lizTH0z57IJ/6yT+5wec6+n8O+dx n0nnY/Hs2LqKK0z+6FpETV6hHkPuT6TFMbszbVAfc+Gjnju39z6THKumvAXgvnNXKSaj8eezXRF3 0DhiBA/zOo+M9qyspjVddPa0xJC+YgQeOfPc84c//smKSQ1xQWC7E+Droks7vct4250G9AcBEAAB ENiWBPhZaxM3RsWr5vjr1oq59RnXfmE1+RxgcV8p9ZKzC/5wjJ23uA2+LW0QSoNAWgKvvvS5D374 o6ZcwTvnactGehAAgeYQ2DvhnQPE7c03RzjUCgIgAAIgAALlE+D3xue8N6iVX12kBnEEvVb+TbHG qck/ShL6uq38XkzoQ2hNII0qQWD7EMDifPu0NTRtLwLypabyT/l79u1FDtqAAAiAAAhUnYD8Snnz F4389bQX2Fjiy5Iy026omvKjJPJtzf5PvX839CG0zOogIwiAQCIBhLUnIkICEAABEAABEAABEAAB EAABEAABEMhLAGHteQkiPwiAAAiAAAiAAAiAAAiAAAiAAAiUSgBh7aXiReEgAAIgAAIgAAIgAAIg AAIgAAIgkEwAi/NkRkgBAiAAAiAAAiAAAiAAAiAAAiAAAqUSwOK8VLwoHARAAARAAARAAARAAARA AARAAASSCWBxnswIKUAABEAABEAABEAABFqfgHy9ufiT9w3q/Bvmdl8q5TXmrauJWHU1+d9HZraa KAyqBgEQYEwszq85HXHz2ojj0YRfO7vk8FmeUG5ul52TilB1ig14LuELVJmH3dpNrUFlZ+RDxjxR LZyL/HKj6099HW18OlU7SSmFmgUaYwnAaUUMrRBVhcxu/5BkQ2X3huSAXTWnFYpq0ECvdDqRr5Fm wL7Niywy5dKk08vC/ZcGVZTILVKOqVPb20PYnxg8JO2OCvBRDQMZcIZuraGH28JmCiBuOWAZbMls nOE2svefeUfwAqA0rog0c4DGSYWa0hEIjFwZFr27T/EvjM6O9aarNXNq3jf558cm+p0CNFeZedqc WRae0ZsAZCqkNjLaPXXQm/+nK4NsOP5w4p4qR3ot0aCynz51dVM+zSpwvs4eGdGo+VJgFuFqkY5J VUaEqJypBilLNZ3mJjfOwmOcDp9YkHqr1DQTs+qMhmJxXn/G3ycbOq++nHzf+c4h70sn2QX15Dw7 YbHoDdotN/en2ZmQl1yaPDTVrSq6Prh4KMbiDdmJMplo1+meG0rUmZFafP9Znjh4q2fI893+J6N5 9voQ69tpzE+JRFPavPbM2qiU58bxAOR0XTtd6jKAk4qQFZGyktntH9qXyeSQHAJub2zpQDckNXc6 w/Xuuvs98/ty+Nc1Gl8/GbO9tXdC0OD2fEB2YfU5dOHIxIdMnW+kv3gkoas0RNEyKqE7tW2vNPmT sIcUOyCUi8vvo8pgQpYZcoYqTeQh1bkaJmJVKkphDFwlwpZMI2O4OUi3Rtl23hG8KuTlzD/VHKBK mm1DWdWYxaeI8WNcC5DZmjl9sedC8MPgftd2ht0WkNNahN2n6kM3LyUdm5mKi2k4x2s5uxi9fezW ncxH9Pk6OzkLIudLjPWOq2XFjeNrJ1KfUFZlRDDO5+0GKXs1zQuH6BjnrT35JNYxyKVJ4qEwRauJ WaVGQxnWvrr20NTRttZW9g/IOT1j/QNDqwvL6ToTN/fI7H95cb53/Am5y7h1d2GFzd0Wp3zkj8rO yIdLL1xkY2eS1uROJbyB18bOjO6k6ty6eml+/zHzioWqnabUeWRGLYdYrbMnDrK107RIWAZwUhGy FUgByez2D+3LDKbs7hKrzhTGZkG3wUmWp+urB0KjvrBPt/swvsm9f2Xx7mYKubbuLEbKTJG9mkm1 Tm3ZK+39SUk+qmGgSWcY5yGFZKpz4RcmYG8MFDujs4o0B52Ssu28I3iF2ti+z1ZIqW0vau0jA70r r8lpp34irY7TxQotGDLmHsaSczsvYNMPQY+WKct1Ux6aWklqgXtXptjxUWeSbEwsTo+vyWhN7cQ4 pJRzTCUi5K96ooqHBjWJMuXZ43B9lc2fDIamRqPt4tTc+wQ/T7riBs8mEaD/XWs4leDe2bH147Ne fAFjg6OPL7wQnfzLs82kcIl8nT3TLKh29NxY79y0c9rvHP4nyVmVEcF6Pk8PPfZqmiqKTjk6dnq0 RaWD/WLOQT4kDdB+pZbNvkvPJRfn3vKbRbo0/9ebiyoiRUxwi5Bna3NNze24Dzp4a3BsP1vf3Mxb 8NbGeu9gx13C90VLlj7inGH5Lfv8k3tTyxNLSaisQU5deL4MBQLPqQiZ3f4hiSGY3QlM4nZ1Q+5k F6h7vkbIkttTTUX7qBHr4caKvjTa0dW3svHAvnSxHdbbs8M+QzukpDt1nDGb/Ul40mPPJ42Psi81 Z0rSGRo8ZLhz5awa2UO2ZHJW0eZIdGsB2y56BG/RhmvJ/tWirCokltihdiIZveAdeZwuVq21o8f8 EyO54ho92kkrx1enhxYGrodP46NlhmLT+hJYLd2+2TewJ1yp27Uf1fYO5uobx2QI6oGVi9NqUs3n wFoUm3OWw5/P32LPytPaC/vF2ZVZTbfM6+Ps4tP8rLt29EUVz+8eJKqzMX5k7URx8kg65kTbBULw QmrW9gz2uX4jo7FoDSdKWJ7gml4Ots6OPYPrtzNtAeTr7FlnQZ0d3RlhWGZrwRHBUiRLBU3JqCkH 32u+P7oxLKa+twfcaGjyoSjVdmJWndFQLM7dozmhth8VrKLN+ydlLIdYGJxmg0M5W0DL7nilmZGO ospcnZpm56T89W7pp+gf5SO8lEnH5oYy4ynxaI1I1FNRStuXUwDwnIqQ2e0fkqqGs6vApPuvjK4d 1AKQCtDdHnQJKb0Rt4Sy279IulMnGjPhTygPmYqfpY9KVWaexKQzNHpIunPlqX8b5zXaUthZmQcs o1vTbbu0EbwV267V+lcrMqqKTHNq2rmLBzled6Mvvfui/oH23n1u7BhfccWcYIv1mBcRKSPO1Gm8 /6Iir0ztbNAOVk9HJI7ID7L1r1i6QXC1HnclLBb25FHQ0KgTBMr3DuRRs0lNr0w/voCQmS9lmcvz sTHnjC1ezVpXN1t7kC5OVtVMNRx/eHKurysy2ecNwSLx8/I+mnbAbmiEpnd2SzntbIixFhwRrEWy 1THVosy/enCBjbmbXORD64lZpUZDsTiPBuSIbTO3Z8qFgVjwXN7D1hnhhtK2i4jxvjk23TUrr7Vv Plhn3Z2daQsh0veOP+tsywlH5njecLrNa9NzvHZ5DukG/3hhUeLuUKZjc7GDS1MSZ57ijoS/J1qA pimLKAR4TkXI7PYPSY3jROJXMKQBF6J7St6FJRfCr2+Exkd+VK4/5AfpxJhnFqGBNywK45CrIKpT WxlzrD/RPWQK8ax8VIry8iUlneGnL8Z4SFWf27ny1Y7cDgHPlihnxcgBi5nH0KhtFz6Ct27LtVb/ al1OVZDMvbrs34uUga/u0bd30rv7yXF5dZmHR/UYj82NCtNltiCfXGryuy3uxWk5mS/1RTPRhuM4 +cPZgVvD0UsHu/f11K/cyQI8R2fPOgsqbrUSq3ALjgixIuVcvhkWZdrVA/EShNUpcQOCfKjBTJyY VWg0pD+lxm/RrDgh/p7e/GUzztUa5wKMuMTCX0YldjLi7vlErVDM7dxAIHmrdp/7lku1i5l0i4Oy a36/hcnG47+tmemb2hvdAmX6Wyx+8I+7tSm0jt42TyeST0kIcvWwODNv6srcnUznAp5OkQgxMrv9 Q6GCXZm+ZXh3VGKMLcuA0Ng84i0PU6e9O06ycuF9lJ+SWE6omDq+Ge+9D0L6L79PhUTuH+X3pk5k fBdrY9UvorZop7Yy5hh/IqWiPGSSuEllJuUv/N9JZ/ip4278VNRDOhL4F8AKF2k7FujbEuGsDAOW wa3F2nZxI3hrtlLL9a/WxFRZqcTxr/MTXcbTQ7xdfGH56uJ87M1BGaftHtJ6U0SyTH8wFV0m8c45 y3jCzBXgF2hXbK92x6sZmEiL6OvAXVE5kQjf7o5XU5AJHsWlmwlHzYy7Mh7TOhye3vMJyfrCop7c piLbCb/B2jPNgu6d5ed5RaxWkrpg40eEJIm0CU/xM+qYRZkbuyGs0VvTkQ81zxBeupLKBVZqieo3 JcEjZ557/vmZf8uDcCb65auhV6UYfJvNWbL6D2Ua8Y9iBsDv9J5hp8UdnnPsmeHFx2dDl0lcZfg1 RTeKRj5yChH3f5TX6/NjlpzV7IpXkfwWVDR7YpluLbJGOV/Ry/Q4C9VeG3XjZ5wrSeE9xUh2snaC kninSPBtIppe5bV1Ipz0wGukIoaKosBJDmSZdEVUI9JsNZF8A5Yvd6GMrbw2KLRknbPbdnz0Ojkn a/FbUxlq8GGojfjutYrgoMosVOhWKSzaqe17pZbS7bmkhyzAR7UArqAzdATSHxo6VwuI3koi2BsD aUvxzio6YAXHUNq2c47grUQ3URaizybmQYIWJMD70eK+yKmGuMdxUw57x8e7L675CeSAqM2vtM6l TzupcZMs0xtMh87zG9qEJDoyXgKPA9UnwF6ZMpkadjWNhJXyG+Dex1PcWbeTUlxEv72PiusOq2ke x6NzHt05uLOjGDXFP/Eb8vor6FUJ++uBh2HbIRsupDs/5Ju93DktPq6kVhkhvcJqGuzT1Nmt5CRn QdR8ybcZfVkkRbKSsxojgmGpZT9I2atpXDhIpoExTpvT+ms66qH9xIxaqTXP/7360uc++OGPmuoX i/PDH/9k88RDzSAAAhkIcB93aad3GS9DAcgCAiAAAiAAAlUnwJdJ3kqv8boEFttlVh9Wk97CKEIC cnYhllXMPaIropaSyqiKnCWpj2IrQyB+cU6HtVdGOQgKAtuUwN6J8z31Q+pzKc4nWLYpCagNAiAA AiCwTQnwe+Nz3hvUmsCgNvIsf2ty6TfFGqcmf3V26HPC8nsxoQ+hNYF0YpVVkTNRESQAAZycwwZA AARAAARAAARAAASqREAFkPfxMGnTF9QapY0xFr0IAQxqlnNyzs/n+Zer9ID2IlRAGSAAAiECCGuH SYAACIAACIAACIAACIAACIAACIBAkwkgrL3JDYDqQQAEQAAEQAAEQAAEQAAEQAAEQCCeAO6cw0JA AARAAARAAARAAARAAARAAARAoMkEsDhvcgOgehAAARAAARAAARAAARAAARAAARDA4hw2AAIgAAIg AAIgAAIgAAIgAAIgAAJNJoDFeZMbANWDAAiAAAiAAAiAAAgUQoC/3lx+ZPTRyeV85fFvmNt9qZTX mLeufJLmyq2ryf8+MrOVqzhkBgEQyEtALM6veR2Rf0RBerTAl5P9h4/uyvItx81rIxEvKXyBquiw Xzuti312KiVZJlm7/UPrMr0RIqBmCt2zta49MbJ8EqOBrWcbFt5cfoLSHcB0o0oeRKnaSVstnW22 FsmTy9E9MNXw1dR4+k0gssiJAv/UijNHCXVq2jLziNn8vNZmn8ZIAkbr6hh6WHmY4V4cMDnN55fl GZpvO5CgDQikG1PaQOE2ViEwcmVY9O4+df+Vl2fHehuEiI8IJ1h9ot+pThsRgnPpBonjTQAy1Vcb Ge2eOphlqh+ecrgNx1tz4p6SRQ6+4rnsrU9d3ZRP0wuMzp6pbZGpQgTE4rz+jNwn493mJLvwMndq 9185z044c/2lSe/hy/Whm5eS1tIh3Xm3fJqdCXnJpclDU93nZUXXBxcPuf2WwEZm37z2zNqolPPG cVd4sQ6JVmRYfBLZyTLJh/ZlMjlCROS01T2bFZUBnGYrlijTPTeUwcyM1OLlXZ44eKtnyBss+ycV GfmnPsT6dhrzU7XTtmrfXtnYNj4XH7SG6911j5Uc/vXuM75+MmZ7a++Eg/eA7NeTu92BkM8k3DJf PJLQco3XOkON9o4ijZGEjFbJFXlIdfMMKjQni6kXDyn/zP84H7w1OBbK66bzDM3RG7W2HYEUY0rb 6d6GCqkxi08R48e4FtB8a+b0xZ4LwQ+D+/7TGXZbQE5rEXafyjDV90qPaThn6uLsYvT2sVt3Mh7R o7NbtyYSVpSADGtfXXvI/3drbWX/gJy+M9Y/MLS6sCz6TcfO3rlptb+1vDjfO9ifbirPlweR2b8o Z/wJucu4dXdhhc3dNoYeUdlZ55EZtcxgtc4eR3hGpiQbhcxu/9C+zGDK7i5BLoXu2SyqDOAk26UX LrKxM0lrckcJvsWzNnZmdCel09bVS/P7j5mXiFTttK2SjZgNY2vkWp6urx4IjfoCl9t9GN/k3r+y eFd2T8vf1p3FSJmWWVs4mb2jsDcS0mjjLFnwUd28Mj/7XkwSzu8ZKkMKglaIQNKYUiFVtr2otY8M 9K68Jtdw+om0OpUV+4DBkDH3MJacangBm34IerRMWa6b8tDUSlIL3LsyxY6POjNnY2JxenxNBg9q J8YhpZxjKhEhf9UTVTw0qEmUKaO6huurbP5kMDQ1Gm0Xp+beJ/i515WlJNVj/11rOJXu3tmx9eOz XnwBY4Ojjy+8EJ38y1Nx+3AJdPZczYTMrUpALs69NfnNRRV8IszdkZjPZe+PbgwLn3J7IPmA1ELP rc01NYXlPujgrcGx/Wx9c9MiH5FEFOUJn74IMrv9Q7LCYHYnOoureUNurBaou726pVS6tbHeO9hx lxhsooJJp3zOsPyWy4MnBZx0P8JW/QJyGkY6SUpL7Wmh4qjViPVwY0VfAe7o6lvZeGAvgtgO6+3Z YZ+hLVJm6NSk0RosOdzNK8PM3IvDczt7ldJ4BvtSkRIErAlkHVOsK0DCxhEQO9ROYJ0XoySP08Wq tXb0mHuMxGdXYt959GgnLRtfnR5aGLgePo2PlhmKTetLUHXp9s2+gT3hSl3/+ai2dzBX3zgm41IP rFycVjNtPgfWoticMyf+fP4We1YGDlzYL86uzGq6ZV4fZxef5mGttaMvqnh+9+henY3xI2sn2pQH KjIn2i4QghdSs7ZnsM+dYmVsa63hRAnLE1zTy8HW2bFncP12vi0Ahs6esX2QrcUJiMW5czTXP3nj +NoJuQY4zQaHHMHFbRDlPi6wMc3R5NXL8UozIx2ZS+LxpZFoohSFkdntH5I1hbOruOL7r4yuHdRe K1KA7in0dJIWX+nq1DQ7p+LSu+XAQP8op+ylzLjrSduqW2pOw0jPtuwc3ohbdkXtWX6GTk0ardGS 6W5eDZhELxYbsv59nLhrRwYVLT1DNQBByooRyDimVEzLthd3Ts1Fd/GYu+tu9KV309g/0N67z40d 4/vOMSfYYlfaC9CTEWfqNF5dfhZ/vDK18EY7yj0dkXApP6zdv/HnBsHVetyVsFjYkycTQ6NOTCLf O5BHzSY1vTL9+AJCZr5hylyej405B2/xata6utnagyxB51TD8dpPzvV1RSb7vCFY5KqsDFnXDtjj GgGd3c5Ekap6BMTi3AvIkWsAMS27vIetM+lxtCBYcRFldYqIQkmptYhFvzk23TUrbzNuPlhn3Z2d KcuQcT7iMry/15iqBDK7/UOyrjiR+DUB6ekK0T2VpjxxWZX2jj/r7IOKkcMZ6sLCbV6bnuPNLcc/ N9rKi0MTl7UyHZuLLfOIrcqqcxpGWralphcNt74RGh/5Ubn+kB+kE2OeWSztJkipsrdK4Zk6NWm0 n74YY8lKXbebt4ryNnLE9mJxfpJhimblGWyEQxoQSEkgx5iSsiYkL5WAe3XZvxcprxS5R9/eSe/u J8fl1WV+gtpjPDY3SkqXWapi2QrPpSa/Btg77rweSMzwS33RTLThuMb84ezAreHopYPd+3rqV+5k Y8JvH2SeQGasEdlAoFEEyE+p8Xcm6bdo3P0zsf0m4oucCzDiEgt/GZU4Wo+75xPVRExh3UAgeat2 n/uWS7WLmXjbhAsgzswtV+aRMsns9g+FQnZl+qp71/VjdC+vyXMDJ0TjF4qYu1OzNTN9U3ujWwCO fwrnR1u5e8n8spa/me3VYWcDbvKAraYzjPKAF1WyePXD1GnnjaZOoWK95O2R8bNcFVPHN+Odl0Q4 G2p+nwoJ0z861jt3IuO7WItSrEHlpOvUvlCk0X7quHueHLVkJ2uWt3I0CAVdTUwvlhlED037npGk MpuqMCpvcwL0mNLmSm8P9cT80/mJVvaUFm8XX1i+ujgfe8NRxmm7h7TejIUs0x9Mxewi8c45y7B9 6QjP3+i0Ynu1O17NwES6s6M7eFdUTiTC52rxagoywYiAdBOzqE3yUZWHWA6Hp/d8QrK+sKgnt64I nX179PxtqqVYnLvrYe8LOsOvjd53LofURp7lb4Y45IT9dJ9Pu+WmbmP6L6iQPXPvhHhJuxez5J9+ i6uhgR+VXeyWcYfpRenoX40KVSTKCpdJZrd/KMWzKlP/kBV/q7mzIjXqXpABlgDcUSTEtvPIGX7v izCMSCMaNJMDZDSmy8oG5Lc31Gm8b6u0YRTEtTnF8HhpMZ65cQdyB6Q2cvn8AedKmxfyF+in/Gad 6lPKGHgYm+os6n0zYowccmIZbL5l2BzNU9Zq7SiKNxLtqz9+N08pftOSk73Y/5TaifVx13GRjoV8 aPQMTdMSFW8TAoYxZZto3+Zqylh0NRed7hp3710KpcXp68W5oX3em2uUBwvOWMS42eNOZfkQKaey ZJn+YMpnF/xTMvE/P+BcT+ffOY/7TDofi2fH1lVcYfJH1yJq8gr1GHJ/Ii2O2Z1pg/qYC592urM1 XpEKXYxVU94CcN8PrRST0fjzua6IO2IED/M6j4z2rKymN1509vTMkKNCBB4589zzhz/+yQpJDFFB AATkwvvSTu8yHoiAAAiAAAiAwDYkwM9am7gxKl41x1+3lvGKZYrmCqvJ5wCL+0qpl5xd8Idj7Lzt bfAUeiEpCGxLAq++9LkPfvijJtXJsPZtyQlKg0CVCOyd8M4B4vbmq6QSZAUBEAABEACBNAT4vfE5 7w1qaTIWlFYcQa+Vf1OscWryj5KEvm4rvxcT+hBaQfRQDAiAAEUAi3PYBQhUk4B8qan8U/6efTUJ QWoQAAEQAIF2JSC/Ut78RSN/PS3/mFHiy5Iyt0JD1ZQfJZFva/Z/6v27oQ+hZVYHGUEABBIJIKw9 ERESgAAIgAAIgAAIgAAIgAAIgAAIgEBeAghrz0sQ+UEABEAABEAABEAABEAABEAABECgVAIIay8V LwoHARAAARAAARAAARAAARAAARAAgWQCWJwnM0IKEAABEAABEAABEAABEAABEAABECiVABbnpeJF 4SAAAiAAAiAAAiAAAiAAAiAAAiCQTACL82RGSAECIAACIAACIAACIND6BOTrzcWfvG9Q598wt/tS Ka8xb11NxKqryf8+MrPVRGFQNQiAAGNicX7N64jLE8qj7dL9kei36uFhP2UKdpvXRiJeMkWZVHZG PmTMk9/CucgvN7r+1FfcxqdTtZeCLgVlLWkJwOn2MrRCVGoyu/1DEgOV3RuSA7aawtiyAS81lwM5 MNXwNdIM2Ld5kUVOFJYmnZ4b7tQ0qFL1aHzhpk5tbw9hfxJoi11nl1ydyvJRDWMWcIZuraGH28Jm CiBuaQwGWzIbZ7iN7P0nOTYVoGmLFZFuEG8x4SFOgEBg5Mqw6N19in9hdHast0FYed/knx+b6Heq 01xlcC7dIHG8CUCm+mojo91TB/3RLVUhZMPxhxP3VDHSa4kGlb31qaub8ml6gYvo7JERjZovBSpy tUiFhF6tRIeJpo8IOUWyHPic5iY3zsJjnA7fM0jiYZqJWXVGQ7E4XzwkbY53m5Psgvpy8nl2wpnr b157Zm1UPrxxnNWfSbujxs39aXYm5CWXJg9NdZ+XFV0fdGqnzd2QnSiTiXad7rmh5J8ZqcX3n+WJ g7d6hjzf7X8ymmevD7G+ncb8lEiloEvnANzUZQAnbYCsiJSZzG7/0L5MJofkkK3aG1s24KXm4k5n uN5dd79nfl8O/7pG4+snY7bM9k4IGtyeD8h+rT6HLhyZ+JCp8430F48kdJVSFSyzcLpT2zo0kz8Z Uo6L/3G+BFuajyqTTaDskDNU/xZ5SHWuholYlYpSGANXibAl08gYbg7SrVG2TY9NVeGZRs4Ug3ia YpG2OQTUmMWniPFjXHOEC9S6NXP6Ys+F4IfB/a7tDLstIKe1CLtP1YduXsp0FMfriGk4x2s5uxi9 fezWnYxH9Hk7OzkLIudLjPWOq2XFjeNrJ+zCKDTSVRkRjPN5u0HKXk3zwiE6xnkLUj6JdQxyaZJ4 KHhbTcwqNRqKxfkKm7vNt7K21lb2D8jpO2P9A0OrC8ui33QemVFzelbr7GGraw+te7hMyM09Mvtf XpzvHX9C7jJu3V1waqeLpbKTZbKlFy6ysTNJa3KnFt7Aa2NnRndSlW5dvTS//5h5xUKJVAq6dKDd 1GUAJ22AbBpSZjK7/UP7MoMpu7vEqjOFsWUDXmau5en66oHQqC/s0+0+jG9y719ZvLuZQoitO4uR MlNkr2ZSrVNbOjR7f1KSj2oYaNIZxnlIIZnqXPiFCdgbA8XO6KwizUGnpGybHpvavOWSBvE2V7+t 1Kt9ZKB35TW5htNPpNVxuthCDYaMuYex5NzOCwL1Q9CjZcpy3ZSHplaSaN67MsWOjzozZ2NicXp8 TUZraifGIaWcg1kRIX/VE1U8NKhJlCnPHofrq2z+ZDDcNRptF6fm3if4UdwVLzQsCQH571rDqX+/ d3Zs/fisF1/A2ODo4wsvyHYM/OTZpn24RJbOnmkWVDt6bqx3bto57XcO/5PkrMqIYD2fp4ceezVN FUWnHB07Pdqi0sF+MecgH5L2Z79Sy2Te5WcSi/Ox/Wx9c1PUdXNRBZ8Ic4/UvbW5xrzVew7JRDly bsd90MFbg37tOcpkWxvrvYMddwnfFy1V+ohzhuW3nJQ/uTe1LA1Bl1oq1ZrFAc9pA2R2+4ek+sHs TmASt6sbcie7QN2zwc+Ty1NNRfuoEevhxoq+NNrR1bey8cC+FrEd1tuzwz5DO6SkO3WcMZv9SXjS Y88njY+yLzVnStIZGjxkuHPlrBrZQ7ZkclbR5kh0awHbjh2b2rEVsg7i7cii8jqJHWonktEL3pHH 6WLVWjt6zD1G4oO92HcePdpJq8xXp4cWBq6HT+OjZYZi0/oSCC7dvtk3sCdcqdu1H9X2DubqG8dk XOqBlYvTaqbN58BaFJtzDMafz99iz8rT2gv7xcmZWU23zOvj7OLT/Ky7dvRFFc/vHiSqszF+ZO0E wPJIOuZE2wVC8EJq1vYM9rl+I6MJaQ0nSlie4JpeDrbOjj2D67fzbQGoY7mUM/ass6DOju6MMCyz teCIYCmSpYKmZNSUg+813x/dGBZT39sDbjQ0+VCUajsxq85oKBbnHQpY/6QM2xBrgNNscChEkYcc REJ38rSH45VmRpza85Sl8q5OTbNzMuK03i39FP2jfISXMssmXMPRZUNVAPCcNkBmt39Iqh3OrgKT 7r8yunZQC0AqQPds0AvK5Y24BZW3vYqhO3WiMRP+RAwM/r0JdRso1c/SR6UqM09i0hkaPSTdufLU v43zGm0p7KzMA5bRrem2HT+st2MDZBzE2xFFlXWaU3PRXTzI8bobfendF/UPtPfuc2PH+Ior5gRb rMe8iEgZcaZO4/0XFXllameDdgB7OiJxRH6QrX/F0g2Cq/W4K2GxsCcXlkOjThAo3zuQR80mNb0y /fgCQma+L8xcno+NOQdv8WrWurrZ2oMsQedUw/HaT871dUUm+7whWCR+XoasawfscY3QzM6eRk4L Q2rBEcFaJAv14pLQY5x/9eACG3M3uciH1hOzSo2GYnH+YJ11d3byv8g1gJh9Xt7D1pnvccTBnQj0 9zf28rSFCI+/OTbdNSsvbW56tecpU+TtHX/W2ZYTjszxvOFCN69Nz/Ha5TmkG/zjhUWJu0OpN+FU DY1Blw1RIcBz2gCZ3f4hqXicSPxehhxaCtE9G/b8uYTw6xuh8ZEflesP+UE6MeaZ6850OSW/Ks0r gerUVsYc60/EwUKGuYuVj2oYK9IZfvpijIdUormdq2GCtndFni1RzoqRAxYzj6FR2zaNTe1JNccg 3p5AqqqVe3XZvxcpA1/do2/vpHf3k+Py6jI/Qe0xHpsbIdBltiCzXGryuy3uxWk5wy/1RTPRhuM4 +cPZgVvD0UsHu/f11K/cyQg8a2fPOgsqbrUSq3ALjgixInVmbD4nm2FRpl09EC9BWJ0SNyDIh1r1 iROzCo2GYnHO77Xuc98zKdXk75Xxb9HwwV6cmWsrc+cCjLjEwl9GJXYy4u75RNtNzO3cQCB5q9av PeVtE79sfr+Fycbjv62Z6ZvaG90CZfpbLH7wj7u1ye8O+XurXtHpREpAl8+Is+bODTxqA3GiRIiR 2e0firrsyvSl8u6oxOieFWfj8olXP0yd9u44yYqF91F+SmI5oWLq+Ga885IIx38Fe7Qmcv8ovzd1 IuO7WBunelE1RTu1lTHH+BMpmSjWuQRlLWlSmdYFFZWQdIafOu5GB0Q9pFOxfwGsKEm2dTm+LRHO yjBgGdxarG37Y1PeEbyFm4sexFtYYIhmS0Ac/zo/0cpeNvF28YXlq4vzsZcuZZy2e0jrTRHJMv3B VHSZxDvnLMMurSM8v0C7Ynu1O17NwERaRF87N1VVRXIiEb7dHa+mIBOMCEg3E462KndlPKZ1OHxJ m09I1hcW9eTWFWWfsWeaBd07y8/zilitJFl840eEJIm0CU/xM+qYRZkbuyGs0VvTkQ81z2A1MQus 1BLVb0oCeef8uv8aZ3Wk/NrofedyiNia4t7JC4lJ8Z4GqY+6pui/oEL2zL0T4iXtXsySfyAvbsoF fmR28mHnkTP8GpIsU7zw1t8ajJRp4Cz9dTTEyE4k71X+BaLLZg8lAKdtgKxIyBwmRma3fygxWJWp fzmMv7ff2XMxGls2vo3NxQOJxXjmBnpI91QbuXz+gHPBxgv5q408y9/govqUuFmn+pRqIx7Gpvqv CsMWY+SQEzyS+fuIjcWQubZop7Z1aKQ/8b/YcWJ93DWwAnxUZv0amFH7zIzfuRpYfzWqsjcG0pbs nRWVkrZtamyqBsz0UhoG8fQFIUfrEZCx6GqMm+4a1+9ditPXi3ND+7xXBSmbD047xbjZow2RcopI lukPpnw6x791Ev/zA871dP6d87j3e/OxeHZsXQVyJn90LaImr1CPIfcn0uKY3Zk2qI+5cHfhTo95 RSpWNFZNeQvAfT+0UkxG48/nuiLuiBE8zOs8Mtqzspre3kyd3UpOchZEzpfEhdmDsoHEoJ86fLgq IwIpp/0gZa+mceEQtoDAnNZd05EP3Y/VOW3kzPzjNdJWaulNrzE5Hjnz3POHP/7JxlSGWkAABAoi wF3PpZ3eZbyCCkUxIAACIAACIFAlAvystYk7huJVc/x1a8Xc+ozDHlaTzwEW95VSLzm74A/H2Hnb 2+DNs5+qyNk8Qqi5NQi8+tLnPvjhj5pkESfn+IEACFSNwN4J7xwg9bc3q6Yr5AUBEAABEAABggC/ Nz7nvUGtCYTEad5a+TfFGqcmf3V26HPC8nsxoQ+hNYF0YpVVkTNRESQAAZycwwZAAARAAARAAARA AASqREB8sOAm6zs+G/pGV+N14JLc3lfWqbJBzXJOzvn5PP9ylfwSLX4gAALlEYg/OcfivDzyKBkE QAAEQAAEQAAEQAAEQAAEQAAEHAIIa4cpgAAIgAAIgAAIgAAIgAAIgAAIgEBLE8Cd85ZuHggHAiAA AiAAAiAAAiAAAiAAAiCwHQhgcb4dWhk6ggAIgAAIgAAIgAAIgAAIgAAItDQBLM5bunkgHAiAAAiA AAiAAAiAAAiAAAiAwHYggMX5dmhl6AgCIAACIAACIAAC7U+Av95812Piz+RyPmX5N8ztvlTKa8xb Vz5Jc+XW1eR/H5nZylUcMoMACOQlIBbn17yOKLqocmqHvYeem9Mfpql289pIxEtSFRnKpLIz8iFj /CMQSn4L5yK/iOj6Uy+jo368n6Vq90uYuOdpkkLNNEQT0pYAnFbE0ApR8cjs9g9Jfe1ttTmtUFSD OpADUw1fI82AfZsXWeREgX9qxZmjyOy+Zebu1EVpV2A5UWsMoNt1dklVlkL3sD+hC2S0OyrARxVI J76ogDN0k4YepuDWMLlbsSLLActgS2ZnFW4je/9Jjk2tiC63TPo47vb33IWigMYTCIxcGRa9u0/d f+Xl2bHeBknO++YJVp/od6rTXGVg2G2QNHI8ygDNEa82Mto9dTBj9yEbjj905x7SawnZZFd96uqm rDSTwLk7e2REo+ZLgaWBNrdP0ZZVGRFsZ1AsxXLAUneHZniMI5uYeJhmYlad0VAszuvPqH2yzWvP rI2+zJ3a/RvHvYdMurnwQ2vL5Ob+NDsT8pJLk4emus/LYq8PLh6KsXhDdqJMJtp1uueGFPWVmZFa vIjLEwdv9Qx5vrt/Uuko/9SHWN9OY35KJG6sJ9kFlf08O+Esk2ie1uiyJSwDOKkIWREpM5nd/qF9 maSt2htbNuCl5uJOZ7jeXfeMUw7/ukbj6yf9fbSIKHsnHHs+II1zcrc7EPKZhFvmi0cSukqpChZV uNEah5Sf4X/cD7daOjSTP4kUWJqPKopNYjkhZ6jSRx5ackusra0TpDAGzoGwJdPIGG4O0q1RTpUe m9qyEZYmvVGYD+I3L/mnDm2pbpsrpcYsPkWMH+NagMLWzOmLPReCHwb3u7Yz7LaAnNYi7D6Vp/vE NJzjtZxdjN4+dutO1iP6nJ1dLOcisyByvsRY77haVtw4vnbCLoxCI12VEcF+BkUOPfZqmhcO0TGO 8OfGdreamFVqNJRh7atrD8X/6zwyo6bvrNbZ4z4MdujurpQzeW7ukdn/8uJ87/gTcpdx6+7CCpu7 bQw9orIz8uHSCxfZ2JmkNbmjDW/gtbEzozspb7V19dL8/mPmFQtV+9bayv4BhY71DwytLiwLl2PB 09pdWicsAzipCNkKpJhkdvuH9mVStprC2KwZNyzh8nR99UBo1Bf26XYfxje5968s3t1MIdHWncVI mSmyt2hSe2u0dGj2/qQkH9Uw0KQzjPOQQrLUA0HD1GluRfbGQMlpdFaR5qBTUk6VHpuaS6mk2jt2 9s5Nq7M4wWewP+VkpSSxUGwuArWPDPSuvCbXcPqJtDoZFluowZAx9zCWqjMacUaVKct1Y0gPTa0k SX/vyhQ7PupM/4yJxenxNRmtqZ0Yh5RyjqlEhPxVL4hVPDSoSZQpzx6H66ts/mQwBpbS3azm3if4 +dwVJ9YsCYDh37WGUynunR1bPz7rxRcwNjj6+MIL0cm/PNtMOvnP19kzzYJqR8+NeR5GOBkbOasy IljPoOihx15NU0XRKQfZxPbtbr9Sy2jgZWeTi3NvYenWtrW5pj10gj0O3hq8EdwdzCacKFzO7bgP 4mWO7Wfrm3JAzfPb2ljvHey4S/i+aKnSR5wzLL/lpPzJvallubmootnF2imSOcgzddk5MxQIPKci ZHb7hySHeFstUPecrZAhu6eaivZRI9bDjRV9abSjq29l44F94WI7rLdnh32GiqcMz1GEOhYOzexP qALtGKXxUXYlFpCKdIYGD2nBrQCJtlERIVsyOatocyS6tYBXjB2b2gg335u4P7oxLFzl7YHk6Lk2 0rydVRE71E4koxe8I4/Txaq1dvSYexbC515i33n0aCdNg69ODy0MXA+fxkfLDMWm9SXAXbp9s29g T7hSt2vrVyzn6hvHZHDlgZWL02q6yOfA2vmtczbGn8/fYs/K09oL+8XZlVlNt8zr4+zi0zxUpHb0 RRXP7x4kqrMxftrpRMXyyFDmRNsFQvBCatb2DPa5fiOjdWkNJ0pYnuCaXg62zo49g+u3s20B5Ors WWdBnR3dGWFYZmvBEcFSJEsFTcmoKQfZxMZ2t52YVWc0FIvz0NGcCGgMROmoYI/7r4yuHUwd1GFs MscrzYx05GxVL/vq1DQ7p+LSu6Wfon+Uj/BSJh2bG8rsn5QRL2L5dJoNDoVShXkWpXC6cgoAnlMR Mrv9Q1JdO1stQPd0sAtO7Y24BZfb5sUJP+5fyfGvz9g5NMKfmAq05mjpo6zLy5uQdIZGD2nHLa9M 2yS/0ZbCzso8YBndmu4V48emtoLth6peYGM2751pK+3bTZk5NaHaxYMcr7vRl959Uf9Ae+8+N3aM r7hiTrDFesyLiJQRZ+o03n9RkVemdjZoB7WnIxKj4QfZ+lcs3SC4Wo+7EhYLe/IoaGjUCQLlewfy qNmkplemH19AyMz3hZnL87Ex5/QoXs1aVzdbe5Al6JxqOF77ybm+rshknzcEi1w/kZdMtQN2shFa oLNbyWlnQSJVC44I1iLZa2mYxkc3btSbCNTWlebPyYfWE7NKjYZica4H5IgzOhHo7+/h+TB5wHbG 7hpoEBEzf3NsumtW3gLdfLDOujs7czauyN47/qyzLSccmeN5w+VuXpue47XLc0g3+McLixJ3hzId m4sdXL5hKVYCl/ewdeY76zieBehsVUQhwHMqQma3f0jqaWOrhehuRbmEREL49Y3Q+MiPyvWH/CCd GPPMwhhvrJQgf+sUKc4Bor4r3qHF+hO6wESFrXxUYilFJSCd4acvxnhIVXNBA0FRalS9HM+WKGfF yAGLmcfQqFc0jU1V5xaWXwtVFZdmV6eIiNl207mN9XGvLvv3ImXgq3v07Z307n5yXF5d5jGPPcZj cyMnuswWxJpLTX63xb04Laeppb5oJtpwHCd/ODtwazh66WD3vp76lTupgefr7FlnQcWtVmIVbsER IVaknMs3w6KMbOKkdk+cmFVoNAx8So2P6+LM3PQGC/cel3MBRlxi4S+jEjsZcfd8olYo5nZuIJC8 VbvPfcul3S0Oyq75/RbmDsZbM9M3tTe6BW6G+FssfvCPu7XJ7w75e6teJVYXS7zU/JU8/gWkBJ6p HVLWDLmBp1MkQozMbv9QqG1Xpg/Iu3MYo3tWnI3LJ95fMHXaeaOpU63wPt68k5+qqZg6vhnvvOnA ie7z+1RI3P5Rfm/qRMZ3sTZO9WJrEl07egc15mJqjD+RktEFxgudVGaxKluURjrDTx13ww2iHtIp Exd6LeDaJ/FtiXBWhgHL4NZiHbU/NuUdwe11a3RK96xPHBXGvNW10WKhvgIIiDZ1fqLLeCWKt4sv LF9dnI9cz9QrlXHa7iGtN0Uky/QHU9FlEu+cs+xHVvwC7Yrt1e54NQMTaRF9HbgrKicS4b2qeDUF mWBEQLqZcLTBuSvjMa3D4cvkfEKyvrCoJ7etyNDZbbJnmgXdO8vP84pYrSR1hsaPCEkSaROe4mfU MYsysonjnLz1xCywUktUvykJHjnz3PPPz/xbHoQzUeN3cgKeSDzs5/cM3TAYvvcm17FiBsDvn59h p8UdnnPsmeHFx2dDl0lcZbTs8pEsU75vw6mrz49ZUiVfXHHSiORk9sQy3VpkjZEyPc7iVdivjbrx M86VpPCeop1I8q3aq5qComKSZ9mtnAgnPfBEw9BbNgqc5ECWSVdENSLNlrBVmZk2trJboqDy9QZ1 244PPyfnZPl+aypDDT4MGQPfvVYRMVSZBYnbpGJIs/d7pXjhqrMHZzCSqNyajbkeKalAvyMkdsOA j2oSNL3aoDN0/kV/aM2tBZRpngj2AxZpS/HOKjpgqfHadQK0VyTGpjQjePNYpq9Z84Gt1r/SK7Ot c/B+tLgvckok7nHclBZ/fLz74pqfQA6I2rxR61z65IQaN8kyPUMaOs9vaBOS6I3DS+BxoPoE2CtT JlPDrqaR6Kf8Brj38RRn6uimFBfRb++j4rrDaprH8eicR3cO+kxezhmiagoC/Ia8/pIpVcL+euBh 2ErJhgvpzo+vZi93TouPK6lBOaRXWE26Jxg7u5Wc5CyImi/5NiNf265/B8pKzmqMCIallv0gZa+m YWpETDmctZv6F693U+1uPzGjVmrN87SvvvS5D374o6b6xeL88Mc/2TzxUDMIgEAGAtzHXdrpXcbL UACygAAIgAAIgEDVCfBlkrfSa7wugcV2mdWH1aS3MIqQgJxdiGUVU6drLf2ripwtDRHCNYBA/OI8 ENbeAGlQBQiAQBEE9k6c76kfUp9LcT7BUkSxKAMEQAAEQAAEqkKA3xuf896g1gShayPP8vcBl35T rHFq8ldnhz4nLL8XE/oQWhNIJ1ZZFTkTFUECEMDJOWwABEAABEAABEAABECgSgRUAHkfD5M2fUGt UdoYY9GLEMCgZjkn5/x8nn+JsIivJhehOsoAgbYlgLD2tm1aKAYCIAACIAACIAACIAACIAACIFAV Aghrr0pLQU4QAAEQAAEQAAEQAAEQAAEQAIFtSgB3zrdpw0NtEAABEAABEAABEAABEAABEACB1iGA xXnrtAUkAQEQAAEQAAEQAAEQAAEQAAEQ2KYEsDjfpg0PtUEABEAABEAABEAABEAABEAABFqHABbn rdMWkAQEQAAEQAAEQAAEQCA7Af56c/mR0Ucnl7MXInLyb5jbfamU15i3rnyS5sqtq8n/PjKzlas4 ZAYBEMhLQCzOdzlfaNy8NuJ4NOHXvM82in6rnh++lqXLOsUGPFeKMu2zUylJPmTt9g+ty/RGiAC6 FLpna117YmT5JEYDW/7VDWUbFt5cfoLSHcC8jI5pxQ9sVO1+CdpXvktnm61F8uQK9EqnE/lqajz9 JhBZZEr+qRWtR2uTDNoy84jZ/LzWdpvGSAJG6+oYelh5mOFebBgImDVhDiqNZ2i+7UCC9iCgDyul f3e6PZC1phaBkSvDonf3qfuvvDw71tsg7fiIcILVJ/qd6rQRgY+/2vykQeJ4E4BM9dVGRrunDmbs PmTD8YcuBDn4igaVXfWpq5tSxEwCo7Nnal5kqgoBsTgfunnJW3UPnedOTf5xvnO4NHloqls9vD64 eCito+Hd8ml2JuQl7csks29ee2ZtVAp54zirP6M2+ciUhsUnkZ0sk3xoXyaTI0REzlw8E+2qDOA0 W7FEme65oaxlZqQWL9ryxMFbPUPeYNk/6ZiZyF4fYn07jfmp2rmLP8kuqKrPsxPOutS+vRIxtkgC PmgN17vrHis5/OvdZ3z9ZMyW2d4JB+8ByWpytzsQ8pmEW+aLRxJarkVQxIthMPtczkdMIAJGq0SI PKS6eSWgCSFNvZgYCEiYxENjmZWBAkErSWBp0hsU+JiizWoqqc12F1qNWXzaGT/GtQCmrZnTF3su BD8M7vtPZ9htATmtRdh9Kk/3iWk4Z+ri7GL09rFbd7Kc96kJPzq7dYMiYRUJiMX5fO9gv2mCvrw4 3zv+hNwR3Lq7sMLmbqcLE+LLg8jsP0WZVHbWeWRGLTNYrbOHra49FH8lU5ItQma3f2hfZjBld5dg nEL3bOZUBnCS7dILF9nYmaQ1uaME96RrY2dGd1I6bV29NL//mHmJSNW+tbayf0DZAOsfGFpdWBY+ nmzEbBhbI9fydH31QGjUF7jcLsn4Jvf+lcW7mynE3bqzGCkzRfYWTUqaaM6+QBptnCULNqqbV+Zn 34utCTP7MiuDCYJWgUDHzt65aXUWJ8ZZ86ymCspARodA7SMDvSuvyTWcfiKtjtPF3mIwZMw9jCWn Gl4QqB+pFy1TluumPDS1ktQS965MseOjzmzEmFicHl+TwYPaiXFIKefoS0TIX/VEFQ8NahJlyqiu 4foqmz8ZDHeNRtvFqbn3CX7udWUpSfXYf9caTqW7d3Zs/fisF1/A2ODo4wsvRBcU8kg8KVwCnT1X 4yBz6xMQi3P92DPUpbc219R0k/uLg7cGx/az9U05+OX4FVimKMpbpKUXicxu/5CsMJjdCfLh6G7I jdUCdbdXt5RKtzbWewc77hKDTVQw6ZTPGZbfcir/pICT7ndzkQ9aAilfrEZy5jSMdJKUltrTQsVR qxHr4caKvgLc0dW3svHAXgSxxdbbs8M+Q3ultO8LpNEaLDnczSvDzNyLw3M7e5XSeAb7UpESBJII 8M3Z+6Mbw8JV3h5IDuZKKg7/3hIExA61E1jnxSjJ43Sxaq0dPeZuzfOpgNh3Hj3aSYvNV6eHFgau h0/jo2WGYtP6Eigs3b7ZN7AnXKnrP/Ubf3P1jWMy1u/AysVpNXvh82otis05c+LP52+xZ2XgwIX9 4jzMrKZb5vVxdvFpHgBbO/qiiud3j+7V2Rg/snaiTXmgInOi7QIheCE1a3sG+9wpVkYz0BpOlLA8 wTW9HGydHXsG129n2wJAZ8/YLMhWFQLyzrmz9SjM3Q/D1iLYHQ8yM9JRnFoFlMnjSyPRRCkEJLPb PyRrCmdXccX3XxldOxi88Ss8cqE8ExUvAHiojtWpaXZOGky9Ww4M9I9yyl7KpGNzQ5n9kzeOr52Q 69XTbHAolCqnYSSibHgCb8RteM3tWWFyXyCN1mjJdDevBjuiFxsHAluNLD2DbXFIBwI2BMTNVbXU ucDGbF6DYlMo0jSJwJwa33fxmLvrbvSld83YP9Deu8+NHeP7zjEn2GJX2gvQkxFn6jTefzuGV6YW 3mine09HJFzKD2v3b/y5QXC1HnclLBb25MnE0KgTk8j3DuRRs0lNr0w/voCQmW+YMpfnY2POYUa8 mrWubrb2IEvQOdVwvPaTc31dkQUEbwjmX6p1JJd3HrUDdrIR0NntbBOpKktA3jlfnQrFlohtM9kz Rdz4zbHprll5BX3zwTrr7uzMqWwhZYqzRHHnxN9rTCUVmd3+IVlXnEg89Lo0nomKFwKcqKV3/Fln H1SMHM5QF063eW16jpuQPPh1o628ODRxWSvTsbnYMuc7xGLj4/Iets780TGnYSTCbGQC0XDrG6Hx kR+V6w/5QTox5pml1G6CNFKVVqnLri+QRvvpizGWrPRzu3mraGsjR2wv9gYCm5L8NFaeIV2RSA0C CQS0Czvi0mxkVgOAlSLgXl3270XKK0Xu0bd30rv7yXF5dZmH4PUYj82NmtNltiCoXGrya4C9487r gcSsqdQXzUQbjuPkD2cHbg1HLx3s3tdTv3InNXB09tTIkKFiBMTifD3yOi5+i2ZFXdkS0003aEfe gN3X716AEZdY+MuoxA5W3D2fKBCqTCeV1W0TIYA4M7dcmUfKJLPbPxSi2pXpq+5dgYvRvTzLyQ2c EI1fKGLuns7WzPRN7Y1uATj+KZwfbeXuJQszi942t7MBVyT+Ejj/xlc6wygPeFEli+v0U6edN5o6 hYr1kjfv5Ge5KqaOb8Y7F++d6D7eT+lf/+hY79yJjO9iLUqx5pVj1QFJo/3UcTewKGrJrvuq2k3X mF4sVfIHAvsWSyrTviSkBIGUBNyzPnFUGPOS0ZSlInkrEBBt6vyEX/JEEm8XX1i+ujgfe8NRxmm7 h7TejIUs0x9Mxewi8c45y3jCzBXgF6dXbK92x6vpTs4llc6O7uD9UzmRCN/ujldTkAlGBKSbmEUt ho+qPMRyOHyZnE9I1hcW9eS2FaGzt0K3hAxlERCL8+7zaiPN/4LOifXxG84Kau+EeEm7F1+U9qRa 3cb0X1Ahe6axTHEjNPCjsovjVu4wvSgd/atRoYpEWeEyyez2D6V4VmXqH7LibzUvhmeiHZQA3FEk xLbzyBl+70sahnj/vL8XG2lEg8xygIzGdFnZgG+rw6+N3ncuMtGGkUislRPweGkxnrlxB3K6WRu5 fP6Ac6XNC/mrjTzL3+Ci+qm4Waf6qTIGHsamOot634wYI4ecWIbM30dsNWik2afrC1lV0j4e43fz rIU1Oh/Zi8mBwJ6w0TM0WjnUt60IBHxgYEjaVhjaVlkZi67GuOmucf0umzh9vTg3tM97c43yYMEZ ixg3e7QhUs5YyDJ9Q+KzC/4pmfifH3Cup/PvnMd9So2PxbNj6yquMPmjaxE1eYV6DLk/ORfH7M60 QX3MhU+53dma9+HbWDXlLQD3nbtKMRmNP5/xirgqwhEjeJjXeWS0Z2U1pdmis6cEhuSVI/DImeee P/zxT1ZObggMAtubAF8sXdrpXcbb3iygPQiAAAiAwDYlwM9am7gxKl41x1+3lvbgKn1bhdXkc4DF faXUS84u+MMxdj7xNnh6vZADBLYlgVdf+twHP/xRk+ri5Bw/EACBqhHYO+GdA8TtzVdNLcgLAiAA AiAAArYE+L3xOe8NaraZCkwnTnHXyr8p1jg1+UdJQl+3ld+LCX0IrUCCKAoEQCBMAItz2AQIVJOA fKmp/FP+nn01CUFqEAABEACBdiUgv1Le/EUjfz0t/0BA0qe5szdCQ9WUHyWRb4D2f+r9u6EPoWXX BzlBAASSCCCsPYkQ/h0EQAAEQAAEQKBdCLzlwcbbf2X+bfylV1/72puMPfLII6k0e/PNN0WGd77z m13df/GjQ290dKXKjsQgAAIgAALbnEB8WPtb9z0++H3/465tzgjqgwAIgAAIgAAItD2Bt7/863+p /i/eurb6yNe+9shffOORr38t/Z+vv+Ub33jk//6Tt65/6e2vLL/5nu96Y0fkG85tzxEKggAIgAAI ZCXw3x9+6Tt3fNCUG2HtWbkiHwiAAAiAAAiAQHUIvHVr81suf+bNb36Tfdu3v/mOd7z5trext789 wx+ekWfnhbBvfpMXyIutDgNICgIgAAIg0HwCH/grzPQHi/PmNw8kAAEQAAEQAAEQKJsAj2Z/5M/+ lEek89D0/HWJQt75Tl4gLzZ/aSgBBEAABEAABDgBLM5hBiAAAiAAAiAAAu1P4K2vrbFveSdLXJkn JvBQ8ZTf8k5RLH4gAAIgAAIgUAQBLM6LoIgyQAAEQAAEQAAEWpwAfwNczOvfXn+dqT9vvOH8hf89 aaEuCvza11pc720lnny9ufiT9w3q/Bvmdl8q5TXmrauJLaSryf8+MrPVRGFQNQiAgDo5v+Z1xOUJ 5dF26f7If/jorrNL6aFtXhuJeEnhC1RFh/3a6aLts1MpyTLJ2u0fWpfpjRABNVPonh62yGFPjCyf xGhg69mGhTeXn8p0BzDdqJIHUap20lZLZ5utRfLkcnQPTDV8NTWefhOILHKisDTp9LJwp6YtM4+Y Tc9rbvqA4XE50xhJOK9UM/Sw8jDDvThgcprPL8szNN12IECbECAHhZBuppU5X4Hzdfi3fivr72cf +xg7cYL9o3/EhodZR4ezUI9nlPJ9720CvCw1AiNXhkXv7lP8C6OzY71lyRcql48I/PNjE/3OY21E CM6lGySONwHIVF9tZLR76mCWqX54yuE2HG/NiXtKFjn4iueyqz51dVM+zSSwTWfPBACZQKAVCIjF +eIh2XN4tznJLqgvJ59nJ5y5/tKk9/Dl+tDNS0lr6ZBSvFs+zc6EvOTS5KGp7vOyouuDTu00DDL7 5rVn1kalnDeOs/ozapOPTEkWSma3f2hfJpMjREROW92zmUcZwGm2Yoky3XNDGczMSC1e3uWJg7d6 hrzB0v9GN89eH2J9O435qdppWyUbMRvGFsnFB63henfd/Z75fTn8691nfP1kzPbW3gnROhzvAdmv 1efQxUAoPmTqfCP9xSMJLdciKOLFMDd9yPAC9OKdj5hABIxWiRB5SHXzSkCTkyVDLx5S/pn/cT54 a3AshHs3llkZKBC0igToQcFOE35Ozv/s3cv+xb9gx469+QM/8OZ73vNmVxc7eJD93M+xj3+cvfvd YumOX+MIqDGLTxHjx7jGCWSsaWvm9MWeC8EPg/v+0xl2W0BOaxF2n8ow1fdKj2k4Z+ri7GL09rFb dzIe0efp7NYckBAEmkhALM5X2NxtvpW1tbayf0BO3xnrHxhaXVgW/aZjZ+/ctNrfWl6c7x3sTzeV 58uDyOxflDP+hNxl3Lq74NROM6Cys84jM2qZwWqdPWx17aH4K5mSLJTMbv/Qvsxgyu4uQS6F7tms ogzgJNulFy6ysTNJa3JHCb7FszZ2ZnQnpdPW1Uvz+4+Zl4hU7bStko2YDWNr5Fqerq8eCI36Apfb fRjf5N6/snhXdk/L39adxUiZlllbOJmp6SOGl6IDkkYbZ8mCj+rmlfnZ92LSCeT3DJUhBUFbnQA9 KFhIzc/M+Z9Dh/iB+Ztf/eo3z59//VOfev1nfub1kye/+VM/9frNm2zPHvYzP8O+8zuwPregWXSS 2kcGeldek2s4/URancqKvcVgyJh7GEtONbyATT8EPVqmLNdNeWhqJUmhe1em2PFRZ+ZsTCxOj6/J 4EHtxDiklHO8LCLkr3qiiocGNYkyZVTXcH2VzZ8MhqZGo+3i1Nz7BD/3upIhTlbTX2s49fTe2bH1 47NefAFjg6OPL7wg2zHwk0fiCeESmTt7Umvi30GgRQiIxfnYfra+uSkEurmogk/EAsARkM96749u DAufcnsg+YDUQq2tzTU1heU+6OCtQb92i7yhJKIob0OhoOxkmfYVBVM60VlczRtyY7VA3e3VLaXS rY313sGOu8RgExVMOuVzhuW3XB48KeCk+xG26hdg317pKm1sak8LFUetRqyHGyv6CnBHV9/KxgN7 ucR2WG/PDvsMVUupN33U8Oz7Amm0BksOd/PKMDP34vDczl6lNJ7BvlSkBIFkArGDgjE7PzPny+8f +7E3bt9+/ezZt3zxi2/7sz972xtvvO0b33jrl7/M/t2/48t19v73s49/gr31reKAHb9GEhA71E5g nRejJI/Txaq1dvSYe4zEZ1di33n0aCctHV+dHloYuB4+jY+WGYpN60tQdun2zb6BPeFKXf/5qLZ3 MFffOCbjUg+sXJxWM20+B9ai2JwzJ/58/hZ7VgYOXNgvTs7MarplXh9nF5/mYa21oy+qeH736F6d jfEjayfalEfSMSfaLhCCF1Kztmewz+1NGVtbazhRwvIE1/RysHV27Blcv511CyBbZ8+oDLKBQKMJ /P8BFl8PCBK7weoAAAAASUVORK5CYII= --0000000000000830be0573f23aa3 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <> X-Attachment-Id: iVBORw0KGgoAAAANSUhEUgAABTQAAAFNCAIAAACxF3dDAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAA4xFJREFUeF7t/Qt0Hdl534nu1stSrmUntmI7kngAEJBg3LHTiT1W2CJMik7D g1CgkSznkgzD6UYvYyTRvAsKxDBux2AzTcJuJlwUOmdCU9EgIdjD8DYZe/nCgBjIoE2CBrt7FCcj erwujBbQAEFZseLEz7Etyeruux/12FX17apdr3NOHfyPuWR2cT++77e//e3Xt6se+cM//EOm/X7v 936PP/nV//ytV35x480332D8D3vzzTdfF/8j/s6fvPmWt7x598ZHf+s3f+MHfuAH9Lz631977bXv /d7v/epXv2pKwJ9/93d/92//9m/v3LmTTPMnf/Inf/7nf/5nf/Znr776qkrwlre85f3vf39nZ+cf /MEf8PL/9E//lD/cv38//3utVoupaHl5+Tu+4zs+9KEP3b1796WXXlpZWeHKdHV17d69e9++fb/x G7/xR3/0R/39/WQJDx8+3LFjB/lP3/ztf/CdHYOKifhf9qbCpf73d19b+p6de/n/vuuv3zDJxuXh 8n/jG9/gan7bt33b1772Nf6XN9544z3veQ//u1KZ/+edO3f27NljKuQzn734u//19776X3/vmX86 9r29nX/8x3/2R3/4J2+88XpH5/v++I//9L/999//Z5P/8tu/7d3vf+97P/Gx4zGF/NTJn/z61//s j/7oT77ru/5KqBDe9O94x9u/+Rev//y/vkYWEkPJVONTH/v4axubb3/72/7d5cvf/d3fFdN80X/6 kz/543e/+9tSZTHYWOpy3njjm5b1vuUtb0tMydvuH3/qp9761rfylF//xtf/13/1L/+Xn/h4Yq5Q At4RfvGXbvxw/97XX3/9C//xlb83/Pff9a53mQqZ+e13/I33vO7961//jq+HUn71D/782L+896d/ /k1u0/z3CGP/j3e97dInd3/1zb+sUn7xv7115Hu/wf+iN3pisSZ5fvP3vyWmWHsU/+7F65df+N95 V/qWb/mWX5n/5Uce4YKn/jWyEN2QZl64fOTwkXe8w0Hx2el//bFR3wxsDCm1qsgAAiAAAiAAAiAA AiDQegQeCS3Ov/SlL/E188qDt2995U/ffEMsyPmPLzf538X/l0tP9sabP/7R7t/64vIP/dAP8dUj qdT9+/ff/e53J+rLV+CPPvoomey//tf/+u3f/u1f//rX1SJc/3GRvP/s6OjgMvMVe/x0nK/wv/zl L/f19fHl/Tvf+U6enRfLn/DdAb6w/+AHP2gSNWbZ+Re//Q/e0/Gj5Mqcr9V/d/3Xv6f7h/n/vuvR hMW5rg4Xg/+nTvWb3/zmrVu34hfnP3XyE+zNv/BVePN13l6PiCXfI/z/eIHf+Po3/+W/+t+TFufZ C8mwOH/45S//zOl/9r6/9t6fPfPPTFaUaD+NT7Dn8R+1rPTurV9JTPmrv7b4pTVn74kn7uv7f+79 4X2JuaIJfv8Pfv/u3Ttvecsje/fs+/Zv/8sxJdisojd/90+env6N//vPxQr8W9/1jnOj/2Pn97w7 fhUdKnbs8N+21KL+4q+qlOSa37IQlewX/7+z/9u/+bd7frj/n/6Tk6ky6okbVohuSP+vv7d/9nOL 3/iG04WPHBy+dmPWk8rGkDLri4wgAAIgAAIgAAIgAAKtQyC8OOeLan5erY7y+NI8Kqh6yFfCv//7 v/+DP/iDf/Wv/tWSlOEr57/4i7/Ql9y6PPpzftrMF9jf+q3fGi8J3wjY2triYvPlLk/5tre9jR+n 84zxmwhxi/OVww4hEVYgKhf/T/yf2sN4k6+M33zLu/7S918xCcZPzi3pxS/OLQuJX5znKSTD4tyy ulZLVuzJeWbt/peP/4Rl3v/tX/8bPaXtKvpt3/K2zr/DM35z8z+wb4rT9fhVtM2anxS4qJNzSxpI BgIgAAIgAAIgAAIgAAItSyC8OG9ZQSEYCIBAfgKhVXSGAr0j7pg1f1HFZigHWUAABEAABEAABEAA BECgogSwOK9ow0FsEMhCgC/Os2QL5lF3zkOL8zKKzV8mSgABEAABEAABEAABEACBqhDA4rwqLQU5 QQAEQAAEQAAEQAAEQAAEQAAE2pYA/Tq3tlUXioEACIAACIAACIAACIAACIAACIBA6xF45POf/3zr SQWJQAAEQAAEQAAEQAAEQAAEQAAEQGAbEXiEfCX7NgIAVUEABEAABEAABEAABEAABEAABECg2QRw 57zZLYD6QQAEQAAEQAAEQAAEQAAEQAAEtj0B3Dnf9iYAACAAAiAAAiAAAiAAAiAAAiAAAs0m4Jyc //Ef//Hc3Nxv/dZvNVse1A8CIAACIAACIAACIAACIAACIAAC6Qg89thj73vf+77/+7//He8o4OPB 6eouKLWzOL969epf+kt/6amnnkpV7E/+5E/+/M//fKosSAwCIAACIAACIAACIAACIAACIAACxRL4 9V//9f/wH/7D+9///n/4D/9hsSU3rDRncf7TP/3T+jL7yp3N3/2Dr73BXxb3JpP/I/73vd/xrp/4 2zt1ybA4b1g7oSIQAAEQAAEQAAEQAAEQAAEQaH0C//2///f19fW/+Iu/iBc19GLyN954w0vPj74/ 8IEPfOd3fmcGZfkS9bnnnsuQsRWy0HfOv/L7f/46x/PGm/zP62+++Tr/3zfY1u/9WStIDBlAAARA AARAAARAAARAAARAAARak8Brr70WvzIXp7/i/Nf5iXWntjLnT7/xjW+8+uqrDdDuL//lv0zWEn1u SqlnV2lsUppUoxfncjXu/HGW6G+8wZ8UDuifub/CS/YKVDXo/5mqrsIljJGn8LpSaVpe4gx66U1W nmAoGQRAAARAAARAAARAAARAoFgCfGltKjBxWc4zqrX617/+9WKlSlXaH/7hH2ZeY+fJa1icv+4v zr/5+pvfdBfqiSqlXVOFVqqJ5WdIkFakUBXFSugtU0mpiq0rA6uYLJ7A8SqQJaTVy0ufs+2KJYDS QAAEQAAEQAAEQAAEQAAEshEgl+Xf933f9zf/5t9817vepcqMHqFnqys+F191ez+eMvSfXl6+xs5c e+a8hsW5E8ouluj85rkIbn+DlXFynlnhzBlbZL2nr3UTdWm6zPpqmTwGL0nCtKv6RJJIAAIgAAIg AAIgAAIgAAIg0EgCMafl3/Ed3/Hud7/7B3/wB7/ru74rFNlenoR85ez9eC2h/wzVSy7jQ0t6U5oM KiSEtfMzc/fk3DasvaR1WgbdkMUjoK9yTX834TKtkEtq6GjYf0kVwTxAAARAAARAAARAAARAAATK I8CX5fxsvD/426P9VNVvectbvvd7v7e3t5f/RT2JOUL/b//tv/3zf/Hc2Z894/3h/8kfptIifjmt /yu5jA8t6U1pVDlKMNPfQ2InhLWrC+f8j3Zj36g4uayKLgXjj0Ptl442x6qJK71QkLZ9zHaG5a5a ZNorqEBHc5kKsQGSympDFZnyhiQMHbOTuXTOiWInJkirFNKDAAiAAAiAAAiAAAiAAAiUR8A7Lf/2 b/92y1r+2l/7a48++mhiZPt73vOewcH9v/3bK//X//Wb/M/Kyv/v8cd/lD+0rEUlMy2n9X9NVWBh iZVkx44dUwTV7x9f+eKJmf/zU5fDf/Q0/O+hXKdPn+YP1f+qn/f3mL+EspC5QvXmSaOLF63aVLIp V7xeMWJHEdk/ISsNSRitOtuTRFyhhvb+MyqPjYSmNDZ5symIXCAAAiAAAiAAAiAAAiAAAgUS4N8b 936piuXL0l/VfjF5v3j/i0eOHv4H//DQb/yn3wgl40tUPVI99PfEVXTMUbm+qo/eKldPYqq2+Sf6 5NzyqDyqm3eImqh2zgTkzecMZWYrJ1uuDOKZskQPk0uK/c58al2gPJllKBA4igIBEAABEAABEAAB EAABELAnoM7A7V+N9l/+y3/54he/qMpPPD9/9K8/evIf/5N/cvKnfvAHftBepOjqOrqijikt9Bp2 tdj2ykwlhikxvTjPXHQh6yib2PICl8cZiopmsZE5M9VoxgwyZ67d1KYFLr+VbGRFhVhUZt2REQRA AARAAARAAARAAARAIBUBfWn9m7/5m3fl7w7185biv83j1FdWXn/99cRluSfJ33j0b/I/qQTTE/NL 4NGNA/LzaXrK0Po8VHv8v9qI+oiS6ad/+qd//ud/3stwYuaL8u/8w+aP8P/3yCNM3Tm/MPI39EJ/ 8id/0suln5lHr0l7C7nQX0ILPP0/E1dlocSktqYCo/Lw7KFj/9B/qvJjMqp/jVmyRgW2pGGiF6qx 8NWyjtRTzZ4AmVJnGGqyKL1EG7AxcaQBARAAARAAARAAARAAARBoGAG+FNfrIl/Drh7y76i99a1v 5cvyP/3TP40me/zxxzPIzJeozz33XHxGtQj3Fudq+R1arpMPeS4ymVedKZelIvGLc/aD3X+FF/Sf 1v9AFRezOCfry7zcauKqLHPVmTNaNlV7JwO99m5faAcCIAACIAACIAACILBNCHiL85hleeLqnSco Y3HuLctDq2jLlXm0BfXDdrXaD638UzV6XFh7z/d866HdNf6H/yVVoSpx9OSZPIsOlawWaaUeAsfo YiNhNHtzZc7QNC2YpVkt3oIoIBIIgAAIgAAIgAAIgAAIVJfAO97xDjI6PfowJoj9ne98ZxkEvIvi ahXtHZ6rk3O1rvaeew/VP3k/lUb99Ne8KYHtr9lHFXROzmdnZ7u6un74h39YpfhX/+FLr7/x5scG ut/1jrfy//zzb7z+2cX1t77lkf/33/mAXoQe1l4GO5QJAiAAAiAAAiAAAiAAAiAAAiBQIQL8q+Nf +tKXvv71r3syR4/QyUN1Lz1fmff19X3nd35nWq35of3Gxsbf/bt/N23GFknvLM7/03/6T7du3frZ n/3ZR/j9cusfFufWqJAQBEAABEAABEAABEAABEAABECgLAJ8Zf4Lv/ALhw4d+r7v+76y6ii5XGdx /o1vfOPf//t//1u/9VslV4fiQQAEQAAEQAAEQAAEQAAEQAAEQKBgAn/rb/2t7u7u7//+7y+43AYW 5yzOG1gjqgIBEAABEAABEAABEAABEAABEAABEAgQKPg756ALAiAAAiAAAiAAAiAAAiAAAiAAAiCQ lsAjn//859PmQXoQAAEQAAEQAAEQAAEQAAEQAAEQAIECCTxy5rnnCywORYEACIAACIAACIAACIAA CIAACIAACKQlIBbnp57+ZNpsMem/8pWvvPe97y2wQBQVTwDA28lCqtKaVZHT3jbaTyNS922ipn27 50zZfjyhUU6TaEB2tFEDIKMKEAABECiPwOc+97kPfvijpvJx57w88igZBEAABEAABEAABEAABEAA BEAABKwIYHFuhQmJQAAEQAAEQAAEQAAEQAAEQAAEQKA8Alicl8cWJYMACIAACIAACIAACIAACIAA CICAFQEszq0wIREIgAAIgAAIgAAIgAAIgAAIgAAIlEcgsDh/xP2VVx9KrhYBbhGFCFxUOYUIg0Is CbSCQ1AyWAqMZM0lUFRLFVVOc2mgdhAAgQYQwBjRAMioAgRAoJEEAovzN+Wv8Oq9KT6mXIWzjRYI 2g2A3LAqmtua9g6hvGV8GR7JsvmaCL9hVTesIkvmRSVrol6hqvX/VCNgE2XLgDcqrd7ZQ9rFL5M8 9TOIUXiWkMsi/1NVGqNjYlPqQEpaQ5LN4UnucfNqT2yjmPaNWq+p9kQy8Q0a7TWm9DylGqcwvSy8 j6BAEACBZhGwCmvP4/U819nESXaz4DalXsU523AVbehsrVZUOU0B2FKVFtua5anmyVlIFXkcTiEC qDmo6kTZukBOMRrW7sVWlI1VGe6iWL3sWzNqNp4J6X/J7KLtJSkqZZRkqLPr/5nNAIoS1b4cr5m8 RazX2ZU1hhTRXYHXjjYuIlqOvZCWKaPMyVbQH5qaidTI1Nz8uUofktN7nsd5RntNIo2q2F6iIkgA AiAAAlaL86IwwXsWRRLlgAAINIwAHFfDULdTRW1vNt7azHLhp/a8vP9tVlvrS8qi2qiocgpnknmj M7Qmj25YWIrasmQs5UcyEAABEGg8AbE4j3ff3miqJ7MP0FLbqNEq9Ife32P+4u1wh0qzl6TxcFuq RpJbqBWUMXiNlZhFbxRP2ajBWBoAmtJkMIqMmuVE+4hlK4QatzEdKmpO0VZWT3S9oqI23jZawXHp 7R5tZdISor0vmxdK7PuJ3TzUrLp/8DyMvlozuR2T4jYm0USA2bC3bC6SZKp1VxUP2AtsDs+BW3bk /FWHalSr6+hDvSKT04sKE7WHbOXYq0n6E9Ld2XgG+3qREgRAAAQaT0AszpVHNtXtjaneSKz8e3yu kKcOJQ6V4JUc+ouXzBvPQoFSaSVpPN8WqZEEpWCGmEefeCrolqDPpEPGEDWY6ByONIBURtUiYBsj RrRRTF3DaxebbhsqRK2UCmwFm1bWZQhN33WzKVAq+yaLVtpgxxXv7hSfUCNG291eX339HNW9iu6i WQAzMG/xLCGSidOGFldHXyHHTH5K0oJ0I1FvnKp2NcWKDrWpClHNqoqKzxiqKFq7ZTn24pHTD5th zr4KpAQBEACBFiGQfHIeFVQ54kT3Hcpo4/GjWUhM+sCQQZIWQd9gMUKgsjViUcbQYN3br7r8kzCd SbGl6SUndk/PDsuTIWfrt7jjKonb9nEXJQHMaXWVyJ6qa3iHnFy1tJOHkmh4SzslUklSkZSi1ZVh hzpzpaNlk9kkKypNSY2LYkEABECgugSck/NUA0OqLd4yBjy9TLVBm0r+6rZWHsmjoArZ205lDHnk R97yCBTeSb0CE7tny9pP4UxCa5JEMuU1t03JcBc2lOLTlGFC+aVqVgn6Sri54zW5qsw5Gia2dUjl xnT/tFOjRC0sjaeociyrQzIQAAEQaDMCzsm5t8Ma+ounrb7R6x12WW6Bq7xqFq4K9EqIPlFlhnZ8 E3NhMNBbymMYxeuB8holZNB6Q0f33fUWV/9qMoaYcqIGQFbUZj0tmzrRjmDZNVR1ZLe16YYqjd4T 47uY7je8lJ5t6DLrFqhbQqj8kBMI5coGM22uJjoum1Ym00TbPV5rveHayV00DGAIr27zpk5EMk9r nA1Ln+iCyN7dMPGyVRSageijmMk9Rp1htK0thYl3jJaFhEZ8PZfu9kmHEOPMo07PZhoQqt0bO3je bBsxUdoxYsQPc2l5Ij0IgAAINJ1A4OTc280NbbiaTlFs9mX1MnVto3lDtZOFx+RqOsoWESAeuD7z iGlWpUsogf6fekNEa4zJ6FEiS/AqbRGYTRcjsY1InmTzkWxNHSpUQmJPj3beqAyk/ajZm/rpq3qv RpPVld00zXVc0XbXeZraN/45Saxd3UXDAEapmrxf1KQ9b1y2MecpP94Fkf3UVJ3St0W0Dvk07z/1 hatpmPNUMJlZiEBU5ahby4xFbwJ91I4K6fE31UV6A5M9h2YIeuEmr2Jvh3oJoZL1gSxGYPu6kBIE QAAEWo1AQz+l1mrKQx4QAIHmEuCzq+hZTXNFQu0gAALbk0Boxb49IUBrEAABEACB5hLA4ry5/FE7 CGx3ApanT9sdE/QHARAAARAAARAAARBodwJYnLd7C0M/EAABEAABEAABEAABEAABEACBlieAxXnL NxEEBAEQAAEQAAEQAAEQAAEQAAEQaHcCWJy3ewtDPxAAARAAARAAARAAARAAARAAgZYn8MiZ554/ /PFPtrycEBAEQAAEQAAEQAAEQAAEQAAEQAAEKkzg1Zc+N7TcbVIAi/MKNy1EBwEQAAEQAAEQAAEQ AAEQAAEQqAoBvjj/4Ic/apIWYe1VaUfICQIgAAIgAAIgAAIgAAIgAAIg0LYEsDhv26aFYiAAAiAA AiAAAiDQBgTunX1012Piz+RyUJutmaeiD5unMCmnUfjmyYmaQQAEWpaAWJxf23LFkz5Our/DCQ9T KLR5bSTiT8mK6DKp7Ix8yNjyhPLdu0ZmPJ1Mkm5dPex7eS+jo37E+wdKoWr3S5i45yVOoWYKoElJ SwBOK2Johah89nZlT4xK6Y1/hRpwEu9y/92BHJiU+Lq7hsrNz7d5kUVOX5YmXXuW2X3LpEGVq0iB pROGR2uUs1eG/UmgLXadXXJVKstHFYgsvqiAM/RGA91DMlZxm2kYS0tjMNiS2QGG28jeqZK9oGE8 GlqR3ZAU9Z9cSNsBxeQEGqpn61VmPeuwHuKjDmf3qfuvvDw71lus9t5wGVssPcLSWUg5SxA+ML67 Gxb8oTvQe3sW0gM8dXVTimunb1gzu55lRhhpTWpyEpiHaxPpFA1eFfcblTPViGCpptPcxH4Wd3jB 8d1fPfG5oje30VvEeZhmFrSNhp4UNmqZVCzOFw+pbrA0eWiq+zx3f/dfuT4Y+9CycLU8eJqdCflT siKyTEN2okxpatM9N7jw/M/MSC1exuWJg7d6hjwv3z8pcjl/6kOsb6cxPyUSd4In2QWV/Tw74SyT Nq89szYqH944zurPJO8X2GM1pywDOKkIWREpF5nd/qF9mUyOfyHg9sZWBP6Cy+B+cLjeXfeMc6I/ 1E/H109q+2jh2vdOCBrcng9I45zc7Y7NJ5hX5otHErpKwSrlLo42PKLp8/VKkz8ZUh6S/zm1V+pS mo/KTcq2gJAzVNkiD6nOZVvDtkmXwhg4E8KWiCGYbA7SrVFOle4FbdkglkOSjs7zn/QwYbL5SMO1 JU97pexnHZbDsVgApBikaiOXX74vB8ft9lMjO5+xR2cCDmoHS28fu3Un8cjKgM+yZ5ngk61JTk4Y 6x1Xc/gbx9dOaMcJdu1aFfdr5Gk3ItiraW648Pi+NOktYfiM8eYleTpLPhRNYTUL2kZDj515pkwl FucrbO42P2dbXpzvHX9COrituwtxD1PUwXtgZPZPVkSXSWVn5MOlFy6ysTNJa3KnFm5za2NnRndS lW5dvTS//5h5xULVvrW2sn9ArnwY6x8YWl1YFpbdeWRGLYdYrbOHra49TMEtc9IygJOKkK1Aik1m t39oX2YwZXeXWHWmMLbMzEvLuDxdXz1wwVkEOrUI+3T7KauNjO5fWby7mUKCrTuLkTJTZG9+UgvD U02fq1fa+5OSfFTDQJPOMM5DCskUYfzCBOyNgWJndFaR5qBTUk6V7gVt2XIWnkGcF1H+02aYgM0b rcZ61mHDWbjuFIMUHS5OBEeII+Vr8rTQO0aWh4fD9VU2fzISMWrZRcgoDMu8QlMvWDU+WjOpxNpH BnpXXtMW3/fOjq0fn9U2LAZHH194IXQdQEyQxKF6+JqAlVtLEsn79zSt6WWqHT031js37Zz255HT yi2IehvnfnOKZD/KmCqKju8dOz3agsNgvxjgyYdku9svi6zNZtsnFIvzsf1sfXNza3NNTbm4szt4 azDmYU5oZEU5y2RbG+u9gx13A57XVKZ0W+cMy285KX9SnYml+d1cVNHsYuyP5BMqe6v3NKUWkrZA 4DkVIbPbPyRpBLM7sVLcgG/INW2BuhfSFqkK8VRTAUhqEH24saIvjXZ09a1sPLAvVuy79fbssM9Q mZThpheCZ+6VZn+SYxqXwkc1jDrpDA0ekiLcMEHbsaKQLZmcVbQ5Et1awCvG9oJ25BqnE+k/zTxp m8/uBLYN7jzzyVSDFBUuzg+NnaBFHjjG/OCyufrGMRneeGDl4jSfsNWOvqji5N2TwNg4stWpg841 MbGelz9TRXbNzFfmhxYGrpuOvu0KUanEPr4W77k8weMOLh/t1IvYsWdw/bZ3FStN4fnSpmpNrarO DuNHpvIJ5OZuQfdrKVJO/anxnW/s3h/dGBbzzNsDbugx+VBUbusAMfTkaCqxOO/Q8vOVuYgmmhlJ fJijUpGVrChXmatT0+ycjDitd1982r8zHyqUcltekqRjc4OA/ZMyCEcsn06zwaFIjQcv9oTOP3Np milzAcB5JEweRcjs9g9JrcPZVazU/VdG1w4Gr1hHrToTxeZk8uYQzam+GrVGmj5nryT8iRir/HsT zm2gNHQsfVSaInOlJZ2h0UPSnSuXANs3s9GWwo7aPGAZXbruFeN7wfblT2hO8YzafG4nsJ2YN2w+ GYDKt1bZnJqP7XpsTDssccPQaj19GVrBjbj2770bK7IqXaxavSBNGQSnH31bFeGpyUNBr3s7C3Mn Ts71delTeFkYr4KpcGXtJ290VuBGQMFytqD7tRbJzjKMqegBxb96cIGNuS8wIh9aO0AMPflaSizO H6yz7s5OEXp9c2y6a1bepdyMeZivRhnjHakoZ5kie+/4s85O4d59Rje3eW16jtcuvbYbzuS9SWtr 5nS2Y3NnC1ZM3C/vYeusp8MN+hRnnuIuhxPfXoCa6YsoBHhORcjs9g9JpeNE4pcL2NqDrdKMLX0r ZMghGm59IzSY8qNy/SE/CCKGYXNlDbxhkUHjIrK4TS9mI+JgJGuvjPUntT2DfdLA0v2sfFS6InOk Jp3hpy/GeEhVmUY4R+3I6hDwbIly1IwcsJh5DI16RVMv2J4NQPrP5CGSsvmMTmB7cM8zn8w7SPGr HP5Cmvv/0t6r0rCKjDbj3jkP6Mgfzg7cGnbfAOdn3r2vp37lToMNMGtrOmuQsqVtQfcbK1JnPiCG FZB29WD3qfrQ6pS4AUE+1KpPdIAYevI0llic83ut+/hVczH89A3skW0vL7uaHorhny9oxW0Z/jIq sbkS9QJxMpEVqQxWF2CosvmVGybtif+2ZqZvBiJ8tEs1/q6PH87kvj3u3pUpfyPTqySdSPyVPFPs +Ki6as5BiaPmpq7MhRy5gadTJEKMzG7/kDSMBJG8azMxuufpN43JK95fMHXau3YlKxUOUblO2V9O 3JR9lh8FOG86cFyq6Lzkr3+UX+U64b9pvDGaNLAW/8aUV2n6XhnjT2Spwlc497KsVUsq07qgohKS zvBTx93ogKiHdComCBcl0nYsx7clwlkZBiyDW4v1in4vyDuCV7mVaP+ZOExQNp/FCVQZXTrZreeT RLE5Byk5bhL3q2kFRPg0v9eZTjuVOl1F4RqEKTpv3oqftWYQjfsNHkA6HL5MzsGuLyzq5aWb30Yk scmeqTXvneWHZ3INon42FWXgpA/ljXK/iWLGjgiJueMTxKyA3MMGEQ/iLaDIh04V1g4wMAHLqcD2 yf7Imeeef+PvfNK5gC3uwEytCO37/CCZyEMxA+B3es+w0+LCzDn2zPDi47Oh+y0uQX5lSw8rEnd7 RAgNWZGzml1x0ogiyOyJZbq1SCHkfEUv02tc8Srs10bdkB7n/k94kzWSnaxdvlVbXkPyhfd1dGrU 9CrPwBLhaC1rCbzmWYWuiKGiaJkkB7JMuiKqEWm2mkh849x7Y7/B2Mprg0JL1jm7bccHqpNzsha/ NZWhBh+G2ohvqKsIDqrMQoUus7Akn+A3fb5eqdmY23P9AsVLZR0DS5JHsoj4vYCPKhOXZdlBZ+hk 0h8aOpdl8dslmb0xkLZkHBklv+iAFRysaa9I9II0I3iFWs44JIV1oPwnNSchbd7QcBXiVLyoaWYd tsNxdJDSyPtOlXyo9yP5AnDhq3mBi/vUCChk4JfS3XhGG5G4zfCPATk+X+uJeqdzKkojJ2mKjoT8 rKjufhOEbDNNI//fQ2rys6LZy53TvvCyRn8uGvpP2jbMPUupnyAnOeWgJic+Da/VXIGyy5kwY9eG 8ga5X8O6xn5EsB9l4l1iYEDRJpD+5IR6aD8LoiZgxTufCpf46kuf++CHP2pSQCzOD3/8kxXWD6KD wHYkwN3upZ3+NbPtiAA6gwAIgEAmAvCfmbAhU4MIiGUVU0dZLf2ripwtDRHCbU8C8YtzEdaOHwiA QNUI7J0431M/pN55M6G+FIAfCIAACICABQH4TwtISNIMAvLjLKEPoTVDjqQ6qyJnkh74dxBoRQI4 OW/FVoFMIAACIAACIAACIAACIAACIAACbUYAJ+dt1qBQBwRAAARAAARAAARAAARAAARAoN0IIKy9 3VoU+oAACIAACIAACIAACIAACIAACFSOABbnlWsyCAwCIAACIAACIAACIAACIAACINBuBLA4b7cW hT4gAAIgAAIgAAIgAAIgAAIgAAKVI4DFeeWaDAKDAAiAAAiAAAiAAAiAAAiAAAi0GwEsztutRaEP CIAACIAACIAACGxPAvfOqo+MPjq5nA/A1sxTdl8q5TXmrSufpLly62ryv4/MbOUqDplBAATyEhCL 811nl0QxyxPKnXl/pK/ZvDaiPVQp0/2cEgKeS/gCVezhawlugMruShX2hp4KFs5FfqTR9ae07iY9 KZH8ErSPTqdQMx3T2NQlAKcVIZuGEo3Mbv+Q1JbK7g3JAbtqTisU1aCBDugYvK+RZsC+zYssMuXS ZKBH+5ZJgypK5GaUY9AojfeIih32JyZnmKaWND6qYSADztCtNfSw/WymHLyWxmCwJbOzCreRvf8k x6ZylG9yqdV29U2G10rVB0auDIve3afuv/Ly7Fhvg3TiffMEq0/0O9VprpJPcbUJYYPE8SYAmeqr jYx2Tx3MMtUPTznchuOt6UKQPVQ8l07pqaubUsRMAufu7JERjZovBZYG2ZqyKiNCVM5Ug5Slmv6i Mtqvw2OcDt8zSOJhmolZdUZDsTgfunlJrJD7J195mXs09ac+xPp21py+PXTefX5qb8ruzs39aXYm 5CWXJg9Ndasyrw8uHoqxeEN2okwm2nW654aSf2bEld0g7/LEwVs9Q57vNuseyU+JxN3ESXZBVX2e nXCWSZvXnlkblQ9vHGf1ZxqzGVkGcFIRsiKSNpnd/qF9mUwOySHg9saW0rQbkZw7neF6d93rmHL4 1zUaXz8Zs721d8LpywekcU7udgdCPpNwy3zxSEJXaYSe+eugm550PpT3iApg8icRZ1iaj8oPxbKE kDNUuSIPKcKWFWyfZCmMQYy84YHV7KzCzUGmpJwqPTa1ZYs0ZcBtS5KtoJQas/gUMX6MawFRt2ZO X+y5EJwb+13bGXZbQE5rEXafqjuLAussWsKYhnO8lrOL0dvHbt3JekSfs7OL5VxkFkTOlxjrHVfL ihvH106k3mqpyohgnM/bDVL2apoXDtExzltV8QWpWqXy2S/xUFif1cSsUqOhWJzP9w72ByfoW1cv ze8/VsSsnZt7ZPa/vDjfO/6E3GXcuruwwuZuG0OPqOyMfLj0wkU2diZpTe64EN7Aa2NnRndSridJ d6r2rbWV/QNy5cP3OAaGVheWhRl1HplRyyFW6+xhq2sPs3i6tHnKAE4qQrYCKS2Z3f6hfZnBlN1d wqhTGFta1OWnX56urx4IjfrCPt3uw/gm9/6VxbubKUTZurMYKTNF9kokVU1POwpLu7X3JyX5qIaB Jp1hnIcUkjmEGyZkVSqyNwZKI6OzijQHnZJyqvTYVBWeqeRsyoCbSkIkTk+g9pGB3pXX5BpOP5FW x25iCzUYMuYexlIVRSPOqDJluW5o56GplSSR712ZYsdHnemfMbE4Pb4mozW1E+OQUs4xlYiQv+rF loqHBjWJMuXZ43B9lc2fDIamUrqb1dz7BD9PupIhTlbTX2s49fTe2bH147NefAFjg6OPL7wQnfzL s82kcIl8nT3TLKh29NxY79y0c9rvHP4nyVmVEcFyXmSaUduraaooOuXo2OnRFuOdWqWSD8leZ79S S+rhTfp3sTiPnDPLiemT/iF5uJ/nk3Vrc03N7bgPOnhrcGw/W9/czFck914b672DHXcJ3xctWfqI c4ath7DutoLdXOQ+VI4Wl+YjeYTK3urdtsTC0hUIPKciZHb7hySRYHYnMInb1Q25k12g7oW1h3VB nmoq2keNWA83VvSl0Y6uvpWNB9ZFyu2w3p4d9hkqkzLc9LkEN/uT7M4wjY/KJXyazKQzNHjIQgmn EbJd04ZsyeSsos2R6NYCXjF2bGpLtjnHqbZkUlWlxA61E8XpBe/I43Sxaq0dPeaehfDBXuw7jx7t pDXlq9NDCwPXw6fx0TJDsWl9CeCWbt/sG9gTrtTt2o9qewdz9Y1jMrjywMrFaTVd5HNg7fzWOcvh z+dvsWflae2F/eLsyqymW+b1cXbxaX60WDv6oorndw8S1dkYP7J2ojh5VCxzou0CIXghNWt7Bvtc v5HRcrSGEyUsT3BNLwdbZ8eewfXb+bYA1Bwv5ew66yyos6M7IwzLbC04IliKZKmgKRk15eD7L/dH N4bF1Pf2gLtKJR+KUm0nZtUZDeWd8+AN7eDRsWDhhwrHhaCnax3HK82MdKTLZ069OjXNzqmY/G7p p+gf5SO8lEnH5oYy+ydlxItYPp1mg0OhVDxaIxL1VJTS9uUUADynImR2+4ekquHsKjDp/iujawe1 AKQCdLcHXUJKb8Qtoey2KZJu+uzqEf4ktzO09FHZhU6Zk3SGRg9ZNOGUwrZXcqMthZ2VecAyujXd K8aPTe3F1NEm5zjVlkyqp9ScmlDt4kGO193oS+++qH+gvXefGzvGV1wxJ9hiPeZFg8qIM3Ua779r yStTC0uxw9bTEbka5gfZ+lcs3SC4Wo+7EhYLe/0YzKtuaNQJAuV7B/Ko2aSmV6YfX0DIzPeFmcvz sTHn9ChezVpXN1t7kCXonGo4XvvJub6uyGSfNwRT4craT14y1Q7YYxuhiZ09lZzJltSCI4K1SMna JTRidONGvYlAbV1dYGPuKpV8aD0xq9Ro+MiZ555fm/m37LzbGZz9ReomquGfuvY/lrNpkB0EQAAE QAAEQAAEQAAEQAAEQKBdCWzc/P/wtym9NqpWnfLNSqtBXfk9/zPstAj3UOEkPGpvTKxSazz+JfLQ fRGjSBhepYrC3YqCVYiUXlHNIf3qS5/74Ic/aqpbnJyva+9+4/dn/P3FYCbxTzLu37kAIy6x8JdR bTZHLdQKAiAAAiAAAiAAAiAAAiAAAiBQPQL+ubd/I8OJN3FjN0Toh/eGcvKho7a3Sk3CwF8oaPOq iKRiyvx3sTjvPu+ek2/NTIfDbPyX1J9YH7+R+Bb0MmVF2SAAAiAAAiAAAiAAAiAAAiAAApUjoL+z 0PhGvdrIs/ythIfk3RbxeS+5SiUfah/81lap6hU5/ssRg58GF8fpoTcgtBpGEdZ++OOfzCOWF9a+ cfPlPOUgLwiAgDUB7nou7fQu41lnQ0IQAAEQAAEQaB8C/C46/4xus46OGhYfG1aTzwEW95XyqTZy duGGFutRxK1oQ1WRsxXZlSoTloohvMlh7aW2BwoHARAogcDeifM9zrZi6m9vliAOigQBEAABEACB RhPgH2Ga896g1ujKeX3iNG/txNm8bx1PkrxxavJXZ4c+pSy/FxP6EFqSvM3496rI2Qw2qLNiBERY O34gAALVIyBfFir/+J9gqZ4WkBgEQAAEQAAE0hOQXz5v/qKRf06Fv1A66ZPX6dVzczRUTfl5iFfk l2i9n/xeTKuHAYt9korImd0UkHPbEEBY+7ZpaigKAiAAAiAAAiAAAiAAAiAAAg0kgLD2EGyEtTfQ +lAVCIAACIAACIAACIAACIAACIAACKQnIE7Ov//Hc70QbugJ5zvn8y/ghXDpWwA5QAAEQAAEQAAE QAAEQAAEQKAdCWCpGGrVt7+a9J3zdjQD6AQCIAACIAACIAACIAACIAACIAAClSGAF8JVpqkgKAiA AAiAAAiAAAiAAAiAAAiAQLsSwOK8XVsWeoEACIAACIAACIBAuxP4nZmzBx69/IXi1Cy8wOJEQ0kg AAJtT0Aszj//OwE1v/qLh38i5Oa+MMGfiD//aOarqZFsfv4fibwBvykdnyzzcKj2SPH22amUpLRk 7fYPrcu8P6V0DKqZQvfUrGUGe2Jk+SRGA9s0hhGwKy+jwyd+WKVq90uYuO/pUTrbbC2SJ5ejuzIk pxP5arpPOA2/b4osMuXSZRevzO6Doi0zj5gNzUvYA61RbiMhnCFjoYcVh8lYuBcHTO4nprzv95bl GRpqO6VXZknJANnswcKmaD9gkb2gdA5NqcB6DtAU6VCpLQF95EqcItoWakjnDZc5y8mQPTBAuzNk /tAdqb0NAtmFz/7ipjfBS78NkbdrRIY5anYRmNdpE7MUbKriP6NypnLplmoa5vOSZ3hE0OF7ozbx MM34vo3GjhQ22pikYnF+47y25P7CxD/99Z7+br92YQHXen5u7v6/4X+eH/nudHLxDvw0Ozl7UCtQ rBk+MfX+U7LAzwx+4RMxfZjMvvn582s/JuX5uRFPeDKlYfFJZCfLJB/al8keHZc6huS01T0daDd1 GcBptukMI2RXH5pUZOSfej/re+/7TPpStfNB6ywbU9lPsbqzLrVvr2xsG5+Lu9HhGx11j9VTH+Iy 6N1n/MtnY+Yue59y8B6QrCYfFRoI11xnXpkv/k9G8o3X16ZG2hqJvpbfSCLOUMgXeUh1cxtFWiKN qRf3K//M/4yrD94aHAvh3uWkIfuQ0RJYsgqRghKvgoBsGh3CVkeOoZQDpHtBVv1aOp/9HKCl1YBw kkDfwc+E5k6xYN43cmruvhwfC/oVXiAtlxqa+Uw4OpQ7fdxRqruP/fqd9GdjqtacXYOcM5CzC8a6 x9Vi4edG1uraeYBdq1TFfxp52rl0ezXNDRcdEbwpMZ9R/9oleeq5dJl4KJrCanzfRmOHnXk2NpUM a19f+12nVt6WawdPjr7XF2Lp5gw7eDLtmtzLzztwZPb/hcXl7vH90o1+9ZWFTTb3n43BSFR21vk/ Pa+WGey7d/S4wpMpSZZkdvuH9mUGU3Z0iX2NFLpnM4QygJNsUxlG1K587b76i5eWf+SYeYlI1f47 a5s/MqBsgH1ooH994YvCE5GNmA1ja+T6wvSN9QNjzurIEUngcrsPe9/Ij/3Iyhde2Uwh7u/c+UKk zBTZm5/UoqervpbXSEijjbNkwUZVXZmffS8msef3DJUhZSeoPSWqPOPoELE6OiXlAOleYKdNxVJZ eIaKaQRx2XfvGuz0JqjRkDE3TjAQWSacvxebGQjK045/xZmQPHscvrHOls8GIhy9ZIZ4T69Mccr9 eRlqqp1sZ2q1933kQ90rX9GCWO9PjX15ZFbbbhj8sR9euBmdKsuzzaSD9HxdI9Oc4bt//NzB7rlf dk77nfisTHJaC984/5lTJPthwlRRdB7S8V6PtuAw+DfEoQv5kLRP+2l2JvNGpvQE5OLcXedId3Au sEz6nY0vdw9+zytFeB9XuK8+XFNTWO4B/+mvDx78Efblh2lWF5qSoihvkZZeeTK7/UOywmB2J/KH q/lzcolVoO726pZSaRrDIOzKl14uDw6q07k0v19bVNHsYrEayZfTMNLIUWJaTwsVv6TG4N/dWtFX gN9T69vcemAvhNgO6+75HvsMlUkZ7mtC8BxGQhqtwZKpqivBzdyLQ7PVFNqk8Qwpim3HpCHIJkcd tbpElx5wgLG9oB25Qqf2IXD/xpS7Ec9Pkp2QSR5tx5yQMb4hpWJ89PBMMqWYcGohY+KA57t//EWV 0T1IdE6SZDBUMN6Tr/Y/sfAheZgfPOWeu7F1TEbwHdicmfZv2KVtAbERr8UPfmGCi3rqxzv1Yr5n 1+CX73mXjNJWkD191jlD5/d0ZK/UJmcL+k9LkWy0i0lDzUNER/ixrWExUbw34MY4kw9FwbbjO8aO nE2VI7tYnDtHc5Q7ECWvT/0yO6fCj98/83TSFXFbWRxH+fxI9nUCj+uY6QmdK9pWz9OR2e0fkjWF s6vIn/v/5sjaPw3e+BWDRB7dU+jpJC0AeKhSS8Mw2ZUsLenY3KDnhyZl0JRYr36WDfaHUuU0jPRs y87hzSHKrqjK5Uf6Wh4jIY3WaMl0N68GTKIXe/NdeW8o7tqRQUVLz1ANQCVJaYQcdtRm/2l06boD jO8FJSmHYkEgL4GVG58Q43v9wbg62GB814/NqUH/Jw6MRXfk/QrplEv/+df6shwDqIkK39T24vtk wJp7yu2Gtr2vpzOLyq5GPGT1M16Q6Vz97FxnLbK05fUyFa6s/eQNwSLj+bNoYZGnYDlb0H9ai2RB Ky4JPSL4Vw/G2Jj7BiLyofX4jrEjZ0vlyy4W585N1Gtz7NfGpONz43zUVd7u8Y85G3h7f8B3Sdmr FbHovzb2y7VZeZtx83cfsPfvSO3WxFmiuE3hxLenlYbMbv+QrC5OJB56zdZ+93dkHH5u3dMqW1al Voax+XmTXYnhduaz2Y7NnT1vsfFxahf7Muv5HvfidE7DSMu21PSi4R5shK6Z8aNy/SE/SCdGcbNY 2k2QUmVvXuFuX+MSyE2NDEZCGu2nfyHGkpW6WtXN0z9lzbG9WMSUSseV7mflGdIV2capPciUo2ak /2TmcSTqAE29oI2RQrXqE5B3zj8z3rk+9VkVGs0vaLj3maVXN78txT5l8zG5d84D6vCHsx/69WH3 DXC+lI/u7rlx406Dpc46Z8g4t0+rXQv6z1iRUi92gkAMM2rt6sGj4/X+9SlxA4J8qBWXOL5j7Ehr jQWm9z6l5u+m+HE+/PVv/CYMk80snOPML/+aCLwRwz9ft4tbPfxlVNJvpvqJKWzfh3ZJG5W3an/A e42H1f0ZIYA4M7dcmUfKJLPbP5Rih+/5JIjkXQKJ0T0Vw1SJcwMnaqMMw0kWgGOwK5lURqxFbpvb 2YArEn8H0hQbGVX3z9MZRiqGTUksrtO7UxNXAHkHz+2SfA/112RX4tv2zsV7xyP7fSok+YdG+U2w uv8K7qYoVmal/oUrr5a0RkIa7af+vhM/6UQ8ikjI0AsyiarL1DR/2TG92Ouhzu0168qSyrQuaLsk FG5QQSYctcF/Glx6rAP0e0FoBOdviIwuA7YLfejZygTeN/KxkT4nXFyOhsSl66j8dEp+/3blxo1o WLiIvk68WSmGXeclW/5MOI5cumlMtCTe8Xmk6nD4kjYfvh8sBC6e56zIJnumOcP9KX7Il3pun8EY G+8/E4WMFSkxd3yCmBm1u40uIke8KxLkQ6cKX84EoQIzqJwKILslgUfOPPf88zP/lk80tcAY8Y7o rxxxn4jLNlObsjyVTMwA+CXqk+yz4hLOuf/1p/+Bqmz+hZcjtfLbmIEAJKciv0y+P+rvgMq5xYom DJX9fb48qjqZ3lCRs2DTytTU8bOTZdIViUxhOckydZH4jq83jzfobtlgSclKAG5iGzEMJVukET2R o3bF7Se8/21lAx+SrzFf921S/I1uhSRgrf7veoO6nYUPqGfnpOB+91Hcgg9DxsD341WkCVVmq3Pw 5CMtXHvo97VCjCRotI4U+kOy6srQ1HuN63h9buLVu47jSsLuu+JATwyOLNXBklFSe0okZB1dYGSU 4pjGZTcl7QCJXhAawdn54S/88GzogmtGAM3MZpwDNFMo1J2FAG/KS+915gaiWfmr0YR96hauz6ni eod8f7jjxLROx7zRMNrp9GTaHIMYdrlsiz+gRlUhG78S78ZyKlF/pO5+7YKkoGX3/z1UJj97mD21 Y1p8/0JpIcXw/WroP2na5q5hJSc5Z6BmFz4iHbuUKbucpPDN9J/BGZRnIfYi2Q8T8T4tMCJoM0Bn pcYlox7aj+/UDCpLd3byDD3xmPobtVTMUW5ls7791c998MMfNYkvFuff/+OfzKMdiOehh7wgkImA Pn3JVAAygQAIgAAIgEA7ECB3UZuomFhWscChVxOFiam6KnK2Jj1IlYIAloohWPGLcy+sPQViJAUB EGg2gb1PnepRr8z5idRfE2227KgfBEAABEAABIoiELogWVSxmcqRX1cJfQgtU0ElZ6qKnCVjQPEg 0IoEcHLeiq0CmUAABEAABEAABEAABIwEDHfrQAwEQKDVCODkPNQiODlvNROFPCAAAiAAAiAAAiAA AjkIvG/klPpabSU+J5ZDUWQFARDYVgQQ1r6tmhvKggAIgAAIgAAIgAAIgAAIgAAItCIBEdZ++OO5 XgjXtd95BV8r6geZQAAEQAAEQAAEQAAEQAAEQAAEmkpg42b0w15NFahJlb/6Utzb2nFy3qRmQbUg AAIgAAIgAAIgAAIgAAIgAAIg4BLA4hy2AAIgAAIgAAIgAAIgAAIgAAIgAAJNJlBAWHuTNUD1IAAC IAACIAACIAAC7Uvg3tlHT9wU6g2dvz/Rr+m5NfPUoanu0MPmcSDlNArfPDlRMwiAQBMJJIe139Ol W57Y9dij4s/IzJZ6zh2fevLY4WvOo1TqbF4bEdknl4PO1LZMKjsjHzIWFd4s6dbVw75UXkZHqqC0 4UKo2v0SJnyeedGl4uwlLgE4rYihFaJSk9ntH5IYqOx8/HOsV7fV5rRCtraL5nIgK72cTuRr5D7h 5ud1WNk7ZMqlSdeeZXbfMmlQRYlcejmE4dEa5eyVYX8SaItdZ5dcRcvyUaWDdCsIOEPDw4rbTMNY WhqDwZbMzircRvb+k+wFDePRwIpsTTTqPw3zHKpAkxNooJ6tWJX1rMN6OI7C333q/isvz471Fqu/ N1zGFkuPsHQWUs4ShA+M7+4Emz90B3qJWjyXHuCpq5tSXDt9g5rZ9iwzwkgJ1OQkMA/XJtIpGrwq 7jcqZ6oRwVJNp7nD6y/JMzyg6PC9uQ3xMM0saNsMPSks1DqpCGs/4U7rRWtN99x4mXvA+6/MjNRU T35mbVQ+uXGc1Z9xV+y2FfAe+DQ7E/KnS5Nym1PUcn1w8VBMJzRkJ8qUphYW3izl8sTBWz1Dnpfv nxTCOH/qQ6xvp1Se+lEicSd4kl1Q2c97PHOis0UcTFcGcFIRsiJSZjK7/UP7Mpkc/0K2am9s2YCX mov7weF6d90zTnlcoGs0vn4yZsts74Sgwe35gDTOyd3u2HyCeWW+eMRo6qWqlrlw2vCIps/XK03+ hB/aOM1xaq/UoTQflZlQ2owhZ6iyRx5SnSttTW2fPoUxcBaELZlGxnBzkG6Ncqp0L2jPhrAzUdJ/ 0sOEqcBIw7UnT2ut7GcdlsOxWACkGKRqI5dfDp6lW4te8YRqZOcT6ehMwEHthBj09rFbd7IcrklA dj3LxJJsTXJywljvuFqA3Di+dkI7TrBrpqq4X+Pk2W5EsFfTPEuPDijeEobPGG9ekgexS5PEQ9EU VrOg7TT02NlnulRicT60urAsW+KFi2zsjFqTe7/OIzNqTs9qnT1sde1huvJ5D4zM/pcX53vHn5BR SVt3F1bY3G39UD1QPpWdkQ9J4U2ycptbGzszupP6962rl+b3HzOvWKjat9ZW9g8oSqx/wOWZE106 0G7qMoCTipCtQMpMZrd/aF9mMGV3l7DkFMaWDXiZuZan66sHLjiLQKciYZ9u92G1kdH9K4t3N1MI sXVnMVJmiuzNT2pheKrpc/VKe39Sko9qGGjSGcZ5SCGZIoxfmIC9MVDsjM4q0hx0Ssqp0r1gG7Sc wURp/2kzTMDmjVZjPeuw4Sxcd4pByjuSNcRmelGQ4kj5moyX9I6R5eHhcH2VzZ/MGhxKRmHYd6+c 2b2Kah8Z6F15TVt83zs7tn58Vgv+Hxx9fOGF6Exbnm0G0CUKn7YjpGlNX6Gj58Z656ad037n8D9J zqq4X4s5jAJB9xd7NU0VRcf3jp0ebVHpYL8Y4MmHpH3YL4sSzQsJHAJicT6v/r61sd472HE34Lx0 Tluba8xbguYAKMqR3Zt71YO3Bsf2s/XNzRzlWQmvly/d1jnD8ltOyp9UZ2JpfjcXVTS7GPsj+YpC l0YgP22BwHMqQma3f0iqH8zuxEpxu7oh17QF6p4Nfp5cnmoqAEkNog83VvSl0Y6uvpWNB/a1iO2w 3p4d9hkqkzLc9ELwzL3S7AxzTOMSHGxTSJPO0OAhKcJNEbpdKg3ZkslZRZsj0a0FvGJsL2gXlkqP ZBMl/aeZJ11gdifQXrhjtCGRJtqtKjDVIEWFi/NDYyfekweOMT+4bK6+cUyGNx5YuTjNJ2y1oy+q OHn3JDA2jmx16qBzTUys5x17oyuya2ZxVX5h4Lrp6NuuEJVK7ONr8Z7LEzzu4PLRTr2IHXsG1297 V7HSFG7Xs0wlpmpNrZDOju60QqZL34Lu11KkdHpGUlPjO9/YvT+6MSzmmbcH3Lhp8qEoztYBbqOh J2ebENnlybn3fHVqmp2TQZv17otPB26Y8yiIiz2hQ7w84ojXY/DY2pmRjjyl6HljhNeTUW7L+/ek Y3ODrP2TMghHLJ9Os0Gfp+M3C0aXDVgBwHPaAJnd/iGpdji7ipW6/8ro2sHgFeuCjS1bG2TN5c0h shawHfJFmj5nryT8iRir/HsTcfdxDMAtfVTDmot0hkYPSXeuhgnbXhUZbSnsqM0DltGl614xvhe0 F1MmouoI/2+pJcUzWmBuJ2ApTVskI020gKlIPBy+tcrm1Hxs12Nj2mGJG4ZW6+nLgNeNuPbvvRsr sipdrFq9IE0ZBKcffVsV4anJQ0GvezsLcydOzvV1RWbWvAqmwpW1n7zRGXi7Hl1xrp5lp0tsKls5 LatqQfdrLZKliqZk9IDiXz24wMbcFxiRD60d4PYaenK2CpFdLM7XWU+HClLsHX/W2Wzbu0/zFOLg Ttw9cOLbc0ohwuNvjk13zb4izjY3H6yz7s7OnGXGCB8sefPa9ByvXXptN5xJe/Xd6WzH5s4WrJgW XN6j8VQvXSgOXTZKhQDPqQiZ3f4hqXicSPxyAVt7sCXvYpRhbNlaImUuIfz6Rmgw5Ufl+kN+EEQM w+aKMl1OSSl3c5O7Tc+lkJsaWXulwRkq5Wp7BvukgaX7xZaZrqgCUpPO8NMXYzykqlQjXIAU274I z5YoZ8XIAYuZ3VrUK5p6QTuDN5so6T+ThwmqwIxOoJ25+7qRSJM5K++a5QalhpVf5fAX0tz/l/Ze lYZVZLQZ9855QEf+cHbg1rD7Bjg/8+59PfUrd3IZYHrnn7U1i1saxCrcgu43VqTOXM3HXyJGju/a 1YPdp+pDq1PiBgT5UKs+0QFux6EnX/PoueV3zo+PivvS/NYKk03Cf1sz0zedIBk+2Iszc21lLoZ/ vqAVt2X4y6jE5krUC8RJKLp338AeaWTyVu0+76sYGS7AqJoMwssq9Es1/q6PH87kvPqO3bsy5W9k egqkE4m/kmfK4SlX5iF0xTVcmpJyA0+nSIQYmd3+YaQRpYXGs/WuzcTongZhc9KK9xdMnfauXSlL 58tC5TqlbZ+4KbsSPwpw3hzhuFS/T4VE7x/lV7lO+G8ab45mJdbq35jyKknfK2P8iSxV+ArnXpa1 KkllWhdUVELSGX7quBsdEPWQTsUE4aJE2o7l+LZEOCvDgGVwa7Fe0e8FeUfw1m8ls4nS/jNxmKAK zOIEWh9dURKSSBM5q9pzDlJy3CTuV9OqifDpjDcr01UUrl6YovPmrcCUW43sqa+CB4rnfoNHvw6H L2lzsOsLi3rKtBWFOoJN9kytee8sPzwrYmmQZM+Nd79JEmmzC8v+kliinyBmBeQeNoh4EO+KBPnQ Kc7aAQYmYCmE3d5Jg985l5+LXJFEnC9Jak8UKP78ic3D4k7vGXZaXJg5x54ZXnx8NnS/xaXKr2zp YUXRYvu0aBy14lrRPmJJZk8sM/AZzEiZXoOLV2G/NuqG9Dj3f8KbrHYiybdqy2tIvvAUOovwoZz2 mAgnPfCabxWeDUz0Gypyls1aI5IcyDLpikSd4Vag2Woi8Y1zd89FfAvQseqA7jlBNyq7ztmVn4+I J+ekAL5GClHwYaiN+Ia6Cn6hymyUPrnrSfIJftPn65VRZyg+QuPeNvRrSZLH4E7Dn+rNzSVfAUFn 6JSlPzR0rny1tl1ue2MgbUl+uNTorKIDlhqsXSdAe0WiFwhfYTuCV6iJrE2U8p8UebJAQ8NViFPx oqaZddgOx9FBSiPvO1Xyod6P5AvAxWSAF7i4T42AQgZ+Kd0NBbURidsM/xiQ9w0jb+qodzqnojRy kqboSMjPiuoyvNT00zTyk4TU5GdFs5c7p33hZY3+6BP6T7oqc89S6ifISU45qMmJT8NrNVegtHL6 FkIaZzPdb3ACJgSVzWEvkv0oY5ylSzyBAUWbQPqrGOqh/SyImoAV73wqXGL8d86Di/MKqwnRQWBb EeBu99JO/5rZttIdyoIACIBAHgLwn3noIW/ZBMSyiok1W9kV5Sy/KnLmVBPZQaB4AvGLcxnWjh8I gEDFCOydON9TP6TeeTOhvhSAHwiAAAiAgAUB+E8LSEjSDALy4yyhD6E1Q46kOqsiZ5Ie+HcQaEUC ODlvxVaBTCAAAiAAAiAAAiAAAiAAAiAAAm1GACfnbdagUAcEQAAEQAAEQAAEQAAEQAAEQKDdCCCs vd1aFPqAAAiAAAiAAAiAAAiAAAiAAAhUjgAW55VrMggMAiAAAiAAAiAAAiAAAiAAAiDQbgSwOG+3 FoU+IAACIAACIAACIAACIAACIAAClSOAxXnlmgwCgwAIgAAIgAAIgAAIgAAIgAAItBsBLM7brUWh DwiAAAiAAAiAAAhsTwL3zqqPjD46uZwPwNbMU3ZfKuU15q0rn6S5cutq8r+PzGzlKg6ZQQAE8hIg Fufy64VBR7M8oTzdriyddvPaSMRLCl+gvOfhawlugMrOyIeMpZEzoKaX0ZEq3s9StfslaB+dTqFm 3obU8pcAnFbE0ApRVcjs9g9JNlR2b0gO2FVzWqGoBnUgB6YavkauoXLz8/umyCInCkuTrj2HPodO gypK5GaUY9v0qXp62J8E2mLX2SVX0bJ8VMNAEj6fsdDD9rOZcvBaGoPBlszOKtxG9v6THJvKUb4V SiWNuRUEgwzWBAIjV4ZF7+5T9195eXas17rCfAm5yZ1g9Yl+pxTNVfIprjYhzFeLdW5vAmCdQ09Y Gxntnjroj26pCiEbjj90IUivJRpUOqWnrm7K0rMLnKezR0Y0ar4UmDBka8qqjAhROVMNUpZqOs1N bpyFW1OH7xkk8TDNxKw6o2Fkcb48cfBWz5Dm1ASv6Z4bL3Nnd/+VmZFaqq4qlgdPszMhL7k0eWiq +7ws8Prg4qEYizdkJ8qUU0l7OUNq9k8KYZw/9SHWt9OoJyUS9zgn2QWV/Tw74SyTNq89szYqH944 zurPNGYzsgzgpCJkRaRxkNntH9qXyeSQHAJub2zpLLshqbnTGa531z3jlMO/rtH4+smY7a29E4IG t+cD0jgnd7sDIZ9JuGW+eCRll26I4qkrsW16655u8idDynHxP6f2SilL81GpGWTNEPH5oqDIQ4pw 1hrbNl8KY+AMCFsyjYzh5iDdGuVU6bGpbRsgarftq2p7a6bGLD5FjB/jWgDC1szpiz0XnOHAkcfv 2s6w2wJyWouw+1R96OalpGMzU3ExDed4LWcXo7eP3bqT64ieHLms1BTLucgsiJwvMdY7rpY/N46v nUi91VKVEcE4n7cbpOzVNC8comOct6rik1jHIJcmiYeiya0mZpUaDUOLc6752tiZ0Z2+fS+9cJGN nUm7Jvfyc3OPzP6XF+d7x5+Qu4xbdxdW2NxtY+gRlZ2RD1PJGVXTV3jr6qX5/cfMKxaq9q21lf0D cuXDWP/A0OrCsnA5nUdm1HKI1Tp72OraQyuvkTNRGcBJRchWIIUns9s/tC8zmLK7S6w6UxhbTvIl ZF+erq8eCI36wj7d7sP4Jvf+lcW7mynq3rqzGCkzRfZKJLVr+tiebu9PSvJRDQNNOsM4DykkU4Tx CxOwNwaKndFZRZqDTkk5VXpsateWS7LbdtW7jfWqfWSgd+U1uYbTT6TVcbrYQg2GjLmHsRSRaMQZ VaYs1w3tPDS1ksT23pUpdnzUmf4ZE4vT42syKFU7MQ4p5RxTiQj5q15sqXhoUJMoU549DtdX2fzJ YGgqpbtZzb1P8POkK15oWBIC8t+1hlP/fu/s2PrxWS++gLHB0ccXXohO/uXZpkW4RI7OnmkWVDt6 bqx3bto57XcO/5PkrMqIYD2fp4ceezVNFUVbs2OnR1tUOtgv5hzkQ9L+7Fdqmcy7/EyBxbnsPOcC 69KtjfXewY67hE/JLNvW5pqa23EfdPDW4Nh+tr65mbk0J2MaOQk1/erlpPxJdSaW5ndzkftQOVpc mo/kEyp7q/c0pRaStkDgORUhs9s/JGkEszuBSdyubsid7AJ1L6QtUhXiqaaifdSI9XBjRV8a7ejq W9l4YF+s2A7r7dlhn6EyKdM2fWxPN/uT8KTHnk8aH2Vfas6UpDM0eMgw4ZxVI3vIlkzOKtociW4t 4BVjx6Z2aoXYkb2dFN1OuogdaieS0QvekcfpYtVaO3rMPQvhg73Ydx492knT4avTQwsD18On8dEy Q7FpfQmwl27f7BvYE67U7dr6VdC5+sYxGVx5YOXitJou8jmwdn7rnOXw5/O32LPytPbCfnF2ZVbT LfP6OLv4ND/rrh19UcXzuweJ6myMH1k7UZw8ko450XaBELyQmrU9g32u38hobVrDiRKWJ7iml4Ot s2PP4PrtjFsAeTp71llQZ0d3RhiW2VpwRLAUyVJBUzKqNfle8/3RjWEx9b094EZtkw9FqbYTs+qM htrinOo8QunVqWl2TkZy1rtl/y/k53ilmZGOQoqzl9OkphQj6djcIGv/pIx4Ecun02xwKJSKR2tE op6KUtq+nAKA51SEzG7/kFQ1nF0FJt1/ZXTtoBaAVIDu9qBLSOmNuCWU3TZFpmv65J5O+D0xMPj3 JuLu4xioluNLszch6QyNHpImnL32bZ3TaEthZ2UesIxuTfeK8WNTOzVB7MjeTopuD13m1IRqF4/l vO5GX3r3Rf0D7b373NgxvuKKOcEW6zEvIlJGnKnTeP9FRV6Z2tmgHeqejkgckR9k618FdYPgaj3u Slgs7MmjoKFRJ1iV7x3Io2aTml6ZfnwBITPfF2Yuz8fGnNOjeDVrXd1s7UGW2T7VcLz2k3N9XZHJ Pm8IFomfl1fPtAN2qhFaobPbyGlnQDJVC44I1iKlUNO+Nf2rBxfYmBsgQz60nphVajT0Fueb16bn 2M0xeUDnRsWoeKHe8Wed7S7hIByPlqMxRIz3zbHprll5aXPzwTrr7uzMUZ6b1UpOs5q8GHF3KNOx udjB5RuWYuJ+eQ9bZ76zFmee4o6EvydagKYpiygEeE5FyOz2D0mN40Tilwvk0FKI7il5F5ZcCL++ ERof+VG5/pAfpBNjnlmEBt6wKIxDuoJsmt6mp8f6E3GwkGHuYuWj0qmbIzXpDD990TQQeDW5hHNU jaw+Ac+WKGfFyHGZmcfQqFc0jU3t1QaxI3t7qbo9tHGvLvv3ImXgq3v07Z307n5yXF5d5pFQPcZj cyMyuswWJJxLTX63xb04Laeppb5oJtpwHCd/ODtwazh66WD3vp76lTspgeft7FlnQcWtVmIVbsER IVaknMs3Q2tqVw/ESxBWp8QNCPKhBjNxYlah0dBbnPt7D35UDN/z4/dGmIQi167TN0V8kXMBRlxi 4S+jEjsZcfd8olYo5nZuIJC8VbvPfcul2sVMusVB2TUlp5MuUKZBTZmU3x3y91a9StKJxF/J419A 4qDEmXlTV+ZCj9zA0ykSIUZmt38oVLAr07cM745KjO4pB4QmJBfvL5g67d1xkhII76P8lMRyQsXU 8c14500Hjv/y+1RI7v5Rfm/qRMZ3sTaBQeoqLZqe7ul6TTH+xPMVziUoawGTyrQuqKiEpDP81HE3 OiAwEOh1+hfAipJkW5cjrFHZEuGsDAOWwa3FOmp/bMo7grdic8WN7K0oL2RKS0Ac/zo/0WW87OLt 4gvLVxfnY28Oyjht95DWncoyskx/MBVdJvHOOcuwS+sIzy/Qrthe7Y5XMzCRFtHXgbuiciIRvt0d r6YgE4wISDcTjrYu76E89nY4PL3nE5L1hcXA+JK4Cojt7DZyZpoF3TvLjy2LWK0kWX7jR4QkieTi yDhIJeaOTxDTmm7shrBG7y3d5EPNM1hNzAIrtZwKlJRdLM5j18OdR87w6z0yvki8SDbtlpu6pui/ oEL2zL0T4iXtXsySf6osbsoFfmR28qFRzkiZBpLSX0dDjOxE8l7lP/za6H3nXo04neOO3YsmyrTp kLrZSwBOK0JWJMQNEyOz2z+UBKzK1L8cxt/b74STGY0tNdomZOCBxGI8c+NZpHuqjVw+f8C5YOOF /NVGnuVvcFF9StysU31KtREPY1NGqN43I8bIISdGxuZbhk1QO32V2kdQEpve0NODlZL+xP9ix4n1 cdfACvBR6fVtfA6ScOPFaPEa7Y2BtCV7Z0WlpB01NTa1OEWIBwJRAjIWXY1x013j+uVBcfp6cW5o n/eqIGXzwWmnGDd7tCFSTmXJMv3BlE/n+LdO4n9+wLmezr9zHvd+bz4Wz46tq3jV5I+uRdTkFeox 5P5EWhyzO9MG9TEX7i7cabz3ReRYNeUtAPclx0oxGY0/n/WKuCzCESN4mNd5ZLRnZbU4i7eSk5wF kfMlcbH3oGwgMeinPmmryohAymk/SNmraVw4hC0gMKd1157kQ/fT2k4bOTP/eI20lVpxpldsSY+c ee75wx//ZLGFojQQAIGSCXDXc2mndxmv5MpQPAiAAAiAAAi0IgF+WOrvyTZcQPGqOf66tfKvLobV 5HOAxX2l1EvOLvjDMXY+6TZ4w/FHKqyKnM0nBQmaS+DVlz73wQ9/1CRD5DvnzRUWtYMACFgR2Dvh nQOk/vamVQVIBAIgAAIgAAKtTYDfG5/z3qDWBFHFad5a+TfFGqcmf3V26HPC8nsxoQ+hNYF0YpVV kTNRESQAAZycwwZAAARAAARAAARAAASqREB8sOAm6zs+G/pGV+N14JLc3lfWqbJBzXJOzvn5PP9y lfwSLX4gAALlEYg/OcfivDzyKBkEQAAEQAAEQAAEQAAEQAAEQAAEHAIIa4cpgAAIgAAIgAAIgAAI gAAIgAAIgEBLExAn5z/yP+OFcC3dSBAOBEAABEAABEAABEAABEAABECg6gT+8It4IVzV2xDygwAI gAAIgAAIgAAIgAAIgAAItDUBvK29rZsXyoEACIAACIAACIAACIAACIAACFSBABbnVWglyAgCIAAC IAACIAACIJBE4D/+80d/7G+LP/WXk5LG//vDmRN/e+I/WpTBa8xbl0UtZSXR1eR//8TMV8qqCeWC AAhYERCL8x/zu+LmL32C8mgvTyhPp6W0Kl0mosoUvkB5z8O/9DC+KPvsBuGjxZO12z8k5aWyeyNE QM0UuttD1lPaEyPLJzEWYBhfuX7YHyw9i3LMIH5go2r3S9DGztLZZmuRPLkc3QNTDV9NlxunEezF cqKwVHfxyuw+KNoy84jZ0LyEPdAa5TaSgNG6OoYeVhwmY2H3HjC5H/vnS67eZXmGhtoOKmtjAm3o /9u4tWJUC4xcGRa9P/RT93/5V2ef+kCD6PER4Syrjz3mVKeNCIFht0HSyCl3BmiOeDtGDndNfcJ3 +6mkJhuOP3TnHrKHCtnkoHPi+qa3RkgtMDp7qpZB4qoREIvzX/7MyHuF3LwLPc1+JuzRxEz0Ss9n fpU7u/tuSnstyTKX6iNTHZOywJnB5ZGYjUky++Yv/ezaYSnPZz7GLv+s2uSjhacEJbPbPzQsaAmR mBwhInLa6m4PWU9ZBvAiDOPliU/c7nncGywfm1Rk5J/646xvx/tN+lK1c788wU6p7JPsrLMuJRsx G8YWycVH2eHLXXWPlRz+9e4z/mAiZntr75iD94BkNflDQi0xcvOZhFvmi39vR4soaykGbY1EX8tv JCGjVQJGHlLd3FKX5iczuffHlX/mf35KffDW4FiKHzKazwQSVJNA+/n/arZDMVKrMYtPEePHuGIq y1XKw5kLn+055fhJpyTffzrDbq4aGpz5h36q/vivXEo6NjMJFdNwztTF2cX4QB+7fSfrET06e4ON AtU1moAe1s6n8tGZ+tIvfJY99TNq9Z7hR5X58uKtD4z/fbnL+JWXFr7E5l42hh6RInX+vc+oZQZ7 b62HfWntd8RfyZSkwGR2+4f2ZQZTdnUJhil0z0DbwCFFpSTG/IaxVJ9Ye+pnRsll4FeuX7r1o8fM S0Sq9i+vfelHB5QNsMcGHv/Swv8h4i/IRsyGsTVyvTx9+UsHQqO+wOV2H8Y3uX90ZfmlzRTiPryz HCkzRfbmJ7Xo6aqv5TUS0mjjLFmwUVVX5mfv3kvyDJUhBUFbnkDb+f+WJ94IAXd8pP8DKw+/LKrS T6TVQavYWwyGjLmHsZRo0YgzqkyR00s5MvWlJCX/47Up9rFRZzZiTCxOj39JBg9qJ8YhpZxjKhEh f92LLRUPDWoSZcqoruHLX2K3JoKhqZTuZjX3/n1+7nXNi5lKQkD+u9Zw6t//4z8fe/CxWS++gLHB w/sWfiE6+ZeH6kkH6ejsmRoFmapDQCzOY93ZxoMPDL7/JcKnZNbxK1tragrLfdAnbg8+9aPswdZm ttJEUd4iLX0RZHb7h2SFwexOkA9X8zNyY7VA3e3VLaXShykMQzrlc4blt1weHFGnc2l+v7KoboKJ xWokX07DSCNHiWk9LVQctRqxfmdzRV8Bvq+z70ubD+yFENthH+h5n32GyqQM9zUheA4jIY3WYMlU 1ZXgZu7F4bmdvTppPIN9qUgJAvYE2sP/2+vbzinFDrUTWOfFKMnjdLFqfe+hY+7WPF9Ri33nw4c6 aRp8dTqy0D8TPo2PlhmKTUsKjV96+Vf6+j8crtT1n/pV0LnLm8dkrN+BL312Ws1e+BxYi2Jzzpz4 81u32QkZOHDqR8XZlVlNt8yZcfbZp/lZ93sPvaji+d2je3Xexo+snWhTHqjInGi7QAheSM33fnjw A+7omdG6tIYTJbw8wTW9EGyd93148MHdfFsAalKdYxWQUTtkA4GSCYjFeYfs1cbfl6ZeZOdU+HFC yjSyOl7pMyPGcObE0nh8aSSaKDGTn4DMbv+QrCmcXcUV3//lJ9c+EbzxKzxyHt1T6OkkLQB4qFJL w6CcsldS0rG5Qc/HJj/zsbWzcr16gQ0+HkqV0zDSsy07hzfill1RlcuP9LU8RkIardGS6W5eDZhE L+aHEtp9nLhrRwYVLT1DNQBByqoRaDv/X7UGKETeOTW+/xiPuZtxIzq9t2P4B9p7H3Njx/i+c8wJ ttiV9gL0ZMSZOo3337jhlalFGtpp0vP+SEygH9buXBrlJblBcO/vcVfCYmFPnkw8/qQTrMr3DuRR s0lNt8zIMXVAcr5hylyef3vMOcyIV3NHVwdb+3LCC6FIPFTD8don5j7Q2RHOwBuCReLn5Z1H7YA9 thHQ2e1sFKkqR0Aszrl3c/wUKf4Hxk84213CQcSltNNexKL/ytiLnbPyNuPmlzdYR63TLqufSpwl ilvH/l5jqhLI7PYPybriROKh19LTFaJ7Kk154rIqtTKMzV+6MsebWx78utFWXhyauKyV6dhcbJnz HWKxhLjwYfaA+aNjTsNIy7bU9KLhNjZCl7L4Ubn+kB+kE2OeWSztJkipsjevcLevCcvPaCSk0X76 SowlK3W1qpunf8qaY3uxOD/JMEWz8gwp5URyELAg0E7+30LdNk7iXl3271rKK0Xu0bd30vtDR8bl 1WUegtdjPDY3cqLLbEGsudTkN7w+MO68N0rMmkp90Uy04ThO/nC2//ZwNEr3h/b0XL52JxtwdPZs 3JCrEgTE4vzFXzG/jotvyLEp51rIwxmV0rkAIy6x8JdRifdLxQXGRzGIKawbCCRv1T7mvuVS7WIm 3TYRAogzc8uVeaRMMrv9Q6GQXZm+6mKTcvBv8e3VGN3Ls5fcwAnRKMNwkgXg+KdwfrSVu5fML2v5 m9leHXY24Cbn7wXxb3ylM4zygBdVsrhOP3XBeaOpU6hYL33J7ZL8LFfF1PHNeOfivRPd5/epkDCP jT71gbmzGd/FWpRiZZbj9TW/krRGQhrtp550z5OjluxavtvNy9SvyLJjerGsRvRQ5bjsf0ll2peE lCCQikC7+f9Uyrd9YnH86/yEX/L0FW8XX/g/ri/eio1tlnHa7iGtO5VlZJn+YCoGjsQ75yzD9qUj fMeOD6zYXu2OVzMwke58f1fwrqicSIRvd8erKcgEIwLSTcyi5shHVR57Oxye3vMJycbCsp7criJ0 9rbv8dtcwUfOPPf8b/V80nkLtBfxIqnwyBzxXNzVcTyUeiJ6Bb9E/TPsgrjDc4797PDyvtnQZRIX K7+N6UbR0GX2+TFL8r0Xn/jsilOvSE9lf78vj6pFpjdUFC1TU8fPTpZJVyQyheUky9RF4tuWXnST nzige0GGWAJwE9uIYSgVIo3oaSbePf7wSTdgybkDFt7EtbKBx+RrzOWw6VsL3QoFcW1aMXqDugbD R6+JOSmRb0KKW/BhyBj47rWKNKHKbJqCaSsmLVx76Pe1QowkaLSOsPpDsuq0SjUvPdGLfW7Mh5mE nXbvWvdsnoqoeVsQaE//vy2aLqIk9zaLj0VOX8TVvF8RaT/wsfGOz675CeSAqM0bNQ+m+yVq3CTL 9AbTxyf5DW1CEl1gXgKPA9UnwF6ZMpkadjWNhKHyG+Dex1OcmYybUlxEf3kPFdcdVtM8jkcnmXrv cL16jJrin/gNef0V9KqEH60HHoZbjmy4kO78NGX2Qm1afARKzYpDeoXVpLoAOvv2dAztpfUffvFz H/zwR006icX5j/zPn2wvlaENCLQ9AT7gXdrhXcZre3WhIAiAAAiAAAhECfDlnLfSazyfwGK7zOrD atJbGEVIQM4uxF4AUyd2+IEACOQmEL841z+llrsqFAACINAgAnvHJnsuj6jPpTifYGlQzagGBEAA BEAABFqCAL83Pue9Qa0JEu0YOcFfT1v6TbHGqck/ShL6uq38XkzoQ2hNII0qQWD7EMDJ+fZpa2gK AiAAAiAAAiAAAu1AQAWQf4CHSZu+oNYoLY2x6EUIYFCznJNzfj5/dyA2dr0IlVAGCGx7Aghr3/Ym AAAgAAIgAAIgAAIgAAIgAAIgAALNJoCw9ma3AOoHARAAARAAARAAARAAARAAARAAgVgCIqz98Mfx QjiYCQiAAAiAAAiAAAiAAAiAAAiAAAiUSODVl+Le1o4XwpWIHkWDAAiAAAiAAAiAAAiAAAiAAAiA gA0BLM5tKCENCIAACIAACIAACIAACIAACIAACJRIAIvzEuGiaBAAARAAARAAARAAgYYRuHf20V2P iT+Ty/nq3Jp56rGJexZl8Brz1mVRS1lJdDX530dmtsqqCeWCAAhYERCL811uV/Q82q7HDl/zeufy hHJz4s/ZJatSA4k2r41EvKTwBapMrSK6aCo7Ix8y5olq4Vy2rh72fbeuY7JPp2r3S9BceQo103M1 5igBOK2IoRWigpHZ7R+SmlLZaQNuTisU1aAO5MBUw9fInRBw8/NtXmSRE4WlSa/nir/4lkmDKkrk FinH1Knt7SHsTwJtoTnDsnxUw0AGnKFba+jhtrCZAohbGoPBlszGGW4je/9Jjk0FaNpqRZi6Z6vJ CXkSCQRGrgyL3t2n7r/y8uxYb2JFxSTgffMEq0/0O6VprjIw7BZTWXIp3gQgOSmRojYy2j11MMtU PzzlcBuOt6Y795BeSzyXTumpq5tSgAwCF9DZIyMaNV8KzCKstmkiSKsyIkTlTDVIWarpNDe5cRYe 48i1J/EwzcSsOqOhWJy/MjNSkwYlPZr4c+M4qz+jNs+WJk+yC/LhKy/Xh25e8hftVh2fm/vT7EzI Sy5NHprqPi/LvD64eCjG4g3ZiTKZaNfpnhtKVFcjo4zLEwdv9Qx5vrt/UinuqMn6dioixI8SiXsc j9J5dsJZJm1ee2ZtNMzTilqORGUAJxUhKyIFJ7PbP7Qv02DAtsaWg3pZWbnTGa531z3jlMO/3n3G 10/GbG/tnVDdlh2QXXhytzsQ8pmEW+aLR4ymXpZWDSqX7tS2vdLkT4aU4+J/Tu2VipTmoxqEScyT As5Q1Rt5SI0ODROxKhWlMAauEmFLJmcVbg5yDKVsmx6bqsIztZwRpKlLQIbWIKDGLD5FjB/jWkDY rZnTF3suOMOBI49vh86w2wJyWouw+1SGqb5XekzDOV7L2cXo7WO37uQ5os/R2cVyLjILIudLjPWO q2XFjeNrJ+zCKDTSVRkRjPN5u0HKXk3zwiE6xhFrT+OC1GpiVqnR0BzW3t0lJ+0dO3vnptX+1vLi fO9gf7qpPDf3yOxflDP+hNxl3Lq7sMLmbhtDj6jsjHy49MJFNnbG2WVI8kK8gdfGzozupNJtXb00 v/+YecVC1b61trJ/QK58GOsfGFpdWBYup/PIjFoOsVpnD1tde5gkVhH/XgZwUhGyFUgNyOz2D+3L DKZUBpzC2IrAX2wZy9P11QOhUV/Yp9t9GN/k3r+yeFd2T8vf1p3FSJmWWaubTOvUlr3S3p+U5KMa Bpt0hnEeUkjmjA4NE7IqFdkbA6WR0VlFmoNOSdk2PTZVhSfk3PYEah8Z6F15Ta7h9BNpdSortlCD IWPuYSzFLRpxRpUpy3VDOw9NrSS1wL0rU+z4qDP9MyYWp8fXZLSmdmIcUso5phIR8le92FLx0KAm UaY8exyur7L5k8HQVEp3s5p7n+Dnc1cyxMlq+msNp57eOzu2fnzWiy9gbHD08YUXopN/ebaZIVwi qaG0f880C6odPTfmrYZ4YVZyVmVEsJ7P00OPvZqmiqJTDnLtab8gtV+ppTCcRiYVi3PNnTlxHQdv Dd5wNgL5eH9/dGNY+JTbA8kn0hayb22uqbkd90G8orH9bH1z0yJfbJKtjfXewY67hO+LZpM+4pxh +S0n5U+qM7E0v5uL6mKSWAZE8gmVvdV7mlILSVsg8JyKkNntH5I0gtnDBlyg7oW0RapCPNVUtI8a sR5urOhLox1dfSsbD+yLFdthvT077DO0Q0q6U8cZs9mfhCc99nzS+Cj7UnOmJJ2hwUNGR4eclW/3 7CFbMjmraHMkurWAbceOTW3WBtm7Z5uBaBt1xA61E8noBe/I43Sxaq0dPeaehfC5l9h3Hj3aSavO V6eHFgauh0/jo2WGYtP6Ekgu3b7ZN7AnXKlrh49qewdz9Y1jIhbg/IGVi9NqusjnwNr5rXOWw5/P 32LPytPaC/vF2ZVZTbfM6+Ps4tM8rLV29EUVz+8eJKqzMX5k7URx8kg65kTbBULwQmrW9gz2uX4j oylpDSdKWJ7gml4Ots6OPYPrt7NvAWTu7FlnQZ0d3RlhWGZrwRHBUiRLBU3JqCkHufY0LkhtjaE6 o6FYnHfLXi1/Kq7j/iujawed+A0//OMCG9McTc62cL3SzEhH3pLc/KtT0+ycikvXNIqUTvkIL1HS sblB1v5JGfEilk+n2eBQKBWP1ohEPRWltH05zjCQB3hORcjs9g9JVcPZowasDYF5dLcHXUJKb8Qt oez2L5Lu1InGTPgTMTD4F3/i7uMYqFr6qIa1CekMjR6S7lwNE7a9KjLaUthRmwcso0vXbTt+bGor prm7Z1vRqLoyc2pCtYsHOV53oy+9+6L+gfbefW7sGF9xxZxgi/WYFxEpI87Uabz/oiKvTO1s0A5i T0ckntQPsvWvWLpBcLUedyUsFvbkUdDQqH/VVB41m9T0yvTjCwiZ+b4wc3k+NuacHsWrWevqZmsP sgSdUw3Haz8519cVmezzhmCRq7LyPpp2wE42Qgt0dis57SxIpGrBEcFaJHstDdP46MaNehOB2rrS 1p7kQ2tjqNRoKBbn3Ls5fsoDx2OzVc/Uwj/ERZTVKSIKJWXDiBjvm2PTXbPy0ubmg3XW3dmZsgwq ee/4s862nHBkYY2cHJvXpud47fIc0g3+8cKixN2hTMfmYgeXb1iKifvlPWyd+c5anHmKixP+nmgB mqYsohDgORUhs9s/JDWOE8k14EJ0T8m7sORC+PWN0PjIj8r1h/wgnRjzzCI08IZFYRxyFUR1aitj jvUn4mAhw9zFykflUjdNZtIZfvpijIdUpXujQ5rKkNZEwLMlylkxcsBi5jE0atumsamNWyRj92xj ItVTzb267N+LlIGv7tG3d9K7+8lxeXWZh0f1GI/NjerTZbYgrVxq8rst7sVpOU0t9UUz0YbjOPnD 2YFbw9FLB7v39dSv3MkDPENnzzoLKm61EqtwC44IsSLlXL4ZFmXk2jNpQZpoDBUaDcXifPpm5P1n gevl7v6Z2H4TKZ0LMOISC38ZldjJiLvnE7VCMbdzA4Hkrdp97lsu7W5xUHbN77cwd+NgayagUeBm iL/F4gf/uFub/O6Qv7fqVWJ1scRLzV/J419A4qDEmXlTV+buZDoX8HSKRIiR2e0fChXsyvQtwzPg GGPLMyA0Jq94f8HUaeeNpk6Vwvt4e2T8VE3F1PHNeOdNB86Gmt+nQqL2j/J7Uycyvou1MWoXWUu0 U1sZc4w/kdKJYtO+gCOpzCLVtiqLdIafOu5GB0Q9pFNqlpePWAm0PRP5tkQ4K8OAZXBrsbbtj015 R/CWb6cs3bPlldruAor5p/MT7evhEG8XX1i+ujgfe3NQxmm7h7TeFJEs0x9MRZdJvHPOMuzSOsLz C7Qrtle749UMTKRF9HXgrqicSITP1eLVFGSCEQHpZsJRa+WujMe0Docvk/MJyfrCop48ZUXhzm6T PdMs6N5Zfp5XxGolqSc3fkRIkkib8BQ/o45ZlIXXnlJO8qHmGawmZoGVWqL6TUnwyJnnnl/7Hz7p vAXai3jh22zuklWO946D4rE6PKV4wi+ln2GnxR2ec+yZ4cXHZ0OXSVxl+DVFN4pGPlIliBdROEFE fX7MknzvBa/LSSOSk9kTy3RrkTVGyvQ4i1dhvzbqxs84V5LCe4p2Ism3aq9qCoqKPR2dGjW9ymvr RDjpgddIRQwVRYGTHMgy6YqoRqTZaiJpBmwytvLaoNCSdc5u2/Hh5+ScrMVvTa2feg9DbcR3r1UE B1VmoUK3SmHRTm3fK7WUbs/1u7l4g6vjIQvwUS2AK+gMHYH0h4bO1QKit5II9sZA2pJxZJQ6Rgcs tXJw+ztt28TYlGYEbyW6CbIYkFZIA4jqEOD9aHFf5FRD3OO4KS3++Hj3xTU/gRwQtfmVZgmyQOef qHGTLNMbTIfO8xvahCR6Q/ESeByoPgH2ypTJ1LCraST6Kb8B7n08xZk6uinFlc/b+6i47rCa5nE8 OsHWnYM7eMWoKf6J35DXX0GvSthfDzwMWyzZcCHd+fHV7OXOafFxJTWGhvQKq0n2CnNnt5KTnAVR 8yXfZuRr2/XvQFnJWY0RwbDUsh+k7NU0LhyiY1x07cnTUA/tJ2bUSq15XvfVlz73wQ9/1FS/WJwf /vgnmyceagYBEMhAgPu4Szu9y3gZCkAWEAABEAABEKg6Ab5M8lZ6jdclsNgus/qwmvQWRhESkLML saxi6nStpX9VkbOlIUK4BhCIX5ybP6XWANFQBQiAQEYCeyfO99QPqc+lOJ9gyVgSsoEACIAACIBA JQnwe+Nz3hvUmqBBbeRZ/j7g0m+KNU5N/urs0OeE5fdiQh9CawLpxCqrImeiIkgAAjg5hw2AAAiA AAiAAAiAAAhUiYAKIO/jYdKmL6g1ShtjLHoRAhjULOfknJ/P868m6wHtRaiAMkAABEIEENYOkwAB EAABEAABEAABEAABEAABEACBJhNAWHuTGwDVgwAIgAAIgAAIgAAIgAAIgAAIgEA8Adw5h4WAAAiA AAiAAAiAAAiAAAiAAAiAQJMJYHHe5AZA9SAAAiAAAiAAAiAAAiAAAiAAAiCAxTlsAARAAARAAARA AARAAARAAARAAASaTACL8yY3AKoHARAAARAAARAAARAohAB/vbn8yOijk8v5yuPfMLf7UimvMW9d +STNlVtXk/99ZGYrV3HIDAIgkJeAWJxf8zqi6KLKqR1OeJii3s1rIxEvSVZEl2mfnUpJlmmvpr2c VEpvhCiUZyJ6e2JkUSRGA1v+1Q1lMBbeXH6C0h3AvIyOvcUPbFTtfgnaV77t2yuRYqskcHQPTDV8 NTWefhOILHKiwD+14sxRQp9Dpy2zVVQuSA6TjaUxkoDRunKFHlYeZrgXB0xul//93rI8Q0HtjWK2 O4HK98Tt3oCe/oGRK8Oid/ep+6+8PDvW2yCgfEQ4weoT/U51mh3y8VebnzRIHG8CkKm+2sho99TB jJ9tJxuOP3QhyMFXNKgcdJ66uilFzCIwOnum1kWmyhAQi/P6M2qfbGny0FT3ee7U7r9yfXDxkOpO 5EN79Xi3fJqdCXlJ+zLJ7JvXnlkb5UK+fP/GcU14oiLD4pPITpZJPrQvk8kRIiInAdmeZ2LKMoCT ZTKxRJnuuSEVfGVmpBYv2vLEwVs9Q95g2T+pyMg/9SHWt9OYn6qdu/iT7ILKfp6dcNal9u2ViLFF EvBBa7jeXfdYyeFf7z7j6ye1fbSw1HsnHLwHJKvJ3e5AyGcSbpkvHklouRZBkV4M2sbSGEnIaJUI kYdUN08vbZNymHrxkBoI+B/ng7cGx0J53XSeoUmKo9r2I1Dpnth+zZFPIzVm8blo/BiXr5JCcm/N nL7YcyH4YXDffzrDbiE1NaiQ3afqQzcv+edz6aqNaThn6uLsYvT2sVt3Mh/Ro7OnaxakrhoBGdbe 3SXm58uL873jT8jNv627Cyts7rbY36IeplCSLw8is/8UZVLZWeeRGbXMYLXOHra69lD8lUxJCkpm t39oX2YwZQzkFDwTk5YBnGS79MJFNnYmaU3uyLs0eXJt7MzoTkr8rauX5vcfMy8Rqdq31lb2Dygb YP0DQ6sLy8LHk42YSKyFEyxP11cPhEZ9gcvtp4xvcu9fWby7mUKHrTuLkTJTZK9mUs3G7I2ENNo4 S/Z9aWUo2fdi0gnk9wyVIQVBK0ZADbj4VZ1A7SMDvSuvyTWcfiKtjtPFPmAwZMw9jCWnGl5kqB+p Fy1TluumPDS1kgTw3pUpdnzUmY0YE4vT42syeFA7MQ4p5Rwviwj5q56o4qFBTaJMGdU1XF9l8yeD MbDRaLs4Nfc+wc+9riwlqR7771rDqXT3zo6tH5/14gsYGxx9fOGF6L0DeaieLlwCnT1XUyFzKxIQ i/Mbcs9va3NNrdK5azh4a3BsP1vf3CQf5tSjwDJFUd4iLb1YZHb7h2SFwexOkA/nGQM5veDpchQI 3K94a2O9d7DjLjHYRIWTTvmcYfktlwdPCgtM97u5KCM7+Lh1aT6SM6dhpJOktNSeFiqOWo1YDzdW nN00We+Orr6VjQf2Ioh9t96eHfYZ2iElbWPxRkIarcGSw928MszMvTg8t7NXKY1nsC8VKUHAgkBl e6KFbts0idihdgLrvMNSeZwuVq21o8fcrXk+FRD7zqNHO2lQfHV6aGHgevg0PlpmKDatL4H70u2b fQN7wpW6/lO/8TdX3zgmY/0OrFycVrMXPtnWoticMyf+fP4We1YGDlzYLw7JzGq6ZV4fZxef5mfd taMvqnh+9+henY3xI2sn2pQHKjIn2i4QghdSs7ZnsM+dYmU0PK3hRAnLE1zTy8HW2bFncP125i0A dPaMLYNslSAgFucHtVsxjrOYGenQxCcf5lSvgDJ5fGkkmiiFVGR2+4dkTeHsKq74/iuja4mQU0ie KWkBwEP1rk5Ns3MqLr1bDgz0j3LKXsqkY3NDmf2TN46vnZDr1dNscCiUKqdhZMJbaiZvxC21lnYt nLaxeCMhjdZoyXQ3rwZPohfz4ALtPo5zvymNNpaeIU2RSAsCFgSq3BMt1NtOSebU+L6Lx9xdd6Mv vbdj+Afae/e5sWN83znmBFvsSnsBejLiTJ3Gq8vP4o9XphbaaQe8pyMSpOGHtfs3/twguFqPuxIW C3vyZGJo1IlJ5HsH8qjZpKZXph9fQMjMN0yZy/OxMecwI17NWlc3W3uQJeicajhe+8m5vi59VSHF 5A3BIvHz8j6adsBuagR0djvzRKpqEhCL8yHZCUWI+M2x6a5Zeclw88E66+7sJB/m1LSQMsVZorh1 7O81ppKKzG7/kKwrTiQeem2GnEryDIkLAU7U2zv+rLMPKkYOZ6gLp9u8Nj3H7UqOf260lReHJi5r ZTo2F1vmfIdYLCEu72HrzB8dcxpGBrzlZRENt74RGh/5Ubn+kB+kE2OeWSbtJkh5grdSyZSNJRkJ abSfvhhjyUpjt5u3kv5JssT2YnF+kmGKZuUZkgTDv4NAZgJV7ImZlW3PjO7VZf9epLxS5B59eye9 u58cl1eXeXhUj/HY3IiILrMFieZSk18D7B13Xg8kZk2lvmgm2nAcJ384O3BrOHrpYPe+nvqVO7mA o7PnwofMLUpALM7newf7+c6fMHE3Pkdedt3Hd+yoh84FGHGJhb+MSrxoMe6eT1RxsiKVzO62CRdA nJlbrswjZZLZ7R+SciaIJDYpzZDLto3cwAkB+YUiNuXcF9qamb6pvdEtANw/hfOjrdy9ZH5Zy9/M 9uqwswE3OX+/l3/jK51hlI09f/niOv3UaeeNpk5xYr206pLnZ7kqpo5vxjsX753oPtF5yV//6Fjv 3ImM72LNr1KjS4jamIWRkEb7qePueXLUkh2tvG7eaC2z1hfTi2WRgp5yXPa/pDLtS0JKEMhIoHI9 MaOe2ymbOP51fsIveaqLt4svLF9dnI+94SjjtN1DWm/GQpbpD6ZidpF455xl2L50hO/Y2btie7U7 Xk1vxi5K7uzoFpdSfeOQE4nw7e54NQWZYERAuolZ1DL5qMpDLIfDl8n5hGR9YVFPnrYidPbt5Aa2 j67yzrmzWNo7IV7S7oUSqUNp8qE9H3UtxH9BheyZxjLFLdDAj8oujsK4w/SidPSvRoUqEmWFyySz 2z+U4lmVqX/Iir/VPA6yPc/ElCUAdxQJse08cobf+3LiwbrP+3uxkUY0yCwHyGhMl5UNyG9vqNP4 10bvOxeZaMNIJNbKCXjglhjP3LgDuQNSG7l8/oBzpc0L+auNPMvf4KI6r7hZpzqvMgYexqY6i3rf jBgjh5xYhuBHE1uZRDbZojZWvJFoH4/xu3k2cRufi+zF/qfUTqyPu46LdCzkQ6NnaLx6qHE7Eah0 T9xODZVNVxmLrsa46a5x/S6bOH29ODe0z3tzjfJgwRmLGDd7tCFSzljIMv3BlM8u+Kdk4n9+wLme zr9zHvcpNT4Wz46tq7jC5I+uRdTkFeox5H4YqThmd6YN6mMufMrtzta8D9/GqilvAbjv3FWKyWj8 +exXxH0xgod5nUdGe1ZW09oEOntaYkhfMQKPnHnu+cMf/2TFpIa4ILDdCfDB6dJO7zLedqcB/UEA BEAABLYlAX7W2sSNUfGqOf66tYxXLFM0WFhNPgdY3FdKveTsgj8cY+dtboOn0AlJQWDbEnj1pc99 8MMfNakvP6WGHwiAQMUI7J3wzgHi9uYrphXEBQEQAAEQAAFrAvze+Jz3BjXrXMUlFEfQa+XfFGuc mvyjJKGv28rvxYQ+hFYcQJQEAiAQIYDFOYwCBKpJQL7UVP4pf8++moQgNQiAAAiAQLsSkF8pb/6i kb+e9gIbS/dp7jRN0lA15UdJ5Guh/Z96/27oQ2hpNEBaEACBdAQQ1p6OF1KDAAiAAAiAAAiAAAiA AAiAAAiAQAYCCGvPAA1ZQAAEQAAEQAAEQAAEQAAEQAAEQKBxBBDW3jjWqAkEQAAEQAAEQAAEQAAE QAAEQAAESAJYnMMwQAAEQAAEQAAEQAAEQAAEQAAEQKDJBLA4b3IDoHoQAAEQAAEQAAEQAAEQAAEQ AAEQwOIcNgACIAACIAACIAACINAOBOTrzcWfvG9Q598wt/tSKa8xb11NBK+ryf8+MrPVRGFQNQiA AGNicX5N74jLE8qp7fL6p/fEzklFqG5eG4l4SeELlPc8HKidaBL77FRKso3J2u0fWpfpjRABNVPo ns1C7YmR5ZMYDWyj1mIWWX4q0x3AfKOyGUSp2kmzLJ1tthbJk8vRPTDV8NXUePoDqsgiJwpLk04v U5An7rmC0JaZR8wWzGuysTRGEjBaV8fQw8rDDPfigMntOrvk6l2WZ2hB24FI1SVA9tnqqrMtJQ+M XBkWvbtP8S+Mzo71NggeNzn++bGJfqc6bUQIDLsNkoZ5E4BMFdZGRrunDvpuP1UhZMPxh+7cQw6+ okHloPPU1U1ZenaB0dlTNQ8SV4iAWJzXn3H2yYShT/fcUB9Pnhmp8X/jfekku6CenGcnUu+o8W75 NDsT8pJLk4emus/LMq8PLh7y1wwRcGT2zWvPrI1KkW4c94QnUxoWn0R2skzyoX2ZTI4QETltdc9m RWUAp9kS1hIj8vLEwVs9Q95g6X+jm/OpD7G+ncLayB9VO22W9u2VjW3jc/FBa7jeXXe/Z35fDv96 9xlfPxmzvbV3Qpgfx3tAdmH1OXQxEIoPmTrfSH/xiJF84/UttEbaxtIYScholXSRh1Q3L1SRMgsz 9eIh5Z/5H+eDtwbHQrh3ls4zlKkdyt52BMg+u+0otIHCasziU8T4Ma4FNN2aOX2x50Lww+C+/3SG 3RaQ01qE3afqQzcvJR2bmYqLaThn6uLsYvT2sVt3ch3Ro7NbtykSVo6ADGvv7pLz86UXLrKxM3JN 7v221lb2D8g5PWP9A0OrC8vpOhNfHkRm/8uL873jT8hdxq27Cyts7rY45SN/VHbWeWRGLTNYrbOH ra49FH8lU5JlktntH9qXGUypIKfQPZstlQGcZEtZi1HkpcmTa2NnRndSCbauXprff8y8RKRqp82S bMRsGFsj1/J0ffVAaNQXuNzuw/gm9/6VxbubKcTdurMYKTNF9mom1WzM3khIo42zZMHG8aVVwWTf i0knkN8zVAUU5KwEgaTuWQklIKROoPaRgd6V1+S0Uz+RVsfpYh8wGDLmHsaSUw0vYNMPQY+WKct1 Ux6aWklqjntXptjxUWeSHDMFemzimgwe1E6MQ0o5x1QiQv6qJ6p4aFBTnEiHypQnycP1VTZ/Mhia Go22i1Nz7xP83OuKFzOVhID8d63h1L/fOzu2fnzWiy9gbHD08YUXopN/eahuES6Bzp6pXZCpIgTE 4vyG2vPb2ljvHey4G3EfNxdVNKyY4Bah1dbmmprCch908Nbg2H62vrmZrWBRlLd3kL4IMrv9Q7LC YHYnyIerqSAXqLu9uqVUarIWSizplM8Zlt9yefCktMBUv1izzGkYqQQpL7GnhYrdUiPWw40VfQW4 o6tvZeOBvQxiO6y3Z4d9hnZISdtYvJGQRmuw5HA3rwwzcy8Oz+3sVUrjGexLRUoQSCQQO9Ak5kaC liQgdqidwDovRkkep4tVa+3oMf/ESO47jx7tpNXgq9NDCwPXw6fx0TJDsWl9CVSWbt/sG9gTrtT1 n9r9UDZX3zgmQ1APrFycVpNqPgfWoticMyf+fP4We1YGDlzYL86uzGq6ZV4fZxef5mfdtaMvqnh+ 9+henY3xI2sn2pRH0jEn2i4QghdSs7ZnsM+dYmU0C63hRAnLE1zTy8HW2bFncP12xi0AdPaM7YJs FSEgFucHvQshq1PT7JyMZqx3y67O+idvHF87IRcGp9ngUHFaOV5pZqQjc5k8piUSTZSiMDK7/UOy pnB2FVd8/5XRNR+y55Hz6J5CTydpAcBDlUatxcAk6pS9hEnH5gY9480yp2GkZ1t2Dm/ELbuitiyf trF4I6FmEuT0QhKju3k1YBK9mAcXaPdx4q4dGVS09AzVAAQpK0KA7LMVkR1iRgjMqWnnLh5zd92N vvTejuEfaO/d58aO8X3nmBNssSvtBejJiDN1Gq8uP4s/XplaeKNdu/R0RK6G+WHt6n6o+LlBcLUe dyUsFvbkycTQqJOL7x3Io2aTml6ZfnwBITPfMGUuz8fGnDO2eDVrXd1s7UG6OFlVM9Vw/OHJub6u yGSfNwSLxM/L+2jaATvVCOjsdqaJVNUlIBbnQ14n7B1/1tnZEr5AOS+5MBBztct72Doj3FBa5UUs +s2x6a5ZeZtx88E66+7sTFuIOEsUl+H9vcZUJZDZ7R+SdcWJxG8ESMiF6J5KU9GCRQAnKqWsJZJs 89r0HG9uOf650VZeHJq4rJXp2NxsljkNIy3bUtOLhlvfCI2P/Khcf8gP0okxzyyWdhOkVNlbpnDK xpKMhDTaT1+MsWSlrtvNW0Z5C0Fie7E4P8kwRbPyDBayIQkI2BKIHWhsC0G61iHgXl3270XKMGb3 6Ns76d395Li8uszDo3qMx+ZGtegyW4eCJ0kuNfk1wN5x52VSYjJf6otmog3HleAPZwduDUcvHeze 11O/ciclcHT2lMCQvIIExOJ8vnewn2/u8SsibMq5AbI1M30z9I4u/iIl52qNcwFGXGLhL6MS75eK u+cThSKmsG4gkLxVu899y6XaxUy8bcIFEGfmlivzSJlkdvuHQiG7Mn3VxSalhByje3nWkxs4IVqM tQTg+KdwfrSVu5fML2v5m9leHXY24Cb3zZI/SWcY5QEvqmTxloep084bTZ1CxXpp1e2nfP9YxdTx zXjvfRAyus/vUyFh+kfHeudOZHwXa1GKNa6cqI1ZGAlptJ867p4nRy3Z0cfr5o3TL19NCT6fCXrK cdn/ksq0LwkpQcCaQNxAY10IErYwAXH86/yEX/IkFW8XX1i+ujgfe8NRxmm7h7Te/JYs0x9Mxewi 8c45y7B96QjfsbN3xfZqd7yagYl0Z0d38K6onEiEb3fHqynIBI/i0k3MoobEeygPyB0OT+/5hGR9 YVFPnlwROnsL91OIVhABeefcWSx1HjnDb/I4ET7d59XumvdZneHXRu+HboxYyKBuY/ovqJA9c++E eEm7F7Pkn36LW6CBH5VdHIVxh+lF6ehfjQpVJMoKl0lmt38oxbMqU/+QFX8HvgPZqLsFTJskJQB3 FAmxJa2FgmOSWg6Q0ZguKxsgzZI2DBtoLZuGx0uL8cyNO5D7ZbWRy+cPOFfavJC/2siz/A0uqk+J m3WqTylj4GFsqrOo982IMXLIiWWw+ZZhy8KxECxqY8UbifbxGL+bW8jWEkniff6jJ9bHXcdFOhby odEztITGEAIEQKCKBGQsuhrjprvG9SuW4vT14tzQPu/NNWrWGpyxiHGzRxsi5fyWLNMfTPmkl3/r JP7nB5zr6fw753FfIOZj8ezYuoorTP7oWkRNXqEeQ+5PpMUxuzNtUB9z4dNOd27vfSY5Vk15C8B9 FbRSTEbjz2e9Ii6LcMQIHuZ1HhntWVmtokVCZhAokcAjZ557/vDHP1liDSgaBECgeAJ8XXRpp3cZ r/jyUSIIgAAIgAAItDwBftbaxI1R8ao5/rq1jFcsU8ANq8nnAIv7SqmXnF3wh2PsfNJt8BT6ICkI bGsCr770uQ9++KMmBPJTaviBAAhUjMDeCe8cIG5vvmJaQVwQAAEQAAEQsCbA743PeW9Qs85VXEJx BL1W/k2xxqnJX4Qe+rqt/F5M6ENoxQFESSAAAhECWJzDKECgmgTkS03ln/L37KtJCFKDAAiAAAi0 KwH5lfLmLxr5W5MvsLHElyVlboWGqilfhC7f1uz/1Guh019rzawxMoLAdieAsPbtbgHQHwRAAARA AARAAARAAARAAARAoAEEENbeAMioAgRAAARAAARAAARAAARAAARAAASyE0BYe3Z2yAkCIAACIAAC IAACIAACIAACIAAChRDA4rwQjCgEBEAABEAABEAABEAABEAABEAABLITwOI8OzvkBAEQAAEQAAEQ AAEQAAEQAAEQAIFCCGBxXghGFAICIAACIAACIAACINBkAvL15uJP3jeo82+Y232plNeYt64mMtPV 5H8fmdlqojCoGgRAgLHg4nx5Qnm0XZ4/8p9kdnab10YiXlL4AlXg4WsJbsA+O5WSbGOydvuH1mV6 I0RAzRS6Z7NQe2Jk+SRGA1vPPCy8ufxUpjuApbMrqvaorXJtSmebrUXy5HJ0D0w1fDU1nn4TiCxy orA06fSyYKdmjLbMPGI2P6+d3aYzPBYwWlfH0MPKwwz34oDJ7Tq75OptR1ilTuMZmm87kKAdCJjs th1022Y6BEauDIve3af4F0Znx3obhI2PCPzzYxP9TnXaiKDNpRskC6/GmwBkqrI2Mto9ddB3+6kK IRuOP5y4p4qRUxfRoHKAeOrqpnyaQWB09lTtgsTVI6Atznm3OckuqC8nn2cn1Fzf/5Yyf14fYn07 a6mU5N3yaXYm5CWXJg9NdZ+XFV0fXDzk9luiYDL75rVn1kalnDeOs/ozapOPTEmKSma3f2hfJpMj REROW91TcfYSlwGcZiuWKNM9N5TBzIwk2MXyxMFbPUPeYJnCrqjaSVvlLp4wjGwYWyQXH4GG6911 93vm9+Xwr3ef8fWTMdtbeydE6/Bue0D2a/U5dDGqiQ+ZOt9If/FIuh7dImRCYhjMPup8UhiemEAE jFbVGXlIdfPWpERIZerFQ8o/8z/OB2+tCfMJWCrPUBlUELQCBCJ2WwGZISJFQI1ZfIoYP8a1ALyt mdMXey4EPwzu26Ez7LaAnNYi7D5VH7p5KenYzFRcTMM5UxdnF6O3j926k+eIHp3dukmRsHoE9MX5 2sr+ATl952vygaHVheVgv9m6eml+/7GUU3m+PIjM/pcX53vHn5C7jFt3F1bY3G1xykf+qOys88iM WmawWmcPW117KP5KpiTLJLPbP7QvM5iyu0ssglLons2YygBOsl164SIbO5O0JneUWJo8uTZ2ZnQn pVOSXVG1b5G2SjZiNoytkWt5ur56IDTqC1xu92F8k3v/yuLdzRTibt1ZjJSZInuLJiVNNMEnJBke abRxlizYqG5emZ99L7YnbF9mZTBBUBAAgeYQqH1koHflNTkX1U+k1XG62AcMhoy5h7HkVMML2PRD 0KNlynLdlIemVpLUvndlih0fdWbOxsTi9PiaDB7UToxDSjnHVCJC/qonqnhoUJMoU0Z1DddX2fzJ YGhqNNouTs29T/BzrytezFQSAvLftYZT/37v7Nj68VkvvoCxwdHHF16ITv7loXqGcIlMUiITCLQo gWBY+81FFXwipq1hgeWU68m9+fXY2lxTU1jugw7eGhzbz9Y3N7MVK4ryNhTSF0Fmt39IVhjM7gT5 cDVvyI3VAnW3V7eUSrc21nsHO+4Sg01UMOmUzxm2dbLaVZytSs45DMOebakpPS1UHLUasR5urOgr wB1dfSsbD+zFENthvT077DO0bcoEwyON1mDJ4W5eGWbmXhye29mrlMYz2JeKlCBgQyC73dqUjjSN JyB2qJ2ATS9GSR6ni1Vr7egx/xhJ7juPHu2kZeSr00MLA9fDp/HRMkOxaX0JKi/dvtk3sCdcqWuH j2p7B3P1jWMyLvXAysVpNdPmc2Atis05c+LP52+xZ2XgwIX94uzKrKZb5vVxdvFpftZdO/qiiud3 T5XV2Rg/snaiTXkkHXOi7QIheCE1a3sG+9wpVsY21xpOlLA8wTW9HGydHXsG129n3wJAZ8/YNMhW BQLa4rx/8sbxtRNyDXCaDQ4FpU86ZUqtq+OVZkY6Umd1M/D40kg0UYrCyOz2D8mawtlVXPH9V0bX DmqvFSlA9xR6OkmLr3R1apqdk7Gv9W45MNA/yil7KTPaVaytisDjPIaRnm3ZObwRt+yKtk/5CYZH Gq3RkuluXg2YRC/mESjafZy4a0cGFS09QzUAQcqqEMhtt1VRdFvIOafmort4zN11N/rSe5OFf6C9 d58bO8b3nWNOsMWutBf4KSPO1Gm8/3YMr0wtvNGOdE9HJFzKj7j2b/y5QXC1HnclLBb25InX0KgT k8j3DuRRs0lNr0w/voCQmW+YMpfnY2POwVu8mrWubrb2IEvQOdVwvPaTc31dkck+bwgWiZ+XV8+0 A3ayEdDZ7WwTqSpLIHByLtcAYlp2eQ9bZ5rHEZdqijk256BELPrNsemuWXmbcfPBOuvu7EwLUJwl ihvy/l5jqhLI7PYPybriROLXBKSnK0T3VJoWBZyotHf8WWcfVIwczlAXTrd5bXqON7c8+HWjrbw4 tBx2ZbLVnIaRlm2p6YW1rG+Exkd+VK4/5AfpxJhnFku7CVKq7K1deILhkUb76YsxlqzUdbt5aysf lC62F4vzkwxTNCvPUCVIkLVaBDLabbWUbHNp3avL/r1IeaXIPfr2Tnp3Pzkury7zSKge47G5kRVd ZguizaUmvwbYO+68HkjM8Et90Uy04ThO/nB24NZw9NLB7n099St38gBHZ89DD3lblgD5KTX+Yq3A LRp+qcbfdPQuwIhLLPxlVOL9UnH3fKKqiymsGwgkb9Xuc99yqXYxE2+b8AWYOBq1XJlHyiSz2z8U CtmV6asuNikH+/n2aozu5dlIbuCEaPxCEZty7gttzUzf1N4UGIDjb3D60VbuXnLIrpxa7GzAFSlg q+kMozzgRZUsXv0wddp5o6lTqBiKVl3y/CxXxdTxzXjvJREyus/vUyFh+kfHeudOZHwXa1GKNbkc 2vB8oUij/dRx9zw5asmu6brdvMn6WVcf04tlGQKUclz2v6Qy7UtCShDIRiCL3WarCbkaRkAc/zo/ 0b5eveLt4gvLVxfnYy+yyTht95DWm7GQZfqDqZhdJN45Zxm2Lx3hO3b2rthe7Y5XMzCR7uzoDt4V lROJ8O3ueDUFmWBEQLqJWdQs+KjKQyyHw9N7PiFZX1jUk6esCJ29YV0QFTWSgFicu+th7+MEw6+N 3vcvh0hHlvW2ubqN6b+gQvbMvRPiJe1ezJJ/+i0u2QZ+VHZx6sUdphelo381KlSRKCtcJpnd/qEU z6pM/UNW/K3mzorUqHtBrV4CcEeRENvOI2f4vS/ZiOL98/5ebKQRDZoZ7MrKBuQrx9VpvG+rtGEU xLU5xfB4aTGeuXEHcgekNnL5/AHntpUX8lcbeZa/wUX1KXGzTvUpZQw8jE11FvW+GTFGDjmxDDbf MmyO5ilrJc2efChe9pPDoUXl0j4e43fzlOI3LTnZi/2v1JxYH3cdlz1ho2dompaoeFsQIO12W2i+ LZSUsehqjJvuGtfvXYrT14tzQ/u8NyIpSwjOWMS42aMNkXLGQpbpD6Z8dsG/dRL/8wPO9XT+nfO4 z6TzsXh2bF3FFSZ/dC2iJq9QjyH3J9LimN2ZNqiPufBppztb4xWp0MVYNeUtAPf90EoxGY0/n+OK uCdG8DCv88hoz8pqWhNGZ09LDOkrRuCRM889f/jjn6yY1BAXBLY7Ab5YurTTu4y33WlAfxAAARAA gW1JgJ+1NnFjVLxqjr9uLeMVyxQNFlaTzwEW95VSLzm74A/H2PnE2+ApFEJSENjOBF596XMf/PBH TQTIsPbtjAu6g0AlCOyd8M4B4vbmK6ELhAQBEAABEACBDAT4vfE57w1qGfLnzSKOoNfKvynWODX5 R0lCX02W34sJfQgtLzbkBwEQiCGAxTnMAwSqSUC+1FT+KX/PvpqEIDUIgAAIgEC7EpBfKW/+opG/ nvYCG0t8WVLmVmiomvKjJPJtzf5PvX839CG0zOogIwiAQCIBhLUnIkICEAABEAABEAABEAABEAAB EAABEMhLAGHteQkiPwiAAAiAAAiAAAiAAAiAAAiAAAiUSgBh7aXiReEgAAIgAAIgAAIgAAIgAAIg AAIgkEwAi/NkRkgBAiAAAiAAAiAAAiAAAiAAAiAAAqUSwOK8VLwoHARAAARAAARAAARAAARAAARA AASSCWBxnswIKUAABEAABEAABEAABFqfgHy9ufiT9w3q/Bvmdl8q5TXmrauJWHU1+d9HZraaKAyq BgEQYCyyOF+eUE5tl9c/Rb9Vnu7wtSxddvPaSMRLpijTPjuVkmxjsnb7h9ZleiNEAF0K3bNZqD0x snwSo4Ft1FrMIstPZboDmJfRMa34gY2q3S9h4p5Xaelss7VInlyO7oGphq+mxtMfUEUWOVFYmnTx yuw+KNoy84jZ9Lzmpg8YHpczjZGE80o1Qw8rDzPciwMmt+vsktu2ZXmGptsOBGgfAmmGpPbRut00 CYxcGRa9u0/xL4zOjvU2iAsfEfjnxyb6neq0ESEw7DZIGuZNADJVWBsZ7Z466Lv9VIWQDccfunMP OfiKBpX99Kmrm7L0rAKjs6dqHCSuFIHA4lxMOqd7bqiPJ8+M1FS3eWZtVD65cZzVn0m7o8a75dPs TMhLLk0emuo+L2u5Prh4SFtchdmR2UmRyJRkU5DZ7R/al8nkCBFCZ697NjsqAzjNlrIWs8zLEwdv 9Qx5g6X/jW7Opz7E+nZKa6N+VO3cxZ9kF5ShnmcnnHVpTlvNBrzUXHzQGq53193vmd+Xw79uQuPr J2O2zPZOCEQc7wHJSn0OXQyE4kOmzjfSXzxiJF+qasUWbm76kOEF6MU7HzGBCBitEjnykOrmxWpX YmmmXjyk/DP/43zw1uBYCPcuNy/C40iJKqBoEFAEYHhtZAlqzOJTxPgxrgU03po5fbHnQvDD4L7/ dIbdFpDTWoTdp+pDNy9lOorjdcQ0nDN1cXYxevvYrTtZzvvQ2a2bEgmrS0BfnC+9cJGNnVFrcu/X eWRGzelZrbOHra49TKcrXx5EZv/Li/O940/IXcatuwsrbO62OOUjf1R2RopEpiTLJLPbP7QvM5iy u0uATaF7OtBu6jKAk2xJazHJvDR5cm3szOhO6t+3rl6a33/MvESkat9aW9k/oMyS9Q8MrS4sCx+f 01azAS8z1/J0ffVAaNQXuNzuw/gm9/6VxbubKYTYurMYKTNF9hZNamr6iOGl6ICk0cZZsmCjunll fva9mHQC+T1DZUhB0JYnYG/MLa8KBPQI1D4y0LvymlzD6SfS6jhdbMcEQ8bcw1hyquEFgfqRetEy ZbluykNTK0ltce/KFDs+6sxGjInF6fE1GTyonRiHlHKOqUSE/FVPVPHQoCZRpozqGq6vsvmTwXDX aLRdnJp7n+BHcVe8mKkkBOS/aw2n/v3e2bH147NefAFjg6OPL7wQnfzL8/CkcAl09kyNgkzVIaAt zrc21nsHO+4S7kOps7W5xrwVUQ4NRTlyCst90MFbg2P72frmZrbycopEZrd/SMoczO4E+XA1b8iN 1QJ1tydWSqVJ1qKLJ53yOcPyWzrZJwWcdL+biyqaXSxWIzlzGkY6SUpL7Wmh4qjViPVwY0VfAe7o 6lvZeGAvgtgO6+3ZYZ+hain1po8ann1fII3WYMnhbl4ZZuZeHJ7b2auUxjPYl4qUIJBAAIbXliYi dqidwDovRkkep4tVa+3oMXdrnk8FxL7z6NFOGgNfnR5aGLgePo2PlhmKTetLoLp0+2bfwJ5wpa7/ 1O6Hsrn6xjEZ63dg5eK0mr3wObAWxeYcg/Hn87fYszJw4MJ+cXZlVtMt8/o4u/g0P+uuHX1RxfO7 R/fqbIwfWTsBsDySjjnRdoEQvJCatT2Dfe4UK6NZaQ0nSlie4JpeDrbOjj2D67czbQGgs2dsFWSr DIHgnfPVqWl2TkYz1rtlV/d/PJgzErqTR0vHK82MdGQuJadIZHb7h6TY4ewqrvj+K6NrB4M3foVH zqN7emgFAA9VGmMtekrKKXv/nnRsbtCzf/LG8bUTcr16mg0OhVLlNIz0bMvO4Y24ZVdU+fL1pjcb XnJfIPMaC6S7eTVgEr2YhyFo93Hirh0ZVLT0DNUABCmrQwCGV522SpJ0To3vu3jM3XU3+tK7Y+wf aO/d58aO8X3nmBNssSvtBejJiDN1Gq8uP4s/XpladFWSkOrfezoi4VJ+WLtzP5Qnc4Pgaj3uSlgs 7MmTiaFRJ4KV7x3Io2aTml6ZfnwBITNfyjKX52NjzmFGvJq1rm629iBL0DnVcLz2k3N9XZHJPm8I Fomfl3cetQN2jDJ2ZohU7UUguDjvHX/W2dkSvsBxXiqoRlzx9Tf28kAQ4fE3x6a7ZuVtxs0H66y7 szNtgTlFIrPbPySljROJh15LT1eI7mlZlVWpwVqC4m1em57jzS3HPzfaSnvX4Olsx+Ziy5zvEIsl xOU9bF0bHXMaRlq2paYXDbe+ERof+VG5/pAfpBNjnlmsTJdTStWysMKDTU8bHrNyPmTeT1+MsWSl hNvNC1OpAQXF9mJxfpJhimblGRqgG6rYZgRgeO3T4O7VZf9epLxS5B59eye9u58cl1eXeQhej/HY 3IiFLrMFKeZSk18D7B13XiYlZk2lvmgm2nByY+Ll2YFbw9FLB7v39dSv3MkCHJ09CzXkqQwBbXHO r4iwKecGyNbM9E0nlIhPecWZubYydy7AiEss/GVU4v1Scfd8oijEFNYNBJK3ave5b7lUu5hJt03E ZkFIpDjekTLJ7PYPRV12ZfpSiU3KwX6+vRqje3k2kxs4IZrBWiJw/FM4P9rK3Uvml7X8zWyvDjsb cJPzN4H5N77SGUZ5wIsqWVynnzrtvNHUKVSsl1bdfsrPclVMHd+Mdy7eO9F9fp8KCdM/OtY7dyLj u1iLUqz4ciJNbzA8qw5I5v3Ucfc8OWrJjj5eNy9ev3JKjOnFskLRQ5Xjsv8llWlfElKCQAoCMLwU sCqYVBz/Oj/hlzwNxNvFF5avLs7HXrqUcdruIa03vyXL9AdTMbtIvHPOMmxfOsJ37Oxdsb3aHa9m YCLd2dEdvCsqJxLh293xagoywYiAdBOzqIHxUZUH5A6Hp/d8QrK+sKgnt6kInb2CPRgipyIgFufu erjzyBl+k8eJ8Ok+L3fXxIsouXfyQmKSV87B6tVtTP8FFbJn7p0QL2n3Ypb8A3lxIzTwo7LTIpEV ibLCZZLZ7R9K8azK1D9kxd9d7KxIjbqnajZz4hKAO4qEGpGyFhKOSVY5QEZjuqxsQL5yXJ3GvzZ6 37nIlNdWC2qBIovh8dJiPHPjDuR+WW3k8vkDzpU2L+SvNvIsf4OL6lPiZp3qU8oYeBib6r/qfTNi jBxyYhkyfx+xSCULKCtF0xfeAbWPx/jdvACdGlIE2Yv9T6mdWB93HRfpWMiHRs/QEI1QybYlAMNr 66aXsehqjJvuGtfvsonT14tzQ/u8N9coDxacsYhxs0cbIuX8lizTH0z57IJ/6yT+5wec6+n8O+dx n0nnY/Hs2LqKK0z+6FpETV6hHkPuT6TFMbszbVAfc+Gjnju39z6THKumvAXgvnNXKSaj8eezXRF3 0DhiBA/zOo+M9qyspjVddPa0xJC+YgQeOfPc84c//smKSQ1xQWC7E+Droks7vct4250G9AcBEAAB ENiWBPhZaxM3RsWr5vjr1oq59RnXfmE1+RxgcV8p9ZKzC/5wjJ23uA2+LW0QSoNAWgKvvvS5D374 o6ZcwTvnactGehAAgeYQ2DvhnQPE7c03RzjUCgIgAAIgAALlE+D3xue8N6iVX12kBnEEvVb+TbHG qck/ShL6uq38XkzoQ2hNII0qQWD7EMDifPu0NTRtLwLypabyT/l79u1FDtqAAAiAAAhUnYD8Snnz F4389bQX2Fjiy5Iy026omvKjJPJtzf5PvX839CG0zOogIwiAQCIBhLUnIkICEAABEAABEAABEAAB EAABEAABEMhLAGHteQkiPwiAAAiAAAiAAAiAAAiAAAiAAAiUSgBh7aXiReEgAAIgAAIgAAIgAAIg AAIgAAIgkEwAi/NkRkgBAiAAAiAAAiAAAiAAAiAAAiAAAqUSwOK8VLwoHARAAARAAARAAARAAARA AARAAASSCWBxnswIKUAABEAABEAABEAABFqfgHy9ufiT9w3q/Bvmdl8q5TXmrauJWHU1+d9HZraa KAyqBgEQYEwszq85HXHz2ojj0YRfO7vk8FmeUG5ul52TilB1ig14LuELVJmH3dpNrUFlZ+RDxjxR LZyL/HKj6099HW18OlU7SSmFmgUaYwnAaUUMrRBVhcxu/5BkQ2X3huSAXTWnFYpq0ECvdDqRr5Fm wL7Niywy5dKk08vC/ZcGVZTILVKOqVPb20PYnxg8JO2OCvBRDQMZcIZuraGH28JmCiBuOWAZbMls nOE2svefeUfwAqA0rog0c4DGSYWa0hEIjFwZFr27T/EvjM6O9aarNXNq3jf558cm+p0CNFeZedqc WRae0ZsAZCqkNjLaPXXQm/+nK4NsOP5w4p4qR3ot0aCynz51dVM+zSpwvs4eGdGo+VJgFuFqkY5J VUaEqJypBilLNZ3mJjfOwmOcDp9YkHqr1DQTs+qMhmJxXn/G3ycbOq++nHzf+c4h70sn2QX15Dw7 YbHoDdotN/en2ZmQl1yaPDTVrSq6Prh4KMbiDdmJMplo1+meG0rUmZFafP9Znjh4q2fI893+J6N5 9voQ69tpzE+JRFPavPbM2qiU58bxAOR0XTtd6jKAk4qQFZGyktntH9qXyeSQHAJub2zpQDckNXc6 w/Xuuvs98/ty+Nc1Gl8/GbO9tXdC0OD2fEB2YfU5dOHIxIdMnW+kv3gkoas0RNEyKqE7tW2vNPmT sIcUOyCUi8vvo8pgQpYZcoYqTeQh1bkaJmJVKkphDFwlwpZMI2O4OUi3Rtl23hG8KuTlzD/VHKBK mm1DWdWYxaeI8WNcC5DZmjl9sedC8MPgftd2ht0WkNNahN2n6kM3LyUdm5mKi2k4x2s5uxi9fezW ncxH9Pk6OzkLIudLjPWOq2XFjeNrJ1KfUFZlRDDO5+0GKXs1zQuH6BjnrT35JNYxyKVJ4qEwRauJ WaVGQxnWvrr20NTRttZW9g/IOT1j/QNDqwvL6ToTN/fI7H95cb53/Am5y7h1d2GFzd0Wp3zkj8rO yIdLL1xkY2eS1uROJbyB18bOjO6k6ty6eml+/zHzioWqnabUeWRGLYdYrbMnDrK107RIWAZwUhGy FUgByez2D+3LDKbs7hKrzhTGZkG3wUmWp+urB0KjvrBPt/swvsm9f2Xx7mYKubbuLEbKTJG9mkm1 Tm3ZK+39SUk+qmGgSWcY5yGFZKpz4RcmYG8MFDujs4o0B52Ssu28I3iF2ti+z1ZIqW0vau0jA70r r8lpp34irY7TxQotGDLmHsaSczsvYNMPQY+WKct1Ux6aWklqgXtXptjxUWeSbEwsTo+vyWhN7cQ4 pJRzTCUi5K96ooqHBjWJMuXZ43B9lc2fDIamRqPt4tTc+wQ/T7riBs8mEaD/XWs4leDe2bH147Ne fAFjg6OPL7wQnfzLs82kcIl8nT3TLKh29NxY79y0c9rvHP4nyVmVEcF6Pk8PPfZqmiqKTjk6dnq0 RaWD/WLOQT4kDdB+pZbNvkvPJRfn3vKbRbo0/9ebiyoiRUxwi5Bna3NNze24Dzp4a3BsP1vf3Mxb 8NbGeu9gx13C90VLlj7inGH5Lfv8k3tTyxNLSaisQU5deL4MBQLPqQiZ3f4hiSGY3QlM4nZ1Q+5k F6h7vkbIkttTTUX7qBHr4caKvjTa0dW3svHAvnSxHdbbs8M+QzukpDt1nDGb/Ul40mPPJ42Psi81 Z0rSGRo8ZLhz5awa2UO2ZHJW0eZIdGsB2y56BG/RhmvJ/tWirCokltihdiIZveAdeZwuVq21o8f8 EyO54ho92kkrx1enhxYGrodP46NlhmLT+hJYLd2+2TewJ1yp27Uf1fYO5uobx2QI6oGVi9NqUs3n wFoUm3OWw5/P32LPytPaC/vF2ZVZTbfM6+Ps4tP8rLt29EUVz+8eJKqzMX5k7URx8kg65kTbBULw QmrW9gz2uX4jo7FoDSdKWJ7gml4Ots6OPYPrtzNtAeTr7FlnQZ0d3RlhWGZrwRHBUiRLBU3JqCkH 32u+P7oxLKa+twfcaGjyoSjVdmJWndFQLM7dozmhth8VrKLN+ydlLIdYGJxmg0M5W0DL7nilmZGO ospcnZpm56T89W7pp+gf5SO8lEnH5oYy4ynxaI1I1FNRStuXUwDwnIqQ2e0fkqqGs6vApPuvjK4d 1AKQCtDdHnQJKb0Rt4Sy279IulMnGjPhTygPmYqfpY9KVWaexKQzNHpIunPlqX8b5zXaUthZmQcs o1vTbbu0EbwV267V+lcrMqqKTHNq2rmLBzled6Mvvfui/oH23n1u7BhfccWcYIv1mBcRKSPO1Gm8 /6Iir0ztbNAOVk9HJI7ID7L1r1i6QXC1HnclLBb25FHQ0KgTBMr3DuRRs0lNr0w/voCQmS9lmcvz sTHnjC1ezVpXN1t7kC5OVtVMNRx/eHKurysy2ecNwSLx8/I+mnbAbmiEpnd2SzntbIixFhwRrEWy 1THVosy/enCBjbmbXORD64lZpUZDsTiPBuSIbTO3Z8qFgVjwXN7D1hnhhtK2i4jxvjk23TUrr7Vv Plhn3Z2daQsh0veOP+tsywlH5njecLrNa9NzvHZ5DukG/3hhUeLuUKZjc7GDS1MSZ57ijoS/J1qA pimLKAR4TkXI7PYPSY3jROJXMKQBF6J7St6FJRfCr2+Exkd+VK4/5AfpxJhnFqGBNywK45CrIKpT WxlzrD/RPWQK8ax8VIry8iUlneGnL8Z4SFWf27ny1Y7cDgHPlihnxcgBi5nH0KhtFz6Ct27LtVb/ al1OVZDMvbrs34uUga/u0bd30rv7yXF5dZmHR/UYj82NCtNltiCfXGryuy3uxWk5mS/1RTPRhuM4 +cPZgVvD0UsHu/f11K/cyQI8R2fPOgsqbrUSq3ALjgixIuVcvhkWZdrVA/EShNUpcQOCfKjBTJyY VWg0pD+lxm/RrDgh/p7e/GUzztUa5wKMuMTCX0YldjLi7vlErVDM7dxAIHmrdp/7lku1i5l0i4Oy a36/hcnG47+tmemb2hvdAmX6Wyx+8I+7tSm0jt42TyeST0kIcvWwODNv6srcnUznAp5OkQgxMrv9 Q6GCXZm+ZXh3VGKMLcuA0Ng84i0PU6e9O06ycuF9lJ+SWE6omDq+Ge+9D0L6L79PhUTuH+X3pk5k fBdrY9UvorZop7Yy5hh/IqWiPGSSuEllJuUv/N9JZ/ip4278VNRDOhL4F8AKF2k7FujbEuGsDAOW wa3F2nZxI3hrtlLL9a/WxFRZqcTxr/MTXcbTQ7xdfGH56uJ87M1BGaftHtJ6U0SyTH8wFV0m8c45 y3jCzBXgF2hXbK92x6sZmEiL6OvAXVE5kQjf7o5XU5AJHsWlmwlHzYy7Mh7TOhye3vMJyfrCop7c piLbCb/B2jPNgu6d5ed5RaxWkrpg40eEJIm0CU/xM+qYRZkbuyGs0VvTkQ81zxBeupLKBVZqieo3 JcEjZ557/vmZf8uDcCb65auhV6UYfJvNWbL6D2Ua8Y9iBsDv9J5hp8UdnnPsmeHFx2dDl0lcZfg1 RTeKRj5yChH3f5TX6/NjlpzV7IpXkfwWVDR7YpluLbJGOV/Ry/Q4C9VeG3XjZ5wrSeE9xUh2snaC kninSPBtIppe5bV1Ipz0wGukIoaKosBJDmSZdEVUI9JsNZF8A5Yvd6GMrbw2KLRknbPbdnz0Ojkn a/FbUxlq8GGojfjutYrgoMosVOhWKSzaqe17pZbS7bmkhyzAR7UArqAzdATSHxo6VwuI3koi2BsD aUvxzio6YAXHUNq2c47grUQ3URaizybmQYIWJMD70eK+yKmGuMdxUw57x8e7L675CeSAqM2vtM6l TzupcZMs0xtMh87zG9qEJDoyXgKPA9UnwF6ZMpkadjWNhJXyG+Dex1PcWbeTUlxEv72PiusOq2ke x6NzHt05uLOjGDXFP/Eb8vor6FUJ++uBh2HbIRsupDs/5Ju93DktPq6kVhkhvcJqGuzT1Nmt5CRn QdR8ybcZfVkkRbKSsxojgmGpZT9I2atpXDhIpoExTpvT+ms66qH9xIxaqTXP/7360uc++OGPmuoX i/PDH/9k88RDzSAAAhkIcB93aad3GS9DAcgCAiAAAiAAAlUnwJdJ3kqv8boEFttlVh9Wk97CKEIC cnYhllXMPaIropaSyqiKnCWpj2IrQyB+cU6HtVdGOQgKAtuUwN6J8z31Q+pzKc4nWLYpCagNAiAA AiCwTQnwe+Nz3hvUmsCgNvIsf2ty6TfFGqcmf3V26HPC8nsxoQ+hNYF0YpVVkTNRESQAAZycwwZA AARAAARAAARAAASqREAFkPfxMGnTF9QapY0xFr0IAQxqlnNyzs/n+Zer9ID2IlRAGSAAAiECCGuH SYAACIAACIAACIAACIAACIAACIBAkwkgrL3JDYDqQQAEQAAEQAAEQAAEQAAEQAAEQCCeAO6cw0JA AARAAARAAARAAARAAARAAARAoMkEsDhvcgOgehAAARAAARAAARAAARAAARAAARDA4hw2AAIgAAIg AAIgAAIgAAIgAAIgAAJNJoDFeZMbANWDAAiAAAiAAAiAAAgUQoC/3lx+ZPTRyeV85fFvmNt9qZTX mLeufJLmyq2ryf8+MrOVqzhkBgEQyEtALM6veR2Rf0RBerTAl5P9h4/uyvItx81rIxEvKXyBquiw Xzuti312KiVZJlm7/UPrMr0RIqBmCt2zta49MbJ8EqOBrWcbFt5cfoLSHcB0o0oeRKnaSVstnW22 FsmTy9E9MNXw1dR4+k0gssiJAv/UijNHCXVq2jLziNn8vNZmn8ZIAkbr6hh6WHmY4V4cMDnN55fl GZpvO5CgDQikG1PaQOE2ViEwcmVY9O4+df+Vl2fHehuEiI8IJ1h9ot+pThsRgnPpBonjTQAy1Vcb Ge2eOphlqh+ecrgNx1tz4p6SRQ6+4rnsrU9d3ZRP0wuMzp6pbZGpQgTE4rz+jNwn493mJLvwMndq 9185z044c/2lSe/hy/Whm5eS1tIh3Xm3fJqdCXnJpclDU93nZUXXBxcPuf2WwEZm37z2zNqolPPG cVd4sQ6JVmRYfBLZyTLJh/ZlMjlCROS01T2bFZUBnGYrlijTPTeUwcyM1OLlXZ44eKtnyBss+ycV GfmnPsT6dhrzU7XTtmrfXtnYNj4XH7SG6911j5Uc/vXuM75+MmZ7a++Eg/eA7NeTu92BkM8k3DJf PJLQco3XOkON9o4ijZGEjFbJFXlIdfMMKjQni6kXDyn/zP84H7w1OBbK66bzDM3RG7W2HYEUY0rb 6d6GCqkxi08R48e4FtB8a+b0xZ4LwQ+D+/7TGXZbQE5rEXafyjDV90qPaThn6uLsYvT2sVt3Mh7R o7NbtyYSVpSADGtfXXvI/3drbWX/gJy+M9Y/MLS6sCz6TcfO3rlptb+1vDjfO9ifbirPlweR2b8o Z/wJucu4dXdhhc3dNoYeUdlZ55EZtcxgtc4eR3hGpiQbhcxu/9C+zGDK7i5BLoXu2SyqDOAk26UX LrKxM0lrckcJvsWzNnZmdCel09bVS/P7j5mXiFTttK2SjZgNY2vkWp6urx4IjfoCl9t9GN/k3r+y eFd2T8vf1p3FSJmWWVs4mb2jsDcS0mjjLFnwUd28Mj/7XkwSzu8ZKkMKglaIQNKYUiFVtr2otY8M 9K68Jtdw+om0OpUV+4DBkDH3MJacangBm34IerRMWa6b8tDUSlIL3LsyxY6POjNnY2JxenxNBg9q J8YhpZxjKhEhf9UTVTw0qEmUKaO6huurbP5kMDQ1Gm0Xp+beJ/i515WlJNVj/11rOJXu3tmx9eOz XnwBY4Ojjy+8EJ38y1Nx+3AJdPZczYTMrUpALs69NfnNRRV8IszdkZjPZe+PbgwLn3J7IPmA1ELP rc01NYXlPujgrcGx/Wx9c9MiH5FEFOUJn74IMrv9Q7LCYHYnOoureUNurBaou726pVS6tbHeO9hx lxhsooJJp3zOsPyWy4MnBZx0P8JW/QJyGkY6SUpL7Wmh4qjViPVwY0VfAe7o6lvZeGAvgtgO6+3Z YZ+hLVJm6NSk0RosOdzNK8PM3IvDczt7ldJ4BvtSkRIErAlkHVOsK0DCxhEQO9ROYJ0XoySP08Wq tXb0mHuMxGdXYt959GgnLRtfnR5aGLgePo2PlhmKTetLUHXp9s2+gT3hSl3/+ai2dzBX3zgm41IP rFycVjNtPgfWoticMyf+fP4We1YGDlzYL86uzGq6ZV4fZxef5mGttaMvqnh+9+henY3xI2sn2pQH KjIn2i4QghdSs7ZnsM+dYmVsa63hRAnLE1zTy8HW2bFncP12vi0Ahs6esX2QrcUJiMW5czTXP3nj +NoJuQY4zQaHHMHFbRDlPi6wMc3R5NXL8UozIx2ZS+LxpZFoohSFkdntH5I1hbOruOL7r4yuHdRe K1KA7in0dJIWX+nq1DQ7p+LSu+XAQP8op+ylzLjrSduqW2pOw0jPtuwc3ohbdkXtWX6GTk0ardGS 6W5eDZhELxYbsv59nLhrRwYVLT1DNQBByooRyDimVEzLthd3Ts1Fd/GYu+tu9KV309g/0N67z40d 4/vOMSfYYlfaC9CTEWfqNF5dfhZ/vDK18EY7yj0dkXApP6zdv/HnBsHVetyVsFjYkycTQ6NOTCLf O5BHzSY1vTL9+AJCZr5hylyej405B2/xata6utnagyxB51TD8dpPzvV1RSb7vCFY5KqsDFnXDtjj GgGd3c5Ekap6BMTi3AvIkWsAMS27vIetM+lxtCBYcRFldYqIQkmptYhFvzk23TUrbzNuPlhn3Z2d KcuQcT7iMry/15iqBDK7/UOyrjiR+DUB6ekK0T2VpjxxWZX2jj/r7IOKkcMZ6sLCbV6bnuPNLcc/ N9rKi0MTl7UyHZuLLfOIrcqqcxpGWralphcNt74RGh/5Ubn+kB+kE2OeWSztJkipsrdK4Zk6NWm0 n74YY8lKXbebt4ryNnLE9mJxfpJhimblGWyEQxoQSEkgx5iSsiYkL5WAe3XZvxcprxS5R9/eSe/u J8fl1WV+gtpjPDY3SkqXWapi2QrPpSa/Btg77rweSMzwS33RTLThuMb84ezAreHopYPd+3rqV+5k Y8JvH2SeQGasEdlAoFEEyE+p8Xcm6bdo3P0zsf0m4oucCzDiEgt/GZU4Wo+75xPVRExh3UAgeat2 n/uWS7WLmXjbhAsgzswtV+aRMsns9g+FQnZl+qp71/VjdC+vyXMDJ0TjF4qYu1OzNTN9U3ujWwCO fwrnR1u5e8n8spa/me3VYWcDbvKAraYzjPKAF1WyePXD1GnnjaZOoWK95O2R8bNcFVPHN+Odl0Q4 G2p+nwoJ0z861jt3IuO7WItSrEHlpOvUvlCk0X7quHueHLVkJ2uWt3I0CAVdTUwvlhlED037npGk MpuqMCpvcwL0mNLmSm8P9cT80/mJVvaUFm8XX1i+ujgfe8NRxmm7h7TejIUs0x9Mxewi8c45y7B9 6QjP3+i0Ynu1O17NwES6s6M7eFdUTiTC52rxagoywYiAdBOzqE3yUZWHWA6Hp/d8QrK+sKgnt64I nX179PxtqqVYnLvrYe8LOsOvjd53LofURp7lb4Y45IT9dJ9Pu+WmbmP6L6iQPXPvhHhJuxez5J9+ i6uhgR+VXeyWcYfpRenoX40KVSTKCpdJZrd/KMWzKlP/kBV/q7mzIjXqXpABlgDcUSTEtvPIGX7v izCMSCMaNJMDZDSmy8oG5Lc31Gm8b6u0YRTEtTnF8HhpMZ65cQdyB6Q2cvn8AedKmxfyF+in/Gad 6lPKGHgYm+os6n0zYowccmIZbL5l2BzNU9Zq7SiKNxLtqz9+N08pftOSk73Y/5TaifVx13GRjoV8 aPQMTdMSFW8TAoYxZZto3+Zqylh0NRed7hp3710KpcXp68W5oX3em2uUBwvOWMS42eNOZfkQKaey ZJn+YMpnF/xTMvE/P+BcT+ffOY/7TDofi2fH1lVcYfJH1yJq8gr1GHJ/Ii2O2Z1pg/qYC592urM1 XpEKXYxVU94CcN8PrRST0fjzua6IO2IED/M6j4z2rKymN1509vTMkKNCBB4589zzhz/+yQpJDFFB AATkwvvSTu8yHoiAAAiAAAiAwDYkwM9am7gxKl41x1+3lvGKZYrmCqvJ5wCL+0qpl5xd8Idj7Lzt bfAUeiEpCGxLAq++9LkPfvijJtXJsPZtyQlKg0CVCOyd8M4B4vbmq6QSZAUBEAABEACBNAT4vfE5 7w1qaTIWlFYcQa+Vf1OscWryj5KEvm4rvxcT+hBaQfRQDAiAAEUAi3PYBQhUk4B8qan8U/6efTUJ QWoQAAEQAIF2JSC/Ut78RSN/PS3/mFHiy5Iyt0JD1ZQfJZFva/Z/6v27oQ+hZVYHGUEABBIJIKw9 ERESgAAIgAAIgAAIgAAIgAAIgAAIgEBeAghrz0sQ+UEABEAABEAABEAABEAABEAABECgVAIIay8V LwoHARAAARAAARAAARAAARAAARAAgWQCWJwnM0IKEAABEAABEAABEAABEAABEAABECiVABbnpeJF 4SAAAiAAAiAAAiAAAiAAAiAAAiCQTACL82RGSAECIAACIAACIAACIND6BOTrzcWfvG9Q598wt/tS Ka8xb11NxKqryf8+MrPVRGFQNQiAAGNicX7N64jLE8qj7dL9kei36uFhP2UKdpvXRiJeMkWZVHZG PmTMk9/CucgvN7r+1FfcxqdTtZeCLgVlLWkJwOn2MrRCVGoyu/1DEgOV3RuSA7aawtiyAS81lwM5 MNXwNdIM2Ld5kUVOFJYmnZ4b7tQ0qFL1aHzhpk5tbw9hfxJoi11nl1ydyvJRDWMWcIZuraGH28Jm CiBuaQwGWzIbZ7iN7P0nOTYVoGmLFZFuEG8x4SFOgEBg5Mqw6N19in9hdHast0FYed/knx+b6Heq 01xlcC7dIHG8CUCm+mojo91TB/3RLVUhZMPxhxP3VDHSa4kGlb31qaub8ml6gYvo7JERjZovBSpy tUiFhF6tRIeJpo8IOUWyHPic5iY3zsJjnA7fM0jiYZqJWXVGQ7E4XzwkbY53m5Psgvpy8nl2wpnr b157Zm1UPrxxnNWfSbujxs39aXYm5CWXJg9NdZ+XFV0fdGqnzd2QnSiTiXad7rmh5J8ZqcX3n+WJ g7d6hjzf7X8ymmevD7G+ncb8lEiloEvnANzUZQAnbYCsiJSZzG7/0L5MJofkkK3aG1s24KXm4k5n uN5dd79nfl8O/7pG4+snY7bM9k4IGtyeD8h+rT6HLhyZ+JCp8430F48kdJVSFSyzcLpT2zo0kz8Z Uo6L/3G+BFuajyqTTaDskDNU/xZ5SHWuholYlYpSGANXibAl08gYbg7SrVG2TY9NVeGZRs4Ug3ia YpG2OQTUmMWniPFjXHOEC9S6NXP6Ys+F4IfB/a7tDLstIKe1CLtP1YduXsp0FMfriGk4x2s5uxi9 fezWnYxH9Hk7OzkLIudLjPWOq2XFjeNrJ+zCKDTSVRkRjPN5u0HKXk3zwiE6xnkLUj6JdQxyaZJ4 KHhbTcwqNRqKxfkKm7vNt7K21lb2D8jpO2P9A0OrC8ui33QemVFzelbr7GGraw+te7hMyM09Mvtf XpzvHX9C7jJu3V1waqeLpbKTZbKlFy6ysTNJa3KnFt7Aa2NnRndSlW5dvTS//5h5xUKJVAq6dKDd 1GUAJ22AbBpSZjK7/UP7MoMpu7vEqjOFsWUDXmau5en66oHQqC/s0+0+jG9y719ZvLuZQoitO4uR MlNkr2ZSrVNbOjR7f1KSj2oYaNIZxnlIIZnqXPiFCdgbA8XO6KwizUGnpGybHpvavOWSBvE2V7+t 1Kt9ZKB35TW5htNPpNVxuthCDYaMuYex5NzOCwL1Q9CjZcpy3ZSHplaSaN67MsWOjzozZ2NicXp8 TUZraifGIaWcg1kRIX/VE1U8NKhJlCnPHofrq2z+ZDDcNRptF6fm3if4UdwVLzQsCQH571rDqX+/ d3Zs/fisF1/A2ODo4wsvyHYM/OTZpn24RJbOnmkWVDt6bqx3bto57XcO/5PkrMqIYD2fp4ceezVN FUWnHB07Pdqi0sF+MecgH5L2Z79Sy2Te5WcSi/Ox/Wx9c1PUdXNRBZ8Ic4/UvbW5xrzVew7JRDly bsd90MFbg37tOcpkWxvrvYMddwnfFy1V+ohzhuW3nJQ/uTe1LA1Bl1oq1ZrFAc9pA2R2+4ek+sHs TmASt6sbcie7QN2zwc+Ty1NNRfuoEevhxoq+NNrR1bey8cC+FrEd1tuzwz5DO6SkO3WcMZv9SXjS Y88njY+yLzVnStIZGjxkuHPlrBrZQ7ZkclbR5kh0awHbjh2b2rEVsg7i7cii8jqJHWonktEL3pHH 6WLVWjt6zD1G4oO92HcePdpJq8xXp4cWBq6HT+OjZYZi0/oSCC7dvtk3sCdcqdu1H9X2DubqG8dk XOqBlYvTaqbN58BaFJtzDMafz99iz8rT2gv7xcmZWU23zOvj7OLT/Ky7dvRFFc/vHiSqszF+ZO0E wPJIOuZE2wVC8EJq1vYM9rl+I6MJaQ0nSlie4JpeDrbOjj2D67fzbQGoY7mUM/ass6DOju6MMCyz teCIYCmSpYKmZNSUg+813x/dGBZT39sDbjQ0+VCUajsxq85oKBbnHQpY/6QM2xBrgNNscChEkYcc REJ38rSH45VmRpza85Sl8q5OTbNzMuK03i39FP2jfISXMssmXMPRZUNVAPCcNkBmt39Iqh3OrgKT 7r8yunZQC0AqQPds0AvK5Y24BZW3vYqhO3WiMRP+RAwM/r0JdRso1c/SR6UqM09i0hkaPSTdufLU v43zGm0p7KzMA5bRrem2HT+st2MDZBzE2xFFlXWaU3PRXTzI8bobfendF/UPtPfuc2PH+Ior5gRb rMe8iEgZcaZO4/0XFXllameDdgB7OiJxRH6QrX/F0g2Cq/W4K2GxsCcXlkOjThAo3zuQR80mNb0y /fgCQma+L8xcno+NOQdv8WrWurrZ2oMsQedUw/HaT871dUUm+7whWCR+XoasawfscY3QzM6eRk4L Q2rBEcFaJAv14pLQY5x/9eACG3M3uciH1hOzSo2GYnH+YJ11d3byv8g1gJh9Xt7D1pnvccTBnQj0 9zf28rSFCI+/OTbdNSsvbW56tecpU+TtHX/W2ZYTjszxvOFCN69Nz/Ha5TmkG/zjhUWJu0OpN+FU DY1Blw1RIcBz2gCZ3f4hqXicSPxehhxaCtE9G/b8uYTw6xuh8ZEflesP+UE6MeaZ6850OSW/Ks0r gerUVsYc60/EwUKGuYuVj2oYK9IZfvpijIdUormdq2GCtndFni1RzoqRAxYzj6FR2zaNTe1JNccg 3p5AqqqVe3XZvxcpA1/do2/vpHf3k+Py6jI/Qe0xHpsbIdBltiCzXGryuy3uxWk5wy/1RTPRhuM4 +cPZgVvD0UsHu/f11K/cyQg8a2fPOgsqbrUSq3ALjgixInVmbD4nm2FRpl09EC9BWJ0SNyDIh1r1 iROzCo2GYnHO77Xuc98zKdXk75Xxb9HwwV6cmWsrc+cCjLjEwl9GJXYy4u75RNtNzO3cQCB5q9av PeVtE79sfr+Fycbjv62Z6ZvaG90CZfpbLH7wj7u1ye8O+XurXtHpREpAl8+Is+bODTxqA3GiRIiR 2e0firrsyvSl8u6oxOieFWfj8olXP0yd9u44yYqF91F+SmI5oWLq+Ga885IIx38Fe7Qmcv8ovzd1 IuO7WBunelE1RTu1lTHH+BMpmSjWuQRlLWlSmdYFFZWQdIafOu5GB0Q9pFOxfwGsKEm2dTm+LRHO yjBgGdxarG37Y1PeEbyFm4sexFtYYIhmS0Ac/zo/0cpeNvF28YXlq4vzsZcuZZy2e0jrTRHJMv3B VHSZxDvnLMMurSM8v0C7Ynu1O17NwERaRF87N1VVRXIiEb7dHa+mIBOMCEg3E462KndlPKZ1OHxJ m09I1hcW9eTWFWWfsWeaBd07y8/zilitJFl840eEJIm0CU/xM+qYRZkbuyGs0VvTkQ81z2A1MQus 1BLVb0oCeef8uv8aZ3Wk/NrofedyiNia4t7JC4lJ8Z4GqY+6pui/oEL2zL0T4iXtXsySfyAvbsoF fmR28mHnkTP8GpIsU7zw1t8ajJRp4Cz9dTTEyE4k71X+BaLLZg8lAKdtgKxIyBwmRma3fygxWJWp fzmMv7ff2XMxGls2vo3NxQOJxXjmBnpI91QbuXz+gHPBxgv5q408y9/govqUuFmn+pRqIx7Gpvqv CsMWY+SQEzyS+fuIjcWQubZop7Z1aKQ/8b/YcWJ93DWwAnxUZv0amFH7zIzfuRpYfzWqsjcG0pbs nRWVkrZtamyqBsz0UhoG8fQFIUfrEZCx6GqMm+4a1+9ditPXi3ND+7xXBSmbD047xbjZow2RcopI lukPpnw6x791Ev/zA871dP6d87j3e/OxeHZsXQVyJn90LaImr1CPIfcn0uKY3Zk2qI+5cHfhTo95 RSpWNFZNeQvAfT+0UkxG48/nuiLuiBE8zOs8Mtqzspre3kyd3UpOchZEzpfEhdmDsoHEoJ86fLgq IwIpp/0gZa+mceEQtoDAnNZd05EP3Y/VOW3kzPzjNdJWaulNrzE5Hjnz3POHP/7JxlSGWkAABAoi wF3PpZ3eZbyCCkUxIAACIAACIFAlAvystYk7huJVc/x1a8Xc+ozDHlaTzwEW95VSLzm74A/H2Hnb 2+DNs5+qyNk8Qqi5NQi8+tLnPvjhj5pkESfn+IEACFSNwN4J7xwg9bc3q6Yr5AUBEAABEAABggC/ Nz7nvUGtCYTEad5a+TfFGqcmf3V26HPC8nsxoQ+hNYF0YpVVkTNRESQAAZycwwZAAARAAARAAARA AASqREB8sOAm6zs+G/pGV+N14JLc3lfWqbJBzXJOzvn5PP9ylfwSLX4gAALlEYg/OcfivDzyKBkE QAAEQAAEQAAEQAAEQAAEQAAEHAIIa4cpgAAIgAAIgAAIgAAIgAAIgAAIgEBLE8Cd85ZuHggHAiAA AiAAAiAAAiAAAiAAAiCwHQhgcb4dWhk6ggAIgAAIgAAIgAAIgAAIgAAItDQBLM5bunkgHAiAAAiA AAiAAAiAAAiAAAiAwHYggMX5dmhl6AgCIAACIAACIAAC7U+Av95812Piz+RyPmX5N8ztvlTKa8xb Vz5Jc+XW1eR/H5nZylUcMoMACOQlIBbn17yOKLqocmqHvYeem9Mfpql289pIxEtSFRnKpLIz8iFj /CMQSn4L5yK/iOj6Uy+jo368n6Vq90uYuOdpkkLNNEQT0pYAnFbE0ApR8cjs9g9Jfe1ttTmtUFSD OpADUw1fI82AfZsXWeREgX9qxZmjyOy+Zebu1EVpV2A5UWsMoNt1dklVlkL3sD+hC2S0OyrARxVI J76ogDN0k4YepuDWMLlbsSLLActgS2ZnFW4je/9Jjk2tiC63TPo47vb33IWigMYTCIxcGRa9u0/d f+Xl2bHeBknO++YJVp/od6rTXGVg2G2QNHI8ygDNEa82Mto9dTBj9yEbjj905x7SawnZZFd96uqm rDSTwLk7e2REo+ZLgaWBNrdP0ZZVGRFsZ1AsxXLAUneHZniMI5uYeJhmYlad0VAszuvPqH2yzWvP rI2+zJ3a/RvHvYdMurnwQ2vL5Ob+NDsT8pJLk4emus/LYq8PLh6KsXhDdqJMJtp1uueGFPWVmZFa vIjLEwdv9Qx5vrt/Uuko/9SHWN9OY35KJG6sJ9kFlf08O+Esk2ie1uiyJSwDOKkIWREpM5nd/qF9 maSt2htbNuCl5uJOZ7jeXfeMUw7/ukbj6yf9fbSIKHsnHHs+II1zcrc7EPKZhFvmi0cSukqpChZV uNEah5Sf4X/cD7daOjSTP4kUWJqPKopNYjkhZ6jSRx5ackusra0TpDAGzoGwJdPIGG4O0q1RTpUe m9qyEZYmvVGYD+I3L/mnDm2pbpsrpcYsPkWMH+NagMLWzOmLPReCHwb3u7Yz7LaAnNYi7D6Vp/vE NJzjtZxdjN4+dutO1iP6nJ1dLOcisyByvsRY77haVtw4vnbCLoxCI12VEcF+BkUOPfZqmhcO0TGO 8OfGdreamFVqNJRh7atrD8X/6zwyo6bvrNbZ4z4MdujurpQzeW7ukdn/8uJ87/gTcpdx6+7CCpu7 bQw9orIz8uHSCxfZ2JmkNbmjDW/gtbEzozspb7V19dL8/mPmFQtV+9bayv4BhY71DwytLiwLl2PB 09pdWicsAzipCNkKpJhkdvuH9mVStprC2KwZNyzh8nR99UBo1Bf26XYfxje5968s3t1MIdHWncVI mSmyt2hSe2u0dGj2/qQkH9Uw0KQzjPOQQrLUA0HD1GluRfbGQMlpdFaR5qBTUk6VHpuaS6mk2jt2 9s5Nq7M4wWewP+VkpSSxUGwuArWPDPSuvCbXcPqJtDoZFluowZAx9zCWqjMacUaVKct1Y0gPTa0k SX/vyhQ7PupM/4yJxenxNRmtqZ0Yh5RyjqlEhPxVL4hVPDSoSZQpzx6H66ts/mQwBpbS3azm3if4 +dwVJ9YsCYDh37WGUynunR1bPz7rxRcwNjj6+MIL0cm/PNtMOvnP19kzzYJqR8+NeR5GOBkbOasy IljPoOihx15NU0XRKQfZxPbtbr9Sy2jgZWeTi3NvYenWtrW5pj10gj0O3hq8EdwdzCacKFzO7bgP 4mWO7Wfrm3JAzfPb2ljvHey4S/i+aKnSR5wzLL/lpPzJvallubmootnF2imSOcgzddk5MxQIPKci ZHb7hySHeFstUPecrZAhu6eaivZRI9bDjRV9abSjq29l44F94WI7rLdnh32GiqcMz1GEOhYOzexP qALtGKXxUXYlFpCKdIYGD2nBrQCJtlERIVsyOatocyS6tYBXjB2b2gg335u4P7oxLFzl7YHk6Lk2 0rydVRE71E4koxe8I4/Txaq1dvSYexbC515i33n0aCdNg69ODy0MXA+fxkfLDMWm9SXAXbp9s29g T7hSt2vrVyzn6hvHZHDlgZWL02q6yOfA2vmtczbGn8/fYs/K09oL+8XZlVlNt8zr4+zi0zxUpHb0 RRXP7x4kqrMxftrpRMXyyFDmRNsFQvBCatb2DPa5fiOjdWkNJ0pYnuCaXg62zo49g+u3s20B5Ors WWdBnR3dGWFYZmvBEcFSJEsFTcmoKQfZxMZ2t52YVWc0FIvz0NGcCGgMROmoYI/7r4yuHUwd1GFs MscrzYx05GxVL/vq1DQ7p+LSu6Wfon+Uj/BSJh2bG8rsn5QRL2L5dJoNDoVShXkWpXC6cgoAnlMR Mrv9Q1JdO1stQPd0sAtO7Y24BZfb5sUJP+5fyfGvz9g5NMKfmAq05mjpo6zLy5uQdIZGD2nHLa9M 2yS/0ZbCzso8YBndmu4V48emtoLth6peYGM2751pK+3bTZk5NaHaxYMcr7vRl959Uf9Ae+8+N3aM r7hiTrDFesyLiJQRZ+o03n9RkVemdjZoB7WnIxKj4QfZ+lcs3SC4Wo+7EhYLe/IoaGjUCQLlewfy qNmkplemH19AyMz3hZnL87Ex5/QoXs1aVzdbe5Al6JxqOF77ybm+rshknzcEi1w/kZdMtQN2shFa oLNbyWlnQSJVC44I1iLZa2mYxkc3btSbCNTWlebPyYfWE7NKjYZica4H5IgzOhHo7+/h+TB5wHbG 7hpoEBEzf3NsumtW3gLdfLDOujs7czauyN47/qyzLSccmeN5w+VuXpue47XLc0g3+McLixJ3hzId m4sdXL5hKVYCl/ewdeY76zieBehsVUQhwHMqQma3f0jqaWOrhehuRbmEREL49Y3Q+MiPyvWH/CCd GPPMwhhvrJQgf+sUKc4Bor4r3qHF+hO6wESFrXxUYilFJSCd4acvxnhIVXNBA0FRalS9HM+WKGfF yAGLmcfQqFc0jU1V5xaWXwtVFZdmV6eIiNl207mN9XGvLvv3ImXgq3v07Z307n5yXF5d5jGPPcZj cyMnuswWxJpLTX63xb04Laeppb5oJtpwHCd/ODtwazh66WD3vp76lTupgefr7FlnQcWtVmIVbsER IVaknMs3w6KMbOKkdk+cmFVoNAx8So2P6+LM3PQGC/cel3MBRlxi4S+jEjsZcfd8olYo5nZuIJC8 VbvPfcul3S0Oyq75/RbmDsZbM9M3tTe6BW6G+FssfvCPu7XJ7w75e6teJVYXS7zU/JU8/gWkBJ6p HVLWDLmBp1MkQozMbv9QqG1Xpg/Iu3MYo3tWnI3LJ95fMHXaeaOpU63wPt68k5+qqZg6vhnvvOnA ie7z+1RI3P5Rfm/qRMZ3sTZO9WJrEl07egc15mJqjD+RktEFxgudVGaxKluURjrDTx13ww2iHtIp Exd6LeDaJ/FtiXBWhgHL4NZiHbU/NuUdwe11a3RK96xPHBXGvNW10WKhvgIIiDZ1fqLLeCWKt4sv LF9dnI9cz9QrlXHa7iGtN0Uky/QHU9FlEu+cs+xHVvwC7Yrt1e54NQMTaRF9HbgrKicS4b2qeDUF mWBEQLqZcLTBuSvjMa3D4cvkfEKyvrCoJ7etyNDZbbJnmgXdO8vP84pYrSR1hsaPCEkSaROe4mfU MYsysonjnLz1xCywUktUvykJHjnz3PPPz/xbHoQzUeN3cgKeSDzs5/cM3TAYvvcm17FiBsDvn59h p8UdnnPsmeHFx2dDl0lcZbTs8pEsU75vw6mrz49ZUiVfXHHSiORk9sQy3VpkjZEyPc7iVdivjbrx M86VpPCeop1I8q3aq5qComKSZ9mtnAgnPfBEw9BbNgqc5ECWSVdENSLNlrBVmZk2trJboqDy9QZ1 244PPyfnZPl+aypDDT4MGQPfvVYRMVSZBYnbpGJIs/d7pXjhqrMHZzCSqNyajbkeKalAvyMkdsOA j2oSNL3aoDN0/kV/aM2tBZRpngj2AxZpS/HOKjpgqfHadQK0VyTGpjQjePNYpq9Z84Gt1r/SK7Ot c/B+tLgvckok7nHclBZ/fLz74pqfQA6I2rxR61z65IQaN8kyPUMaOs9vaBOS6I3DS+BxoPoE2CtT JlPDrqaR6Kf8Brj38RRn6uimFBfRb++j4rrDaprH8eicR3cO+kxezhmiagoC/Ia8/pIpVcL+euBh 2ErJhgvpzo+vZi93TouPK6lBOaRXWE26Jxg7u5Wc5CyImi/5NiNf265/B8pKzmqMCIallv0gZa+m YWpETDmctZv6F693U+1uPzGjVmrN87SvvvS5D374o6b6xeL88Mc/2TzxUDMIgEAGAtzHXdrpXcbL UACygAAIgAAIgEDVCfBlkrfSa7wugcV2mdWH1aS3MIqQgJxdiGUVU6drLf2ripwtDRHCNYBA/OI8 ENbeAGlQBQiAQBEE9k6c76kfUp9LcT7BUkSxKAMEQAAEQAAEqkKA3xuf896g1gShayPP8vcBl35T rHFq8ldnhz4nLL8XE/oQWhNIJ1ZZFTkTFUECEMDJOWwABEAABEAABEAABECgSgRUAHkfD5M2fUGt UdoYY9GLEMCgZjkn5/x8nn+JsIivJhehOsoAgbYlgLD2tm1aKAYCIAACIAACIAACIAACIAACIFAV Aghrr0pLQU4QAAEQAAEQAAEQAAEQAAEQAIFtSgB3zrdpw0NtEAABEAABEAABEAABEAABEACB1iGA xXnrtAUkAQEQAAEQAAEQAAEQAAEQAAEQ2KYEsDjfpg0PtUEABEAABEAABEAABEAABEAABFqHABbn rdMWkAQEQAAEQAAEQAAEQCA7Af56c/mR0Ucnl7MXInLyb5jbfamU15i3rnyS5sqtq8n/PjKzlas4 ZAYBEMhLQCzOdzlfaNy8NuJ4NOHXvM82in6rnh++lqXLOsUGPFeKMu2zUylJPmTt9g+ty/RGiAC6 FLpna117YmT5JEYDW/7VDWUbFt5cfoLSHcC8jI5pxQ9sVO1+CdpXvktnm61F8uQK9EqnE/lqajz9 JhBZZEr+qRWtR2uTDNoy84jZ/LzWdpvGSAJG6+oYelh5mOFebBgImDVhDiqNZ2i+7UCC9iCgDyul f3e6PZC1phaBkSvDonf3qfuvvDw71tsg7fiIcILVJ/qd6rQRgY+/2vykQeJ4E4BM9dVGRrunDmbs PmTD8YcuBDn4igaVXfWpq5tSxEwCo7Nnal5kqgoBsTgfunnJW3UPnedOTf5xvnO4NHloqls9vD64 eCito+Hd8ml2JuQl7csks29ee2ZtVAp54zirP6M2+ciUhsUnkZ0sk3xoXyaTI0REzlw8E+2qDOA0 W7FEme65oaxlZqQWL9ryxMFbPUPeYNk/6ZiZyF4fYn07jfmp2rmLP8kuqKrPsxPOutS+vRIxtkgC PmgN17vrHis5/OvdZ3z9ZMyW2d4JB+8ByWpytzsQ8pmEW+aLRxJarkVQxIthMPtczkdMIAJGq0SI PKS6eSWgCSFNvZgYCEiYxENjmZWBAkErSWBp0hsU+JiizWoqqc12F1qNWXzaGT/GtQCmrZnTF3su BD8M7vtPZ9htATmtRdh9Kk/3iWk4Z+ri7GL09rFbd7Kc96kJPzq7dYMiYRUJiMX5fO9gv2mCvrw4 3zv+hNwR3Lq7sMLmbqcLE+LLg8jsP0WZVHbWeWRGLTNYrbOHra49FH8lU5ItQma3f2hfZjBld5dg nEL3bOZUBnCS7dILF9nYmaQ1uaME96RrY2dGd1I6bV29NL//mHmJSNW+tbayf0DZAOsfGFpdWBY+ nmzEbBhbI9fydH31QGjUF7jcLsn4Jvf+lcW7mynE3bqzGCkzRfYWTUqaaM6+QBptnCULNqqbV+Zn 34utCTP7MiuDCYJWgUDHzt65aXUWJ8ZZ86ymCspARodA7SMDvSuvyTWcfiKtjtPF3mIwZMw9jCWn Gl4QqB+pFy1TluumPDS1ktQS965MseOjzmzEmFicHl+TwYPaiXFIKefoS0TIX/VEFQ8NahJlyqiu 4foqmz8ZDHeNRtvFqbn3CX7udWUpSfXYf9caTqW7d3Zs/fisF1/A2ODo4wsvRBcU8kg8KVwCnT1X 4yBz6xMQi3P92DPUpbc219R0k/uLg7cGx/az9U05+OX4FVimKMpbpKUXicxu/5CsMJjdCfLh6G7I jdUCdbdXt5RKtzbWewc77hKDTVQw6ZTPGZbfcir/pICT7ndzkQ9aAilfrEZy5jSMdJKUltrTQsVR qxHr4caKvgLc0dW3svHAXgSxxdbbs8M+Q3ultO8LpNEaLDnczSvDzNyLw3M7e5XSeAb7UpESBJII 8M3Z+6Mbw8JV3h5IDuZKKg7/3hIExA61E1jnxSjJ43Sxaq0dPeZuzfOpgNh3Hj3aSYvNV6eHFgau h0/jo2WGYtP6Eigs3b7ZN7AnXKnrP/Ubf3P1jWMy1u/AysVpNXvh82otis05c+LP52+xZ2XgwIX9 4jzMrKZb5vVxdvFpHgBbO/qiiud3j+7V2Rg/snaiTXmgInOi7QIheCE1a3sG+9wpVkYz0BpOlLA8 wTW9HGydHXsG129n2wJAZ8/YLMhWFQLyzrmz9SjM3Q/D1iLYHQ8yM9JRnFoFlMnjSyPRRCkEJLPb PyRrCmdXccX3XxldOxi88Ss8cqE8ExUvAHiojtWpaXZOGky9Ww4M9I9yyl7KpGNzQ5n9kzeOr52Q 69XTbHAolCqnYSSibHgCb8RteM3tWWFyXyCN1mjJdDevBjuiFxsHAluNLD2DbXFIBwI2BMTNVbXU ucDGbF6DYlMo0jSJwJwa33fxmLvrbvSld83YP9Deu8+NHeP7zjEn2GJX2gvQkxFn6jTefzuGV6YW 3mine09HJFzKD2v3b/y5QXC1HnclLBb25MnE0KgTk8j3DuRRs0lNr0w/voCQmW+YMpfnY2POYUa8 mrWubrb2IEvQOdVwvPaTc31dkQUEbwjmX6p1JJd3HrUDdrIR0NntbBOpKktA3jlfnQrFlohtM9kz Rdz4zbHprll5BX3zwTrr7uzMqWwhZYqzRHHnxN9rTCUVmd3+IVlXnEg89Lo0nomKFwKcqKV3/Fln H1SMHM5QF063eW16jpuQPPh1o628ODRxWSvTsbnYMuc7xGLj4/Iets780TGnYSTCbGQC0XDrG6Hx kR+V6w/5QTox5pml1G6CNFKVVqnLri+QRvvpizGWrPRzu3mraGsjR2wv9gYCm5L8NFaeIV2RSA0C CQS0Czvi0mxkVgOAlSLgXl3270XKK0Xu0bd30rv7yXF5dZmH4PUYj82NmtNltiCoXGrya4C9487r gcSsqdQXzUQbjuPkD2cHbg1HLx3s3tdTv3InNXB09tTIkKFiBMTifD3yOi5+i2ZFXdkS0003aEfe gN3X716AEZdY+MuoxA5W3D2fKBCqTCeV1W0TIYA4M7dcmUfKJLPbPxSi2pXpq+5dgYvRvTzLyQ2c EI1fKGLuns7WzPRN7Y1uATj+KZwfbeXuJQszi942t7MBVyT+Ejj/xlc6wygPeFEli+v0U6edN5o6 hYr1kjfv5Ge5KqaOb8Y7F++d6D7eT+lf/+hY79yJjO9iLUqx5pVj1QFJo/3UcTewKGrJrvuq2k3X mF4sVfIHAvsWSyrTviSkBIGUBNyzPnFUGPOS0ZSlInkrEBBt6vyEX/JEEm8XX1i+ujgfe8NRxmm7 h7TejIUs0x9Mxewi8c45y3jCzBXgF6dXbK92x6vpTs4llc6O7uD9UzmRCN/ujldTkAlGBKSbmEUt ho+qPMRyOHyZnE9I1hcW9eS2FaGzt0K3hAxlERCL8+7zaiPN/4LOifXxG84Kau+EeEm7F1+U9qRa 3cb0X1Ahe6axTHEjNPCjsovjVu4wvSgd/atRoYpEWeEyyez2D6V4VmXqH7LibzUvhmeiHZQA3FEk xLbzyBl+70sahnj/vL8XG2lEg8xygIzGdFnZgG+rw6+N3ncuMtGGkUislRPweGkxnrlxB3K6WRu5 fP6Ac6XNC/mrjTzL3+Ci+qm4Waf6qTIGHsamOot634wYI4ecWIbM30dsNWik2afrC1lV0j4e43fz rIU1Oh/Zi8mBwJ6w0TM0WjnUt60IBHxgYEjaVhjaVlkZi67GuOmucf0umzh9vTg3tM97c43yYMEZ ixg3e7QhUs5YyDJ9Q+KzC/4pmfifH3Cup/PvnMd9So2PxbNj6yquMPmjaxE1eYV6DLk/ORfH7M60 QX3MhU+53dma9+HbWDXlLQD3nbtKMRmNP5/xirgqwhEjeJjXeWS0Z2U1pdmis6cEhuSVI/DImeee P/zxT1ZObggMAtubAF8sXdrpXcbb3iygPQiAAAiAwDYlwM9am7gxKl41x1+3lvbgKn1bhdXkc4DF faXUS84u+MMxdj7xNnh6vZADBLYlgVdf+twHP/xRk+ri5Bw/EACBqhHYO+GdA8TtzVdNLcgLAiAA AiAAArYE+L3xOe8NaraZCkwnTnHXyr8p1jg1+UdJQl+3ld+LCX0IrUCCKAoEQCBMAItz2AQIVJOA fKmp/FP+nn01CUFqEAABEACBdiUgv1Le/EUjfz0t/0BA0qe5szdCQ9WUHyWRb4D2f+r9u6EPoWXX BzlBAASSCCCsPYkQ/h0EQAAEQAAEQKBdCLzlwcbbf2X+bfylV1/72puMPfLII6k0e/PNN0WGd77z m13df/GjQ290dKXKjsQgAAIgAALbnEB8WPtb9z0++H3/465tzgjqgwAIgAAIgAAItD2Bt7/863+p /i/eurb6yNe+9shffOORr38t/Z+vv+Ub33jk//6Tt65/6e2vLL/5nu96Y0fkG85tzxEKggAIgAAI ZCXw3x9+6Tt3fNCUG2HtWbkiHwiAAAiAAAiAQHUIvHVr81suf+bNb36Tfdu3v/mOd7z5trext789 wx+ekWfnhbBvfpMXyIutDgNICgIgAAIg0HwCH/grzPQHi/PmNw8kAAEQAAEQAAEQKJsAj2Z/5M/+ lEek89D0/HWJQt75Tl4gLzZ/aSgBBEAABEAABDgBLM5hBiAAAiAAAiAAAu1P4K2vrbFveSdLXJkn JvBQ8ZTf8k5RLH4gAAIgAAIgUAQBLM6LoIgyQAAEQAAEQAAEWpwAfwNczOvfXn+dqT9vvOH8hf89 aaEuCvza11pc720lnny9ufiT9w3q/Bvmdl8q5TXmrauJLaSryf8+MrPVRGFQNQiAgDo5v+Z1xOUJ 5dF26f7If/jorrNL6aFtXhuJeEnhC1RFh/3a6aLts1MpyTLJ2u0fWpfpjRABNVPonh62yGFPjCyf xGhg69mGhTeXn8p0BzDdqJIHUap20lZLZ5utRfLkcnQPTDV8NTWefhOILHKisDTp9LJwp6YtM4+Y Tc9rbvqA4XE50xhJOK9UM/Sw8jDDvThgcprPL8szNN12IECbECAHhZBuppU5X4Hzdfi3fivr72cf +xg7cYL9o3/EhodZR4ezUI9nlPJ9720CvCw1AiNXhkXv7lP8C6OzY71lyRcql48I/PNjE/3OY21E CM6lGySONwHIVF9tZLR76mCWqX54yuE2HG/NiXtKFjn4iueyqz51dVM+zSSwTWfPBACZQKAVCIjF +eIh2XN4tznJLqgvJ59nJ5y5/tKk9/Dl+tDNS0lr6ZBSvFs+zc6EvOTS5KGp7vOyouuDTu00DDL7 5rVn1kalnDeOs/ozapOPTEkWSma3f2hfJpMjREROW92zmUcZwGm2Yoky3XNDGczMSC1e3uWJg7d6 hrzB0v9GN89eH2J9O435qdppWyUbMRvGFsnFB63henfd/Z75fTn8691nfP1kzPbW3gnROhzvAdmv 1efQxUAoPmTqfCP9xSMJLdciKOLFMDd9yPAC9OKdj5hABIxWiRB5SHXzSkCTkyVDLx5S/pn/cT54 a3AshHs3llkZKBC0igToQcFOE35Ozv/s3cv+xb9gx469+QM/8OZ73vNmVxc7eJD93M+xj3+cvfvd YumOX+MIqDGLTxHjx7jGCWSsaWvm9MWeC8EPg/v+0xl2W0BOaxF2n8ow1fdKj2k4Z+ri7GL09rFb dzIe0efp7NYckBAEmkhALM5X2NxtvpW1tbayf0BO3xnrHxhaXVgW/aZjZ+/ctNrfWl6c7x3sTzeV 58uDyOxflDP+hNxl3Lq74NROM6Cys84jM2qZwWqdPWx17aH4K5mSLJTMbv/Qvsxgyu4uQS6F7tms ogzgJNulFy6ysTNJa3JHCb7FszZ2ZnQnpdPW1Uvz+4+Zl4hU7bStko2YDWNr5Fqerq8eCI36Apfb fRjf5N6/snhXdk/L39adxUiZlllbOJmp6SOGl6IDkkYbZ8mCj+rmlfnZ92LSCeT3DJUhBUFbnQA9 KFhIzc/M+Z9Dh/iB+Ztf/eo3z59//VOfev1nfub1kye/+VM/9frNm2zPHvYzP8O+8zuwPregWXSS 2kcGeldek2s4/URancqKvcVgyJh7GEtONbyATT8EPVqmLNdNeWhqJUmhe1em2PFRZ+ZsTCxOj6/J 4EHtxDiklHO8LCLkr3qiiocGNYkyZVTXcH2VzZ8MhqZGo+3i1Nz7BD/3upIhTlbTX2s49fTe2bH1 47NefAFjg6OPL7wg2zHwk0fiCeESmTt7Umvi30GgRQiIxfnYfra+uSkEurmogk/EAsARkM96749u DAufcnsg+YDUQq2tzTU1heU+6OCtQb92i7yhJKIob0OhoOxkmfYVBVM60VlczRtyY7VA3e3VLaXS rY313sGOu8RgExVMOuVzhuW3XB48KeCk+xG26hdg317pKm1sak8LFUetRqyHGyv6CnBHV9/KxgN7 ucR2WG/PDvsMVUupN33U8Oz7Amm0BksOd/PKMDP34vDczl6lNJ7BvlSkBIFkArGDgjE7PzPny+8f +7E3bt9+/ezZt3zxi2/7sz972xtvvO0b33jrl7/M/t2/48t19v73s49/gr31reKAHb9GEhA71E5g nRejJI/Txaq1dvSYe4zEZ1di33n0aCctHV+dHloYuB4+jY+WGYpN60tQdun2zb6BPeFKXf/5qLZ3 MFffOCbjUg+sXJxWM20+B9ai2JwzJ/58/hZ7VgYOXNgvTs7MarplXh9nF5/mYa21oy+qeH736F6d jfEjayfalEfSMSfaLhCCF1Kztmewz+1NGVtbazhRwvIE1/RysHV27Blcv511CyBbZ8+oDLKBQKMJ /P8BFl8PCBK7weoAAAAASUVORK5CYII= --0000000000000830be0573f23aa3-- From nobody Tue Aug 21 15:11:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAE7128CF3 for ; Tue, 21 Aug 2018 15:11:54 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKGQJNluXDP9 for ; Tue, 21 Aug 2018 15:11:53 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366B81277CC for ; Tue, 21 Aug 2018 15:11:53 -0700 (PDT) Received: from [67.219.250.102] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-a.us-west-2.aws.symcld.net id 00/23-20440-82E8C7B5; Tue, 21 Aug 2018 22:11:52 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRWlGSWpSXmKPExsWS8eIhk65GX02 0Qet1ZovWFe8ZHRg9Hj17wxzAGMWamZeUX5HAmtEwYy5TwWOritNXaxsYP1l2MXJxCAk8Z5TY dvoSYxcjJ5CzkFFi/VtOEJtNQFti38x/YHERAX2J2z9usYDYwgKGEicfL2KFiJtJdLU/gqrRk /h9fR6YzSKgKvH01hEmEJtXwFZi+fMLzCA2o4CsxLRH98HizALiEnOnzQKbIyEgILFkz3lmCF tU4uXjf6wQNQkSh8+vgpojKHFy5hOWCYz8s5C0z0JSNgtJ2SxGDqC4psT6XfoQJYoSU7ofskP YGhKtc+ZC2ZYSV27+ZkVWs4CRYxWjRVJRZnpGSW5iZo6uoYGBrqGhka6hkYWukZGhXmKVbqJe abFueWpxia6RXmJ5sV5xZW5yTopeXmrJJkZgbDAAwQ7Gby9SDjFKcjApifKeS6uOFuJLyk+pz EgszogvKs1JLT7EKMPBoSTBq91bEy0kWJSanlqRlpkDjFKYtAQHj5II74UeoDRvcUFibnFmOk TqFKM9x5F7UyYxc1wAk3/eTwWSd7qnTWIWYsnLz0uVEud9DdImANKWUZoHNxSWVC4xykoJ8zI CnSnEU5BalJtZgir/ilGcg1FJmDce5DaezLwSuN2vgM5iAjqLna0S5KySRISUVANjQ8cF52vv zSaxTfris2e+ZmX0sa4sCYEGg5q1k54Hzzscuje7mPuFLn/w/MPrr9UmCJ+yrORRm536/Oojd SY+06VBjy6sWPrQuWCFyjYVxWc+7rpvzU4t95j4fvJRkRPzr2yzc4iOqLq8WyE7QtHzxM1Tvx +JzL0RZBrEG7dQc6bfn+Z7O4/JK7EUZyQaajEXFScCAEFvOAElAwAA X-Env-Sender: changzhi2@lenovo.com X-Msg-Ref: server-37.tower-326.messagelabs.com!1534889510!2594846!1 X-Originating-IP: [104.232.225.2] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14991 invoked from network); 21 Aug 2018 22:11:51 -0000 Received: from unknown (HELO maesmtp01.lenovo.com) (104.232.225.2) by server-37.tower-326.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 21 Aug 2018 22:11:51 -0000 Received: from CNMAILEX01.lenovo.com (unknown [10.96.80.1]) by maesmtp01.lenovo.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3043_582f_058670b8_acd1_4b79_abc2_de22cf7b9985; Tue, 21 Aug 2018 22:11:48 +0000 Received: from CNMAILEX03.lenovo.com ([169.254.11.183]) by CNMAILEX01.lenovo.com ([169.254.9.235]) with mapi id 14.03.0389.001; Wed, 22 Aug 2018 06:11:46 +0800 From: Zhi Zhi2 Chang To: "quic@ietfa.amsl.com" Subject: Questions about QUIC Stream Multiplexing Thread-Topic: Questions about QUIC Stream Multiplexing Thread-Index: AdQ5m/Mnv3xyf6rhRc6H5t9bQ9bTdQ== Date: Tue, 21 Aug 2018 22:11:46 +0000 Message-ID: <33507A8C-A2C6-4211-96A1-7B88F8B00416@lenovo.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_33507A8CA2C6421196A17B88F8B00416lenovocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 22:11:55 -0000 --_000_33507A8CA2C6421196A17B88F8B00416lenovocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbA0KDQpJIGhhdmUgc29tZSB0aG91Z2h0IGFib3V0IFFVSUMgU3RyZWFtIE11bHRpcGxl eGluZy4gUGxlYXNlIGZlZWwgZnJlZSB0byBwb2ludCBvdXQgbXkgZXJyb3IuIDotKQ0KDQpJbiBI VFRQMiwgU3RyZWFtIE11bHRpcGxleGluZyBzdWZmZXJzIGZyb20gaGVhZC1vZi1saW5lIGJsb2Nr aW5nLiBUaGF0IG1lYW5zIGEgbG9zcyBvZiBhIFRDUCBzZWdtZW50IHJlc3VsdHMgaW4gYmxvY2tp bmcgb2YgYWxsIHN1YnNlcXVlbnQgc2VnbWVudHMgdW50aWwgYSByZXRyYW5zbWlzc2lvbiBhcnJp dmVzLg0KQmVjYXVzZSBIVFRQMiBTdHJlYW0gTXVsdGlwbGV4aW5nIGlzIGEgVENQIGNvbm5lY3Rp b24gYW5kIHRyYW5zZmVyIG1hbnkgSFRUUCByZXF1ZXN0cyBpbiB0aGlzIFRDUCBjb25uZWN0aW9u LiBUaGUgcmVzZXQgb2Ygc2VnbWVudHMgd2lsbCBiZSBibG9ja2VkIHdoZW4gYSBUQ1Agc2VnbWVu dCBpcyBsb3N0Lg0KDQpJbiBRVUlDLCB3ZSBkb24ndCBuZWVkIHRvIHdvcnJ5IGFib3V0IHRoZSBo ZWFkLW9mLWxpbmUgYmxvY2tpbmcuIEJlY2F1c2UgUVVJQyBpcyBiYXNlZCBVRFAgYW5kIFVEUCBp cyBhIGNvbm5lY3Rpb25sZXNzIHByb3RvY29sLg0KDQpJbiBhIFFVSUMgY29ubmVjdGlvbiwgd2Ug Y2FuIHNlbmQgbWFueSBIVFRQIHJlcXVlc3QgYW5kIG9uZSBIVFRQIHJlcXVlc3QgaXMgbmFtZWQg IiBTdHJlYW0gIi4gSWYgc29tZSBvZiBzZWdtZW50cyBpcyBsb3N0IGluIHRoaXMgIiBTdHJlYW0g Iiwgb3RoZXIgU3RyZWFtcyB3b24ndCBiZSBhZmZlY3RlZCBleHBlY3QgdGhpcyBvbmUuDQoNCklm IG15IHRob3VnaHQgd2FzIHJpZ2h0IEkgc3RpbGwgaGF2ZSBhIHByb2JsZW0uIElmIGEgc2VnbWVu dCBpcyBsb3N0IGluIG9uZSBTdHJlYW0sIGhvdyBkb2VzIFFVSUMgd2lsbCBoYW5kbGUgdGhlIHJl c3Qgb2Ygc2VnbWVudHM/IFN0b3JlIHRoZSByZXNldCBvZiBzZWdtZW50cyBpbiBtZW1vcnkgPw0K SWYgc28sIGNhbiB3ZSBzZW5kIG1hbnkgIiBsYWNrIG9mIG9uZSBzZWdtZW50IHN0cmVhbSIgdG8g UVVJQyBzZXJ2ZXIgaW4gb3JkZXIgdG8gd2FzdGUgc2VydmVyJ3MgbWVtb3J5IHVudGlsIHJ1biBv dXQgb2Ygc2VydmVyJ3MgbWVtb3J5Pw0KDQoNClRoYW5rcw0KWmhpIENoYW5nDQo= --_000_33507A8CA2C6421196A17B88F8B00416lenovocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5F777BF6909E5045AAF7B5C121AB2B18@lenovo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29s b3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwg MjU1LCAwKTsiPkhpLCBhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1 NSwgMjU1LCAwKTsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjogc3RhcnQ7IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAw KTsiPkkgaGF2ZSBzb21lIHRob3VnaHQgYWJvdXQgUVVJQyBTdHJlYW0gTXVsdGlwbGV4aW5nLiBQ bGVhc2UgZmVlbCBmcmVlIHRvIHBvaW50IG91dCBteSBlcnJvci4gOi0pPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyBt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImJhY2tn cm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4mbmJzcDs8L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyBtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImJhY2tncm91bmQtY29s b3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5JbiBIVFRQMiwgU3RyZWFtIE11bHRpcGxleGlu ZyBzdWZmZXJzIGZyb20gaGVhZC1vZi1saW5lIGJsb2NraW5nLiBUaGF0IG1lYW5zIGEgbG9zcyBv ZiBhIFRDUCBzZWdtZW50IHJlc3VsdHMgaW4gYmxvY2tpbmcNCiBvZiBhbGwgc3Vic2VxdWVudCBz ZWdtZW50cyB1bnRpbCBhIHJldHJhbnNtaXNzaW9uIGFycml2ZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyBtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImJhY2tncm91 bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5CZWNhdXNlIEhUVFAyIFN0cmVhbSBN dWx0aXBsZXhpbmcgaXMgYSBUQ1AgY29ubmVjdGlvbiBhbmQgdHJhbnNmZXIgbWFueSBIVFRQIHJl cXVlc3RzIGluIHRoaXMgVENQIGNvbm5lY3Rpb24uIFRoZQ0KIHJlc2V0IG9mIHNlZ21lbnRzIHdp bGwgYmUgYmxvY2tlZCB3aGVuIGEgVENQIHNlZ21lbnQgaXMgbG9zdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IG1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iYmFja2dy b3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IG1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkluIFFVSUMsIHdlIGRvbid0IG5lZWQgdG8gd29y cnkgYWJvdXQgdGhlIGhlYWQtb2YtbGluZSBibG9ja2luZy4gQmVjYXVzZSBRVUlDIGlzIGJhc2Vk IFVEUCBhbmQgVURQIGlzIGEgY29ubmVjdGlvbmxlc3MNCiBwcm90b2NvbC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7 IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPiZuYnNwOzwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IG1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iYmFja2dyb3VuZC1j b2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkluIGEgUVVJQyBjb25uZWN0aW9uLCB3ZSBj YW4gc2VuZCBtYW55IEhUVFAgcmVxdWVzdCBhbmQgb25lIEhUVFAgcmVxdWVzdCBpcyBuYW1lZCAm cXVvdDsgU3RyZWFtICZxdW90Oy4gSWYgc29tZSBvZiBzZWdtZW50cw0KIGlzIGxvc3QgaW4gdGhp cyAmcXVvdDsgU3RyZWFtICZxdW90Oywgb3RoZXIgU3RyZWFtcyB3b24ndCBiZSBhZmZlY3RlZCBl eHBlY3QgdGhpcyBvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUs IDI1NSwgMCk7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYWxpZ246IHN0YXJ0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7 Ij5JZiBteSB0aG91Z2h0IHdhcyByaWdodCBJIHN0aWxsIGhhdmUgYSBwcm9ibGVtLiBJZiBhIHNl Z21lbnQgaXMgbG9zdCBpbiBvbmUgU3RyZWFtLCBob3cgZG9lcyBRVUlDIHdpbGwgaGFuZGxlIHRo ZQ0KIHJlc3Qgb2Ygc2VnbWVudHM/IFN0b3JlIHRoZSByZXNldCBvZiBzZWdtZW50cyBpbiBtZW1v cnkgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOiBzdGFydDsgbWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+ SWYgc28sIGNhbiB3ZSBzZW5kIG1hbnkgJnF1b3Q7IGxhY2sgb2Ygb25lIHNlZ21lbnQgc3RyZWFt JnF1b3Q7IHRvIFFVSUMgc2VydmVyIGluIG9yZGVyIHRvIHdhc3RlIHNlcnZlcidzIG1lbW9yeSB1 bnRpbCBydW4gb3V0DQogb2Ygc2VydmVyJ3MgbWVtb3J5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgbWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJiYWNrZ3JvdW5kLWNv bG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgbWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2Jh KDI1NSwgMjU1LCAyNTUsIDApOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgbWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1 LCAyNTUsIDApOyI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAy NTUsIDI1NSwgMCk7Ij5aaGkgQ2hhbmc8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_33507A8CA2C6421196A17B88F8B00416lenovocom_-- From nobody Tue Aug 21 17:55:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B78E130DCC for ; Tue, 21 Aug 2018 17:55:26 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZaSxjPMCOe8 for ; Tue, 21 Aug 2018 17:55:24 -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 444B5130DC1 for ; Tue, 21 Aug 2018 17:55:24 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id j192-v6so204759wmj.1 for ; Tue, 21 Aug 2018 17:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=q/YQlCeRoa5tj6BPb2IwE+86MJMWzqvm5kqLKr+BS5o=; b=BpngGTjxdWWFhKFE0QAREd2qn2fpmsNDQt9eDyC+R6VMNntzc6g72wuibGGEo/3TW5 2dBfk5d1RrEAPfoQ6GY3p1VMamb0KgIYkoNbmwIz7D4HMNHuCwkXB4hrScGvy6OTml5Y Tu7dKwUVZBdOPibzyEtHm/6d3bQLFHSGxwnvVYbEePUH75qF8bkrra8eeyI27ELQLO+N 9MFVWjuZf5YkS2tNhTxi+Rf00t90LEZ6OnKEON/Z4RCSWZlnhGBkVoXjJzmpEhYoSdHz VB/YpOgo3/8OYMjdsFv4PNrDLP7FWPztUb1Q24n3psSY9zJv7AB2jDS3FxmftcQx1rTU T9/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=q/YQlCeRoa5tj6BPb2IwE+86MJMWzqvm5kqLKr+BS5o=; b=sc0rQJhJc44J1mOSZj1RVWnt0SRqLOXZDXJdATV/RGjy0vhYsOdihYzQvRoARLrPjY PhAcESmrGH5Zylbmlhvm4yVPQXG8kO+swnTXlrIQPOmEhrZsPbeZLvdEaMa4m6Jid6/p X/Q9Eu4wCACDI4b9RId+OPyIjOW6PrsNhXd3cNVrNDpjLKLHhNi7/iaZXHAB2AoZ8/2T m44x0d+xR8qcZUalodrjJnvWEqTzyBjDPLJ8viOraAkD2etmcjhFTh0578mtVzOjA9gG 67Jxrsr45G/cJBq+6ofgnqHQiVi3mOCVdPGtWDv0tX0j2od3Tae41oI+cG8tRQqx1f+3 kzSA== X-Gm-Message-State: APzg51BqdItF/TnMZqXx9MPpIUi+FbYXxu5wLCIW31Niw4Y1pwu2GKOc kA2Lg9syPh4aWA/br/IMoyQ= X-Google-Smtp-Source: ANB0VdYHM6vcK8zVto52AOnGB1W0VuDLw0i36z1tvtAiQpARYl7RPAOMN/yZ5MiQSILR9tdac1NWPQ== X-Received: by 2002:a1c:497:: with SMTP id 145-v6mr960362wme.157.1534899322622; Tue, 21 Aug 2018 17:55:22 -0700 (PDT) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id n5-v6sm384365wmh.1.2018.08.21.17.55.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 17:55:21 -0700 (PDT) From: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Zhi Zhi2 Chang , "quic@ietfa.amsl.com" Subject: Re: Questions about QUIC Stream Multiplexing Thread-Topic: Questions about QUIC Stream Multiplexing Thread-Index: ATZGQTRDGauyT4Qg6CqKd80/DO1WVLvm4y0n X-MS-Exchange-MessageSentRepresentingType: 2 Date: Wed, 22 Aug 2018 00:55:18 +0000 Message-ID: References: <33507A8C-A2C6-4211-96A1-7B88F8B00416@lenovo.com> In-Reply-To: <33507A8C-A2C6-4211-96A1-7B88F8B00416@lenovo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1766EF4A9DA0A2B47E863D89AC300DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 00:55:27 -0000 --_000_DB6PR10MB1766EF4A9DA0A2B47E863D89AC300DB6PR10MB1766EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No. There are several stream types and each has a maximum that is raised wh= en an endpoint is ready for more open streams. ________________________________ From: QUIC on behalf of Zhi Zhi2 Chang Sent: Wednesday, August 22, 2018 12:11:46 AM To: quic@ietfa.amsl.com Subject: Questions about QUIC Stream Multiplexing Hi, all I have some thought about QUIC Stream Multiplexing. Please feel free to poi= nt out my error. :-) In HTTP2, Stream Multiplexing suffers from head-of-line blocking. That mean= s a loss of a TCP segment results in blocking of all subsequent segments un= til a retransmission arrives. Because HTTP2 Stream Multiplexing is a TCP connection and transfer many HTT= P requests in this TCP connection. The reset of segments will be blocked wh= en a TCP segment is lost. In QUIC, we don't need to worry about the head-of-line blocking. Because QU= IC is based UDP and UDP is a connectionless protocol. In a QUIC connection, we can send many HTTP request and one HTTP request is= named " Stream ". If some of segments is lost in this " Stream ", other St= reams won't be affected expect this one. If my thought was right I still have a problem. If a segment is lost in one= Stream, how does QUIC will handle the rest of segments? Store the reset of= segments in memory ? If so, can we send many " lack of one segment stream" to QUIC server in ord= er to waste server's memory until run out of server's memory? Thanks Zhi Chang --_000_DB6PR10MB1766EF4A9DA0A2B47E863D89AC300DB6PR10MB1766EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No. There are several stream types and each ha= s a maximum that is raised when an endpoint is ready for more open streams.=

From: QUIC <quic-bounces= @ietf.org> on behalf of Zhi Zhi2 Chang <changzhi2@lenovo.com>
Sent: Wednesday, August 22, 2018 12:11:46 AM
To: quic@ietfa.amsl.com
Subject: Questions about QUIC Stream Multiplexing
 

= Hi, all=

=  <= /span>

= I have = some thought about QUIC Stream Multiplexing. Please feel free to point out = my error. :-)

=  <= /span>

= In HTTP= 2, Stream Multiplexing suffers from head-of-line blocking. That means a los= s of a TCP segment results in blocking of all subsequent segments until a retransmission arrives.

= Because= HTTP2 Stream Multiplexing is a TCP connection and transfer many HTTP reque= sts in this TCP connection. The reset of segments will be blocked when a TCP segment is lost.

=  <= /span>

= In QUIC= , we don't need to worry about the head-of-line blocking. Because QUIC is b= ased UDP and UDP is a connectionless protocol.

=  <= /span>

= In a QU= IC connection, we can send many HTTP request and one HTTP request is named = " Stream ". If some of segments is lost in this " Stream ", other Streams won't be affected expect this = one.

=  <= /span>

= If my t= hought was right I still have a problem. If a segment is lost in one Stream= , how does QUIC will handle the rest of segments? Store the reset of segments in memory ?

= If so, = can we send many " lack of one segment stream" to QUIC server in = order to waste server's memory until run out of server's memory?

=  <= /span>

=  <= /span>

= Thanks<= /span>

= Zhi Cha= ng

--_000_DB6PR10MB1766EF4A9DA0A2B47E863D89AC300DB6PR10MB1766EURP_-- From nobody Tue Aug 21 20:10:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA23128CB7 for ; Tue, 21 Aug 2018 20:10:42 -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_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jey85cYuINb5 for ; Tue, 21 Aug 2018 20:10:40 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832DE1277D2 for ; Tue, 21 Aug 2018 20:10:40 -0700 (PDT) Received: from [67.219.251.54] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-c.us-west-2.aws.symcld.net id 58/CD-11873-F24DC7B5; Wed, 22 Aug 2018 03:10:39 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIKsWRWlGSWpSXmKPExsWS8eIhk67+lZp ogwnzBSx+3tvJatG64j2jA5PHgk2lHo+evWEOYIpizcxLyq9IYM2YeP8ha8GcW4wVa6+dZW9g XHKdsYuRi0NI4DmjxKvfjWwQzkJGiQmPb7J2MXJysAloS+yb+Y8RxBYRUJY4emcSmM0soC+x+ cROMFtYwFVi7ewNQM0cQDVuEjdaQiHKjSRWNnUxgdgsAqoSv1++YwexeQV8JF79OwsWFxI4yy RxszMGxOYUCJT4uuwkG4jNKCArMe3RfSaIVeISc6fNAjtHQkBAYsme88wQtqjEy8f/WEHWSgj IS2yZJQhRnidx++omRohVghInZz5hmcAoPAvJpFlIymYhKZsFNIlZQFNi/S59iBJFiSndD9kh bA2J1jlz2ZHFFzCyr2K0SCrKTM8oyU3MzNE1NDDQNTQ00jU0tgBiY73EKt1kvdJi3fLU4hJdI 73E8mK94src5JwUvbzUkk2MwMhjAIIdjM8PpRxilORgUhLlPZdWHS3El5SfUpmRWJwRX1Sak1 p8iFGGg0NJgnfx5ZpoIcGi1PTUirTMHGAKgElLcPAoifAKXQJK8xYXJOYWZ6ZDpE4x2nMcuTd lEjPHBTD55/1UIHmne9okZiGWvPy8VClx3p0gUwVA2jJK8+CGwlLWJUZZKWFeRqAzhXgKUoty M0tQ5V8xinMwKgnzXgWZwpOZVwK3+xXQWUxAZ7GzVYKcVZKIkJJqYBQzUy/14q9YZ+TOe91pZ lYin/+tL8Gh9taHkngdH06673PAZmXOzM9/nux//9Jx+RRW++jFD2JOCfd+3vRgem15ymEeo6 5HsdPOvnrKsTQ11/Ym98rqyzxz9tUUzNwW55yyT/7u17DoNIEiq+3PTcrWrXnQLlZ06WjPiux Vv75tPJhbWfrJvU+JpTgj0VCLuag4EQAQOnBVVAMAAA== X-Env-Sender: changzhi2@lenovo.com X-Msg-Ref: server-14.tower-366.messagelabs.com!1534907437!2364868!1 X-Originating-IP: [104.232.225.2] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6432 invoked from network); 22 Aug 2018 03:10:38 -0000 Received: from unknown (HELO maesmtp01.lenovo.com) (104.232.225.2) by server-14.tower-366.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 22 Aug 2018 03:10:38 -0000 Received: from CNMAILEX01.lenovo.com (unknown [10.96.80.1]) by maesmtp01.lenovo.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 44d9_29b9_992475e9_5513_43fc_aa77_d24219781007; Wed, 22 Aug 2018 03:10:35 +0000 Received: from CNMAILEX03.lenovo.com ([169.254.11.183]) by CNMAILEX01.lenovo.com ([169.254.9.235]) with mapi id 14.03.0389.001; Wed, 22 Aug 2018 11:08:53 +0800 From: Zhi Zhi2 Chang To: Ian Swett CC: "quic@ietfa.amsl.com" Subject: RE: [External] Re: Same packet number in a QUIC connection ? Thread-Topic: [External] Re: Same packet number in a QUIC connection ? Thread-Index: AQHUOVUlWx1XmSO7FU2HB8NcdLPxB6TLFtbg Date: Wed, 22 Aug 2018 03:08:52 +0000 Message-ID: <7335E3E9AC2DE240988251CF62CAE90A0A237148@CNMAILEX03.lenovo.com> References: <7335E3E9AC2DE240988251CF62CAE90A0A236086@CNMAILEX03.lenovo.com> <5DFAC0AB-2135-4792-A3A3-54D7D35B942A@lenovo.com> <7335E3E9AC2DE240988251CF62CAE90A0A236CE0@CNMAILEX03.lenovo.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.19.89] Content-Type: multipart/alternative; boundary="_000_7335E3E9AC2DE240988251CF62CAE90A0A237148CNMAILEX03lenov_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 03:10:43 -0000 --_000_7335E3E9AC2DE240988251CF62CAE90A0A237148CNMAILEX03lenov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIElhbi4NCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBJcyB0aGVyZSBhbnkgZGlmZmVyZW5j ZXMgYmV0d2VlbiBRVUlDIGFuZCBHUVVJQz8NCg0KSSBjYW4ndCBmaW5kIGFueSBvZmZpY2lhbCBk b2N1bWVudCBhYm91dCB0aGF0IGV4cGVjdCBhdCBoZXJlWzFdLg0KDQoNClRoYW5rcw0KWmhpIENo YW5nDQoNCg0KWzFdOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3F1aWMv Y3VycmVudC9tc2cwMjAwOS5odG1sDQoNCkZyb206IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0 QGdvb2dsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjEsIDIwMTggOTo0NCBQTQ0KVG86 IFpoaSBaaGkyIENoYW5nDQpDYzogcXVpY0BpZXRmYS5hbXNsLmNvbQ0KU3ViamVjdDogUmU6IFtF eHRlcm5hbF0gUmU6IFNhbWUgcGFja2V0IG51bWJlciBpbiBhIFFVSUMgY29ubmVjdGlvbiA/DQoN ClRoZSBDSUQgZnJvbSBzZXJ2ZXIgdG8gY2xpZW50IGlzIG9ubHkgZHJvcHBlZCBhZnRlciBoYW5k c2hha2UgY29tcGxldGlvbiBpbiB0aGUgY3VycmVudCBnUVVJQyBpbXBsZW1lbnRhdGlvbi4NCg0K T24gTW9uLCBBdWcgMjAsIDIwMTggYXQgOToxNSBQTSBaaGkgWmhpMiBDaGFuZyA8Y2hhbmd6aGky QGxlbm92by5jb208bWFpbHRvOmNoYW5nemhpMkBsZW5vdm8uY29tPj4gd3JvdGU6DQpIaSwgSWFu Lg0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgc3RpbGwgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0 IHRoYXQuDQoNCkluIFdpcmVTaGFyaywgSSBzdGlsbCBmaW5kIHRoZSBzZXJ2ZXIgdG8gY2xpZW50 IHBhY2tldCBoYXZlIGEgQ0lELiBMaWtlIHRoaXM6DQpbY2lkOmltYWdlMDAxLnBuZ0AwMUQ0Mzky Ri43RkE3REE2MF0NCg0KVGhpcyBpcyByZWplY3Rpb24gcGFja2V0IHdoaWNoIGlzIHNlcnZlciB0 byBjbGllbnQuDQoNCldoeSB0aGlzIHNlcnZlciB0byBjbGllbnQgcGFja2V0IGhhcyBhIENJRD8g QmVjYXVzZSB0aGlzIGlzIGEgc2VydmVyIHRvIGNsaWVudCByZWplY3Rpb24gcGFja2V0ID8NCg0K DQpUaGFua3MNClpoaSBDaGFuZw0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSWFuIFN3 ZXR0DQpTZW50OiBNb25kYXksIEF1Z3VzdCAyMCwgMjAxOCA3OjMwIFBNDQpUbzogWmhpIFpoaTIg Q2hhbmcNCkNjOiBxdWljQGlldGZhLmFtc2wuY29tPG1haWx0bzpxdWljQGlldGZhLmFtc2wuY29t Pg0KU3ViamVjdDogW0V4dGVybmFsXSBSZTogU2FtZSBwYWNrZXQgbnVtYmVyIGluIGEgUVVJQyBj b25uZWN0aW9uID8NCg0KWWVzLCB0aGUgY2xpZW50IHRvIHNlcnZlciBwYWNrZXRzIGhhdmUgYSBD SUQsIGFuZCB0aGUgc2VydmVyIHRvIGNsaWVudCBwYWNrZXRzIGRvIG5vdCBoYXZlIG9uZS4NCg0K Qm90aCBjbGllbnQgYW5kIHNlcnZlciBzZW5kIHRoZWlyIG93biBwYWNrZXRzIG51bWJlcmVkIDEs IDIsIDMsIGV0Yywgc28gc2VlaW5nIHR3byBwYWNrZXRzIHdpdGggdGhlIHNhbWUgbnVtYmVyIGlz IG5vcm1hbCBhcyBsb25nIGFzIHRoZXkncmUgZ29pbmcgaW4gb3Bwb3NpdGUgZGlyZWN0aW9ucy4N Cg0KV2lyZXNoYXJrIHZlcnkgaGVscGZ1bGx5IHBhcnNlcyB0aGUgZmxhZyBpbmRpY2F0aW5nIHdo ZXRoZXIgQ0lEIGlzIHByZXNlbnQsIGFuZCBpZiBzbyBkaXNwbGF5cyBpdC4NCg0KT24gRnJpLCBB dWcgMTcsIDIwMTggYXQgNzoxNyBQTSBaaGkgWmhpMiBDaGFuZyA8Y2hhbmd6aGkyQGxlbm92by5j b208bWFpbHRvOmNoYW5nemhpMkBsZW5vdm8uY29tPj4gd3JvdGU6DQpIaSwgSSBoYXZlIGEgcXVl c3Rpb24gYWJvdXQgIiBwYWNrZXQgbnVtYmVyICIuDQoNCkkgc2V0IHVwIGFuIGVudmlyb25tZW50 IGFib3V0IFFVSUMgYW5kIEkgY2FwdHVyZSBzb21lIFFVSUMgcGFja2V0cyBieSB3aXJlc2hhcmsu IEkgZmluZCBhbiBpbnN0ZXJlc3RpbmcgcGhlbm9tZW5vbiBieSB3YXRjaGluZyB0aGVzZSBwYWNr ZXRzLiBQbGVhc2Ugd2F0Y2ggdGhpcyBwaWN0dXJlOg0K6ZSZ6K+vIeacquaMh+WumuaWh+S7tuWQ jeOAgg0KDQpJbiBteSBlbnZpcm9ubWVudCwgdGhlIHNlcnZlciBpcyAxMC4xMjEuMjIyLjIzMCBh bmQgdGhlIGNsaWVudCBpcyAxMC4xMTYuNDcuMTkyLiBXaHkgdGhlcmUgYXJlIHR3byBpZGVudGlj YWwgcGFja2V0IHdoaWNoIHRoZSBQS04gKCBwYWNrZXQgbnVtYmVyICkgaXMgdGhlIHNhbWUgPyBK dXN0IGxpa2UgdHdvICIgUEtOOiAyICIgcGFja2V0cywgdHdvICIgUEtOOiAzICIgcGFja2V0cy4N Cg0KQWZ0ZXIgbXkgY29uc2lkZXJhdGlvbiwgSSBmaW5kIHRoYXQgdGhlIHBhY2tldCB3aGljaCBj bGllbnQgdG8gc2VydmVyIGhhcyAiIENJRCAiIGFuZCB0aGUgcGFja2V0IHdoaWNoIHNlcnZlciB0 byBjbGllbnQgaGFzIG5vICIgQ0lEICIsIGZvciBleGFtcGxlICAiIFBLTjogMiAiLg0KDQpUaGlz IGlzIGEgcGFpciBvZiBwYWNrZXRzIHdoaWNoIGNsaWVudCB0byBzZXJ2ZXIoIFBLTjogMiApIGFu ZCBzZXJ2ZXIgdG8gY2xpZW50ICggUEtOOiAyICksIGlzbid0IHJpZ2h0PyBBbmQgdGhlIHBhY2tl dCBjbGllbnQgdG8gc2VydmVyIGhhcyBDSUQgYW5kIHRoZSBzZXJ2ZXIgdG8gY2xpZW50IHBhY2tl dCBoYXMgbm8gQ0lEID8NCg0KQW0gSSByaWdodCA/DQoNCg0KSG9wZSBmb3IgcmVwbHkuDQoNCg0K VGhhbmtzDQpaaGkgQ2hhbmcNCg0KDQo= --_000_7335E3E9AC2DE240988251CF62CAE90A0A237148CNMAILEX03lenov_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrnrYnnur87DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOetiee6 vyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlVJQ1RGb250VGV4dFN0eWxlQm9keTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAg MCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buROw0KCXBhbm9zZS0x OjIgMTEgNSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5b6u 6L2v6ZuF6buRIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTrnrYnnur87DQoJY29sb3I6 IzQ0NTQ2QTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseTrnrYnnur87fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPkhpLCBJYW4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj5UaGFua3MgZm9yIHlvdXIgcmVwbHkuIElz IHRoZXJlIGFueSBkaWZmZXJlbmNlcyBiZXR3ZWVuIFFVSUMgYW5kIEdRVUlDPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+SSBjYW4ndCBmaW5kIGFueSBvZmZp Y2lhbCBkb2N1bWVudCBhYm91dCB0aGF0IGV4cGVjdCBhdCBoZXJlWzFdLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj5aaGkgQ2hhbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNDQ1NDZBIj5bMV06IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvcXVpYy9jdXJyZW50L21zZzAyMDA5Lmh0bWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdv b2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDIxLCAyMDE4IDk6 NDQgUE08YnI+DQo8Yj5Ubzo8L2I+IFpoaSBaaGkyIENoYW5nPGJyPg0KPGI+Q2M6PC9iPiBxdWlj QGlldGZhLmFtc2wuY29tPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRXh0ZXJuYWxdIFJlOiBT YW1lIHBhY2tldCBudW1iZXIgaW4gYSBRVUlDIGNvbm5lY3Rpb24gPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoZSBDSUQgZnJvbSBzZXJ2ZXIgdG8gY2xpZW50IGlzIG9ubHkgZHJvcHBlZCBh ZnRlciBoYW5kc2hha2UgY29tcGxldGlvbiBpbiB0aGUgY3VycmVudCBnUVVJQyBpbXBsZW1lbnRh dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBNb24sIEF1 ZyAyMCwgMjAxOCBhdCA5OjE1IFBNIFpoaSBaaGkyIENoYW5nICZsdDs8YSBocmVmPSJtYWlsdG86 Y2hhbmd6aGkyQGxlbm92by5jb20iPmNoYW5nemhpMkBsZW5vdm8uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6IzQ0NTQ2QSI+SGksIElhbi48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5Ouetiee6vztjb2xvcjojNDQ1NDZBIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6 vztjb2xvcjojNDQ1NDZBIj5UaGFua3MgZm9yIHlvdXIgcmVwbHkuIEkgc3RpbGwgaGF2ZSBhIHF1 ZXN0aW9uIGFib3V0IHRoYXQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6IzQ0NTQ2QSI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6IzQ0NTQ2QSI+SW4gV2lyZVNoYXJrLCBJIHN0 aWxsIGZpbmQgdGhlIHNlcnZlciB0byBjbGllbnQgcGFja2V0IGhhdmUgYSBDSUQuIExpa2UgdGhp czo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjxpbWcgYm9yZGVyPSIwIiB3aWR0 aD0iMTMzMiIgaGVpZ2h0PSIzMzMiIGlkPSJtXy0xNzM5NjUwMTIzMDQ3MDU3MDk15Zu+54mHX3gw MDIwXzEiIHNyYz0iY2lkOmltYWdlMDAxLnBuZ0AwMUQ0MzkyRi43RkE3REE2MCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPlRoaXMgaXMgcmVqZWN0 aW9uIHBhY2tldCB3aGljaCBpcyBzZXJ2ZXIgdG8gY2xpZW50Lg0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnn ur87Y29sb3I6IzQ0NTQ2QSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6IzQ0NTQ2 QSI+V2h5IHRoaXMgc2VydmVyIHRvIGNsaWVudCBwYWNrZXQgaGFzIGEgQ0lEPyBCZWNhdXNlIHRo aXMgaXMgYSBzZXJ2ZXIgdG8gY2xpZW50IHJlamVjdGlvbiBwYWNrZXQgPzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 562J57q/O2NvbG9yOiM0NDU0NkEiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0 NDU0NkEiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPlRoYW5rczwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPlpoaSBDaGFuZzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 562J57q/O2NvbG9yOiM0NDU0NkEiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBRVUlDDQogW21haWx0bzo8YSBocmVmPSJt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgQXVndXN0IDIwLCAyMDE4IDc6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IFpo aSBaaGkyIENoYW5nPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmYS5h bXNsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0ZmEuYW1zbC5jb208L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtFeHRlcm5hbF0gUmU6IFNhbWUgcGFja2V0IG51bWJlciBpbiBhIFFVSUMg Y29ubmVjdGlvbiA/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+WWVzLCB0aGUgY2xpZW50IHRvIHNlcnZlciBwYWNrZXRzIGhhdmUgYSBDSUQs IGFuZCB0aGUgc2VydmVyIHRvIGNsaWVudCBwYWNrZXRzIGRvIG5vdCBoYXZlIG9uZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Qm90aCBjbGllbnQgYW5kIHNl cnZlciBzZW5kIHRoZWlyIG93biBwYWNrZXRzIG51bWJlcmVkIDEsIDIsIDMsIGV0Yywgc28gc2Vl aW5nIHR3byBwYWNrZXRzIHdpdGggdGhlIHNhbWUgbnVtYmVyIGlzIG5vcm1hbCBhcyBsb25nIGFz IHRoZXkncmUgZ29pbmcgaW4gb3Bwb3NpdGUNCiBkaXJlY3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPldpcmVzaGFyayB2ZXJ5IGhlbHBm dWxseSBwYXJzZXMgdGhlIGZsYWcgaW5kaWNhdGluZyB3aGV0aGVyIENJRCBpcyBwcmVzZW50LCBh bmQgaWYgc28gZGlzcGxheXMgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+T24gRnJpLCBBdWcgMTcsIDIwMTggYXQgNzoxNyBQTSBaaGkgWmhp MiBDaGFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoYW5nemhpMkBsZW5vdm8uY29tIiB0YXJnZXQ9 Il9ibGFuayI+Y2hhbmd6aGkyQGxlbm92by5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRU ZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IaSwgSSBoYXZlIGEgcXVlc3Rp b24gYWJvdXQgJnF1b3Q7IHBhY2tldCBudW1iZXIgJnF1b3Q7Ljwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQt YWxpZ246c3RhcnQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO3RleHQtYWxpZ246c3RhcnQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtVSUNURm9udFRleHRTdHlsZUJvZHkmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPkkgc2V0IHVwIGFuIGVudmlyb25tZW50IGFib3V0IFFVSUMgYW5kIEkgY2FwdHVy ZSBzb21lIFFVSUMgcGFja2V0cyBieSB3aXJlc2hhcmsuIEkgZmluZCBhbiBpbnN0ZXJlc3Rpbmcg cGhlbm9tZW5vbiBieSB3YXRjaGluZyB0aGVzZSBwYWNrZXRzLiBQbGVhc2Ugd2F0Y2ggdGhpcyBw aWN0dXJlOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+6ZSZ6K+vPHNwYW4gbGFuZz0iRU4tVVMi PiE8L3NwYW4+5pyq5oyH5a6a5paH5Lu25ZCN44CCPC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFs aWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5JbiBteSBlbnZpcm9ubWVudCwgdGhlIHNlcnZlciBpcyAxMC4xMjEuMjIyLjIzMCBh bmQgdGhlIGNsaWVudCBpcyAxMC4xMTYuNDcuMTkyLiBXaHkgdGhlcmUgYXJlIHR3byBpZGVudGlj YWwgcGFja2V0IHdoaWNoIHRoZSBQS04gKCBwYWNrZXQgbnVtYmVyICkgaXMgdGhlIHNhbWUgPyBK dXN0IGxpa2UgdHdvICZxdW90OyBQS046IDIgJnF1b3Q7DQogcGFja2V0cywgdHdvICZxdW90OyBQ S046IDMgJnF1b3Q7IHBhY2tldHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpzdGFydCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0 eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4 dC1hbGlnbjpzdGFydCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QWZ0ZXIg bXkgY29uc2lkZXJhdGlvbiwgSSBmaW5kIHRoYXQgdGhlIHBhY2tldCB3aGljaCBjbGllbnQgdG8g c2VydmVyIGhhcyAmcXVvdDsgQ0lEICZxdW90OyBhbmQgdGhlIHBhY2tldCB3aGljaCBzZXJ2ZXIg dG8gY2xpZW50IGhhcyBubyAmcXVvdDsgQ0lEICZxdW90OywgZm9yIGV4YW1wbGUgJm5ic3A7JnF1 b3Q7IFBLTjogMiAmcXVvdDsuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpzdGFydCI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1VJQ1RGb250VGV4dFN0eWxl Qm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1h bGlnbjpzdGFydCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1VJQ1RGb250VGV4dFN0eWxlQm9keSZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhpcyBpcyBh IHBhaXIgb2YgcGFja2V0cyB3aGljaCBjbGllbnQgdG8gc2VydmVyKCBQS046IDIgKSBhbmQgc2Vy dmVyIHRvIGNsaWVudCAoIFBLTjogMiApLCBpc24ndCByaWdodD8gQW5kIHRoZSBwYWNrZXQgY2xp ZW50IHRvIHNlcnZlciBoYXMgQ0lEIGFuZCB0aGUgc2VydmVyIHRvIGNsaWVudCBwYWNrZXQgaGFz IG5vIENJRA0KID88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0 YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZv bnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BbSBJIHJpZ2h0ID88L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWdu OnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlD VEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Ib3BlIGZvciByZXBs eS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5 bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0 LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGFua3M8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5bGVCb2R5JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5aaGkgQ2hhbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOnN0YXJ0Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VUlDVEZvbnRUZXh0U3R5 bGVCb2R5JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7335E3E9AC2DE240988251CF62CAE90A0A237148CNMAILEX03lenov_-- From nobody Wed Aug 22 04:56:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86902130E0F for ; Wed, 22 Aug 2018 04:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 eb69YthQdBhW for ; Wed, 22 Aug 2018 04:56:54 -0700 (PDT) Received: from mail-yw1-xc2e.google.com (mail-yw1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13591130DEF for ; Wed, 22 Aug 2018 04:56:54 -0700 (PDT) Received: by mail-yw1-xc2e.google.com with SMTP id n21-v6so434637ywh.5 for ; Wed, 22 Aug 2018 04:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X0frt3BMTVxWUyIIPgC2koUyiMmceLPNJxniqoiLKTA=; b=WlRZydyk+l+PQRwdaMEK4Noy1zzrYwVQajblncBcfi/gwIssudmEo+t7uWea5NKq1L ANoOrqFkyNq+bIlTk5+P9XkZTux0Ag+vUMtnCepgUqSwOB3o9Mj1ZMl/QkWMfwaRFB0m J10Uy10LWDS4q3pET7eHpSY04UTi88gu82XKTg9w5/xfjmT9fkYw3Age6mXjyjJezFKM 6S29hxAytg1ZXnvN7UGwLHn3gzh1pN5MEz334e8qiuuk78G6qrqHBoRfa3TzP2UoaggZ fE723CvSxlJMxeV3FeDCF5r/Rcpaf6dHc7yZVMNqdjSU38pcuUBTRbk6aK0HtRBvk5uj ui9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X0frt3BMTVxWUyIIPgC2koUyiMmceLPNJxniqoiLKTA=; b=PgvZ48m8oEZmHnvPbHrwD5Y2hgKpoNoffpyUwM2TffdW2NNkTp5D1PvTIee9/Ki9jA 3MToGNtCHYBCUGitnmc1Sl2D++ME4nZcRF4pzsBg9ZYZSBb05SmNDdQ4vtq+cpkcovlw gBH+DVyckl5Cnu2YVQv8GQ41aTL93s/31djNDnOCUfebeyCKk7Nu6yOa1ontS6VyTwl1 E1TWYTz8nO2p0i3B6MsoRJjmKe9nZ3EcLLVL3dFONN4eVwcUYSpoTDP62/VyPcRiKalD q0XB/Wp5gzSAIqqdZ3HT5ALMohbyMILxvQzk5Z7wiSsW301PX7Hhrys4KGXHHkSwlL3n mTLQ== X-Gm-Message-State: APzg51CcA7gyya9E+VkeQuDZ9crKONo6tHUwG+Xh/WQ5thxm0l6oxGvC dq7HL9vmHycLgz+ut2Y0PInzm4svG4eUgsLd07pEnw== X-Google-Smtp-Source: ANB0VdYN3Y1V57jm2MNkvUAYczKKAXHsiC0ZPGdf5pOi5NeOnqvbQTkb0axa4mYTsU20OcCIbKfRvECJQ8PQIFSGHtM= X-Received: by 2002:a81:6e87:: with SMTP id j129-v6mr5679248ywc.6.1534939012843; Wed, 22 Aug 2018 04:56:52 -0700 (PDT) MIME-Version: 1.0 References: <7335E3E9AC2DE240988251CF62CAE90A0A236086@CNMAILEX03.lenovo.com> <5DFAC0AB-2135-4792-A3A3-54D7D35B942A@lenovo.com> <7335E3E9AC2DE240988251CF62CAE90A0A236CE0@CNMAILEX03.lenovo.com> <7335E3E9AC2DE240988251CF62CAE90A0A237148@CNMAILEX03.lenovo.com> In-Reply-To: <7335E3E9AC2DE240988251CF62CAE90A0A237148@CNMAILEX03.lenovo.com> From: Ian Swett Date: Wed, 22 Aug 2018 07:56:14 -0400 Message-ID: Subject: Re: [External] Re: Same packet number in a QUIC connection ? To: changzhi2@lenovo.com Cc: quic@ietfa.amsl.com Content-Type: multipart/alternative; boundary="0000000000009d9315057404d671" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 11:56:57 -0000 --0000000000009d9315057404d671 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The differences in framing are huge and IETF QUIC uses TLS 1.3, not QUIC crypto. IETF QUIC is still undergoing changes, but is increasingly stable. The most recent transport draft is here: https://tools.ietf.org/html/draft-ietf-quic-transport-14 GQUIC is what is currently deployed at Google and some other places and there is not up-to-date documentation on it. Google is migrating towards IETF QUIC as quickly as possible. On Tue, Aug 21, 2018 at 11:10 PM Zhi Zhi2 Chang wrote: > Hi, Ian. > > > > Thanks for your reply. Is there any differences between QUIC and GQUIC? > > > > I can't find any official document about that expect at here[1]. > > > > > > Thanks > > Zhi Chang > > > > > > [1]: https://www.ietf.org/mail-archive/web/quic/current/msg02009.html > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Tuesday, August 21, 2018 9:44 PM > *To:* Zhi Zhi2 Chang > *Cc:* quic@ietfa.amsl.com > *Subject:* Re: [External] Re: Same packet number in a QUIC connection ? > > > > The CID from server to client is only dropped after handshake completion > in the current gQUIC implementation. > > > > On Mon, Aug 20, 2018 at 9:15 PM Zhi Zhi2 Chang > wrote: > > Hi, Ian. > > > > Thanks for your reply. I still have a question about that. > > > > In WireShark, I still find the server to client packet have a CID. Like > this: > > > > This is rejection packet which is server to client. > > > > Why this server to client packet has a CID? Because this is a server to > client rejection packet ? > > > > > > Thanks > > Zhi Chang > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Monday, August 20, 2018 7:30 PM > *To:* Zhi Zhi2 Chang > *Cc:* quic@ietfa.amsl.com > *Subject:* [External] Re: Same packet number in a QUIC connection ? > > > > Yes, the client to server packets have a CID, and the server to client > packets do not have one. > > > > Both client and server send their own packets numbered 1, 2, 3, etc, so > seeing two packets with the same number is normal as long as they're goin= g > in opposite directions. > > > > Wireshark very helpfully parses the flag indicating whether CID is > present, and if so displays it. > > > > On Fri, Aug 17, 2018 at 7:17 PM Zhi Zhi2 Chang > wrote: > > Hi, I have a question about " packet number ". > > > > I set up an environment about QUIC and I capture some QUIC packets by > wireshark. I find an insteresting phenomenon by watching these packets. > Please watch this picture: > > *=E9=94=99=E8=AF=AF!=E6=9C=AA=E6=8C=87=E5=AE=9A=E6=96=87=E4=BB=B6=E5=90= =8D=E3=80=82* > > > > In my environment, the server is 10.121.222.230 and the client is > 10.116.47.192. Why there are two identical packet which the PKN ( packet > number ) is the same ? Just like two " PKN: 2 " packets, two " PKN: 3 " > packets. > > > > After my consideration, I find that the packet which client to server has > " CID " and the packet which server to client has no " CID ", for example > " PKN: 2 ". > > > > This is a pair of packets which client to server( PKN: 2 ) and server to > client ( PKN: 2 ), isn't right? And the packet client to server has CID a= nd > the server to client packet has no CID ? > > > > Am I right ? > > > > > > Hope for reply. > > > > > > Thanks > > Zhi Chang > > > > > > --0000000000009d9315057404d671 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The differences in framing are huge and IETF QUIC uses TLS= 1.3, not QUIC crypto.=C2=A0 IETF QUIC is still undergoing changes, but is = increasingly stable.=C2=A0 The most recent transport draft is here:=C2=A0https://= tools.ietf.org/html/draft-ietf-quic-transport-14

GQU= IC is what is currently deployed at Google and some other places and there = is not up-to-date documentation on it.=C2=A0 Google is migrating towards IE= TF QUIC as quickly as possible.

<= div dir=3D"ltr">On Tue, Aug 21, 2018 at 11:10 PM Zhi Zhi2 Chang <changzhi2@lenovo.com> wrote:

Hi, Ian.

=C2=A0

Thanks for your reply. Is there any differences between QUIC and= GQUIC?

=C2=A0

I can't find any official document about that expect at here= [1].

=C2=A0

=C2=A0

Thanks

Zhi Chang

=C2=A0

=C2=A0

[1]: https://www.ietf.org/mail-archive/web/q= uic/current/msg02009.html

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Tuesday, August 21, 2018 9:44 PM
To: Zhi Zhi2 Chang
Cc: quic@ie= tfa.amsl.com
Subject: Re: [External] Re: Same packet number in a QUIC connection = ?

=C2=A0

The CID from server to client i= s only dropped after handshake completion in the current gQUIC implementati= on.

=C2=A0

On Mon, Aug 20, 2018 at 9:15 PM= Zhi Zhi2 Chang <changzhi2@lenovo.com> wrote:

Hi, Ian.

=C2=A0=

Thanks for your reply. I still hav= e a question about that.

=C2=A0=

In WireShark, I still find the ser= ver to client packet have a CID. Like this:<= /u>

=C2=A0=

This is rejection packet which is = server to client.

=C2=A0=

Why this server to client packet h= as a CID? Because this is a server to client rejection packet ?

=C2=A0=

=C2=A0=

Thanks=

Zhi Chang

=C2=A0=

From: QUIC [mailto:quic-bo= unces@ietf.org] On Behalf Of Ian Swett
Sent: Monday, August 20, 2018 7:30 PM
To: Zhi Zhi2 Chang
Cc: quic@ie= tfa.amsl.com
Subject: [External] Re: Same packet number in a QUIC connection ?

=C2=A0

Yes, the client to server packe= ts have a CID, and the server to client packets do not have one.<= /u>

=C2=A0

Both client and server send the= ir own packets numbered 1, 2, 3, etc, so seeing two packets with the same n= umber is normal as long as they're going in opposite directions.

=C2=A0

Wireshark very helpfully parses= the flag indicating whether CID is present, and if so displays it.<= u>

=C2=A0

On Fri, Aug 17, 2018 at 7:17 PM= Zhi Zhi2 Chang <changzhi2@lenovo.com> wrote:

Hi, I have a question about " packet number "= .

=C2=A0=

I set up an environment about QUIC and I capture some Q= UIC packets by wireshark. I find an insteresting phenomenon by watching the= se packets. Please watch this picture:

=E9=94=99=E8=AF=AF!= =E6=9C=AA=E6=8C=87=E5=AE=9A=E6=96=87=E4=BB=B6=E5=90=8D=E3=80=82

=C2=A0=

In my environment, the server is 10.121.222.230 and the= client is 10.116.47.192. Why there are two identical packet which the PKN = ( packet number ) is the same ? Just like two " PKN: 2 " packets, two " PKN: 3 " packets.<= /u>

=C2=A0=

After my consideration, I find that the packet which cl= ient to server has " CID " and the packet which server to client = has no " CID ", for example =C2=A0" PKN: 2 ".

=C2=A0=

This is a pair of packets which client to server( PKN: = 2 ) and server to client ( PKN: 2 ), isn't right? And the packet client= to server has CID and the server to client packet has no CID ?

=C2=A0=

Am I right ?<= /span>

=C2=A0=

=C2=A0=

Hope for reply.

=C2=A0=

=C2=A0=

Thanks=

Zhi Chang

=C2=A0=

=C2=A0

--0000000000009d9315057404d671-- From nobody Fri Aug 24 07:51:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B31A128CE4 for ; Fri, 24 Aug 2018 07:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da051tizRJqI for ; Fri, 24 Aug 2018 07:51:23 -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 2FC3F1286E3 for ; Fri, 24 Aug 2018 07:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1535122281; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jGnD8UMyCQbTzvZUV22kTstV3jvM3zCLECJdSYCfhEI=; b=ZlbM40YbVzLxs1vuL/IKh4qoIGx15rDu7CcYIPLov0GnN9v5k3qx1I9IXs3vYjL0 MR1A/KNBaLo1WTwK7Gy3SZHLOAjVYraoSod4GDCTh1dAm22pltjw6vb31neHX3Uw BwofZIkuO+RS8j9zvUl3Xh6hGQDDi0ezOTMkzxJE+ak=; X-AuditID: c1b4fb30-3cd869c0000055da-f3-5b801b6944af Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FF.35.21978.96B108B5; Fri, 24 Aug 2018 16:51:21 +0200 (CEST) Received: from [147.214.163.201] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 24 Aug 2018 16:51:20 +0200 Subject: Re: Unified ACK frame encoding To: Martin Thomson , Ian Swett CC: Brian Trammell , Jana Iyengar , QUIC WG References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> From: Magnus Westerlund Message-ID: <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> Date: Fri, 24 Aug 2018 16:51:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-ClientProxiedBy: ESESSMB501.ericsson.se (153.88.183.162) To ESESSMB502.ericsson.se (153.88.183.163) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2J7hW6mdEO0wcYmRYuf93ayWmxsecdm 0X5pHrPFtTP/GC16FnA7sHrsnHWX3WPBplKPJUt+Mnk82T+TJYAlissmJTUnsyy1SN8ugSvj 2CHXgqWyFYuXLGdsYDwl3sXIySEhYCKxYN56dhBbSOAoo8TSvoouRi4g+yOjxLE5T5hAEsIC 6hJdF7aDFYkI+Els/vqQGcRmFkiWaF28lxGi4RaTxNuFHWANbAIWEjd/NLJ1MXJw8ArYSxzf agkSZhFQlTjY/QhsjqhAjMTRyS1sIDavgKDEyZlPWEBsToFAib6/i9gg5ltIzJx/nhHClpfY /nYO1F5xiaYvK1khjtaWaGjqYIV4Rkni+rzrLCBrJQTSJV6f5pvAKDwLyYZZSKbOQjJ1FpKp CxhZVjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERsjBLb8NdjC+fO54iFGAg1GJhzdIvCFa iDWxrLgy9xCjBAezkgivmgBQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK+F3+YoIYH0xJLU7NTU gtQimCwTB6dUA2PW8+V73e6ceHd0FY/Apefx2gnHrkf5iz3KFfWa97Jl+r5PGUvmHPwRHu9W cdJmwbeZiUUPV708waHvfutE/TOxo8wtS9hfzO2YfTZYYOtr8yftnQ8uKc+f5nzt3TXj0L5p lee+hKyaHFMjmbbg3B1lL9vL5vZZijdXKWk9efv5jbH8N42kaeY8SizFGYmGWsxFxYkAnCr+ dIwCAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 14:51:26 -0000 Hi, Catching up. I have posted on github (https://github.com/quicwg/base-drafts/issues/1439) some consideration what this implies in regards to ack frame sizes for different cases discussed. I think Martins design here with being able to switch between each different type of marking as well as being able to reasonably efficient encode any range lengths without issues are a good one. My analysis on the github isssue showed that in low rate changes is is equivalent to a single byte design as well as being better capable of handling longer ranges of the same type. I think it is worth continuing with this one. If one wants to use the 2-bit type field for an explicitly encoded 4 alternative one or use the delta encoding can of course be discussed. I would prefer the delta encoding to avoid the information loss and the need for specifying what is the default ECT value and what to do in situations with a none expected one. Cheers Magnus Den 2018-08-13 kl. 08:29, skrev Martin Thomson: > On Fri, Aug 10, 2018 at 6:15 AM Ian Swett wrote: >> There are a few things I like about this proposal: >> 1) It makes ECN and ACK_ECN either the same(or more similar) >> 2) As Kazuho said, it provides more precise feedback about which packets were marked, which avoids some edge cases we've had to write up in the current text around ack loss and being unsure of exactly when recovery is exited. >> 3) It doesn't get more expensive as the connection goes on. This is an unfortunate property of the current design. >> >> I find Jana's variation on this particularly interesting, because if ECN isn't negotiated, I don't think there a reason to add any overhead. From personal experience, if you find a form of feedback valuable(whether it's ECN or timestamps for one-way-delay), then you're happy to consume a few extra bytes to get better feedback. If the extra information isn't useful for whatever reason, it's just wasted bytes. > OK, 4 values is definitely easier to reason about. Merging ECT(0) and > ECT(1) into the same bucket is easy as long as we're OK with that. > The simpler encoding is easier to describe and write code for, and we > can just tolerate (or reject) two adjacent ranges of the same type, > just as we might tolerate (or reject) a trailing gap. > >> So overall this seems like an improvement we should do, but I'd prefer a variant that doesn't increase the ACK frame size when ECN is disabled or there are no ECN marks to report. FYI, if we need to steal a bit from the number of ack blocks, I'm ok with that since I expect more than 32 ack blocks to be very rare. > This is very close to a variant I suggested on the issue, which we > agreed pretty quickly wasn't great. You can create two ACK frames, > one with the full expressiveness, and another that has the potential > to encode the ECN information. Call the second one ACK_ECN... > > I'm not convinced that optimizing for the awkward space between 16 and > 64 is worth the extra complexity of a variant encoding of the frame. > There are other ways to optimize for the cost of that occasional octet > that seem like they would be more fruitful (like truncating ACK frames > more aggressively). -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Sat Aug 25 17:45:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D191274D0 for ; Sat, 25 Aug 2018 17:45: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, 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=mnot.net header.b=FYW7/0k0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VjpXVbFZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qju46PHsX0ao for ; Sat, 25 Aug 2018 17:45:18 -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 B548F1252B7 for ; Sat, 25 Aug 2018 17:45:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id CDE422156E for ; Sat, 25 Aug 2018 20:45:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 25 Aug 2018 20:45:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=j40a+bt/H4z00p+LV Yd1YEoIacW1zKdNlo2jxN+tTds=; b=FYW7/0k0a21GwoOegScEQGYyDVkaP8P96 V/nXrzRu+oeWtoWHsyL8FT51kgRmmfwDDZiypWD3LlLInDPR/jiyp0mYlj8/dXm5 cjimKMQuxJoA1omLeceGau3JP0HxZ538K76R56BtUmfiHW0tTKc2GsRSC7oPSa2L y8yiqcG+CanNidT40lUjIUM21tgUmaRj2UOSbkx4lQbJLnPssG5pX+Z3MeZbwxuO PPf7dURIOmRQ7IxmhKlWRD3YGHvkUGN1bqsR9UpBkqzlD/AkW99ZfSI9GhJlNQjY xa27fmMMowdsmAIMMPnRRQdBXHSnMN17knxM/XQkBI1+4hGJ8sijg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=j40a+bt/H4z00p+LVYd1YEoIacW1zKdNlo2jxN+tTds=; b=VjpXVbFZ oyeQCorCGU72uz4LYshjX9ojZ8HOyWkpJhl2VdR/DGlaGhzk7lVr09W6TTFnjl+1 Ml+PRwqAFJlP5c1B5nlqBMhunb+6FViq+c5Ps0vWUkTOOPvPrDr+rozw6BTwN82w YPFM0wQpD29ZKnHZZY7LIfQeKJIktsoJcQtHOPr5eVU01SlUDi+9sKmQg1yV+DjB c3NEnITD5Y1NGNH6gplRfuBD5M6rhT4KfdbCEF3ZAwGdd5ftjT4t/PkRKMGKQNl3 B4XAIqbU0YxcF/Rz8I3962ojLhftfueWnz0obMmeeiWGC89TaP4angZwl1Vcvwke FgUVX41sIp4f0A== X-ME-Proxy: X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A29C10269 for ; Sat, 25 Aug 2018 20:45:15 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id E0A8CCBAFF for ; Sun, 26 Aug 2018 00:45:12 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============0702607462293059236==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180826004512.E0A8CCBAFF@cloud.mnot.net> Date: Sun, 26 Aug 2018 00:45:12 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 00:45:22 -0000 --===============0702607462293059236== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+3/-4/=F0=9F=92=AC14) 3 issues created: - Should coalescing order be enforced? (by huitema) https://github.com/quicwg/base-drafts/issues/1702 = - Error for not receiving SETTINGS frame as the first frame on a control = stream (by ddragana) https://github.com/quicwg/base-drafts/issues/1697 = - Ensure the use of full-length (128-bit) tags for all AEAD algorithms (b= y DemiMarie) https://github.com/quicwg/base-drafts/issues/1688 = 5 issues received 14 new comments: - #904 HTTP header compression: static table fit for QUIC (9 by dtikhonov= , LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/904 [-qpack] [design] = - #1439 Improve ACK_ECN frame encoding (e.g., use bit-vector) (2 by gloin= ul) https://github.com/quicwg/base-drafts/issues/1439 [-transport] [design] = - #1697 Error for not receiving SETTINGS frame as the first frame on a co= ntrol stream (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1697 = - #1420 encoder stream can deadlock (1 by afrind) https://github.com/quicwg/base-drafts/issues/1420 [-qpack] [design] = - #1688 Ensure the use of full-length (128-bit) tags for all AEAD algorit= hms (1 by DemiMarie) https://github.com/quicwg/base-drafts/issues/1688 = 4 issues closed: - Initial size of dynamic table https://github.com/quicwg/base-drafts/iss= ues/1530 [-qpack] [design] = - Small packets don't trigger a stateless reset https://github.com/quicwg= /base-drafts/issues/1681 [-transport] [design] = - Target of HTTP version fallback https://github.com/quicwg/base-drafts/i= ssues/1677 [-http] [design] = - Ensure the use of full-length (128-bit) tags for all AEAD algorithms ht= tps://github.com/quicwg/base-drafts/issues/1688 = Pull requests ------------- * quicwg/base-drafts (+13/-12/=F0=9F=92=AC4) 13 pull requests submitted: - Fix nits in transport draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1701 = - Fix nits in recovery draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1700 = - Fix nits in recovery draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1699 = - Fix nits in transport draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1698 = - Grammar fix to invariants draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1696 = - Fix typo in HTTP draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1695 = - Grammar and spelling fixes to TLS draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1694 = - Grammar fix to HTTP draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1693 = - Remove redundant word (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1692 = - Grammar fixes to transport draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1691 = - 1-RTT ACK frames can acknowledge 0-RTT packets (by kazuho) https://github.com/quicwg/base-drafts/pull/1690 = - Fix typos in transport draft (by amirlivneh) https://github.com/quicwg/base-drafts/pull/1689 = - HTTP_VERSION_FALLBACK points to 1.1 (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1685 [-http] [design] [merge= -imminent] = 4 pull requests received 4 new comments: - #1698 Fix nits in transport draft (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1698 = - #1699 Fix nits in recovery draft (1 by ianswett) https://github.com/quicwg/base-drafts/pull/1699 = - #1700 Fix nits in recovery draft (1 by ianswett) https://github.com/quicwg/base-drafts/pull/1700 = - #1694 Grammar and spelling fixes to TLS draft (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1694 = 12 pull requests merged: - Fix nits in transport draft https://github.com/quicwg/base-drafts/pull/1701 = - Fix nits in transport draft https://github.com/quicwg/base-drafts/pull/1698 = - Fix nits in recovery draft https://github.com/quicwg/base-drafts/pull/1700 = - Fix typo in HTTP draft https://github.com/quicwg/base-drafts/pull/1695 = - Fix nits in recovery draft https://github.com/quicwg/base-drafts/pull/1699 = - Grammar fix to invariants draft https://github.com/quicwg/base-drafts/pull/1696 = - Grammar and spelling fixes to TLS draft https://github.com/quicwg/base-drafts/pull/1694 = - Grammar fix to HTTP draft https://github.com/quicwg/base-drafts/pull/1693 = - Initial table size is the maximum permitted when table is first usable https://github.com/quicwg/base-drafts/pull/1642 [-qpack] [design] = - 1-RTT ACK frames can acknowledge 0-RTT packets https://github.com/quicwg/base-drafts/pull/1690 = - Fix typos in transport draft https://github.com/quicwg/base-drafts/pull/1689 = - HTTP_VERSION_FALLBACK points to 1.1 https://github.com/quicwg/base-drafts/pull/1685 [-http] [design] [merge= -imminent] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============0702607462293059236== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday August 26, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+3/-4/=F0=9F=92=AC14)

3 issues created:

5 issues received 14 new comments:

4 issues closed:

Pull requests

quicwg/base-drafts (+13/-12/=F0=9F=92=AC4)

13 pull requests submitted:

4 pull requests received 4 new comments:

12 pull requests merged:

Repositories tracked by this digest:

--===============0702607462293059236==-- From nobody Sun Aug 26 15:55:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7068130E6B for ; Sun, 26 Aug 2018 15:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 bLl1S8S1GBt5 for ; Sun, 26 Aug 2018 15:55:17 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5185D130E73 for ; Sun, 26 Aug 2018 15:55:17 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id r4-v6so10476044lff.12 for ; Sun, 26 Aug 2018 15:55:17 -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=08Kr66HArUcKXK7YultSee+6DPS6jWSXszHsSRlVDDw=; b=AqgxteZopYtFlGme0A8Rftg5vqqlQUPuapM/1EZVPcW7r+TgHoN835xHxmGdSlsNvs R3iv0p2l5ZgGDmfugs6Z8sq1aNhagWNATXgCkjrzTNvEfHG+r3dTq3y/0E4LniMkO7iE pLvujuME71TW71rL5wpeilVfAg/G/jDTtjMEltUIDsnDCnA+7V3y3B8YhNZkvqAaqQSc 78eR3KhVir8GRsk71JxPx1PElnWPXt7ECt9yinyx4xog0syWQzyoRSrnO30bjbiStISN iayJxBK3syP9N0k4Ml3FyDex5jVQ1gcGnm4rYvfvIsQFEwHL2P1/dqg2qMqNZruOYTe3 dDPQ== 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=08Kr66HArUcKXK7YultSee+6DPS6jWSXszHsSRlVDDw=; b=p6pjp+bz4lnqSCkQ6ENkvkPIdpl2FpRw3ZrSPHOxYaBsGn8pAwE8XVp8Th1JpsHzSo c6gwKT+ANVEYxvJw5V6lpb5HoK9tAu19gtSHsG0xNdpQn/YKJieK2npsPW6rXJYOkHCp AfodP/vq6PAbvavpfJstxMsz4cooaImz9sNdYNNzEwN326lJmuXjs8pIe60bXyucxfdY kVlnzC153/QKO5gTK7C8ibjpGF3eUGSxLsgVsZvG8F0s7VOyT5/KPkIJ2OJLGhDtavxB cYQ9UQ1egzxS+/0rI1U1NVWlQeZm+DuUKbtovrXAoUQUE54qeB4K4lOYDH6os33ukX2n 4Q2A== X-Gm-Message-State: APzg51Cpt2eFv038v47EqVKhxJsqDoC6wCf7yHRjW3ZGBqmo0zngq/iz eaWcpiALjpVVLonqQOONps6ADawK2GX4/8tp97/GXA== X-Google-Smtp-Source: ANB0VdaWnEGJE5RWeEIgbVLh1uj9+qn7CWJE2aRB9GfUASNLXf3stCIBw/FdtVcGRXBtYnuMMYZatbHlebVXJyg5Pnk= X-Received: by 2002:a19:cb93:: with SMTP id b141-v6mr6463115lfg.119.1535324115542; Sun, 26 Aug 2018 15:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Sun, 26 Aug 2018 15:54:34 -0700 (PDT) In-Reply-To: <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> From: Eric Rescorla Date: Sun, 26 Aug 2018 15:54:34 -0700 Message-ID: Subject: Re: Unified ACK frame encoding To: Magnus Westerlund Cc: Martin Thomson , Ian Swett , Jana Iyengar , Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary="00000000000085b87405745e805a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 22:55:30 -0000 --00000000000085b87405745e805a Content-Type: text/plain; charset="UTF-8" On balance I don't think I'm in favor of this bit-packing technique because it complicates the ordinary ACK frame even for people who don't care about ECN (and not doing so was part of why we decided to have another frame type in the first place). Moreover, it's not a scalable extension method, so anything *else* we want to add to the ACK frame will just need some other technique. -Ekr On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > Catching up. I have posted on github (https://github.com/quicwg/bas > e-drafts/issues/1439) some consideration what this implies in regards to > ack frame sizes for different cases discussed. > > I think Martins design here with being able to switch between each > different type of marking as well as being able to reasonably efficient > encode any range lengths without issues are a good one. My analysis on the > github isssue showed that in low rate changes is is equivalent to a single > byte design as well as being better capable of handling longer ranges of > the same type. > > I think it is worth continuing with this one. If one wants to use the > 2-bit type field for an explicitly encoded 4 alternative one or use the > delta encoding can of course be discussed. I would prefer the delta > encoding to avoid the information loss and the need for specifying what is > the default ECT value and what to do in situations with a none expected one. > > Cheers > > Magnus > > > > Den 2018-08-13 kl. 08:29, skrev Martin Thomson: > >> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett wrote: >> >>> There are a few things I like about this proposal: >>> 1) It makes ECN and ACK_ECN either the same(or more similar) >>> 2) As Kazuho said, it provides more precise feedback about which packets >>> were marked, which avoids some edge cases we've had to write up in the >>> current text around ack loss and being unsure of exactly when recovery is >>> exited. >>> 3) It doesn't get more expensive as the connection goes on. This is an >>> unfortunate property of the current design. >>> >>> I find Jana's variation on this particularly interesting, because if ECN >>> isn't negotiated, I don't think there a reason to add any overhead. From >>> personal experience, if you find a form of feedback valuable(whether it's >>> ECN or timestamps for one-way-delay), then you're happy to consume a few >>> extra bytes to get better feedback. If the extra information isn't useful >>> for whatever reason, it's just wasted bytes. >>> >> OK, 4 values is definitely easier to reason about. Merging ECT(0) and >> ECT(1) into the same bucket is easy as long as we're OK with that. >> The simpler encoding is easier to describe and write code for, and we >> can just tolerate (or reject) two adjacent ranges of the same type, >> just as we might tolerate (or reject) a trailing gap. >> >> So overall this seems like an improvement we should do, but I'd prefer a >>> variant that doesn't increase the ACK frame size when ECN is disabled or >>> there are no ECN marks to report. FYI, if we need to steal a bit from the >>> number of ack blocks, I'm ok with that since I expect more than 32 ack >>> blocks to be very rare. >>> >> This is very close to a variant I suggested on the issue, which we >> agreed pretty quickly wasn't great. You can create two ACK frames, >> one with the full expressiveness, and another that has the potential >> to encode the ECN information. Call the second one ACK_ECN... >> >> I'm not convinced that optimizing for the awkward space between 16 and >> 64 is worth the extra complexity of a variant encoding of the frame. >> There are other ways to optimize for the cost of that occasional octet >> that seem like they would be more fruitful (like truncating ACK frames >> more aggressively). >> > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --00000000000085b87405745e805a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On balance I don't think I'm in favor of this= bit-packing technique because it complicates the ordinary ACK frame even f= or people who don't care about ECN (and not doing so was part of why we= decided to have another frame type in the first place). Moreover, it's= not a scalable extension method, so anything *else* we want to add to the = ACK frame will just need some other technique.

-Ek= r


On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

Catching up. I have posted on github (https://githu= b.com/quicwg/base-drafts/issues/1439) some consideration what this= implies in regards to ack frame sizes for different cases discussed.

I think Martins design here with being able to switch between each differen= t type of marking as well as being able to reasonably efficient encode any = range lengths without issues are a good one. My analysis on the github isss= ue showed that in low rate changes is is equivalent to a single byte design= as well as being better capable of handling longer ranges of the same type= .

I think it is worth continuing with this one. If one wants to use the 2-bit= type field for an explicitly encoded 4 alternative one or use the delta en= coding can of course be discussed. I would prefer the delta encoding to avo= id the information loss and the need for specifying what is the default ECT= value and what to do in situations with a none expected one.

Cheers

Magnus



Den 2018-08-13 kl. 08:29, skrev Martin Thomson:
On Fri, Aug 10, 2018 at 6:15 AM Ian Swett <ianswett@google.com> wrote:
There are a few things I like about this proposal:
1) It makes ECN and ACK_ECN either the same(or more similar)
2) As Kazuho said, it provides more precise feedback about which packets we= re marked, which avoids some edge cases we've had to write up in the cu= rrent text around ack loss and being unsure of exactly when recovery is exi= ted.
3) It doesn't get more expensive as the connection goes on.=C2=A0 This = is an unfortunate property of the current design.

I find Jana's variation on this particularly interesting, because if EC= N isn't negotiated, I don't think there a reason to add any overhea= d.=C2=A0 From personal experience, if you find a form of feedback valuable(= whether it's ECN or timestamps for one-way-delay), then you're happ= y to consume a few extra bytes to get better feedback.=C2=A0 If the extra i= nformation isn't useful for whatever reason, it's just wasted bytes= .
OK, 4 values is definitely easier to reason about.=C2=A0 Merging ECT(0) and=
ECT(1) into the same bucket is easy as long as we're OK with that.
The simpler encoding is easier to describe and write code for, and we
can just tolerate (or reject) two adjacent ranges of the same type,
just as we might tolerate (or reject) a trailing gap.

So overall this seems like an improvement we should do, but I'd prefer = a variant that doesn't increase the ACK frame size when ECN is disabled= or there are no ECN marks to report.=C2=A0 FYI, if we need to steal a bit = from the number of ack blocks, I'm ok with that since I expect more tha= n 32 ack blocks to be very rare.
This is very close to a variant I suggested on the issue, which we
agreed pretty quickly wasn't great.=C2=A0 You can create two ACK frames= ,
one with the full expressiveness, and another that has the potential
to encode the ECN information.=C2=A0 Call the second one ACK_ECN...

I'm not convinced that optimizing for the awkward space between 16 and<= br> 64 is worth the extra complexity of a variant encoding of the frame.
There are other ways to optimize for the cost of that occasional octet
that seem like they would be more fruitful (like truncating ACK frames
more aggressively).

--

Magnus Westerlund

-----------------------------------------------------------------= -----
Network Architecture & Protocols, Ericsson Research
-----------------------------------------------------------------= -----
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0= 949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----


--00000000000085b87405745e805a-- From nobody Mon Aug 27 01:11:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1569B128C65 for ; Mon, 27 Aug 2018 01:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBR1D6Z8cUku for ; Mon, 27 Aug 2018 01:11:51 -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 BEE53130E80 for ; Mon, 27 Aug 2018 01:11:49 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id b15-v6so25770400oib.10 for ; Mon, 27 Aug 2018 01:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Dbf+EZcBjotCDU1NXRGG2T6s5iheCerFGecK8DjRIyU=; b=FYz6QmAKtGSHcDPmjJ+bCMEqcYvWTWKKyBhatsDBIRsAaQXDSiYkIN4SX496I32P/q IfI/UA8Oed37mzGxSgc3uDvMAT8QdWqrBHvSrpRSqOfqCQaQ3KIZrpnqCKry0ZZg6Tk0 qpHHe6hJ0oc5BCXuwInbSMcCio39WVZOk8+oFewVC91YvLw4VtPZq8geooMmDtOzm3Zl E+VQpFD60l+0f6TRyoWkSCWGohxi80u06dsS+kLkQbAeXH2L+7EHMIIf7Un+rZRDaeFX e5BqGeUgd0zKU2zkfrjDPi0O+OyN9fb+aggaNN9Sy0sMiJSz2m1N2AWvHxyRIq/Fk2OL Qz5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Dbf+EZcBjotCDU1NXRGG2T6s5iheCerFGecK8DjRIyU=; b=WkEKdvAlPm/G5mAe2xGx7lPp3BkGdOSfPFg2qexrbBKj4CweMJePo0SgjRfEem6j5Y 2HCNCCHT3a4CUprLV/u2eCPlhU8eTQWxt8I1Z90ZQEmZxtCIUZWuUeeFa2+aXeKt9Fdt 9nCqayvuSM1dQaNTeQ5nIBW6+42BA0oEmNmXDrZAgk4I5+tPPu6RT58TFym74JdSykjE Og2YRX8GgVhXl7uWNg3GU4cefJyAdG42RYb9NaO0okjpJ7kSWVFyVsxwxfPKcTed2a50 N2oSZ3Na7+GwVLfN8YyA6xCvtwcDf59SjgESp155/Q62qO1F7FKpx82+X55iuHJIT84N R6mg== X-Gm-Message-State: APzg51DXi1HGk3Zwa34FRLxgzQbFkROjYAeCvYh/qRU7ZnZyIFuDDYjv gL8WWQfg9IhIVMid56IWSi7vj9NpX0r6LX1F1GI= X-Google-Smtp-Source: ANB0VdbotD9ZibcA08OIxBxrsEum69VOnQzh1F+TEev0xWh9j7b1BR/kkmdeKFskTpub6OK7Rhnj5Ye6UHPmDPPIneg= X-Received: by 2002:aca:3fc2:: with SMTP id m185-v6mr11847562oia.240.1535357508969; Mon, 27 Aug 2018 01:11:48 -0700 (PDT) MIME-Version: 1.0 References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> In-Reply-To: From: Martin Thomson Date: Mon, 27 Aug 2018 18:11:37 +1000 Message-ID: Subject: Re: Unified ACK frame encoding To: Eric Rescorla Cc: Magnus Westerlund , Ian Swett , Jana Iyengar , Brian Trammell , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 08:11:53 -0000 I think that this is simpler. See https://github.com/quicwg/base-drafts/pull/1706 for a draft. On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla wrote: > > On balance I don't think I'm in favor of this bit-packing technique becau= se it complicates the ordinary ACK frame even for people who don't care abo= ut ECN (and not doing so was part of why we decided to have another frame t= ype in the first place). Moreover, it's not a scalable extension method, so= anything *else* we want to add to the ACK frame will just need some other = technique. > > -Ekr > > > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund wrote: >> >> Hi, >> >> Catching up. I have posted on github (https://github.com/quicwg/base-dra= fts/issues/1439) some consideration what this implies in regards to ack fra= me sizes for different cases discussed. >> >> I think Martins design here with being able to switch between each diffe= rent type of marking as well as being able to reasonably efficient encode a= ny range lengths without issues are a good one. My analysis on the github i= sssue showed that in low rate changes is is equivalent to a single byte des= ign as well as being better capable of handling longer ranges of the same t= ype. >> >> I think it is worth continuing with this one. If one wants to use the 2-= bit type field for an explicitly encoded 4 alternative one or use the delta= encoding can of course be discussed. I would prefer the delta encoding to = avoid the information loss and the need for specifying what is the default = ECT value and what to do in situations with a none expected one. >> >> Cheers >> >> Magnus >> >> >> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: >>> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett wrote: >>>> >>>> There are a few things I like about this proposal: >>>> 1) It makes ECN and ACK_ECN either the same(or more similar) >>>> 2) As Kazuho said, it provides more precise feedback about which packe= ts were marked, which avoids some edge cases we've had to write up in the c= urrent text around ack loss and being unsure of exactly when recovery is ex= ited. >>>> 3) It doesn't get more expensive as the connection goes on. This is a= n unfortunate property of the current design. >>>> >>>> I find Jana's variation on this particularly interesting, because if E= CN isn't negotiated, I don't think there a reason to add any overhead. Fro= m personal experience, if you find a form of feedback valuable(whether it's= ECN or timestamps for one-way-delay), then you're happy to consume a few e= xtra bytes to get better feedback. If the extra information isn't useful f= or whatever reason, it's just wasted bytes. >>> >>> OK, 4 values is definitely easier to reason about. Merging ECT(0) and >>> ECT(1) into the same bucket is easy as long as we're OK with that. >>> The simpler encoding is easier to describe and write code for, and we >>> can just tolerate (or reject) two adjacent ranges of the same type, >>> just as we might tolerate (or reject) a trailing gap. >>> >>>> So overall this seems like an improvement we should do, but I'd prefer= a variant that doesn't increase the ACK frame size when ECN is disabled or= there are no ECN marks to report. FYI, if we need to steal a bit from the= number of ack blocks, I'm ok with that since I expect more than 32 ack blo= cks to be very rare. >>> >>> This is very close to a variant I suggested on the issue, which we >>> agreed pretty quickly wasn't great. You can create two ACK frames, >>> one with the full expressiveness, and another that has the potential >>> to encode the ECN information. Call the second one ACK_ECN... >>> >>> I'm not convinced that optimizing for the awkward space between 16 and >>> 64 is worth the extra complexity of a variant encoding of the frame. >>> There are other ways to optimize for the cost of that occasional octet >>> that seem like they would be more fruitful (like truncating ACK frames >>> more aggressively). >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Network Architecture & Protocols, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> > From nobody Mon Aug 27 06:02:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BC3124C04 for ; Mon, 27 Aug 2018 06:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 XNWf_cW92Omx for ; Mon, 27 Aug 2018 06:02:21 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED561130DD8 for ; Mon, 27 Aug 2018 06:02:19 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id j8-v6so11880758lfb.4 for ; Mon, 27 Aug 2018 06:02:19 -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=zFAqgc3277GvOBTy58AdXs9WkSWGjg7oYfrm88BeX0Y=; b=xp8Ib3cv3wCZzApHuiXiGoVLlCipnqC3Yq5XaN2D0Q4B06vcc32wcbnXutzVtu8sd5 8N7v9bNXnPNUHdIFQNlYfIbuyNb1sVUmKu1K/nmsnkjlR2vo69rbr6iDF9JGl7Xln1jH 5nlHAijchKmbj3BWcD4b4Lj3mIbhBaNgz6O9ewm1pWtXKF08mvECSwpn2ZrwO1C9MyEg WQHfBFHAVMv0DD4yudI2uNczLg2aJDVd+STZTZ1U6WjsuToUE2AwInR3DclEKQ9ZsIbg j2QuRX6lDv1V9PXn3za6v6OW+DXag5xMVYde4oQskQlQ/dD3Ouq5qTWypnKPkO59U882 5ZUQ== 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=zFAqgc3277GvOBTy58AdXs9WkSWGjg7oYfrm88BeX0Y=; b=tS87nyD3thkEnud/OdvYe1Gq9a0Cci6qk89Ackca8Q9+4u9uOFq3LLsDqgt9O2eHbi IV8TuOZKKSvP1uu0scjfF6ejETyUCpM4yYTAAf8JRQ3q4XEKT99RYc4/m/1aNN+R7l2n R9QsJtw8NEeh9yKmdFPErjOpAiWnUGKbI1vac030F6/qBapS2haRvziQ7fIuCf6eBwJw Qc9Qdu1n61ls0f/3+pTplfHXnKrC4sFiqKdGX7X5ZAb9SPp2BvdU7UL1qa/yPpDFbUz0 kvTP6pv7QboPZ/V/XgzrjwETbwVfhTdhYUYRQrgW2iZouWyWdkaPgZinqYxIIuzdhYq/ KdAA== X-Gm-Message-State: APzg51Bmsj+zqsLAKLxFtPl5oiUqq+NaOKxv1kXP+mrS7coYvGyYj0zm dXra+3Hx44uIAk3XPFgP5SGkwIxnkIn0d4UVCCNcrg== X-Google-Smtp-Source: ANB0VdbJkW2iTwA6aW+5eBQELW/h09onXWuT2T52TGEMuT4rb8R9nAel5Vzty5cPRcfWf3gEvDOfx2HAy+2r18YwG1Q= X-Received: by 2002:a19:cb93:: with SMTP id b141-v6mr8135846lfg.119.1535374938035; Mon, 27 Aug 2018 06:02:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Mon, 27 Aug 2018 06:01:37 -0700 (PDT) In-Reply-To: References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> From: Eric Rescorla Date: Mon, 27 Aug 2018 06:01:37 -0700 Message-ID: Subject: Re: Unified ACK frame encoding To: Martin Thomson Cc: Magnus Westerlund , Ian Swett , Jana Iyengar , Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary="000000000000c77cf605746a5537" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 13:02:26 -0000 --000000000000c77cf605746a5537 Content-Type: text/plain; charset="UTF-8" Yes, this PR reflects what I believed you were proposing. I believe the objections I raised here continue to apply. -Ekr On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson wrote: > I think that this is simpler. See > https://github.com/quicwg/base-drafts/pull/1706 for a draft. > On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla wrote: > > > > On balance I don't think I'm in favor of this bit-packing technique > because it complicates the ordinary ACK frame even for people who don't > care about ECN (and not doing so was part of why we decided to have another > frame type in the first place). Moreover, it's not a scalable extension > method, so anything *else* we want to add to the ACK frame will just need > some other technique. > > > > -Ekr > > > > > > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> > >> Hi, > >> > >> Catching up. I have posted on github (https://github.com/quicwg/ > base-drafts/issues/1439) some consideration what this implies in regards > to ack frame sizes for different cases discussed. > >> > >> I think Martins design here with being able to switch between each > different type of marking as well as being able to reasonably efficient > encode any range lengths without issues are a good one. My analysis on the > github isssue showed that in low rate changes is is equivalent to a single > byte design as well as being better capable of handling longer ranges of > the same type. > >> > >> I think it is worth continuing with this one. If one wants to use the > 2-bit type field for an explicitly encoded 4 alternative one or use the > delta encoding can of course be discussed. I would prefer the delta > encoding to avoid the information loss and the need for specifying what is > the default ECT value and what to do in situations with a none expected one. > >> > >> Cheers > >> > >> Magnus > >> > >> > >> > >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: > >>> > >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett wrote: > >>>> > >>>> There are a few things I like about this proposal: > >>>> 1) It makes ECN and ACK_ECN either the same(or more similar) > >>>> 2) As Kazuho said, it provides more precise feedback about which > packets were marked, which avoids some edge cases we've had to write up in > the current text around ack loss and being unsure of exactly when recovery > is exited. > >>>> 3) It doesn't get more expensive as the connection goes on. This is > an unfortunate property of the current design. > >>>> > >>>> I find Jana's variation on this particularly interesting, because if > ECN isn't negotiated, I don't think there a reason to add any overhead. > From personal experience, if you find a form of feedback valuable(whether > it's ECN or timestamps for one-way-delay), then you're happy to consume a > few extra bytes to get better feedback. If the extra information isn't > useful for whatever reason, it's just wasted bytes. > >>> > >>> OK, 4 values is definitely easier to reason about. Merging ECT(0) and > >>> ECT(1) into the same bucket is easy as long as we're OK with that. > >>> The simpler encoding is easier to describe and write code for, and we > >>> can just tolerate (or reject) two adjacent ranges of the same type, > >>> just as we might tolerate (or reject) a trailing gap. > >>> > >>>> So overall this seems like an improvement we should do, but I'd > prefer a variant that doesn't increase the ACK frame size when ECN is > disabled or there are no ECN marks to report. FYI, if we need to steal a > bit from the number of ack blocks, I'm ok with that since I expect more > than 32 ack blocks to be very rare. > >>> > >>> This is very close to a variant I suggested on the issue, which we > >>> agreed pretty quickly wasn't great. You can create two ACK frames, > >>> one with the full expressiveness, and another that has the potential > >>> to encode the ECN information. Call the second one ACK_ECN... > >>> > >>> I'm not convinced that optimizing for the awkward space between 16 and > >>> 64 is worth the extra complexity of a variant encoding of the frame. > >>> There are other ways to optimize for the cost of that occasional octet > >>> that seem like they would be more fruitful (like truncating ACK frames > >>> more aggressively). > >> > >> > >> -- > >> > >> Magnus Westerlund > >> > >> ---------------------------------------------------------------------- > >> Network Architecture & Protocols, Ericsson Research > >> ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> Torshamnsgatan 23 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >> ---------------------------------------------------------------------- > >> > > > --000000000000c77cf605746a5537 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, this PR reflects what I believed you were propos= ing. I believe the objections I raised here continue to apply.

-Ekr

=
On Mon, Aug 27, 2018 at 1:11 AM, Martin Thom= son <martin.thomson@gmail.com> wrote:
I think that this is simpler.=C2=A0 See
https://github.com/quicwg/base-drafts/pull/1706<= /a> for a draft.
On Mon, Aug 27, 2018 at 8:55 AM Eri= c Rescorla <ekr@rtfm.com> wrote:<= br> >
> On balance I don't think I'm in favor of this bit-packing tech= nique because it complicates the ordinary ACK frame even for people who don= 't care about ECN (and not doing so was part of why we decided to have = another frame type in the first place). Moreover, it's not a scalable e= xtension method, so anything *else* we want to add to the ACK frame will ju= st need some other technique.
>
> -Ekr
>
>
> On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund <magnus.westerlund@ericsson.com&= gt; wrote:
>>
>> Hi,
>>
>> Catching up. I have posted on github (http= s://github.com/quicwg/base-drafts/issues/1439) some consideration = what this implies in regards to ack frame sizes for different cases discuss= ed.
>>
>> I think Martins design here with being able to switch between each= different type of marking as well as being able to reasonably efficient en= code any range lengths without issues are a good one. My analysis on the gi= thub isssue showed that in low rate changes is is equivalent to a single by= te design as well as being better capable of handling longer ranges of the = same type.
>>
>> I think it is worth continuing with this one. If one wants to use = the 2-bit type field for an explicitly encoded 4 alternative one or use the= delta encoding can of course be discussed. I would prefer the delta encodi= ng to avoid the information loss and the need for specifying what is the de= fault ECT value and what to do in situations with a none expected one.
>>
>> Cheers
>>
>> Magnus
>>
>>
>>
>> Den 2018-08-13 kl. 08:29, skrev Martin Thomson:
>>>
>>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett <ianswett@google.com> wrote:
>>>>
>>>> There are a few things I like about this proposal:
>>>> 1) It makes ECN and ACK_ECN either the same(or more simila= r)
>>>> 2) As Kazuho said, it provides more precise feedback about= which packets were marked, which avoids some edge cases we've had to w= rite up in the current text around ack loss and being unsure of exactly whe= n recovery is exited.
>>>> 3) It doesn't get more expensive as the connection goe= s on.=C2=A0 This is an unfortunate property of the current design.
>>>>
>>>> I find Jana's variation on this particularly interesti= ng, because if ECN isn't negotiated, I don't think there a reason t= o add any overhead.=C2=A0 From personal experience, if you find a form of f= eedback valuable(whether it's ECN or timestamps for one-way-delay), the= n you're happy to consume a few extra bytes to get better feedback.=C2= =A0 If the extra information isn't useful for whatever reason, it's= just wasted bytes.
>>>
>>> OK, 4 values is definitely easier to reason about.=C2=A0 Mergi= ng ECT(0) and
>>> ECT(1) into the same bucket is easy as long as we're OK wi= th that.
>>> The simpler encoding is easier to describe and write code for,= and we
>>> can just tolerate (or reject) two adjacent ranges of the same = type,
>>> just as we might tolerate (or reject) a trailing gap.
>>>
>>>> So overall this seems like an improvement we should do, bu= t I'd prefer a variant that doesn't increase the ACK frame size whe= n ECN is disabled or there are no ECN marks to report.=C2=A0 FYI, if we nee= d to steal a bit from the number of ack blocks, I'm ok with that since = I expect more than 32 ack blocks to be very rare.
>>>
>>> This is very close to a variant I suggested on the issue, whic= h we
>>> agreed pretty quickly wasn't great.=C2=A0 You can create t= wo ACK frames,
>>> one with the full expressiveness, and another that has the pot= ential
>>> to encode the ECN information.=C2=A0 Call the second one ACK_E= CN...
>>>
>>> I'm not convinced that optimizing for the awkward space be= tween 16 and
>>> 64 is worth the extra complexity of a variant encoding of the = frame.
>>> There are other ways to optimize for the cost of that occasion= al octet
>>> that seem like they would be more fruitful (like truncating AC= K frames
>>> more aggressively).
>>
>>
>> --
>>
>> Magnus Westerlund
>>
>> ------------------------------------------------------------<= wbr>----------
>> Network Architecture & Protocols, Ericsson Research
>> ------------------------------------------------------------<= wbr>----------
>> Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0| Phone=C2=A0 +46 10 7148287
>> Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile= +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ------------------------------------------------------------<= wbr>----------
>>
>

--000000000000c77cf605746a5537-- From nobody Mon Aug 27 19:16:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983F1130E01 for ; Mon, 27 Aug 2018 19:16:48 -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, FREEMAIL_FROM=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 aSwxonuHX4k1 for ; Mon, 27 Aug 2018 19:16:46 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1CC130EE1 for ; Mon, 27 Aug 2018 19:16:46 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id p84-v6so100875oic.4 for ; Mon, 27 Aug 2018 19:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jzpS1eU2GjcABiX+Rwefo/1G2NeS1lw7fi9DN9CQ/Yo=; b=hkiZMsBKNP645MY9pvwKCIQELB+/dYyze/ua8Wq+4NOsXrQuacQRJVs/ljBTtwceKU YK8qLtrFOaOB9E7Np2ZR+XwE066cJ7Qr4Ajacd6uW/GHoUGaFIVU7exIfTRL6xCYz7XT GwM7DIkKaVXw1BYrPkkE3JLBK7mDdk48CI+J6cjYqw72+9Ld1vQu986hneF1FAVw35yO 2a512aEYOrJskw+ghLeCcKabtLZCukK5dQEL/h5YKp0Lr7dQmN/jWhsUo9ch+zN2S4ir l/RCrr7nY9LYTzT4jIjxpNrPOugLA2C5z7APFXwQS1R8KKhAOTiDelmuJTknNTVeSMrV mPRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jzpS1eU2GjcABiX+Rwefo/1G2NeS1lw7fi9DN9CQ/Yo=; b=M4CFg0o211oXKZipElXtpEVQbBFsp138eXud+qo9P/DQ4mKQB3vepfaRVppXHOM5Ml rlPWNZqROIIOHTNfkR+CeFQGda3fCskE5tHhdViBuubJ9K3W2o9Nd4TZPGpQnr8ZiCFX I2GIl0v4bIu4PRxLlfePLDDeiD/m2hUcSwrwxKgDZnhDc/QnmqXibM2758v6NDOf5T0p 2iXCpRYC1L8UOAt0z4lWQQZJiGuRO/bcmjtKLyhTMYCdtlw8VHSnjG7zBpGG10i9o4Ew z4sYuCCYQG8DHjFQlOsyOSkwEsgzzqW6NvmnqDXhq0g0eGrs/K2vN50K6JRFAptDZFRj 0f1g== X-Gm-Message-State: APzg51A5nCXuihibg1sKUQZvehdwJc2lGcXafoSndRopjvT/9EsNORxv Ioyg5eft4d0tnyRxj0MA1Egcyc5TabTDI5YjlKw= X-Google-Smtp-Source: ANB0VdYRT+VYhEm2nXb/5J25szxpcvIdP69a3n69Ew6iHvalqhApKNdefLYl/J8hTxBgI0Np02i7bGis33C0f/G8naY= X-Received: by 2002:aca:da88:: with SMTP id r130-v6mr1052813oig.163.1535422605404; Mon, 27 Aug 2018 19:16:45 -0700 (PDT) MIME-Version: 1.0 References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> In-Reply-To: From: Martin Thomson Date: Tue, 28 Aug 2018 12:16:35 +1000 Message-ID: Subject: Re: Unified ACK frame encoding To: Eric Rescorla Cc: Magnus Westerlund , Ian Swett , Jana Iyengar , Brian Trammell , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 02:16:49 -0000 I'm not saying that these are invalid complaints, but I don't reach the same conclusion on the subjective assessment of balance of concerns. I don't think that this is significantly more complicated than existing code. Rather than switch on all four values of the type, zero (gap) and non-zero (acknowledged) is simple enough. Extension in the future necessarily uses new frame types, which aren't constrained. For v1, I really hope that no one attempts to extend before we ship. On Mon, Aug 27, 2018 at 11:02 PM Eric Rescorla wrote: > > Yes, this PR reflects what I believed you were proposing. I believe the o= bjections I raised here continue to apply. > > -Ekr > > > On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson wrote: >> >> I think that this is simpler. See >> https://github.com/quicwg/base-drafts/pull/1706 for a draft. >> On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla wrote: >> > >> > On balance I don't think I'm in favor of this bit-packing technique be= cause it complicates the ordinary ACK frame even for people who don't care = about ECN (and not doing so was part of why we decided to have another fram= e type in the first place). Moreover, it's not a scalable extension method,= so anything *else* we want to add to the ACK frame will just need some oth= er technique. >> > >> > -Ekr >> > >> > >> > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund wrote: >> >> >> >> Hi, >> >> >> >> Catching up. I have posted on github (https://github.com/quicwg/base-= drafts/issues/1439) some consideration what this implies in regards to ack = frame sizes for different cases discussed. >> >> >> >> I think Martins design here with being able to switch between each di= fferent type of marking as well as being able to reasonably efficient encod= e any range lengths without issues are a good one. My analysis on the githu= b isssue showed that in low rate changes is is equivalent to a single byte = design as well as being better capable of handling longer ranges of the sam= e type. >> >> >> >> I think it is worth continuing with this one. If one wants to use the= 2-bit type field for an explicitly encoded 4 alternative one or use the de= lta encoding can of course be discussed. I would prefer the delta encoding = to avoid the information loss and the need for specifying what is the defau= lt ECT value and what to do in situations with a none expected one. >> >> >> >> Cheers >> >> >> >> Magnus >> >> >> >> >> >> >> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: >> >>> >> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett wrot= e: >> >>>> >> >>>> There are a few things I like about this proposal: >> >>>> 1) It makes ECN and ACK_ECN either the same(or more similar) >> >>>> 2) As Kazuho said, it provides more precise feedback about which pa= ckets were marked, which avoids some edge cases we've had to write up in th= e current text around ack loss and being unsure of exactly when recovery is= exited. >> >>>> 3) It doesn't get more expensive as the connection goes on. This i= s an unfortunate property of the current design. >> >>>> >> >>>> I find Jana's variation on this particularly interesting, because i= f ECN isn't negotiated, I don't think there a reason to add any overhead. = >From personal experience, if you find a form of feedback valuable(whether i= t's ECN or timestamps for one-way-delay), then you're happy to consume a fe= w extra bytes to get better feedback. If the extra information isn't usefu= l for whatever reason, it's just wasted bytes. >> >>> >> >>> OK, 4 values is definitely easier to reason about. Merging ECT(0) a= nd >> >>> ECT(1) into the same bucket is easy as long as we're OK with that. >> >>> The simpler encoding is easier to describe and write code for, and w= e >> >>> can just tolerate (or reject) two adjacent ranges of the same type, >> >>> just as we might tolerate (or reject) a trailing gap. >> >>> >> >>>> So overall this seems like an improvement we should do, but I'd pre= fer a variant that doesn't increase the ACK frame size when ECN is disabled= or there are no ECN marks to report. FYI, if we need to steal a bit from = the number of ack blocks, I'm ok with that since I expect more than 32 ack = blocks to be very rare. >> >>> >> >>> This is very close to a variant I suggested on the issue, which we >> >>> agreed pretty quickly wasn't great. You can create two ACK frames, >> >>> one with the full expressiveness, and another that has the potential >> >>> to encode the ECN information. Call the second one ACK_ECN... >> >>> >> >>> I'm not convinced that optimizing for the awkward space between 16 a= nd >> >>> 64 is worth the extra complexity of a variant encoding of the frame. >> >>> There are other ways to optimize for the cost of that occasional oct= et >> >>> that seem like they would be more fruitful (like truncating ACK fram= es >> >>> more aggressively). >> >> >> >> >> >> -- >> >> >> >> Magnus Westerlund >> >> >> >> ---------------------------------------------------------------------= - >> >> Network Architecture & Protocols, Ericsson Research >> >> ---------------------------------------------------------------------= - >> >> Ericsson AB | Phone +46 10 7148287 >> >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> ---------------------------------------------------------------------= - >> >> >> > > > From nobody Tue Aug 28 00:02:14 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00F0130E4B for ; Tue, 28 Aug 2018 00:02:11 -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, FREEMAIL_FROM=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 ewJJimRyjCzj for ; Tue, 28 Aug 2018 00:02:09 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 A1870130DE9 for ; Tue, 28 Aug 2018 00:02:08 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id p6-v6so481053ljc.5 for ; Tue, 28 Aug 2018 00:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gw+WtCqG0RwHj4e+VBMNZfM/zjWgh8/kt9F6Qtz4MKQ=; b=ayiqQ4UetS5NiG1puB0EgEEEKqrjqULgRg6DcMgPZHcu1RFE+5bJwFdhMf1o5ww1vA zJ34Il+pKszACbg6tUf05FLV8Oif4UYo3/i0MKJqiPl/kWbf/fKY76Cg1cqu/+5vg2nj J9aChUGtyVTlFRAbFPdmbBmvf+9PVhBHXbuw0cSkPjwhjz6bEdG4TNEnaEJWRhVv0wQI eRs2sGzavlL8v70WVEbwVMzTySOaD5fnsMwgPT2IUOFAou88o13eOyf4YGfEkqDi9c+t RVu1ydnMQ4i7BwYNCCGfXAaH3jw1tFiyLJVfm/w3q+miXwHzmUxXDI583+8U3aBUY2bW Zl2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gw+WtCqG0RwHj4e+VBMNZfM/zjWgh8/kt9F6Qtz4MKQ=; b=bYSnfZPT9HfgBW4IHBkcuIWwkU7w+l3/dAtnVLAwx+uKWXJyJ17yjfzyOpwM9EnVh0 h58BeHCXlNRe/YZMJYiSUrogp3OemKrxackm8KAppqjkrc/lYJj6Xs75+eJcGMu38IHJ /Oy213VSF8kQLLX7nCJYhu35VbN5jnoMQ2Uatn3h6M4oc1/fyvK9t9VkghtFu9CfHtxb 01luSk894sgXjfhT32x6Knv9/hedq9UsqqNszWu8NWiqcsNPAhJaNKpN6D0KtBhkBxTg XhQOvy8hzGyeaHlWRXZx4U0dnUeJngpMErshHB225tFoJH5yCapvfewC83uqT7XP1F3j zX7A== X-Gm-Message-State: APzg51DZ7Y5uvmFuNw7JqC1J4KVRqQZ08gmQLiukTNRdbFo4q97jI08W bSuLcdnFQY5e+WwrMuM2iWMoJ4UypyQ24xV5c1Y= X-Google-Smtp-Source: ANB0VdadvWcd6Jue39LBHXPZuV/Nw14JPgdqVCMCvi3+gOBP6rPceI3oNGThMZjO9YPIh7KIVtazyBe8aggUbVeCwQ4= X-Received: by 2002:a2e:2e02:: with SMTP id u2-v6mr244568lju.77.1535439726830; Tue, 28 Aug 2018 00:02:06 -0700 (PDT) MIME-Version: 1.0 References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> In-Reply-To: From: Kazuho Oku Date: Tue, 28 Aug 2018 16:01:12 +0900 Message-ID: Subject: Re: Unified ACK frame encoding To: Eric Rescorla Cc: Magnus Westerlund , Jana Iyengar , Brian Trammell , Ian Swett , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 07:02:12 -0000 2018=E5=B9=B48=E6=9C=8827=E6=97=A5(=E6=9C=88) 7:55 Eric Rescorla : > > On balance I don't think I'm in favor of this bit-packing technique becau= se it complicates the ordinary ACK frame even for people who don't care abo= ut ECN (and not doing so was part of why we decided to have another frame t= ype in the first place). IMO, Martin's PR (#1706) is in good balance. The design provides two big design wins to QUIC stacks that care about ECN: unified frame type and accurate signaling of ECN. The design also removes the requirement of requiring QUIC stacks that *do not care about ECN handling ACK_ECN in some way*. At the moment, QUIC endpoints do not negotiate the use of ECN in a secure form, which means that a middlebox can inject an Initial frame carrying an ACK_ECN frame. All endpoints (even those do not care about ECN) need to handle that in some way. One way to mitigate the issue is to forbid use of ACK_ECN in Initial packets, but that requires us to have a special case... that would be an additional complexity. Considering these aspects, I think that having a unified frame type that encodes the type of every ACK block is a reasonable solution. The only thing I feel (a bit) uneasy about #1706 is that it only has four modes, requiring some negotiation to handle ECT(1) markings. My preference is to send 5 modes (possibly encoded in 2-bits as we have discussed on list), so that we do not need to make changes to the QUIC specification for ECN experiments / future extensions. > Moreover, it's not a scalable extension method, so anything *else* we wan= t to add to the ACK frame will just need some other technique. > > -Ekr > > > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund wrote: >> >> Hi, >> >> Catching up. I have posted on github (https://github.com/quicwg/base-dra= fts/issues/1439) some consideration what this implies in regards to ack fra= me sizes for different cases discussed. >> >> I think Martins design here with being able to switch between each diffe= rent type of marking as well as being able to reasonably efficient encode a= ny range lengths without issues are a good one. My analysis on the github i= sssue showed that in low rate changes is is equivalent to a single byte des= ign as well as being better capable of handling longer ranges of the same t= ype.. >> >> I think it is worth continuing with this one. If one wants to use the 2-= bit type field for an explicitly encoded 4 alternative one or use the delta= encoding can of course be discussed. I would prefer the delta encoding to = avoid the information loss and the need for specifying what is the default = ECT value and what to do in situations with a none expected one. >> >> Cheers >> >> Magnus >> >> >> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: >>> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett wrote: >>>> >>>> There are a few things I like about this proposal: >>>> 1) It makes ECN and ACK_ECN either the same(or more similar) >>>> 2) As Kazuho said, it provides more precise feedback about which packe= ts were marked, which avoids some edge cases we've had to write up in the c= urrent text around ack loss and being unsure of exactly when recovery is ex= ited. >>>> 3) It doesn't get more expensive as the connection goes on. This is a= n unfortunate property of the current design. >>>> >>>> I find Jana's variation on this particularly interesting, because if E= CN isn't negotiated, I don't think there a reason to add any overhead. Fro= m personal experience, if you find a form of feedback valuable(whether it's= ECN or timestamps for one-way-delay), then you're happy to consume a few e= xtra bytes to get better feedback. If the extra information isn't useful f= or whatever reason, it's just wasted bytes.. >>> >>> OK, 4 values is definitely easier to reason about. Merging ECT(0) and >>> ECT(1) into the same bucket is easy as long as we're OK with that. >>> The simpler encoding is easier to describe and write code for, and we >>> can just tolerate (or reject) two adjacent ranges of the same type, >>> just as we might tolerate (or reject) a trailing gap. >>> >>>> So overall this seems like an improvement we should do, but I'd prefer= a variant that doesn't increase the ACK frame size when ECN is disabled or= there are no ECN marks to report. FYI, if we need to steal a bit from the= number of ack blocks, I'm ok with that since I expect more than 32 ack blo= cks to be very rare. >>> >>> This is very close to a variant I suggested on the issue, which we >>> agreed pretty quickly wasn't great. You can create two ACK frames, >>> one with the full expressiveness, and another that has the potential >>> to encode the ECN information. Call the second one ACK_ECN... >>> >>> I'm not convinced that optimizing for the awkward space between 16 and >>> 64 is worth the extra complexity of a variant encoding of the frame. >>> There are other ways to optimize for the cost of that occasional octet >>> that seem like they would be more fruitful (like truncating ACK frames >>> more aggressively). >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Network Architecture & Protocols, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> > --=20 Kazuho Oku From nobody Tue Aug 28 01:49:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C61130DEB for ; Tue, 28 Aug 2018 01:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5Tzc0_vZIMT for ; Tue, 28 Aug 2018 01:49:02 -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 5E77A130DDF for ; Tue, 28 Aug 2018 01:49:02 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id 13-v6so1485466ois.1 for ; Tue, 28 Aug 2018 01:49:02 -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=AZQT8nn6fdljMd3FSevep4O5Q7vGfvHLuD6HCnGyKpY=; b=qVQLwu6Kvq6HvDwmbfkkGiZhA8SDBp9sSU7avJshkC+sQPT9HRRGquwbYEoc4IQ7Qg wixUiYT9pbYl/X0HdGWysA5wBUJLhknKBRu6fbGf5VlF4XhdOHVCeaYorHrhZ7ZMFRLp zwRuyYV7nxYtZQSKZXSNDy8kbheKWmJVl3AnMHXnhgCFjkHWl0gDMZ9pCID/eEUFaKSw fWLqV0RaJaOzlEHu7mqPPKO9qTnUEHqc547ywtMcwZQvMZSxr1gr1YH2E7N7kqyioR3v rPDAAQbEV+MBHG78b6FH4nM9g9z/GZssy7OnBuKmDFZt+2kAtANocL5T/VJuXU2WE564 D1jw== 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=AZQT8nn6fdljMd3FSevep4O5Q7vGfvHLuD6HCnGyKpY=; b=jEqcetIX74DrIr0eUbFBRZ6e8wzZaIf6dbr/z2AKlCWvxdOoJG2ke2NTVbX5QOtJeW 16AKrMXHZTRO0r2PkzMOXewdzNa2lAJ2nuwZNzKB+pGFGNrLOVH95VK/OEeGEcHOKPzp GZG53R3E2TtUt3lHVP5GuW3nBLAv1gLFXUSpGsr/3VwjPzZdhILzHbIBjvXw601Z2JKZ BdRgCVTbAmRplQz0MmfOPU5CiAlFR1wN7krQnANKyQbGCxmiBGh8RM9qphOTOTfE6l4u hQlTpaVxsem1DjSKu5PNCBSh8uw9nUAaaRM3X7CN7U7iuR1wfVZZR11zCYqGTG1z2D4w /G2Q== X-Gm-Message-State: APzg51A/hYJczOguXYK2o+JdN2sUEveOTk/XKtAAZ7YfNOm+/1PDVNmb P8NKwTLy1E4mxi7Lam7cw5F4Uw4UxIP/7lAB8aw= X-Google-Smtp-Source: ANB0VdZTic18g+vX3gTzSQRgBatkqTSIK/T2AjB2jcoD8XcpMjbKo7NVygXW7dV0MXVqLxg0nD83V6fmgN35V2Nfrds= X-Received: by 2002:aca:5b57:: with SMTP id p84-v6mr232917oib.109.1535446141720; Tue, 28 Aug 2018 01:49:01 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 28 Aug 2018 01:49:01 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 28 Aug 2018 01:49:00 -0700 Message-ID: Subject: Re: Unified ACK frame encoding To: Eric Rescorla , Kazuho Oku Cc: Martin Thomson , Jana Iyengar , IETF QUIC WG , Magnus Westerlund , Ian Swett , Brian Trammell Content-Type: multipart/alternative; boundary="000000000000d95d9505747ae97d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 08:49:05 -0000 --000000000000d95d9505747ae97d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Kazuho. I wonder if the ECT(1) could be carried in two bits as follows: If a single unmarked packet globally disables ECN, then we can have an ECN mode signalling frame that is only sent once before any ACK frame with unmarked packets. This signalling frame disables ECN. The two bit code is still the same as Martin=E2=80=99s proposal, but now it is possible to dist= inguish between ECT(1) and ECT(0) explicitly. Due to packet loss and reordering, the ECN mode signalling frame can be out of sync with ACK=E2=80=99s, but it may not be a problem that a few ACK fram= es are misinterpreted for a while. If this is a concern, the ECN mode frame can be a prefix to every ACK frame, at least for a while, or until the same frame is received from peer. Peers that do not are about ECN can just ignore the signalling frame (or reflect it once) and treat non-zero two-bit code as an ACK. On 28 August 2018 at 09.02.29, Kazuho Oku (kazuhooku@gmail.com) wrote: 2018=E5=B9=B48=E6=9C=8827=E6=97=A5(=E6=9C=88) 7:55 Eric Rescorla : > > On balance I don't think I'm in favor of this bit-packing technique because it complicates the ordinary ACK frame even for people who don't care about ECN (and not doing so was part of why we decided to have another frame type in the first place). IMO, Martin's PR (#1706) is in good balance. The design provides two big design wins to QUIC stacks that care about ECN: unified frame type and accurate signaling of ECN. The design also removes the requirement of requiring QUIC stacks that *do not care about ECN handling ACK_ECN in some way*. At the moment, QUIC endpoints do not negotiate the use of ECN in a secure form, which means that a middlebox can inject an Initial frame carrying an ACK_ECN frame. All endpoints (even those do not care about ECN) need to handle that in some way. One way to mitigate the issue is to forbid use of ACK_ECN in Initial packets, but that requires us to have a special case... that would be an additional complexity. Considering these aspects, I think that having a unified frame type that encodes the type of every ACK block is a reasonable solution. The only thing I feel (a bit) uneasy about #1706 is that it only has four modes, requiring some negotiation to handle ECT(1) markings. My preference is to send 5 modes (possibly encoded in 2-bits as we have discussed on list), so that we do not need to make changes to the QUIC specification for ECN experiments / future extensions. > Moreover, it's not a scalable extension method, so anything *else* we want to add to the ACK frame will just need some other technique. > > -Ekr > > > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: >> >> Hi, >> >> Catching up. I have posted on github ( https://github.com/quicwg/base-drafts/issues/1439) some consideration what this implies in regards to ack frame sizes for different cases discussed. >> >> I think Martins design here with being able to switch between each different type of marking as well as being able to reasonably efficient encode any range lengths without issues are a good one. My analysis on the github isssue showed that in low rate changes is is equivalent to a single byte design as well as being better capable of handling longer ranges of the same type.. >> >> I think it is worth continuing with this one. If one wants to use the 2-bit type field for an explicitly encoded 4 alternative one or use the delta encoding can of course be discussed. I would prefer the delta encoding to avoid the information loss and the need for specifying what is the default ECT value and what to do in situations with a none expected one. >> >> Cheers >> >> Magnus >> >> >> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: >>> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett wrote: >>>> >>>> There are a few things I like about this proposal: >>>> 1) It makes ECN and ACK_ECN either the same(or more similar) >>>> 2) As Kazuho said, it provides more precise feedback about which packets were marked, which avoids some edge cases we've had to write up in the current text around ack loss and being unsure of exactly when recovery is exited. >>>> 3) It doesn't get more expensive as the connection goes on. This is an unfortunate property of the current design. >>>> >>>> I find Jana's variation on this particularly interesting, because if ECN isn't negotiated, I don't think there a reason to add any overhead. >From personal experience, if you find a form of feedback valuable(whether it's ECN or timestamps for one-way-delay), then you're happy to consume a few extra bytes to get better feedback. If the extra information isn't useful for whatever reason, it's just wasted bytes.. >>> >>> OK, 4 values is definitely easier to reason about. Merging ECT(0) and >>> ECT(1) into the same bucket is easy as long as we're OK with that. >>> The simpler encoding is easier to describe and write code for, and we >>> can just tolerate (or reject) two adjacent ranges of the same type, >>> just as we might tolerate (or reject) a trailing gap. >>> >>>> So overall this seems like an improvement we should do, but I'd prefer a variant that doesn't increase the ACK frame size when ECN is disabled or there are no ECN marks to report. FYI, if we need to steal a bit from the number of ack blocks, I'm ok with that since I expect more than 32 ack blocks to be very rare. >>> >>> This is very close to a variant I suggested on the issue, which we >>> agreed pretty quickly wasn't great. You can create two ACK frames, >>> one with the full expressiveness, and another that has the potential >>> to encode the ECN information. Call the second one ACK_ECN... >>> >>> I'm not convinced that optimizing for the awkward space between 16 and >>> 64 is worth the extra complexity of a variant encoding of the frame. >>> There are other ways to optimize for the cost of that occasional octet >>> that seem like they would be more fruitful (like truncating ACK frames >>> more aggressively). >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Network Architecture & Protocols, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> > --=20 Kazuho Oku --000000000000d95d9505747ae97d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I agree with Kazuho.=

I wonder if the ECT(= 1) could be carried in two bits as follows:

If a single unmarked packet globally disables ECN, t= hen we can have an ECN mode signalling frame that is only sent once before = any ACK frame with unmarked packets. This signalling frame disables ECN. Th= e two bit code is still the same as Martin=E2=80=99s proposal, but now it i= s possible to distinguish between ECT(1) and ECT(0) explicitly.

Due to packet loss and reorderin= g, the ECN mode signalling frame can be out of sync with ACK=E2=80=99s, but= it may not be a problem that a few ACK frames are misinterpreted for a whi= le. If this is a concern, the ECN mode frame can be a prefix to every ACK f= rame, at least for a while, or until the same frame is received from peer.<= /div>

Peers that do not are= about ECN can just ignore the signalling frame (or reflect it once) and tr= eat non-zero two-bit code as an ACK.



On 28 Augus= t 2018 at 09.02.29, Kazuho Oku (kazu= hooku@gmail.com) wrote:

2018=E5=B9=B48=E6=9C=8827=E6=97=A5(=E6=9C=88) = 7:55 Eric Rescorla <ekr@rtfm.com>= :
>
> On balance I don't think I'm in favor of this bit-packing = technique because it complicates the ordinary ACK frame even for people who= don't care about ECN (and not doing so was part of why we decided to h= ave another frame type in the first place).

IMO, Martin's PR (#1706) is in good balance.

The design provides two big design wins to QUIC stacks that care about
ECN: unified frame type and accurate signaling of ECN.

The design also removes the requirement of requiring QUIC stacks that
*do not care about ECN handling ACK_ECN in some way*. At the moment,
QUIC endpoints do not negotiate the use of ECN in a secure form, which
means that a middlebox can inject an Initial frame carrying an ACK_ECN
frame. All endpoints (even those do not care about ECN) need to handle
that in some way. One way to mitigate the issue is to forbid use of
ACK_ECN in Initial packets, but that requires us to have a special
case... that would be an additional complexity.

Considering these aspects, I think that having a unified frame type
that encodes the type of every ACK block is a reasonable solution.

The only thing I feel (a bit) uneasy about #1706 is that it only has
four modes, requiring some negotiation to handle ECT(1) markings. My
preference is to send 5 modes (possibly encoded in 2-bits as we have
discussed on list), so that we do not need to make changes to the QUIC
specification for ECN experiments / future extensions.

> Moreover, it's not a scalable extension method, so anything *e= lse* we want to add to the ACK frame will just need some other technique.
>
> -Ekr
>
>
> On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund <magnus.westerlund@ericsson.com&g= t; wrote:
>>
>> Hi,
>>
>> Catching up. I have posted on github (https://github.com/quicwg/base-drafts= /issues/1439) some consideration what this implies in regards to ack fr= ame sizes for different cases discussed.
>>
>> I think Martins design here with being able to switch between = each different type of marking as well as being able to reasonably efficien= t encode any range lengths without issues are a good one. My analysis on th= e github isssue showed that in low rate changes is is equivalent to a singl= e byte design as well as being better capable of handling longer ranges of = the same type..
>>
>> I think it is worth continuing with this one. If one wants to = use the 2-bit type field for an explicitly encoded 4 alternative one or use= the delta encoding can of course be discussed. I would prefer the delta en= coding to avoid the information loss and the need for specifying what is th= e default ECT value and what to do in situations with a none expected one.
>>
>> Cheers
>>
>> Magnus
>>
>>
>>
>> Den 2018-08-13 kl. 08:29, skrev Martin Thomson:
>>>
>>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett <ianswett@google.com> wrote:
>>>>
>>>> There are a few things I like about this proposal:
>>>> 1) It makes ECN and ACK_ECN either the same(or more si= milar)
>>>> 2) As Kazuho said, it provides more precise feedback a= bout which packets were marked, which avoids some edge cases we've had = to write up in the current text around ack loss and being unsure of exactly= when recovery is exited.
>>>> 3) It doesn't get more expensive as the connection= goes on. This is an unfortunate property of the current design.
>>>>
>>>> I find Jana's variation on this particularly inter= esting, because if ECN isn't negotiated, I don't think there a reas= on to add any overhead. From personal experience, if you find a form of fe= edback valuable(whether it's ECN or timestamps for one-way-delay), then= you're happy to consume a few extra bytes to get better feedback. If = the extra information isn't useful for whatever reason, it's just w= asted bytes..
>>>
>>> OK, 4 values is definitely easier to reason about. Mergin= g ECT(0) and
>>> ECT(1) into the same bucket is easy as long as we're O= K with that.
>>> The simpler encoding is easier to describe and write code = for, and we
>>> can just tolerate (or reject) two adjacent ranges of the s= ame type,
>>> just as we might tolerate (or reject) a trailing gap.
>>>
>>>> So overall this seems like an improvement we should do= , but I'd prefer a variant that doesn't increase the ACK frame size= when ECN is disabled or there are no ECN marks to report. FYI, if we need= to steal a bit from the number of ack blocks, I'm ok with that since I= expect more than 32 ack blocks to be very rare.
>>>
>>> This is very close to a variant I suggested on the issue, = which we
>>> agreed pretty quickly wasn't great. You can create tw= o ACK frames,
>>> one with the full expressiveness, and another that has the= potential
>>> to encode the ECN information. Call the second one ACK_EC= N...
>>>
>>> I'm not convinced that optimizing for the awkward spac= e between 16 and
>>> 64 is worth the extra complexity of a variant encoding of = the frame.
>>> There are other ways to optimize for the cost of that occa= sional octet
>>> that seem like they would be more fruitful (like truncatin= g ACK frames
>>> more aggressively).
>>
>>
>> --
>>
>> Magnus Westerlund
>>
>> --------------------------------------------------------------= --------
>> Network Architecture & Protocols, Ericsson Research
>> --------------------------------------------------------------= --------
>> Ericsson AB | Phone +46 10 7148287
>> Torshamnsgatan 23 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> --------------------------------------------------------------= --------
>>
>


-- =20
Kazuho Oku

--000000000000d95d9505747ae97d-- From nobody Tue Aug 28 01:55:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596CB130E45 for ; Tue, 28 Aug 2018 01:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 c3nZ6ZL5ruiu for ; Tue, 28 Aug 2018 01:55:35 -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 DCEE1130DF3 for ; Tue, 28 Aug 2018 01:55:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.53,298,1531810800"; d="asc'?scan'208";a="280892584" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx143-out.netapp.com with ESMTP; 28 Aug 2018 01:55:34 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 28 Aug 2018 01:55:34 -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.1395.4; Tue, 28 Aug 2018 01:55:34 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 28 Aug 2018 01:55:33 -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:X-MS-Exchange-SenderADCheck; bh=9Q2bk0i6v2DeHmxWr6giYDqEZS7MqTLvH+g3T5QeFNY=; b=m0B5W1OG6f4yCU++57OtIe3v3yGwsLs6SZJM2Kq8KbBGAjJcdjodqIrSi8bD4T7j7+7/cidJAYaXOf8xfd57urR77AIPcw7dzzk8lS4cp1xomiuApbcTuI0zx+MkGRbJuV7Wot+P93vxmYg3uHw0lX3i1YzksmZWeLg3Pdk3OPs= Received: from MWHPR06MB2830.namprd06.prod.outlook.com (10.175.138.7) by MWHPR06MB2574.namprd06.prod.outlook.com (10.168.208.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.14; Tue, 28 Aug 2018 08:55:32 +0000 Received: from MWHPR06MB2830.namprd06.prod.outlook.com ([fe80::ac73:d037:9315:7c65]) by MWHPR06MB2830.namprd06.prod.outlook.com ([fe80::ac73:d037:9315:7c65%4]) with mapi id 15.20.1080.015; Tue, 28 Aug 2018 08:55:32 +0000 From: "Eggert, Lars" To: Kazuho Oku CC: Eric Rescorla , Magnus Westerlund , Jana Iyengar , "Ian Swett" , Brian Trammell , IETF QUIC WG , Martin Thomson Subject: Re: Unified ACK frame encoding Thread-Topic: Unified ACK frame encoding Thread-Index: AQHUL5S95bm3GZTUHk6+01Gum6wk1qS291EAgAAVQwCAAM9sgIAFYuGAgBHVywCAA6utAIACGkwAgAAf7wA= Date: Tue, 28 Aug 2018 08:55:32 +0000 Message-ID: <04F65BF2-5F26-44D9-96E0-C8530FC717F1@netapp.com> References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.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.9.1) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [62.248.255.56] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR06MB2574; 6:oc9xBf+gCE+oSQ7GqdOss5UzfKv5+JawYIWCKDQLfytV8S4QpbRhAnCr7YWZAV1PZsWr/svgGSobklGY/WgbgAZs6tVTkaoH+WCIUgmEuJ5WziG1kBickqmEcA5lFUjHbu1uhG5aCAKwUDHPZGnbnLcDm3vgPLXIEvL6WYn7xxRVMxt61QY7zv0UD1RMt/vFwmctTfEMf7J+NccZ7fxWWt8mScGUBTVpYiXauigBafaEjKsXXDUfnbVdDZmM+VZCK3pIvgYVbmIHdJb544Lhhl0kpGHjWA+vF98IZv8NM5XlX9eKf7WUEbpA69KkRFZiZ/WzSy6XpcGzEeSdL3ceaIfLiKQjYPyseAepaD+3a67vBgmpld4mF6yzMn8Hn7Sc9YWslu2Jdk3vt06c2sT9HItuYKdCMGsVB9d9pWIHo6J307C6IRhbYOcYXXy78fhCwG8uXOqgqs5JZmgMxvIDYQ==; 5:MYDULx9ino1BipaIAQ/nNqJMp5ohZu5gvWedo8CYq5kaGENuIIRKJe5PPdVRY63TnUt6CiSO55kTgioORoqHUtgXHNaZK46CaldEG1HKrpjDAhq2wGiKXrJQef4MiBPn2SoJNMxqHx9DPn9Sm15SAff0fd+5zOjxE6ziTg+Wdtg=; 7:qam1R3jiIT8tYYbusf85tIQmAqcOxdvnzKp0eBKAf/hkYHo4Q2CvzxJgDGwk52rXqNCIdu21tcO6xfFhnDw+wv3sX5p1yXaT2AfuRdkJWQERGff1spSwERWHRCXaZbHknZ4IR0QaODiHFgkCy7lvL2TtOIQEeg7zwdNh5CRKnxhbTUbhfGfiilZi+T+8ORZ/jTUCvG4FUuMgLtUYNuNpFI9VP8ND4SB8ue5Ys3+qntgr5F86qt5sDwx4H70m3BL/ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6da51e76-ab79-4366-3277-08d60cc4033d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(49563074)(7193020); SRVR:MWHPR06MB2574; x-ms-traffictypediagnostic: MWHPR06MB2574: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(201708071742011)(7699016); SRVR:MWHPR06MB2574; BCL:0; PCL:0; RULEID:; SRVR:MWHPR06MB2574; x-forefront-prvs: 077884B8B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(136003)(366004)(396003)(199004)(189003)(51444003)(50226002)(6246003)(558084003)(53546011)(86362001)(256004)(54906003)(6506007)(76176011)(97736004)(2900100001)(2906002)(6436002)(5250100002)(33656002)(5660300001)(36756003)(83716003)(39060400002)(3480700004)(316002)(99286004)(68736007)(4326008)(478600001)(8936002)(25786009)(14454004)(8676002)(82746002)(102836004)(81166006)(57306001)(26005)(6512007)(7736002)(1411001)(305945005)(66066001)(105586002)(3846002)(93886005)(6116002)(81156014)(53936002)(99936001)(186003)(2616005)(11346002)(486006)(6486002)(476003)(106356001)(446003)(229853002)(4001150100001)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR06MB2574; H:MWHPR06MB2830.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4LfaSacAKw6+tt0JTe45Gp58bZh2A1Xow5KLO42M1UhMg6ZbK5mmQL4lW8vm2L0odR4mme88URe1dAIa6YTIhA1n+W+bOs6F5sxtf6mkVOiQBdvPZe5nCqFFLzQ9U1vlealILtXHQAyAVS2uqDCCOCkIzbqfE0vSudB3GupcJq5aoSs6xGf5faOZUFovz8ukiNZ549epBS8P6WYD6/WbWWHLOV+4vHJ6B41VIlrx57E2WBVAakaEirhWfufB0nyDUqFym4iDipkoKpKH3JiEIjRnqpoEZYH7zJ/RfSEPNl5lPos2KRFkWJQ4ZsEFD8rY5q3/DIWNiXlUicQ3hlZxu+nEB0c5qUEaZqv0bs+dQYo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_1172BBA6-8710-4B9C-8466-E053251CAEF5"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6da51e76-ab79-4366-3277-08d60cc4033d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2018 08:55:32.4467 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB2574 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 08:55:37 -0000 --Apple-Mail=_1172BBA6-8710-4B9C-8466-E053251CAEF5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2018-8-28, at 10:01, Kazuho Oku wrote: > Considering these aspects, I think that having a unified frame type > that encodes the type of every ACK block is a reasonable solution. +1 (as an individual) Lars --Apple-Mail=_1172BBA6-8710-4B9C-8466-E053251CAEF5 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAluFDgMACgkQVLXDCb9w wVchdg/+NtcAD3HNimLaJ/c37f/AxyN/4wboZUpqfyki+J3t+DJhu5OST4uh8AQP S1awnNM+YFf/VGBtLxqICLG3cQATAKb7N/BRtJ6Y998xqWoIMZTm81TSHjFtHrGB Yo8nLGeOBvw00k1SDqh9IeTJIvyEK3h0ScZgSFPdvA7fOHm7BYoHIkncGlCixm6N 4jkaoOlYf8JBTv5fw/IfqVynghipTHJv4nCtcMCvm+mvxYV13mwcq2p2ZRqHnQaD yEPi9ujXzKSTtShOVLHBdWEdGr1EpZFTfZCpnkXO56KmrckEvS8qt1E4E3Z4EQau ZXpc8IY4XyG5WzgW95YHa8fgdCP0IRv537hzIrAnTWeNFPpwjlP5cBenKd6wOFlc 8V7slY8gLyFoZmjmey41geX//K2CSvq6smHp4wUMM+BLR82uOWIp/3naSv32NhD8 TfilsmJcnWWoXH8IASCrDp/kpm9z8O10r/rcE5W8gOpPF1A/hx1QU1yifcbnio4/ qabML1JFbqXco6qrG683mi2WdPCT5BcefCarydzQdndkQH/p6RUPe3xoTXRp5Udj px/p/WbeGwd1RWbS6S0szgSXqE2eOKUPoM1hmaC/6QLXNFPU6g6ZwOkdZuEsXJ8k febaMpeOyD3/oqYWaJXwGVYN4fHIcOwKccPASOdhzF5Z1jairGA= =YryC -----END PGP SIGNATURE----- --Apple-Mail=_1172BBA6-8710-4B9C-8466-E053251CAEF5-- From nobody Tue Aug 28 01:58:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A74130DF3 for ; Tue, 28 Aug 2018 01:58: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 lAQlJa-F9Eaf for ; Tue, 28 Aug 2018 01:58:27 -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 7A5CA130DDF for ; Tue, 28 Aug 2018 01:58:27 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 66FCA3408E8; Tue, 28 Aug 2018 10:58:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.1285); Tue, 28 Aug 2018 10:58:24 +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; Tue, 28 Aug 2018 10:58:24 +0200 (CEST) Received: from [195.176.111.5] (account ietf@trammell.ch HELO public-docking-cx-4089.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65466908; Tue, 28 Aug 2018 10:58:24 +0200 From: "Brian Trammell (IETF)" Message-Id: <3EB5860E-55E0-484A-BEE0-11864C903D4D@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_D2AE572E-F807-414E-A170-2F18ACAA03E1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Unified ACK frame encoding Date: Tue, 28 Aug 2018 10:58:24 +0200 In-Reply-To: Cc: Eric Rescorla , Magnus Westerlund , Jana Iyengar , Ian Swett , IETF QUIC WG , Martin Thomson To: Kazuho Oku References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 08:58:30 -0000 --Apple-Mail=_D2AE572E-F807-414E-A170-2F18ACAA03E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Kazuho, all, > On 28 Aug 2018, at 09:01, Kazuho Oku wrote: >=20 > 2018=E5=B9=B48=E6=9C=8827=E6=97=A5(=E6=9C=88) 7:55 Eric Rescorla = : >>=20 >> On balance I don't think I'm in favor of this bit-packing technique = because it complicates the ordinary ACK frame even for people who don't = care about ECN (and not doing so was part of why we decided to have = another frame type in the first place). >=20 > IMO, Martin's PR (#1706) is in good balance. >=20 > The design provides two big design wins to QUIC stacks that care about > ECN: unified frame type and accurate signaling of ECN. >=20 > The design also removes the requirement of requiring QUIC stacks that > *do not care about ECN handling ACK_ECN in some way*. At the moment, > QUIC endpoints do not negotiate the use of ECN in a secure form, which > means that a middlebox can inject an Initial frame carrying an ACK_ECN > frame. All endpoints (even those do not care about ECN) need to handle > that in some way. One way to mitigate the issue is to forbid use of > ACK_ECN in Initial packets, but that requires us to have a special > case... that would be an additional complexity. >=20 > Considering these aspects, I think that having a unified frame type > that encodes the type of every ACK block is a reasonable solution. +1. I'm not sure it's a good idea to have a structural feature in the = protocol that separates "stacks that don't care about ECN" from "stacks = that care about ECN" -- to the extent possible, the design of the = protocol and the text of the standard should not encourage the former = while encouraging the latter. Cheers, Brian > The only thing I feel (a bit) uneasy about #1706 is that it only has > four modes, requiring some negotiation to handle ECT(1) markings. My > preference is to send 5 modes (possibly encoded in 2-bits as we have > discussed on list), so that we do not need to make changes to the QUIC > specification for ECN experiments / future extensions. >=20 >> Moreover, it's not a scalable extension method, so anything *else* we = want to add to the ACK frame will just need some other technique. >>=20 >> -Ekr >>=20 >>=20 >> On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund = wrote: >>>=20 >>> Hi, >>>=20 >>> Catching up. I have posted on github = (https://github.com/quicwg/base-drafts/issues/1439) some consideration = what this implies in regards to ack frame sizes for different cases = discussed. >>>=20 >>> I think Martins design here with being able to switch between each = different type of marking as well as being able to reasonably efficient = encode any range lengths without issues are a good one. My analysis on = the github isssue showed that in low rate changes is is equivalent to a = single byte design as well as being better capable of handling longer = ranges of the same type.. >>>=20 >>> I think it is worth continuing with this one. If one wants to use = the 2-bit type field for an explicitly encoded 4 alternative one or use = the delta encoding can of course be discussed. I would prefer the delta = encoding to avoid the information loss and the need for specifying what = is the default ECT value and what to do in situations with a none = expected one. >>>=20 >>> Cheers >>>=20 >>> Magnus >>>=20 >>>=20 >>>=20 >>> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: >>>>=20 >>>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett = wrote: >>>>>=20 >>>>> There are a few things I like about this proposal: >>>>> 1) It makes ECN and ACK_ECN either the same(or more similar) >>>>> 2) As Kazuho said, it provides more precise feedback about which = packets were marked, which avoids some edge cases we've had to write up = in the current text around ack loss and being unsure of exactly when = recovery is exited. >>>>> 3) It doesn't get more expensive as the connection goes on. This = is an unfortunate property of the current design. >>>>>=20 >>>>> I find Jana's variation on this particularly interesting, because = if ECN isn't negotiated, I don't think there a reason to add any = overhead. =46rom personal experience, if you find a form of feedback = valuable(whether it's ECN or timestamps for one-way-delay), then you're = happy to consume a few extra bytes to get better feedback. If the extra = information isn't useful for whatever reason, it's just wasted bytes.. >>>>=20 >>>> OK, 4 values is definitely easier to reason about. Merging ECT(0) = and >>>> ECT(1) into the same bucket is easy as long as we're OK with that. >>>> The simpler encoding is easier to describe and write code for, and = we >>>> can just tolerate (or reject) two adjacent ranges of the same type, >>>> just as we might tolerate (or reject) a trailing gap. >>>>=20 >>>>> So overall this seems like an improvement we should do, but I'd = prefer a variant that doesn't increase the ACK frame size when ECN is = disabled or there are no ECN marks to report. FYI, if we need to steal = a bit from the number of ack blocks, I'm ok with that since I expect = more than 32 ack blocks to be very rare. >>>>=20 >>>> This is very close to a variant I suggested on the issue, which we >>>> agreed pretty quickly wasn't great. You can create two ACK frames, >>>> one with the full expressiveness, and another that has the = potential >>>> to encode the ECN information. Call the second one ACK_ECN... >>>>=20 >>>> I'm not convinced that optimizing for the awkward space between 16 = and >>>> 64 is worth the extra complexity of a variant encoding of the = frame. >>>> There are other ways to optimize for the cost of that occasional = octet >>>> that seem like they would be more fruitful (like truncating ACK = frames >>>> more aggressively). >>>=20 >>>=20 >>> -- >>>=20 >>> Magnus Westerlund >>>=20 >>> = ---------------------------------------------------------------------- >>> Network Architecture & Protocols, Ericsson Research >>> = ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> Torshamnsgatan 23 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> = ---------------------------------------------------------------------- >>>=20 >>=20 >=20 >=20 > -- > Kazuho Oku --Apple-Mail=_D2AE572E-F807-414E-A170-2F18ACAA03E1 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluFDrAACgkQihK3vwvq RqNKLg/5Ab5gwXonnCnrX3JHKupB2JakanZihkRhhOdmATd3uHu+ufaQkQDciq0a /AYwhwL9vdSZkh0ucecttCO/bUetaIKlRO9P0wqBB/foFLhSL/bz+GNxcp3AV6FM dr+wJ7hE5nwRfjttktZAJ3ZSlMbtZWkAe5Tp4HeqtcRLbNbK3bGt+YGv6GULTmq0 LewgLcAn+PDrRiVEV0Gdy5LA9roQx3x+tXzWfnWlLImSlCuUF2RY6vJ90Z+wfiNg JhkxcMbl527o8xJLYKTkUNfypHGMSRiRqMjQT5Jo/YOcwWW/j1KNrek40lsT654l yC4uz75vX4b9WgcBobihF2q4pFf5khiyxooJ6GmtaPI1DSDUXmvwCotV7dM6IXEh /axdJKmcXUmfpDK+iGcN51mleD2i+xU0JN1Ez7amvg1iLgulfBF+Znbhz2Qvvwh9 ZWo7OSkDmFTOzZDil3mR27uTlHHA3wYiYie1ZvZy0YU8dS0KFqiFyIqyvE9GuN0K DmuSjVJ9WD/WtCr7NbW/4lrxTFF0zKPNqy6NMXixHU8uPo2NwIZP235nIoG/Ddrd nPsC1j92rRlN/0V67WTo6Fl0pE8wnFJ4Z9gynsV9EaNiGNwon7O81BV03wkdwvoC /35C/r1VFahDxShZRfEr1Yhknd6VUaS6D7X0ZPNYmMZOgGxm77o= =QbEI -----END PGP SIGNATURE----- --Apple-Mail=_D2AE572E-F807-414E-A170-2F18ACAA03E1-- From nobody Tue Aug 28 04:38:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D4D130EFF for ; Tue, 28 Aug 2018 04:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcNM2PfxzfQQ for ; Tue, 28 Aug 2018 04:38:38 -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 826AD130E95 for ; Tue, 28 Aug 2018 04:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1535456316; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pqveqpukiV/VpNDfYC1a97gs8Tcgs2dlhRGyC+55r/E=; b=CGlQTkEPD1/+tbtVkasojcAkVn9D6QxbgCS1jagINFfD9qNDBvyo37j9F+AMUUDt mf4x8V0mPjGYBKUsHgxBXu54LjojqrNAkpuCtZm2jIA51sTcst/NOGz/a0nQ2W6q fTShhQfPMn4B18R2tTJwFISjPzh3RNSkTY4NsodlxlY=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-2a-5b85343c4bac Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.A2.22015.C34358B5; Tue, 28 Aug 2018 13:38:36 +0200 (CEST) Received: from [147.214.162.1] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 28 Aug 2018 13:37:52 +0200 Subject: Re: Unified ACK frame encoding To: Kazuho Oku , Eric Rescorla CC: Jana Iyengar , Brian Trammell , Ian Swett , IETF QUIC WG , Martin Thomson References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> From: Magnus Westerlund Message-ID: <0c1c0cd5-fac3-d272-4fce-f6d3c75945e0@ericsson.com> Date: Tue, 28 Aug 2018 13:37:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-ClientProxiedBy: ESESSMB501.ericsson.se (153.88.183.162) To ESESSMB502.ericsson.se (153.88.183.163) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbG9QtfGpDXaYOdPVYsVr8+xW/y8t5PV YmPLOzaL9kvzmC3efmxntbh25h+jRc8Cbgd2j52z7rJ7LNhU6rFkyU8mj8mP25g9nuyfyRLA GsVlk5Kak1mWWqRvl8CV8ff4fKaC5+IVf95MZGtgnCbcxcjJISFgIrF1VjtTFyMXh5DAUUaJ iaeWsIAkhATeM0rsXs8DYgsLqEt0XdjODmKLCDhJLHn0iwWkgVlgG6PE657VLBDd81gktuyd BFbFJmAhcfNHIxuIzStgL/G5+RmYzSKgKrH8VAfYBlGBGImjk1ugagQlTs58AhTn4OAUCJTo Xs4MEmYGGjNz/nlGCFteonnrbKi4uETTl5WsEIdqSzQ0dbBCfKMkcX3edbAxEgLpEq9P801g FJ6FZMEsJFNnIZk6C8nUBYwsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECY+jglt+6OxhX v3Y8xCjAwajEw5sp2xotxJpYVlyZe4hRgoNZSYR3anZLtBBvSmJlVWpRfnxRaU5q8SFGaQ4W JXFevVV7ooQE0hNLUrNTUwtSi2CyTBycUg2MvbNdZ236w9jP0FX659xn1wdiXrz+u+ROLnB8 Hu7VmZJ2VkIzvp5L1EN5VWnNosqpi8/GTJjw5/fMfXsiToaahM82bCs5tLnrZcTmjjc15+aG Fcrt49o248Df5Jnm3883SjOnO0fKqk8891atJSFRz/HNk9O52hN/7dnC4LbX4y7/w48s0/bs V2Ipzkg01GIuKk4EAF+2MGGdAgAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 11:38:41 -0000 Hi, In regards to the below specific point: Den 2018-08-28 kl. 09:01, skrev Kazuho Oku: > > The only thing I feel (a bit) uneasy about #1706 is that it only has > four modes, requiring some negotiation to handle ECT(1) markings. My > preference is to send 5 modes (possibly encoded in 2-bits as we have > discussed on list), so that we do not need to make changes to the QUIC > specification for ECN experiments / future extensions. I think usage of a single ECT code point are going to work fine. The reason has to do with how the ECT(0) and ECT(1) codepoints are defined for the experimental usage. In legacy the two ECT codepoint are the same, but by default a QUIC stack will mark only with ECT(0). Thus, reception of ECT(1) means a non-compliant path that does remarking that should not occur. ECT(1) will be used for alternative behaviours, including different ECN marking schemes such as in L4S. For a  QUIC endpoint to use ECT(1) as marking when sending it needs to have awareness of the experiment and implement the correct response functions. It also needs to agree with the receiver about this capability. Although possible it could be limited to that the receiver only needs to know that ECT marking will be ECT(1) and that should be reported. However it might imply additional receiver behaviour changes. Thus, I fully expect that any such experiment in QUIC will require either a version or a Transport Parameter. Why I think a single ECT code point will be sufficient is that if one start using both ECT code point simultaneous in one connection one will have to treat this as a multi-path scenario as it is to be expected that ECT(0) packets will not see the same path treatment as ECT(1) marked packets. Thus, for safe handling of these differences one appear to need to apply more changes to reporting to ensure that one treats the packet correctly and measure both paths independently. Thus some other mechanism will be in place for path differentiation or one need another ACK format anyway to report different time offsets since last received packet with the two different ECT codepoints where received etc. Because of the above I don't see a strong reason to require a reporting scheme that requires the ACK block to be able to report all 5 types of type values. But, I did find Martin's delta encoding proposal a clever solution that has the advantage of providing explicit information. If people find the additional complexity of that fine, I would say go for it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Aug 28 06:41:50 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F46130F1D for ; Tue, 28 Aug 2018 06:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 hLQKj4uRIiW0 for ; Tue, 28 Aug 2018 06:41:46 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 03CBF130F18 for ; Tue, 28 Aug 2018 06:41:46 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id z12-v6so588793ybg.9 for ; Tue, 28 Aug 2018 06:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZOUXEfdGwZO+mtmh5TBA/uZHb1tfym5YshDbzAr65QI=; b=s3YWnUQ419wErcFi0ICy5EPLXg2oqcbjXjn7QQv2UQ+RB97ZQdlbDOxg3Zhpa3JDXk 920XBZdjVf8VJdNRSmz0T4pzc0MgoO2nfz7NF62SfuyLtW9+vezqvejKCH+2glNpwRje sCC48mVsu06JqwJlXohFSwxlgU8TkMED8BpaedZDVSX3qGrJnTBtb9ssUPttpdb5KTmU mojstYNWiiiPloY+gN0SYkQHhkNHI614GmRZXzAfavPtYv/PxeAWhmq0ZXasrUDZ6WFP iCfDIv2dsMRofB8LyuIuscH02ddwbulbAVXP290i4PNonHfHAfx3hv9mHQQ3bqtJ1VMl 3Qig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZOUXEfdGwZO+mtmh5TBA/uZHb1tfym5YshDbzAr65QI=; b=bJBH1AIg0d5JcoicighpcW3+6/PejkBBugqDUnnkNfMAVbdEw0hLL3YEXBs5zGY4Px eKrEvohrU2Lw9HaUUrJlWQ6JjveK73LINI+RRJG4Ca4lWYsjzWE6OpMa5GSkKyA1iuNs 3V0n5VTCHTrbt6LqEm7o4BzahGae3PLNEfCECQGWTbI1xJS5QvTRN8SG0HxCcTtGKZf3 cJoER626XmVCjamAhwQOBcM0XW/paHsTWdhzEcuMolb03topAShWCZEJxZolmZTBHO8U JkXCebUtooDyZHt8CTlEOXl+E1LCIqoMPyzsLAq7yWTjwFvYW/Rj7bQFjav5QclWUlZP B6AA== X-Gm-Message-State: APzg51Cs13rGm/WN9GYSatV8HFDYcojVvm8V3wW7WGb+BrdsLt+G8EXV 96QiPlGX3Y4cleoRGxBjF0dlvtCvRSRwO4bFoaBdUQ== X-Google-Smtp-Source: ANB0VdZyabQbf2CBtn0j0m/+MxPHQ69/cq0s83ybqLZadwNY4PgGRkVgvgX9xFdp7ggwfSWfUV3eK/O5OZJnc4LMnxo= X-Received: by 2002:a25:ca8f:: with SMTP id a137-v6mr834598ybg.46.1535463704803; Tue, 28 Aug 2018 06:41:44 -0700 (PDT) MIME-Version: 1.0 References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> <0c1c0cd5-fac3-d272-4fce-f6d3c75945e0@ericsson.com> In-Reply-To: <0c1c0cd5-fac3-d272-4fce-f6d3c75945e0@ericsson.com> From: Ian Swett Date: Tue, 28 Aug 2018 09:41:32 -0400 Message-ID: Subject: Re: Unified ACK frame encoding To: Magnus Westerlund Cc: Kazuho Oku , Eric Rescorla , Jana Iyengar , Brian Trammell , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000b15d9c05747f00d7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 13:41:49 -0000 --000000000000b15d9c05747f00d7 Content-Type: text/plain; charset="UTF-8" My understanding of Martin's 5 type proposal was it eliminated the possibility of ambiguous encodings. ie: ACK block followed by another ACK block, etc. If it's slightly more expressive and eliminates ambiguity, that seems like a slight improvement, but it makes the implementation somewhat more complex, so I am fine with either approach. The major negative of this change from my perspective is the loss of 2 bits, which makes a single byte ACK block pretty useless in a lot of cases it was formerly useful. I'd still prefer an approach that didn't burn the bits in cases when there were no marks by using a bit in the type byte(or some other approach), but overall I think this is a move in the right direction, because it removes a lot of complexity introduced to deal with the old design's ambiguity. On Tue, Aug 28, 2018 at 7:38 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > In regards to the below specific point: > > > Den 2018-08-28 kl. 09:01, skrev Kazuho Oku: > > > > The only thing I feel (a bit) uneasy about #1706 is that it only has > > four modes, requiring some negotiation to handle ECT(1) markings. My > > preference is to send 5 modes (possibly encoded in 2-bits as we have > > discussed on list), so that we do not need to make changes to the QUIC > > specification for ECN experiments / future extensions. > > I think usage of a single ECT code point are going to work fine. The > reason has to do with how the ECT(0) and ECT(1) codepoints are defined > for the experimental usage. In legacy the two ECT codepoint are the > same, but by default a QUIC stack will mark only with ECT(0). Thus, > reception of ECT(1) means a non-compliant path that does remarking that > should not occur. ECT(1) will be used for alternative behaviours, > including different ECN marking schemes such as in L4S. For a QUIC > endpoint to use ECT(1) as marking when sending it needs to have > awareness of the experiment and implement the correct response > functions. It also needs to agree with the receiver about this > capability. Although possible it could be limited to that the receiver > only needs to know that ECT marking will be ECT(1) and that should be > reported. However it might imply additional receiver behaviour changes. > Thus, I fully expect that any such experiment in QUIC will require > either a version or a Transport Parameter. > > Why I think a single ECT code point will be sufficient is that if one > start using both ECT code point simultaneous in one connection one will > have to treat this as a multi-path scenario as it is to be expected that > ECT(0) packets will not see the same path treatment as ECT(1) marked > packets. Thus, for safe handling of these differences one appear to need > to apply more changes to reporting to ensure that one treats the packet > correctly and measure both paths independently. Thus some other > mechanism will be in place for path differentiation or one need another > ACK format anyway to report different time offsets since last received > packet with the two different ECT codepoints where received etc. > > Because of the above I don't see a strong reason to require a reporting > scheme that requires the ACK block to be able to report all 5 types of > type values. But, I did find Martin's delta encoding proposal a clever > solution that has the advantage of providing explicit information. If > people find the additional complexity of that fine, I would say go for it. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --000000000000b15d9c05747f00d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My understanding of Martin's 5 type proposal was it el= iminated the possibility of ambiguous encodings.=C2=A0 ie: ACK block follow= ed by another ACK block, etc.=C2=A0 If it's slightly more expressive an= d eliminates ambiguity, that seems like a slight improvement, but it makes = the implementation somewhat more complex, so I am fine with either approach= .

The major negative of this change from my perspective is the loss= of 2 bits, which makes a single byte ACK block pretty useless in a lot of = cases it was formerly useful.=C2=A0 I'd still prefer an approach that d= idn't burn the bits in cases when there were no marks by using a bit in= the type byte(or some other approach), but overall I think this is a move = in the right direction, because it removes a lot of complexity introduced t= o deal with the old design's ambiguity.



On Tue= , Aug 28, 2018 at 7:38 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

In regards to the below specific point:


Den 2018-08-28 kl. 09:01, skrev Kazuho Oku:
>
> The only thing I feel (a bit) uneasy about #1706 is that it only has > four modes, requiring some negotiation to handle ECT(1) markings. My > preference is to send 5 modes (possibly encoded in 2-bits as we have > discussed on list), so that we do not need to make changes to the QUIC=
> specification for ECN experiments / future extensions.

I think usage of a single ECT code point are going to work fine. The
reason has to do with how the ECT(0) and ECT(1) codepoints are defined
for the experimental usage. In legacy the two ECT codepoint are the
same, but by default a QUIC stack will mark only with ECT(0). Thus,
reception of ECT(1) means a non-compliant path that does remarking that should not occur. ECT(1) will be used for alternative behaviours,
including different ECN marking schemes such as in L4S. For a=C2=A0 QUIC endpoint to use ECT(1) as marking when sending it needs to have
awareness of the experiment and implement the correct response
functions. It also needs to agree with the receiver about this
capability. Although possible it could be limited to that the receiver
only needs to know that ECT marking will be ECT(1) and that should be
reported. However it might imply additional receiver behaviour changes. Thus, I fully expect that any such experiment in QUIC will require
either a version or a Transport Parameter.

Why I think a single ECT code point will be sufficient is that if one
start using both ECT code point simultaneous in one connection one will have to treat this as a multi-path scenario as it is to be expected that ECT(0) packets will not see the same path treatment as ECT(1) marked
packets. Thus, for safe handling of these differences one appear to need to apply more changes to reporting to ensure that one treats the packet correctly and measure both paths independently. Thus some other
mechanism will be in place for path differentiation or one need another ACK format anyway to report different time offsets since last received
packet with the two different ECT codepoints where received etc.

Because of the above I don't see a strong reason to require a reporting=
scheme that requires the ACK block to be able to report all 5 types of
type values. But, I did find Martin's delta encoding proposal a clever =
solution that has the advantage of providing explicit information. If
people find the additional complexity of that fine, I would say go for it.<= br>
Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0= 949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--000000000000b15d9c05747f00d7-- From nobody Tue Aug 28 06:59:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EEA130F18 for ; Tue, 28 Aug 2018 06:59:01 -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, FREEMAIL_FROM=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 PaiDWBSuJzyU for ; Tue, 28 Aug 2018 06:58:58 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B57130E61 for ; Tue, 28 Aug 2018 06:58:58 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id g9-v6so1483249lfh.1 for ; Tue, 28 Aug 2018 06:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=75+jbKowF0iZ8gRj+vOwqo8WNvdDGFKsHd69m/ob6xU=; b=NW9mSJvUpoZfK+yvo+iibYzgSpfP1w3TIcQ8lzCrcSaQqzg7ZN72OnDihgTF7DGk8J 8D+HRMBOHQeJxQjCHdv743rM1ong1JeI9e9lCLnqpVb0eImYO0WVN0PBIIX2Cb+JE9JI PsZo2FaWtMe7jhTDcQx6desHd9BSe2tOgnrbQkCAv4rJrvrFVha4TwXjgkYOexLcQN+y 59rQbOfvW3hTd5SWbvwYNWAA5Lb9YDL8qzVlyPa7wGhI8HUJPNt2+KT6I+d/+RCDRU6H 5s5oeaYlrBjDXNS0tVNBS1jkwhOvehhyV8Tj2Is9vINqdGbw2nXAIVOlCR3QxfIzI4Ll +H2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=75+jbKowF0iZ8gRj+vOwqo8WNvdDGFKsHd69m/ob6xU=; b=PZVscIOZeQQdSiwlV4EKGe71Brsj7B5zCiCfAaUrXkt2tdJahS0OnvIthz5EpIEYy1 sb6soX5DFc9RxL4wT+o91Wtm1+C9iSvxW+DD1r57TdXqhI4AY1yR3r0quqUVLZVGws35 a+KJtoQcoNtRYDlyCmBkOBBJHzgn1Se/tdHyYHSx0DOt3FdzWdnPuSBXmDsVdarCxsLo xy99LD0iifXrhEVi/dd8OIghzigUWw36zJ29pHp9UnxdM3nnDIIOhQ05qg4MxSYiwjyL qv6D6HoTGEn59rw22Pj7tlHp9aUm4PIMhkNLsykgRSJ7+pJp/byDSP2962OyYjfnyQSB lPOQ== X-Gm-Message-State: APzg51CzMiraBs1Ult4lS/pKv0fscnHXp2YHPFJ+GRaxQcNkvfuiPhOF CiCSXkfBklsgYbwyJqAnmZwK7XVjUDZyfTFg6AE= X-Google-Smtp-Source: ANB0VdacdkLpa28Btxmfd1GJFdOCpERTTnh/5R8BPOJk/GhkGWJF1wMY1MC4z/gM9j6LvX+4bGBry++hV3EKf1dxgYg= X-Received: by 2002:a19:d769:: with SMTP id o102-v6mr999421lfg.106.1535464736619; Tue, 28 Aug 2018 06:58:56 -0700 (PDT) MIME-Version: 1.0 References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> <0c1c0cd5-fac3-d272-4fce-f6d3c75945e0@ericsson.com> In-Reply-To: <0c1c0cd5-fac3-d272-4fce-f6d3c75945e0@ericsson.com> From: Kazuho Oku Date: Tue, 28 Aug 2018 22:58:45 +0900 Message-ID: Subject: Re: Unified ACK frame encoding To: Magnus Westerlund Cc: Eric Rescorla , Jana Iyengar , Brian Trammell , Ian Swett , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 13:59:02 -0000 2018=E5=B9=B48=E6=9C=8828=E6=97=A5(=E7=81=AB) 20:38 Magnus Westerlund : > > Hi, > > In regards to the below specific point: > > > Den 2018-08-28 kl. 09:01, skrev Kazuho Oku: > > > > The only thing I feel (a bit) uneasy about #1706 is that it only has > > four modes, requiring some negotiation to handle ECT(1) markings. My > > preference is to send 5 modes (possibly encoded in 2-bits as we have > > discussed on list), so that we do not need to make changes to the QUIC > > specification for ECN experiments / future extensions. > > I think usage of a single ECT code point are going to work fine. The > reason has to do with how the ECT(0) and ECT(1) codepoints are defined > for the experimental usage. In legacy the two ECT codepoint are the > same, but by default a QUIC stack will mark only with ECT(0). Thus, > reception of ECT(1) means a non-compliant path that does remarking that > should not occur. ECT(1) will be used for alternative behaviours, > including different ECN marking schemes such as in L4S. For a QUIC > endpoint to use ECT(1) as marking when sending it needs to have > awareness of the experiment and implement the correct response > functions. It also needs to agree with the receiver about this > capability. Although possible it could be limited to that the receiver > only needs to know that ECT marking will be ECT(1) and that should be > reported. However it might imply additional receiver behaviour changes. > Thus, I fully expect that any such experiment in QUIC will require > either a version or a Transport Parameter. To clarify, my point is that if we could have an ACK frame that can transmit all 5 modes (4 ECN types + gaps) precisely, the sender of the packets and the middleboxes can use the ECN flags in the way they want, without requiring an update on the receiver. As you imply, it is true that we might need to make changes to the receiver on how frequent it sends acknowledgements when it receives a packet with non-standard ECN mark. But that might not always be the case. So my anticipation is (was) that having such kind of ACK frame will help us. But how much the benefit is depends on how such experiments would be make in practice, and I could well be missing something. Anyways, it is good to see us arguing about such a minor point :-) I agree to the other points that you have stated. > > Why I think a single ECT code point will be sufficient is that if one > start using both ECT code point simultaneous in one connection one will > have to treat this as a multi-path scenario as it is to be expected that > ECT(0) packets will not see the same path treatment as ECT(1) marked > packets. Thus, for safe handling of these differences one appear to need > to apply more changes to reporting to ensure that one treats the packet > correctly and measure both paths independently. Thus some other > mechanism will be in place for path differentiation or one need another > ACK format anyway to report different time offsets since last received > packet with the two different ECT codepoints where received etc. > > Because of the above I don't see a strong reason to require a reporting > scheme that requires the ACK block to be able to report all 5 types of > type values. But, I did find Martin's delta encoding proposal a clever > solution that has the advantage of providing explicit information. If > people find the additional complexity of that fine, I would say go for it= . > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > --=20 Kazuho Oku From nobody Tue Aug 28 07:06:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB6A130F18 for ; Tue, 28 Aug 2018 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 eRRxvtBHZJta for ; Tue, 28 Aug 2018 07:06:28 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBEF7130E5A for ; Tue, 28 Aug 2018 07:06:27 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id x26-v6so1485489lfi.7 for ; Tue, 28 Aug 2018 07:06:27 -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=j7FXihHslR0DgaSk1zEG3WiFXtTvtME2x86i9uGc8DE=; b=OEAwBuyzzUyCTWrnHrxaL6M6J3MeHyT5DX3yd0gKi6egk4u2C8ttiP/6TNZ1KfgGgp q3x33tv5fRPQ6X04H0UIEMZXdJ4s/ogTpb2MKWIp2EFIhNnLcUvY133mrZq4g/xzfX1b qdjW2HBtwxz0if4n6nRIf6+7ZjdKcy2hoqu/dDwKOUFfUD2I3lwA+Fo/uJAzAo1VoHK6 YKfIxT240j9r8KH2I9V4sPNdW/EodSkqVtjrRCbHLSRJ8/GhQWsLybD5pwrQYbL4pMyD 3PoJuTSwpFbhnkljmnrE3PItQ9sXLTEDEDYxEc9IA6IXNM56ogs/IzeovxUlpPuBa5W9 Mk4Q== 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=j7FXihHslR0DgaSk1zEG3WiFXtTvtME2x86i9uGc8DE=; b=A1hKcOeI4x6HcsWIrJeKwJr2GcTuBvTRdzDh21Ne+6rTRzeCl3B0y1Q9JQKXh1qe3i XBDTEDhhaU/5KrgOkF62u+TDAuhy25HepDhuk/mJivBiuIQ7lsvzolDmc3eOWfF3emuQ pJ/IZVN6oiNV5jomQCdjIn80NHtwX+mss+qd1FMl0I2L+MiqeHHPWxjmgNY8ROQvky7N ldsWkLcCluEWd9wi2e9I9UyMbW/DoNma8mJu7EPaivvHkCQjC/IsRdXgLa9RnwPtwiVV j7stBc1porqWYW20IceAJibop5d2dsKttiUofrpEzOXPRNruufQ3PgdcD0ZO2nk9Hs56 kl8Q== X-Gm-Message-State: APzg51Dl/UpfnSPTxKpO0XOwnHbyLxXey1y7Pb6m0D8A4/F7WFIZ5qUI vPvg/qoUGVpjD/o/pBaov3PJ4Q6LXYrwxnjCVOkNFw== X-Google-Smtp-Source: ANB0VdYm9to+Z37so/4QC8BtCVcoeOXM4MXnQXnEF2tOKEyLk3MdzKhlfRzU9q6Ck/mlp33SX7y2zPM/hZKLvJnbPG4= X-Received: by 2002:a19:5517:: with SMTP id n23-v6mr1425911lfe.101.1535465186126; Tue, 28 Aug 2018 07:06:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 07:05:45 -0700 (PDT) In-Reply-To: References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> From: Eric Rescorla Date: Tue, 28 Aug 2018 07:05:45 -0700 Message-ID: Subject: Re: Unified ACK frame encoding To: Martin Thomson Cc: Magnus Westerlund , Ian Swett , Jana Iyengar , Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary="000000000000fc005705747f58cf" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 14:06:31 -0000 --000000000000fc005705747f58cf Content-Type: text/plain; charset="UTF-8" On Mon, Aug 27, 2018 at 7:16 PM, Martin Thomson wrote: > I'm not saying that these are invalid complaints, but I don't reach > the same conclusion on the subjective assessment of balance of > concerns. > Sure. Sounds like a topic for New York. > I don't think that this is significantly more complicated than > existing code. Rather than switch on all four values of the type, zero > (gap) and non-zero (acknowledged) is simple enough. Maybe I'm looking at the wrong PR? It's not so much a matter of individual code complexity, but rather about embedding something in length that's not length. Aside from being odd, this makes having a uniform encoder/decoder hard, which is a real cost, especially if you use mechanically generated encoders. > Extension in the > future necessarily uses new frame types, which aren't constrained. > Right, that's my complaint. We know that this is a piece of the protocol we like to extend. Arguably ECN is an extension and we have at least one other extension that's been floated (timestamp), but the structure you've designed here has no internal extensibility points, so any *other* extensions require a huge change where we just have a different frame type. That seems like an overly rigid design. Taking a step back, the "natural" design is just to have a type byte in front of every ACK block. I.e., enum { gap(0), unmarked(1), ... } AckType struct { AckType type; varint length; ... } AckBlock; As you observe, this costs us a byte for every block compared to your design, because we're stealing two bits from length, although that's only true to the extent to which one-byte lengths remain useful. If you are consistently pushed over into two-byte lengths for lengths in the range 65-255, then your encoding is equally efficient to the natural one. And as I said above, you're left with no extensibility. I have two thoughts about this: 1. I'm actually not that worried about the extra byte here. It's true that ACKs are common, but one byte one way or another isn't going to kill us. 2. If we are that worried about the extra byte, we can address that problem by having "ACKs" and "Extended ACKs" where ACKs don't have a type field and we use the frame type to distinguish them (I think this is what Ian is alluding to downthread). So, IMO either the natural design or one which has an optional type byte is better than what you have here. -Ekr On Mon, Aug 27, 2018 at 11:02 PM Eric Rescorla wrote: > > > > Yes, this PR reflects what I believed you were proposing. I believe the > objections I raised here continue to apply. > > > > -Ekr > > > > > > On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson < > martin.thomson@gmail.com> wrote: > >> > >> I think that this is simpler. See > >> https://github.com/quicwg/base-drafts/pull/1706 for a draft. > >> On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla wrote: > >> > > >> > On balance I don't think I'm in favor of this bit-packing technique > because it complicates the ordinary ACK frame even for people who don't > care about ECN (and not doing so was part of why we decided to have another > frame type in the first place). Moreover, it's not a scalable extension > method, so anything *else* we want to add to the ACK frame will just need > some other technique. > >> > > >> > -Ekr > >> > > >> > > >> > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> >> > >> >> Hi, > >> >> > >> >> Catching up. I have posted on github (https://github.com/quicwg/bas > e-drafts/issues/1439) some consideration what this implies in regards to > ack frame sizes for different cases discussed. > >> >> > >> >> I think Martins design here with being able to switch between each > different type of marking as well as being able to reasonably efficient > encode any range lengths without issues are a good one. My analysis on the > github isssue showed that in low rate changes is is equivalent to a single > byte design as well as being better capable of handling longer ranges of > the same type. > >> >> > >> >> I think it is worth continuing with this one. If one wants to use > the 2-bit type field for an explicitly encoded 4 alternative one or use the > delta encoding can of course be discussed. I would prefer the delta > encoding to avoid the information loss and the need for specifying what is > the default ECT value and what to do in situations with a none expected one. > >> >> > >> >> Cheers > >> >> > >> >> Magnus > >> >> > >> >> > >> >> > >> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: > >> >>> > >> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett > wrote: > >> >>>> > >> >>>> There are a few things I like about this proposal: > >> >>>> 1) It makes ECN and ACK_ECN either the same(or more similar) > >> >>>> 2) As Kazuho said, it provides more precise feedback about which > packets were marked, which avoids some edge cases we've had to write up in > the current text around ack loss and being unsure of exactly when recovery > is exited. > >> >>>> 3) It doesn't get more expensive as the connection goes on. This > is an unfortunate property of the current design. > >> >>>> > >> >>>> I find Jana's variation on this particularly interesting, because > if ECN isn't negotiated, I don't think there a reason to add any overhead. > From personal experience, if you find a form of feedback valuable(whether > it's ECN or timestamps for one-way-delay), then you're happy to consume a > few extra bytes to get better feedback. If the extra information isn't > useful for whatever reason, it's just wasted bytes. > >> >>> > >> >>> OK, 4 values is definitely easier to reason about. Merging ECT(0) > and > >> >>> ECT(1) into the same bucket is easy as long as we're OK with that. > >> >>> The simpler encoding is easier to describe and write code for, and > we > >> >>> can just tolerate (or reject) two adjacent ranges of the same type, > >> >>> just as we might tolerate (or reject) a trailing gap. > >> >>> > >> >>>> So overall this seems like an improvement we should do, but I'd > prefer a variant that doesn't increase the ACK frame size when ECN is > disabled or there are no ECN marks to report. FYI, if we need to steal a > bit from the number of ack blocks, I'm ok with that since I expect more > than 32 ack blocks to be very rare. > >> >>> > >> >>> This is very close to a variant I suggested on the issue, which we > >> >>> agreed pretty quickly wasn't great. You can create two ACK frames, > >> >>> one with the full expressiveness, and another that has the potential > >> >>> to encode the ECN information. Call the second one ACK_ECN... > >> >>> > >> >>> I'm not convinced that optimizing for the awkward space between 16 > and > >> >>> 64 is worth the extra complexity of a variant encoding of the frame. > >> >>> There are other ways to optimize for the cost of that occasional > octet > >> >>> that seem like they would be more fruitful (like truncating ACK > frames > >> >>> more aggressively). > >> >> > >> >> > >> >> -- > >> >> > >> >> Magnus Westerlund > >> >> > >> >> ------------------------------------------------------------ > ---------- > >> >> Network Architecture & Protocols, Ericsson Research > >> >> ------------------------------------------------------------ > ---------- > >> >> Ericsson AB | Phone +46 10 7148287 > >> >> Torshamnsgatan 23 | Mobile +46 73 0949079 > >> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >> >> ------------------------------------------------------------ > ---------- > >> >> > >> > > > > > > --000000000000fc005705747f58cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 27, 2018 at 7:16 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I'm not say= ing that these are invalid complaints, but I don't reach
the same conclusion on the subjective assessment of balance of
concerns.

Sure. Sounds like a topic for= New York.

=C2=A0
I don't think that this is significantly more complicated than
existing code. Rather than switch on all four values of the type, zero
(gap) and non-zero (acknowledged) is simple enough.

Maybe I'm looking at the wrong PR? It's not so much a matt= er of individual code complexity, but rather about embedding something in l= ength that's not length. Aside from being odd, this makes having a unif= orm encoder/decoder hard, which is a real cost, especially if you use mecha= nically generated encoders.

=C2=A0
=C2=A0 Extension in the
future necessarily uses new frame types, which aren't constrained.
<= /blockquote>

Right, that's my complaint. We know tha= t this is a piece of the protocol we like to extend. Arguably ECN is an ext= ension and we have at least one other extension that's been floated (ti= mestamp), but the structure you've designed here has no internal extens= ibility points, so any *other* extensions require a huge change where we ju= st have a different frame type. That seems like an overly rigid design.

Taking a step back, the "natural" design is= just to have a type byte in front of every ACK block. I.e.,

=
enum { gap(0), unmarked(1), ... } AckType

struct {
=C2=A0 =C2=A0 AckType type;
=C2=A0 =C2=A0 v= arint length;
=C2=A0 =C2=A0 ...
} AckBlock;
<= br>
As you observe, this costs us a byte for every block compared= to your design, because we're stealing two bits from length, although = that's only true to the extent to which one-byte lengths remain useful.= If you are consistently pushed over into two-byte lengths for lengths in t= he range 65-255, then your encoding is equally efficient to the natural one= . And as I said above, you're left with no extensibility.

I have two thoughts about this:
1. I'm actua= lly not that worried about the extra byte here. It's true that ACKs are= common, but one byte one way or another isn't going to kill us.
<= div>2. If we are that worried about the extra byte, we can address that pro= blem by having "ACKs" and "Extended ACKs" where ACKs do= n't have a type field and we use the frame type to distinguish them (I = think this is what Ian is alluding to downthread).

So, IMO either the natural design or one which has an optional type byte i= s better than what you have here.

-Ekr

On Mon, Aug 27, 2018 at 11:02 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> Yes, this PR reflects what I believed you were proposing. I believe th= e objections I raised here continue to apply.
>
> -Ekr
>
>
> On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson <martin.thomson@gmail.com>= ; wrote:
>>
>> I think that this is simpler.=C2=A0 See
>> https://github.com/quicwg/base-drafts/p= ull/1706 for a draft.
>> On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> > On balance I don't think I'm in favor of this bit-pac= king technique because it complicates the ordinary ACK frame even for peopl= e who don't care about ECN (and not doing so was part of why we decided= to have another frame type in the first place). Moreover, it's not a s= calable extension method, so anything *else* we want to add to the ACK fram= e will just need some other technique.
>> >
>> > -Ekr
>> >
>> >
>> > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund <magnus.wester= lund@ericsson.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Catching up. I have posted on github (https://github.com/quicwg/base-drafts/issues/1439) some consi= deration what this implies in regards to ack frame sizes for different case= s discussed.
>> >>
>> >> I think Martins design here with being able to switch bet= ween each different type of marking as well as being able to reasonably eff= icient encode any range lengths without issues are a good one. My analysis = on the github isssue showed that in low rate changes is is equivalent to a = single byte design as well as being better capable of handling longer range= s of the same type.
>> >>
>> >> I think it is worth continuing with this one. If one want= s to use the 2-bit type field for an explicitly encoded 4 alternative one o= r use the delta encoding can of course be discussed. I would prefer the del= ta encoding to avoid the information loss and the need for specifying what = is the default ECT value and what to do in situations with a none expected = one.
>> >>
>> >> Cheers
>> >>
>> >> Magnus
>> >>
>> >>
>> >>
>> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson:
>> >>>
>> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett <ianswett@google.com&g= t; wrote:
>> >>>>
>> >>>> There are a few things I like about this proposal= :
>> >>>> 1) It makes ECN and ACK_ECN either the same(or mo= re similar)
>> >>>> 2) As Kazuho said, it provides more precise feedb= ack about which packets were marked, which avoids some edge cases we've= had to write up in the current text around ack loss and being unsure of ex= actly when recovery is exited.
>> >>>> 3) It doesn't get more expensive as the conne= ction goes on.=C2=A0 This is an unfortunate property of the current design.=
>> >>>>
>> >>>> I find Jana's variation on this particularly = interesting, because if ECN isn't negotiated, I don't think there a= reason to add any overhead.=C2=A0 From personal experience, if you find a = form of feedback valuable(whether it's ECN or timestamps for one-way-de= lay), then you're happy to consume a few extra bytes to get better feed= back.=C2=A0 If the extra information isn't useful for whatever reason, = it's just wasted bytes.
>> >>>
>> >>> OK, 4 values is definitely easier to reason about.=C2= =A0 Merging ECT(0) and
>> >>> ECT(1) into the same bucket is easy as long as we'= ;re OK with that.
>> >>> The simpler encoding is easier to describe and write = code for, and we
>> >>> can just tolerate (or reject) two adjacent ranges of = the same type,
>> >>> just as we might tolerate (or reject) a trailing gap.=
>> >>>
>> >>>> So overall this seems like an improvement we shou= ld do, but I'd prefer a variant that doesn't increase the ACK frame= size when ECN is disabled or there are no ECN marks to report.=C2=A0 FYI, = if we need to steal a bit from the number of ack blocks, I'm ok with th= at since I expect more than 32 ack blocks to be very rare.
>> >>>
>> >>> This is very close to a variant I suggested on the is= sue, which we
>> >>> agreed pretty quickly wasn't great.=C2=A0 You can= create two ACK frames,
>> >>> one with the full expressiveness, and another that ha= s the potential
>> >>> to encode the ECN information.=C2=A0 Call the second = one ACK_ECN...
>> >>>
>> >>> I'm not convinced that optimizing for the awkward= space between 16 and
>> >>> 64 is worth the extra complexity of a variant encodin= g of the frame.
>> >>> There are other ways to optimize for the cost of that= occasional octet
>> >>> that seem like they would be more fruitful (like trun= cating ACK frames
>> >>> more aggressively).
>> >>
>> >>
>> >> --
>> >>
>> >> Magnus Westerlund
>> >>
>> >> ----------------------------------------------------= ------------------
>> >> Network Architecture & Protocols, Ericsson Research >> >> ----------------------------------------------------= ------------------
>> >> Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
>> >> Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Mobile +46 73 0949079
>> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson= .com
>> >> ----------------------------------------------------= ------------------
>> >>
>> >
>
>

--000000000000fc005705747f58cf-- From nobody Tue Aug 28 07:28:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BD4130E61 for ; Tue, 28 Aug 2018 07:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BrfacTsRiV4W for ; Tue, 28 Aug 2018 07:28:36 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021371294D0 for ; Tue, 28 Aug 2018 07:28:36 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id q13-v6so1564277lfc.2 for ; Tue, 28 Aug 2018 07:28:35 -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=tE+4+K4onp2DaUOUv6SaeBvwxGCp/PWow/+SyBaL17c=; b=lqxdEtkhRriT1ByPtFJVr2bA/8KVXifvJPAYVSiRSqgnz/RMGZgxUiQ3NmKzxnT/qr jLvezqf0hS5U9nAOOoz49rxu3PJP2v8d7QsuwgUNh8k05OgNl8heE0Nd/r0XyKZNKTnY ZAc1EaAn5eIOQ9hrV2vXAoFU4X9sqL5w9gzn8QS78TIGAvuFj0/7LaLAv1M3D0u1i+3b V8RKoybo9uDbDHbyS32doKIJTaMg2gcP02ArKcIYOj90GoxwHRxbLcpXyaDHk9koGMGg gUyKQOxT/v7iT8J3B962qMTbNesZ+1bjMeaLZ9QiXEON7Maw8985EBCv6/Z/IvcN9lQF H3iw== 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=tE+4+K4onp2DaUOUv6SaeBvwxGCp/PWow/+SyBaL17c=; b=JYZZAIhr0VOa29c7UoMQaKa0J3oz0LtOlInCAHXf8h+krfZaSDpmv3ev0nnXZjA8cq nNzKI5xn6BdhFix4CZY8TzW/kcNKYQuqp2gKD1bXu6PETSv6Dlbr/PSrTVODkv2OG1TJ OlmPyAKpd58339PxqFm5jJnU+P57V6GfdZECM9WMQFiFQ3vk5PJJjJOo0u8eaB0fxnUP qzjpuQRWuUI0zl5XF24HTBMRWc/U5B6ory305D+FDO9feO2bd4tFFnB5XXKyIrdToavf Oc5uJJS0q6lHvjRuW0wPWa8BMJX+o6D2QPklhi1p01rjbPOIb+/Me6baI/SUnpQUEcX5 SQYQ== X-Gm-Message-State: APzg51CVqQ9xt53shwwoxNY3m9ZTlMmOJkdJO4w7ONbXL4wZ911jFLwT +Ksj7MTGrRUxloAPzwoNbwqitXSMcy9AXskTG3sgIw== X-Google-Smtp-Source: ANB0VdZfmq63FjpW8+ialyo0cDr+i3vR4Dp+Is7Se2A8Y+GUvkHLO/LqGY0/xjYg7kZuw+AVNsmn6B65QxFAP3ULoPI= X-Received: by 2002:a19:1ac8:: with SMTP id a191-v6mr1456186lfa.54.1535466514193; Tue, 28 Aug 2018 07:28:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 07:27:53 -0700 (PDT) In-Reply-To: References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> From: Eric Rescorla Date: Tue, 28 Aug 2018 07:27:53 -0700 Message-ID: Subject: Re: Unified ACK frame encoding To: Martin Thomson Cc: Magnus Westerlund , Ian Swett , Jana Iyengar , Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary="00000000000024b1d605747fa82a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 14:28:42 -0000 --00000000000024b1d605747fa82a Content-Type: text/plain; charset="UTF-8" On Tue, Aug 28, 2018 at 7:05 AM, Eric Rescorla wrote: > On Mon, Aug 27, 2018 at 7:16 PM, Martin Thomson > wrote: > >> I'm not saying that these are invalid complaints, but I don't reach >> the same conclusion on the subjective assessment of balance of >> concerns. >> > > Sure. Sounds like a topic for New York. > > > >> I don't think that this is significantly more complicated than >> existing code. Rather than switch on all four values of the type, zero >> (gap) and non-zero (acknowledged) is simple enough. > > > Maybe I'm looking at the wrong PR? It's not so much a matter of individual > code complexity, but rather about embedding something in length that's not > length. Aside from being odd, this makes having a uniform encoder/decoder > hard, which is a real cost, especially if you use mechanically generated > encoders. > > > >> Extension in the >> future necessarily uses new frame types, which aren't constrained. >> > > Right, that's my complaint. We know that this is a piece of the protocol > we like to extend. Arguably ECN is an extension and we have at least one > other extension that's been floated (timestamp), but the structure you've > designed here has no internal extensibility points, so any *other* > extensions require a huge change where we just have a different frame type. > That seems like an overly rigid design. > > Taking a step back, the "natural" design is just to have a type byte in > front of every ACK block. I.e., > > enum { gap(0), unmarked(1), ... } AckType > > struct { > AckType type; > varint length; > ... > } AckBlock; > > As you observe, this costs us a byte for every block compared to your > design, because we're stealing two bits from length, although that's only > true to the extent to which one-byte lengths remain useful. If you are > consistently pushed over into two-byte lengths for lengths in the range > 65-255, > Correction: Ian pointed out to me that because of the two varint bits, we actually pay an extra byte whenever the range length would fit in 6 bits, but not 4, which is a lot worse, because lengths in the range 17-64 are going to be quite common. -Ekr then your encoding is equally efficient to the natural one. And as I said > above, you're left with no extensibility. > > I have two thoughts about this: > 1. I'm actually not that worried about the extra byte here. It's true that > ACKs are common, but one byte one way or another isn't going to kill us. > 2. If we are that worried about the extra byte, we can address that > problem by having "ACKs" and "Extended ACKs" where ACKs don't have a type > field and we use the frame type to distinguish them (I think this is what > Ian is alluding to downthread). > > So, IMO either the natural design or one which has an optional type byte > is better than what you have here. > > -Ekr > > On Mon, Aug 27, 2018 at 11:02 PM Eric Rescorla wrote: >> > >> > Yes, this PR reflects what I believed you were proposing. I believe the >> objections I raised here continue to apply. >> > >> > -Ekr >> > >> > >> > On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson < >> martin.thomson@gmail.com> wrote: >> >> >> >> I think that this is simpler. See >> >> https://github.com/quicwg/base-drafts/pull/1706 for a draft. >> >> On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla wrote: >> >> > >> >> > On balance I don't think I'm in favor of this bit-packing technique >> because it complicates the ordinary ACK frame even for people who don't >> care about ECN (and not doing so was part of why we decided to have another >> frame type in the first place). Moreover, it's not a scalable extension >> method, so anything *else* we want to add to the ACK frame will just need >> some other technique. >> >> > >> >> > -Ekr >> >> > >> >> > >> >> > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Catching up. I have posted on github (https://github.com/quicwg/bas >> e-drafts/issues/1439) some consideration what this implies in regards to >> ack frame sizes for different cases discussed. >> >> >> >> >> >> I think Martins design here with being able to switch between each >> different type of marking as well as being able to reasonably efficient >> encode any range lengths without issues are a good one. My analysis on the >> github isssue showed that in low rate changes is is equivalent to a single >> byte design as well as being better capable of handling longer ranges of >> the same type. >> >> >> >> >> >> I think it is worth continuing with this one. If one wants to use >> the 2-bit type field for an explicitly encoded 4 alternative one or use the >> delta encoding can of course be discussed. I would prefer the delta >> encoding to avoid the information loss and the need for specifying what is >> the default ECT value and what to do in situations with a none expected one. >> >> >> >> >> >> Cheers >> >> >> >> >> >> Magnus >> >> >> >> >> >> >> >> >> >> >> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: >> >> >>> >> >> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett >> wrote: >> >> >>>> >> >> >>>> There are a few things I like about this proposal: >> >> >>>> 1) It makes ECN and ACK_ECN either the same(or more similar) >> >> >>>> 2) As Kazuho said, it provides more precise feedback about which >> packets were marked, which avoids some edge cases we've had to write up in >> the current text around ack loss and being unsure of exactly when recovery >> is exited. >> >> >>>> 3) It doesn't get more expensive as the connection goes on. This >> is an unfortunate property of the current design. >> >> >>>> >> >> >>>> I find Jana's variation on this particularly interesting, because >> if ECN isn't negotiated, I don't think there a reason to add any overhead. >> From personal experience, if you find a form of feedback valuable(whether >> it's ECN or timestamps for one-way-delay), then you're happy to consume a >> few extra bytes to get better feedback. If the extra information isn't >> useful for whatever reason, it's just wasted bytes. >> >> >>> >> >> >>> OK, 4 values is definitely easier to reason about. Merging ECT(0) >> and >> >> >>> ECT(1) into the same bucket is easy as long as we're OK with that. >> >> >>> The simpler encoding is easier to describe and write code for, and >> we >> >> >>> can just tolerate (or reject) two adjacent ranges of the same type, >> >> >>> just as we might tolerate (or reject) a trailing gap. >> >> >>> >> >> >>>> So overall this seems like an improvement we should do, but I'd >> prefer a variant that doesn't increase the ACK frame size when ECN is >> disabled or there are no ECN marks to report. FYI, if we need to steal a >> bit from the number of ack blocks, I'm ok with that since I expect more >> than 32 ack blocks to be very rare. >> >> >>> >> >> >>> This is very close to a variant I suggested on the issue, which we >> >> >>> agreed pretty quickly wasn't great. You can create two ACK frames, >> >> >>> one with the full expressiveness, and another that has the >> potential >> >> >>> to encode the ECN information. Call the second one ACK_ECN... >> >> >>> >> >> >>> I'm not convinced that optimizing for the awkward space between 16 >> and >> >> >>> 64 is worth the extra complexity of a variant encoding of the >> frame. >> >> >>> There are other ways to optimize for the cost of that occasional >> octet >> >> >>> that seem like they would be more fruitful (like truncating ACK >> frames >> >> >>> more aggressively). >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Magnus Westerlund >> >> >> >> >> >> ------------------------------------------------------------ >> ---------- >> >> >> Network Architecture & Protocols, Ericsson Research >> >> >> ------------------------------------------------------------ >> ---------- >> >> >> Ericsson AB | Phone +46 10 7148287 >> >> >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> >> >> SE-164 80 Stockholm, Sweden | mailto: >> magnus.westerlund@ericsson.com >> >> >> ------------------------------------------------------------ >> ---------- >> >> >> >> >> > >> > >> > >> > > --00000000000024b1d605747fa82a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 28, 2018 at 7:05 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
On Mon, Aug 27, 2018 at 7:16 PM, Martin Thomson <martin.thomson@gm= ail.com> wrote:
I'm = not saying that these are invalid complaints, but I don't reach
the same conclusion on the subjective assessment of balance of
concerns.

Sure. Sounds like a to= pic for New York.

=C2=A0
I don't think that this is significantly more complicated than
existing code. Rather than switch on all four values of the type, zero
(gap) and non-zero (acknowledged) is simple enough.

Maybe I'm looking at the wrong PR? It's not so much= a matter of individual code complexity, but rather about embedding somethi= ng in length that's not length. Aside from being odd, this makes having= a uniform encoder/decoder hard, which is a real cost, especially if you us= e mechanically generated encoders.

=C2=A0
=C2=A0 Extension in the future necessarily uses new frame types, which aren't constrained.
<= /blockquote>

Right, that's my complaint. We k= now that this is a piece of the protocol we like to extend. Arguably ECN is= an extension and we have at least one other extension that's been floa= ted (timestamp), but the structure you've designed here has no internal= extensibility points, so any *other* extensions require a huge change wher= e we just have a different frame type. That seems like an overly rigid desi= gn.

Taking a step back, the "natural" de= sign is just to have a type byte in front of every ACK block. I.e.,

enum { gap(0), unmarked(1), ... } AckType

<= /div>
struct {
=C2=A0 =C2=A0 AckType type;
=C2=A0 = =C2=A0 varint length;
=C2=A0 =C2=A0 ...
} AckBlock;

As you observe, this costs us a byte for every block = compared to your design, because we're stealing two bits from length, a= lthough that's only true to the extent to which one-byte lengths remain= useful. If you are consistently pushed over into two-byte lengths for leng= ths in the range 65-255,

Correction: Ian pointed out to me that because of the two varint bits= , we actually pay an extra byte whenever the range length would fit in 6 bi= ts, but not 4, which is a lot worse, because lengths in the range 17-64 are= going to be quite common.

-Ekr

=

then your encoding is= equally efficient to the natural one. And as I said above, you're left= with no extensibility.

I have two thoughts a= bout this:
1. I'm actually not that worried about the extra b= yte here. It's true that ACKs are common, but one byte one way or anoth= er isn't going to kill us.
2. If we are that worried about th= e extra byte, we can address that problem by having "ACKs" and &q= uot;Extended ACKs" where ACKs don't have a type field and we use t= he frame type to distinguish them (I think this is what Ian is alluding to = downthread).

So, IMO either the natural design or = one which has an optional type byte is better than what you have here.
<= /div>

-Ekr

On Mon, Aug 27, 2018 a= t 11:02 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> Yes, this PR reflects what I believed you were proposing. I believe th= e objections I raised here continue to apply.
>
> -Ekr
>
>
> On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson <martin.thomson@gmail.com>= ; wrote:
>>
>> I think that this is simpler.=C2=A0 See
>> https://github.com/quicwg/base-drafts/p= ull/1706 for a draft.
>> On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> > On balance I don't think I'm in favor of this bit-pac= king technique because it complicates the ordinary ACK frame even for peopl= e who don't care about ECN (and not doing so was part of why we decided= to have another frame type in the first place). Moreover, it's not a s= calable extension method, so anything *else* we want to add to the ACK fram= e will just need some other technique.
>> >
>> > -Ekr
>> >
>> >
>> > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund <magnus.wester= lund@ericsson.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Catching up. I have posted on github (https://github.com/quicwg/base-drafts/issues/1439) some consi= deration what this implies in regards to ack frame sizes for different case= s discussed.
>> >>
>> >> I think Martins design here with being able to switch bet= ween each different type of marking as well as being able to reasonably eff= icient encode any range lengths without issues are a good one. My analysis = on the github isssue showed that in low rate changes is is equivalent to a = single byte design as well as being better capable of handling longer range= s of the same type.
>> >>
>> >> I think it is worth continuing with this one. If one want= s to use the 2-bit type field for an explicitly encoded 4 alternative one o= r use the delta encoding can of course be discussed. I would prefer the del= ta encoding to avoid the information loss and the need for specifying what = is the default ECT value and what to do in situations with a none expected = one.
>> >>
>> >> Cheers
>> >>
>> >> Magnus
>> >>
>> >>
>> >>
>> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson:
>> >>>
>> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett <ianswett@google.com&g= t; wrote:
>> >>>>
>> >>>> There are a few things I like about this proposal= :
>> >>>> 1) It makes ECN and ACK_ECN either the same(or mo= re similar)
>> >>>> 2) As Kazuho said, it provides more precise feedb= ack about which packets were marked, which avoids some edge cases we've= had to write up in the current text around ack loss and being unsure of ex= actly when recovery is exited.
>> >>>> 3) It doesn't get more expensive as the conne= ction goes on.=C2=A0 This is an unfortunate property of the current design.=
>> >>>>
>> >>>> I find Jana's variation on this particularly = interesting, because if ECN isn't negotiated, I don't think there a= reason to add any overhead.=C2=A0 From personal experience, if you find a = form of feedback valuable(whether it's ECN or timestamps for one-way-de= lay), then you're happy to consume a few extra bytes to get better feed= back.=C2=A0 If the extra information isn't useful for whatever reason, = it's just wasted bytes.
>> >>>
>> >>> OK, 4 values is definitely easier to reason about.=C2= =A0 Merging ECT(0) and
>> >>> ECT(1) into the same bucket is easy as long as we'= ;re OK with that.
>> >>> The simpler encoding is easier to describe and write = code for, and we
>> >>> can just tolerate (or reject) two adjacent ranges of = the same type,
>> >>> just as we might tolerate (or reject) a trailing gap.=
>> >>>
>> >>>> So overall this seems like an improvement we shou= ld do, but I'd prefer a variant that doesn't increase the ACK frame= size when ECN is disabled or there are no ECN marks to report.=C2=A0 FYI, = if we need to steal a bit from the number of ack blocks, I'm ok with th= at since I expect more than 32 ack blocks to be very rare.
>> >>>
>> >>> This is very close to a variant I suggested on the is= sue, which we
>> >>> agreed pretty quickly wasn't great.=C2=A0 You can= create two ACK frames,
>> >>> one with the full expressiveness, and another that ha= s the potential
>> >>> to encode the ECN information.=C2=A0 Call the second = one ACK_ECN...
>> >>>
>> >>> I'm not convinced that optimizing for the awkward= space between 16 and
>> >>> 64 is worth the extra complexity of a variant encodin= g of the frame.
>> >>> There are other ways to optimize for the cost of that= occasional octet
>> >>> that seem like they would be more fruitful (like trun= cating ACK frames
>> >>> more aggressively).
>> >>
>> >>
>> >> --
>> >>
>> >> Magnus Westerlund
>> >>
>> >> ----------------------------------------------------= ------------------
>> >> Network Architecture & Protocols, Ericsson Research >> >> ----------------------------------------------------= ------------------
>> >> Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
>> >> Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Mobile +46 73 0949079
>> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson= .com
>> >> ----------------------------------------------------= ------------------
>> >>
>> >
>
>


--00000000000024b1d605747fa82a-- From nobody Tue Aug 28 07:58:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8323130DE1 for ; Tue, 28 Aug 2018 07:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yM6TNIxy0XyD for ; Tue, 28 Aug 2018 07:58:35 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8136C130DD9 for ; Tue, 28 Aug 2018 07:58:35 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id p84-v6so3387927oic.4 for ; Tue, 28 Aug 2018 07:58:35 -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=6H43I6KqlnqkYfPdNX65r2bDEoRqUb1bJQWkcYKs/E0=; b=PITfLMSMgRDtTupKS2nd8wla3NljT4a9tHrRUdDm4GBOyRIHvoGbHOp3dg39jSRo4U XnMTKnonAPWC3bOvseJT2KXs4v0Lx2F4YPh5giDhdn1L739rx7I1DTUbulLnuog7DGXA zQElDsliFD/0K9ATJxBJWW2Vrttoae/xnxc1KcISEGynX0jUnCUdehZgfb/iU1ELqRdV fEuZkwHMWM1L1dxTxHY8oTBoMqjGhcC41uJFbAIHry/DBtRKzrN0WM+Jg3hoVKuCglyy 6MpLM+5XGGe8z/0IR5Bf+u+1SMcE6Jh1Mw58+L3T3fOUSyPOi+IqTHY1Z1AZGDYzwDUX l0ig== 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=6H43I6KqlnqkYfPdNX65r2bDEoRqUb1bJQWkcYKs/E0=; b=NiPSLKSfJ9YpIA1j/Wx9m2Bmrmq6tOuwt6qKZzOf9QsHjyXXYQNrNrKxqs5RdE02mO MF18qDogDrcJxys4N+KG9QEHo+XosiQwCUoKu4JdePhaFnU9f/GKaOtaQjyXS1quQZK7 9kA0QJbPEAjPBF7KvlGGCkyNm/1TNIU6qEsX2ZGK1/3s5j/23zTjUREfrsXjPOdH3548 OGNEEnqsnVVwGBnwMeDetPX9vmuQnd2sNzpDt58PszJnibe4l5n2shYmTxru5kjWOQY0 HtaRYOni11Q7mICY/MOF+LPzMzJ9SvHu4XA8sX58p0/jq0WYU9E8htW7MLgrFVfGu+Ot 5wcg== X-Gm-Message-State: APzg51Da4rZTa19z8M0apHglEORY3XOeF8TnPyjsdyURgqXvocWCepVJ QHOESNh1XdxXSvKbBNlmKFOrKcvPkX+ArrDcp5E= X-Google-Smtp-Source: ANB0Vdb0tVfyUH+eJjg1M6vMm2+TjmCYEIUtoK1BPU8giH32CAgG0EF1FEJV+D5avFfWv0K2DlCk8JmH03wVhr6u7nU= X-Received: by 2002:aca:5b57:: with SMTP id p84-v6mr1347539oib.109.1535468314857; Tue, 28 Aug 2018 07:58:34 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 28 Aug 2018 07:58:34 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 28 Aug 2018 07:58:33 -0700 Message-ID: Subject: Re: Unified ACK frame encoding To: Eric Rescorla , Martin Thomson Cc: Jana Iyengar , QUIC WG , Magnus Westerlund , Ian Swett , Brian Trammell Content-Type: multipart/alternative; boundary="00000000000078952f057480131b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 14:58:39 -0000 --00000000000078952f057480131b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You could have an encoding where each block is a varlen integer with no bit magic. The blocks alternate between ACK and GAP such that the first block is an ACK and a trailing GAP is ignored. Each ACK has an implicit mode which is one of: { unmarked, ECT(0), ECT(1), ECT(2), ECN-CE } The mode defaults to ACK_UNMARKED. A modifier byte can be inserted in front of a block. The modifier has the value 0b110000xx, xx =3D ACK mode. The rules out 62-bit block lengths, but that is hardly a concern. The modifier values are enumerated as: enum ack_modifier =3D { ACK_UNMARKED =3D 0xC0, ACK_ECT_0 =3D 0xC1, ACK_ECT_1 =3D 0xC2, ACK_ECN_CE =3D 0xC3 }; When a modifier is present, the ACK mode changes for all subsequent ACK blocks until a new modifier is seen. Furthermore a modifier byte is always followed by an ACK block even if the preceding block was not a GAP; this makes it efficient to have ECT-CE followed by ECT(0) and so forth. Example: The modifier byte is enumerated as the coded: ACK_UNMARKED, ACK_ECT_0, ACK_ECT_1, ACK_ECN_CE An ACK block is shown as ACK(n) or GAP(n) where n is the block length. block count(6) ACK_ECT_0, ACK(4), GAP (2), ACK_ECT_CE, ACK(1), ACK_ECT_0(4), GAP(20), ACK(10) Here there are four ACK blocks and 2 GAP blocks. The first ack block is ECT(0) marked, the second ACK block as ECT_CE marked, the third ACK block is ECT(0) marked, and the last ACK block is also ECT(0) marked. A block length can be zero which is simply ignored. It is never necessary to use a zero length block. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 28 August 2018 at 16.29.02, Eric Rescorla (ekr@rtfm.com) wrote: On Tue, Aug 28, 2018 at 7:05 AM, Eric Rescorla wrote: > On Mon, Aug 27, 2018 at 7:16 PM, Martin Thomson > wrote: > >> I'm not saying that these are invalid complaints, but I don't reach >> the same conclusion on the subjective assessment of balance of >> concerns. >> > > Sure. Sounds like a topic for New York. > > > >> I don't think that this is significantly more complicated than >> existing code. Rather than switch on all four values of the type, zero >> (gap) and non-zero (acknowledged) is simple enough. > > > Maybe I'm looking at the wrong PR? It's not so much a matter of individua= l > code complexity, but rather about embedding something in length that's no= t > length. Aside from being odd, this makes having a uniform encoder/decoder > hard, which is a real cost, especially if you use mechanically generated > encoders. > > > >> Extension in the >> future necessarily uses new frame types, which aren't constrained. >> > > Right, that's my complaint. We know that this is a piece of the protocol > we like to extend. Arguably ECN is an extension and we have at least one > other extension that's been floated (timestamp), but the structure you've > designed here has no internal extensibility points, so any *other* > extensions require a huge change where we just have a different frame typ= e. > That seems like an overly rigid design. > > Taking a step back, the "natural" design is just to have a type byte in > front of every ACK block. I.e., > > enum { gap(0), unmarked(1), ... } AckType > > struct { > AckType type; > varint length; > ... > } AckBlock; > > As you observe, this costs us a byte for every block compared to your > design, because we're stealing two bits from length, although that's only > true to the extent to which one-byte lengths remain useful. If you are > consistently pushed over into two-byte lengths for lengths in the range > 65-255, > Correction: Ian pointed out to me that because of the two varint bits, we actually pay an extra byte whenever the range length would fit in 6 bits, but not 4, which is a lot worse, because lengths in the range 17-64 are going to be quite common. -Ekr then your encoding is equally efficient to the natural one. And as I said > above, you're left with no extensibility. > > I have two thoughts about this: > 1. I'm actually not that worried about the extra byte here. It's true tha= t > ACKs are common, but one byte one way or another isn't going to kill us. > 2. If we are that worried about the extra byte, we can address that > problem by having "ACKs" and "Extended ACKs" where ACKs don't have a type > field and we use the frame type to distinguish them (I think this is what > Ian is alluding to downthread). > > So, IMO either the natural design or one which has an optional type byte > is better than what you have here. > > -Ekr > > On Mon, Aug 27, 2018 at 11:02 PM Eric Rescorla wrote: >> > >> > Yes, this PR reflects what I believed you were proposing. I believe th= e >> objections I raised here continue to apply. >> > >> > -Ekr >> > >> > >> > On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson < >> martin.thomson@gmail.com> wrote: >> >> >> >> I think that this is simpler. See >> >> https://github.com/quicwg/base-drafts/pull/1706 for a draft. >> >> On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla wrote: >> >> > >> >> > On balance I don't think I'm in favor of this bit-packing technique >> because it complicates the ordinary ACK frame even for people who don't >> care about ECN (and not doing so was part of why we decided to have anot= her >> frame type in the first place). Moreover, it's not a scalable extension >> method, so anything *else* we want to add to the ACK frame will just nee= d >> some other technique. >> >> > >> >> > -Ekr >> >> > >> >> > >> >> > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Catching up. I have posted on github (https://github.com/quicwg/ba= s >> e-drafts/issues/1439) some consideration what this implies in regards to >> ack frame sizes for different cases discussed. >> >> >> >> >> >> I think Martins design here with being able to switch between each >> different type of marking as well as being able to reasonably efficient >> encode any range lengths without issues are a good one. My analysis on t= he >> github isssue showed that in low rate changes is is equivalent to a sing= le >> byte design as well as being better capable of handling longer ranges of >> the same type. >> >> >> >> >> >> I think it is worth continuing with this one. If one wants to use >> the 2-bit type field for an explicitly encoded 4 alternative one or use = the >> delta encoding can of course be discussed. I would prefer the delta >> encoding to avoid the information loss and the need for specifying what = is >> the default ECT value and what to do in situations with a none expected = one. >> >> >> >> >> >> Cheers >> >> >> >> >> >> Magnus >> >> >> >> >> >> >> >> >> >> >> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: >> >> >>> >> >> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett >> wrote: >> >> >>>> >> >> >>>> There are a few things I like about this proposal: >> >> >>>> 1) It makes ECN and ACK_ECN either the same(or more similar) >> >> >>>> 2) As Kazuho said, it provides more precise feedback about which >> packets were marked, which avoids some edge cases we've had to write up = in >> the current text around ack loss and being unsure of exactly when recove= ry >> is exited. >> >> >>>> 3) It doesn't get more expensive as the connection goes on. Thi= s >> is an unfortunate property of the current design. >> >> >>>> >> >> >>>> I find Jana's variation on this particularly interesting, becaus= e >> if ECN isn't negotiated, I don't think there a reason to add any overhea= d. >> From personal experience, if you find a form of feedback valuable(whethe= r >> it's ECN or timestamps for one-way-delay), then you're happy to consume = a >> few extra bytes to get better feedback. If the extra information isn't >> useful for whatever reason, it's just wasted bytes. >> >> >>> >> >> >>> OK, 4 values is definitely easier to reason about. Merging ECT(0= ) >> and >> >> >>> ECT(1) into the same bucket is easy as long as we're OK with that= . >> >> >>> The simpler encoding is easier to describe and write code for, an= d >> we >> >> >>> can just tolerate (or reject) two adjacent ranges of the same typ= e, >> >> >>> just as we might tolerate (or reject) a trailing gap. >> >> >>> >> >> >>>> So overall this seems like an improvement we should do, but I'd >> prefer a variant that doesn't increase the ACK frame size when ECN is >> disabled or there are no ECN marks to report. FYI, if we need to steal = a >> bit from the number of ack blocks, I'm ok with that since I expect more >> than 32 ack blocks to be very rare. >> >> >>> >> >> >>> This is very close to a variant I suggested on the issue, which w= e >> >> >>> agreed pretty quickly wasn't great. You can create two ACK frame= s, >> >> >>> one with the full expressiveness, and another that has the >> potential >> >> >>> to encode the ECN information. Call the second one ACK_ECN... >> >> >>> >> >> >>> I'm not convinced that optimizing for the awkward space between 1= 6 >> and >> >> >>> 64 is worth the extra complexity of a variant encoding of the >> frame. >> >> >>> There are other ways to optimize for the cost of that occasional >> octet >> >> >>> that seem like they would be more fruitful (like truncating ACK >> frames >> >> >>> more aggressively). >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Magnus Westerlund >> >> >> >> >> >> ------------------------------------------------------------ >> ---------- >> >> >> Network Architecture & Protocols, Ericsson Research >> >> >> ------------------------------------------------------------ >> ---------- >> >> >> Ericsson AB | Phone +46 10 7148287 >> >> >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> >> >> SE-164 80 Stockholm, Sweden | mailto: >> magnus.westerlund@ericsson..com >> >> >> ------------------------------------------------------------ >> ---------- >> >> >> >> >> > >> > >> > >> > > --00000000000078952f057480131b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = You could have an en= coding where each block is a varlen integer with no bit magic.

The blocks alternate between ACK = and GAP such that the first block is an ACK and a trailing GAP is ignored.<= /div>

Each ACK has an impli= cit mode which is one of: { unmarked, ECT(0), ECT(1), ECT(2), ECN-CE }

The mode defaults to ACK_= UNMARKED.
A modifier = byte can be inserted in front of a block. The modifier has the value 0b1100= 00xx, xx =3D ACK mode.
The rules out 6= 2-bit block lengths, but that is hardly a concern.

The modifier val= ues are enumerated as:

=C2=A0 =C2=A0 ACK_UNMARKED =3D 0xC0,
=C2=A0 =C2=A0 ACK_ECT_0 =3D 0xC1,
=C2=A0 =C2=A0 ACK= _ECT_1 =3D 0xC2,
=C2=A0 =C2=A0 ACK_ECN_CE =3D 0xC3
};

When a modifier is present, the ACK mode changes for all subsequent = ACK blocks until a new modifier is seen.
Furthermore a modifier byte is always followed = by an ACK block even if the preceding block was not a GAP; this makes it ef= ficient to have ECT-CE followed by ECT(0) and so forth.


Example:
The modifier byte is enumerated as the coded: ACK_UN= MARKED, ACK_ECT_0, ACK_ECT_1, ACK_ECN_CE
An ACK block is shown as ACK(n) or GAP(n) where= n is the block length.

block count(6)

ACK= _ECT_0, ACK(4),
GAP (2),
A= CK_ECT_CE, ACK(1),
ACK_ECT_0(4),
GAP(20),
ACK(10)
Here there= are four ACK blocks and 2 GAP blocks. The first ack block is ECT(0) marked= , the second ACK block as ECT_CE marked, the third ACK block is ECT(0) mark= ed, and the last ACK block is also ECT(0) marked.

A block length can be zero which is simply ign= ored. It is never necessary to use a zero length block.



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


On 28 August 2018 at 16.29.02, Eric Rescorl= a (ekr@rtfm.com) wrote:



On Tue, Aug 28, 2018 at 7:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Mon, Aug 27, 2018 at 7:16 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I'm not saying that these are invalid complaints, but I don't reach
the same conclusion on the subjective assessment of balance of
concerns.

Sure. Sounds like a topic for New York.

=C2=A0
I don't think that this is significantly more complicated than
existing code. Rather than switch on all four values of the type, zero
(gap) and non-zero (acknowledged) is simple enough.

Maybe I'm looking at the wrong PR? It's not so much a matter of individual code complexity, but rather about embedding something in length that's not length. Aside from being odd, this makes having a uniform encoder/decoder hard, which is a real cost, especially if you use mechanically generated encoders.

=C2=A0
=C2=A0 Extension in the
future necessarily uses new frame types, which aren't constrained.

Right, that's my complaint. We know that this is a piece of the protocol we like to extend. Arguably ECN is an extension and we have at least one other extension that's been floated (timestamp), but the structure you've designed here has no internal extensibility points, so any *other* extensions require a huge change where we just have a different frame type. That seems like an overly rigid design.

Taking a step back, the "natural" design is just to have a type byte in front of every ACK block. I.e.,

enum { gap(0), unmarked(1), ... } AckType

struct {
=C2=A0 =C2=A0 AckType type;
=C2=A0 =C2=A0 varint length;
=C2=A0 =C2=A0 ...
} AckBlock;

As you observe, this costs us a byte for every block compared to your design, because we're stealing two bits from length, although that's only true to the extent to which one-byte lengths remain useful. If you are consistently pushed over into two-byte lengths for lengths in the range 65-255,

Correction: Ian pointed out to me that because of the two varint bits, we actually pay an extra byte whenever the range length would fit in 6 bits, but not 4, which is a lot worse, because lengths in the range 17-64 are going to be quite common.

-Ekr


then your encoding is equally efficient to the natural one. And as I said above, you're left with no extensibility.

I have two thoughts about this:
1. I'm actually not that worried about the extra byte here. It's true that ACKs are common, but one byte one way or another isn't going to kill us.
2. If we are that worried about the extra byte, we can address that problem by having "ACKs" and "Extended ACKs" where= ACKs don't have a type field and we use the frame type to distinguish them (I think this is what Ian is alluding to downthread).

So, IMO either the natural design or one which has an optional type byte is better than what you have here.

-Ekr

On Mon, Aug 27, 2018 at 11:02 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> Yes, this PR reflects what I believed you were proposing. I believe the objections I raised here continue to apply.
>
> -Ekr
>
>
> On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson <martin.thomson@gmail.com>= ; wrote:
>>
>> I think that this is simpler.=C2=A0 See
>> https://github.com/quicwg/base-drafts/p= ull/1706 for a draft.
>> On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> > On balance I don't think I'm in favor of this bit-packing technique because it complicates the ordinary ACK frame even for people who don't care about ECN (and not doing so was part of why we decided to have another frame type in the first place). Moreover, it's not a scalable extension method, so anything *else* we want to add to the ACK frame will just need some other technique.
>> >
>> > -Ekr
>> >
>> >
>> > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund <mag= nus.westerlund@ericsson.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Catching up. I have posted on github (https://github.com/quicwg/base-drafts/issues/1439) some consideration what this implies in regards to ack frame sizes for different cases discussed.
>> >>
>> >> I think Martins design here with being able to switch between each different type of marking as well as being able to reasonably efficient encode any range lengths without issues are a good one. My analysis on the github isssue showed that in low rate changes is is equivalent to a single byte design as well as being better capable of handling longer ranges of the same type.
>> >>
>> >> I think it is worth continuing with this one. If one wants to use the 2-bit type field for an explicitly encoded 4 alternative one or use the delta encoding can of course be discussed. I would prefer the delta encoding to avoid the information loss and the need for specifying what is the default ECT value and what to do in situations with a none expected one.
>> >>
>> >> Cheers
>> >>
>> >> Magnus
>> >>
>> >>
>> >>
>> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson:
>> >>>
>> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett <ianswett@googl= e.com> wrote:
>> >>>>
>> >>>> There are a few things I like about this proposal:
>> >>>> 1) It makes ECN and ACK_ECN either the same(or more similar)
>> >>>> 2) As Kazuho said, it provides more precise feedback about which packets were marked, which avoids some edge cases we've had to write up in the current text around ack loss and being unsure of exactly when recovery is exited.
>> >>>> 3) It doesn't get more expensive as the connection goes on.=C2=A0 This is an unfortunate property of the current design.
>> >>>>
>> >>>> I find Jana's variation on this particularly interesting, because if ECN isn't negotiated, I don't think there a reason to add any overhead.=C2=A0 From personal experience, if you find a form of feedback valuable(whether it's ECN or timestamps for one-way-delay), then you're happy to consume a few extra bytes to get better feedback.=C2=A0 If the extra information isn't useful for whatever reason, it's just wasted bytes.
>> >>>
>> >>> OK, 4 values is definitely easier to reason about.=C2=A0 Merging ECT(0) and
>> >>> ECT(1) into the same bucket is easy as long as we're OK with that.
>> >>> The simpler encoding is easier to describe and write code for, and we
>> >>> can just tolerate (or reject) two adjacent ranges of the same type,
>> >>> just as we might tolerate (or reject) a trailing gap.
>> >>>
>> >>>> So overall this seems like an improvement we should do, but I'd prefer a variant that doesn't increase the ACK frame size when ECN is disabled or there are no ECN marks to report.=C2=A0 FYI, if we need to steal a bit from the number of ack blocks, I'm ok with that since I expect more than 32 ack blocks to be very rare.
>> >>>
>> >>> This is very close to a variant I suggested on the issue, which we
>> >>> agreed pretty quickly wasn't great.=C2=A0 You can create two ACK frames,
>> >>> one with the full expressiveness, and another that has the potential
>> >>> to encode the ECN information.=C2=A0 Call the second one ACK_ECN...
>> >>>
>> >>> I'm not convinced that optimizing for the awkward space between 16 and
>> >>> 64 is worth the extra complexity of a variant encoding of the frame.
>> >>> There are other ways to optimize for the cost of that occasional octet
>> >>> that seem like they would be more fruitful (like truncating ACK frames
>> >>> more aggressively).
>> >>
>> >>
>> >> --
>> >>
>> >> Magnus Westerlund
>> >>
>> >> -----------------------------------------------------------------= -----
>> >> Network Architecture & Protocols, Ericsson Research
>> >> -----------------------------------------------------------------= -----
>> >> Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
>> >> Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0949079
>> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson= ..com
>> >> -----------------------------------------------------------------= -----
>> >>
>> >
>
>


 --00000000000078952f057480131b-- From nobody Tue Aug 28 08:14:51 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C80130DE5 for ; Tue, 28 Aug 2018 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zJ2xPfBoqhvl for ; Tue, 28 Aug 2018 08:14:45 -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 8C3C9130DD9 for ; Tue, 28 Aug 2018 08:14:45 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id b15-v6so3446838oib.10 for ; Tue, 28 Aug 2018 08:14:45 -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=JlU5c2xeQQ9MwXC80YBN9uOdtR0IdVSxnTQ+qSO6cls=; b=GTNgAqwcDwT9HEcn/KudEBu57xPKXbruoKeCzFEXQ5yfYawT/Tpwc/H6Kr9Pgebqzo bNSrdoBF6kJ98BWIzxFgx5u6FZMGy0AexuEuu94LJXDXxAnFrwuVmp/Jv8ec20IY4JEG w6WtxpS0xsUmtlvNgUe03Uu23cJ6zUC/53YwtbyVjIk7dJQmCFsK4B00XaGlB5dgb6QI Mr194VPKVa6gY72xJGs7PkYtvuBxM5RVwpcN5KZ1y2fY2mMUjzyr6BiBD8S5jNGV6yzN AY3cyirQ/PbOZ03aww+u3JLiC+HERlUsKJ7HpznmWhEe2qmAlwxsPCjYiwWaHHnITH/s me1Q== 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=JlU5c2xeQQ9MwXC80YBN9uOdtR0IdVSxnTQ+qSO6cls=; b=cE3cucYRHjUBUL5zK8g4nWt0cq19/Pt/wCQLZBkrFKjcw1l+IMK+8WzCL0suOpYQyb WV8hieRmJm4VJ3FETpE9JfnzD9ZrTaUXzUOGAz5GiA1Q1Eob+2D4AHoYXuPdJmm1bTO/ MYy+YumEocaN3LcZRLNh8Md0knBJHKAuXw6HE3fL6M6eWRGqhvOe/vlYK2wwrbmzK+dZ Zu39j6VRn8Idf/VfJT5tvfP2Q64EZDMX0GUcrKa1x9NdnW2wh7y2N9gqNfkeezGsZ5+Q ECKNc6YHNh+DzzZ74Yf9yJdSXZW7XjLCLzmv3COzPUVsJdoQwOtVY0+jz3fPW2Hm/3K3 zIfw== X-Gm-Message-State: APzg51Dm+pHM7RF1Nq7RNmyoUTnRBsQgQS0fC7jWA1XvspjxKvhnpVTN gXymWS3+g8BbFKXgKoQcd4sgAz8b/Hi0ijkvjEg= X-Google-Smtp-Source: ANB0VdYR5/6daHPF0b4lDZ+AlZ8W8K7X6Oig8dwzcmQ0sEC8UCiK28q/1E/HZeTNCbdB0WzytTmUJq1Puf8YZi+d+7U= X-Received: by 2002:aca:e0c2:: with SMTP id x185-v6mr1740479oig.220.1535469284828; Tue, 28 Aug 2018 08:14:44 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 28 Aug 2018 08:14:44 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 28 Aug 2018 08:14:44 -0700 Message-ID: Subject: Re: Unified ACK frame encoding To: Eric Rescorla , Martin Thomson Cc: Jana Iyengar , QUIC WG , Magnus Westerlund , Ian Swett , Brian Trammell Content-Type: multipart/alternative; boundary="000000000000492ca30574804d99" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 15:14:49 -0000 --000000000000492ca30574804d99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ECT(2) was a typo, there are only 4 modes: { unmarked, ECT(0), ECT(1), ECN-CE }, but more could be added in the future since there are 64 available code points in total. On 28 August 2018 at 16.58.34, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote: You could have an encoding where each block is a varlen integer with no bit magic. The blocks alternate between ACK and GAP such that the first block is an ACK and a trailing GAP is ignored. Each ACK has an implicit mode which is one of: { unmarked, ECT(0), ECT(1), ECT(2), ECN-CE } The mode defaults to ACK_UNMARKED. A modifier byte can be inserted in front of a block. The modifier has the value 0b110000xx, xx =3D ACK mode. The rules out 62-bit block lengths, but that is hardly a concern. The modifier values are enumerated as: enum ack_modifier =3D { ACK_UNMARKED =3D 0xC0, ACK_ECT_0 =3D 0xC1, ACK_ECT_1 =3D 0xC2, ACK_ECN_CE =3D 0xC3 }; When a modifier is present, the ACK mode changes for all subsequent ACK blocks until a new modifier is seen. Furthermore a modifier byte is always followed by an ACK block even if the preceding block was not a GAP; this makes it efficient to have ECT-CE followed by ECT(0) and so forth. Example: The modifier byte is enumerated as the coded: ACK_UNMARKED, ACK_ECT_0, ACK_ECT_1, ACK_ECN_CE An ACK block is shown as ACK(n) or GAP(n) where n is the block length. block count(6) ACK_ECT_0, ACK(4), GAP (2), ACK_ECT_CE, ACK(1), ACK_ECT_0(4), GAP(20), ACK(10) Here there are four ACK blocks and 2 GAP blocks. The first ack block is ECT(0) marked, the second ACK block as ECT_CE marked, the third ACK block is ECT(0) marked, and the last ACK block is also ECT(0) marked. A block length can be zero which is simply ignored. It is never necessary to use a zero length block. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 28 August 2018 at 16.29.02, Eric Rescorla (ekr@rtfm.com) wrote: On Tue, Aug 28, 2018 at 7:05 AM, Eric Rescorla wrote: > On Mon, Aug 27, 2018 at 7:16 PM, Martin Thomson > wrote: > >> I'm not saying that these are invalid complaints, but I don't reach >> the same conclusion on the subjective assessment of balance of >> concerns. >> > > Sure. Sounds like a topic for New York. > > > >> I don't think that this is significantly more complicated than >> existing code. Rather than switch on all four values of the type, zero >> (gap) and non-zero (acknowledged) is simple enough. > > > Maybe I'm looking at the wrong PR? It's not so much a matter of individua= l > code complexity, but rather about embedding something in length that's no= t > length. Aside from being odd, this makes having a uniform encoder/decoder > hard, which is a real cost, especially if you use mechanically generated > encoders. > > > >> Extension in the >> future necessarily uses new frame types, which aren't constrained. >> > > Right, that's my complaint. We know that this is a piece of the protocol > we like to extend. Arguably ECN is an extension and we have at least one > other extension that's been floated (timestamp), but the structure you've > designed here has no internal extensibility points, so any *other* > extensions require a huge change where we just have a different frame typ= e. > That seems like an overly rigid design. > > Taking a step back, the "natural" design is just to have a type byte in > front of every ACK block. I.e., > > enum { gap(0), unmarked(1), ... } AckType > > struct { > AckType type; > varint length; > ... > } AckBlock; > > As you observe, this costs us a byte for every block compared to your > design, because we're stealing two bits from length, although that's only > true to the extent to which one-byte lengths remain useful. If you are > consistently pushed over into two-byte lengths for lengths in the range > 65-255, > Correction: Ian pointed out to me that because of the two varint bits, we actually pay an extra byte whenever the range length would fit in 6 bits, but not 4, which is a lot worse, because lengths in the range 17-64 are going to be quite common. -Ekr then your encoding is equally efficient to the natural one. And as I said > above, you're left with no extensibility. > > I have two thoughts about this: > 1. I'm actually not that worried about the extra byte here. It's true tha= t > ACKs are common, but one byte one way or another isn't going to kill us. > 2. If we are that worried about the extra byte, we can address that > problem by having "ACKs" and "Extended ACKs" where ACKs don't have a type > field and we use the frame type to distinguish them (I think this is what > Ian is alluding to downthread). > > So, IMO either the natural design or one which has an optional type byte > is better than what you have here. > > -Ekr > > On Mon, Aug 27, 2018 at 11:02 PM Eric Rescorla wrote: >> > >> > Yes, this PR reflects what I believed you were proposing. I believe th= e >> objections I raised here continue to apply. >> > >> > -Ekr >> > >> > >> > On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson < >> martin.thomson@gmail.com> wrote: >> >> >> >> I think that this is simpler. See >> >> https://github.com/quicwg/base-drafts/pull/1706 for a draft. >> >> On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla wrote: >> >> > >> >> > On balance I don't think I'm in favor of this bit-packing technique >> because it complicates the ordinary ACK frame even for people who don't >> care about ECN (and not doing so was part of why we decided to have anot= her >> frame type in the first place). Moreover, it's not a scalable extension >> method, so anything *else* we want to add to the ACK frame will just nee= d >> some other technique. >> >> > >> >> > -Ekr >> >> > >> >> > >> >> > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Catching up. I have posted on github (https://github.com/quicwg/ba= s >> e-drafts/issues/1439) some consideration what this implies in regards to >> ack frame sizes for different cases discussed. >> >> >> >> >> >> I think Martins design here with being able to switch between each >> different type of marking as well as being able to reasonably efficient >> encode any range lengths without issues are a good one. My analysis on t= he >> github isssue showed that in low rate changes is is equivalent to a sing= le >> byte design as well as being better capable of handling longer ranges of >> the same type. >> >> >> >> >> >> I think it is worth continuing with this one. If one wants to use >> the 2-bit type field for an explicitly encoded 4 alternative one or use = the >> delta encoding can of course be discussed. I would prefer the delta >> encoding to avoid the information loss and the need for specifying what = is >> the default ECT value and what to do in situations with a none expected = one. >> >> >> >> >> >> Cheers >> >> >> >> >> >> Magnus >> >> >> >> >> >> >> >> >> >> >> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson: >> >> >>> >> >> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett >> wrote: >> >> >>>> >> >> >>>> There are a few things I like about this proposal: >> >> >>>> 1) It makes ECN and ACK_ECN either the same(or more similar) >> >> >>>> 2) As Kazuho said, it provides more precise feedback about which >> packets were marked, which avoids some edge cases we've had to write up = in >> the current text around ack loss and being unsure of exactly when recove= ry >> is exited. >> >> >>>> 3) It doesn't get more expensive as the connection goes on. Thi= s >> is an unfortunate property of the current design. >> >> >>>> >> >> >>>> I find Jana's variation on this particularly interesting, becaus= e >> if ECN isn't negotiated, I don't think there a reason to add any overhea= d. >> From personal experience, if you find a form of feedback valuable(whethe= r >> it's ECN or timestamps for one-way-delay), then you're happy to consume = a >> few extra bytes to get better feedback. If the extra information isn't >> useful for whatever reason, it's just wasted bytes. >> >> >>> >> >> >>> OK, 4 values is definitely easier to reason about. Merging ECT(0= ) >> and >> >> >>> ECT(1) into the same bucket is easy as long as we're OK with that= . >> >> >>> The simpler encoding is easier to describe and write code for, an= d >> we >> >> >>> can just tolerate (or reject) two adjacent ranges of the same typ= e, >> >> >>> just as we might tolerate (or reject) a trailing gap. >> >> >>> >> >> >>>> So overall this seems like an improvement we should do, but I'd >> prefer a variant that doesn't increase the ACK frame size when ECN is >> disabled or there are no ECN marks to report. FYI, if we need to steal = a >> bit from the number of ack blocks, I'm ok with that since I expect more >> than 32 ack blocks to be very rare. >> >> >>> >> >> >>> This is very close to a variant I suggested on the issue, which w= e >> >> >>> agreed pretty quickly wasn't great. You can create two ACK frame= s, >> >> >>> one with the full expressiveness, and another that has the >> potential >> >> >>> to encode the ECN information. Call the second one ACK_ECN... >> >> >>> >> >> >>> I'm not convinced that optimizing for the awkward space between 1= 6 >> and >> >> >>> 64 is worth the extra complexity of a variant encoding of the >> frame. >> >> >>> There are other ways to optimize for the cost of that occasional >> octet >> >> >>> that seem like they would be more fruitful (like truncating ACK >> frames >> >> >>> more aggressively). >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Magnus Westerlund >> >> >> >> >> >> ------------------------------------------------------------ >> ---------- >> >> >> Network Architecture & Protocols, Ericsson Research >> >> >> ------------------------------------------------------------ >> ---------- >> >> >> Ericsson AB | Phone +46 10 7148287 >> >> >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> >> >> SE-164 80 Stockholm, Sweden | mailto: >> magnus.westerlund@ericsson..com >> >> >> ------------------------------------------------------------ >> ---------- >> >> >> >> >> > >> > >> > >> > > --000000000000492ca30574804d99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = ECT(2) was a typo, t= here are only 4 modes: =C2=A0{ unmarked, ECT(0), ECT(1), ECN-CE }, but more= could be added in the future since there are 64 available code points in t= otal.



On 28 August 2018 at 16.58.34, Mikkel Fahn= =C3=B8e J=C3=B8rgensen (mikkelfj@gmai= l.com) wrote:

<= div>
You could have an encoding where each block is a varlen integer with no bit magic.

The blocks alternate between ACK and GAP such that the first block is an ACK and a trailing GAP is ignored.

Each ACK has an implicit mode which is one of: { unmarked, ECT(0), ECT(1), ECT(2), ECN-CE }

The mode defaults to ACK_UNMARKED.

A modifier byte can be inserted in front of a block. The modifier has the value 0b110000xx, xx =3D ACK mode.
The rules out 62-bit block lengths, but that is hardly a concern.

The modifier values are enumerated as:

enum ack_modifier =3D {
=C2=A0 =C2=A0 ACK_UNMARKED =3D 0xC0,
=C2=A0 =C2=A0 ACK_ECT_0 =3D 0xC1,
=C2=A0 =C2=A0 ACK_ECT_1 =3D 0xC2,
=C2=A0 =C2=A0 ACK_ECN_CE =3D 0xC3
};

When a modifier is present, the ACK mode changes for all subsequent ACK blocks until a new modifier is seen.
Furthermore a modifier byte is always followed by an ACK block even if the preceding block was not a GAP; this makes it efficient to have ECT-CE followed by ECT(0) and so forth.


Example:
The modifier byte is enumerated as the coded: ACK_UNMARKED, ACK_ECT_0, ACK_ECT_1, ACK_ECN_CE
An ACK block is shown as ACK(n) or GAP(n) where n is the block length.

block count(6)

ACK_ECT_0, ACK(4),
GAP (2),
ACK_ECT_CE, ACK(1),
ACK_ECT_0(4),
GAP(20),
ACK(10)

Here there are four ACK blocks and 2 GAP blocks. The first ack block is ECT(0) marked, the second ACK block as ECT_CE marked, the third ACK block is ECT(0) marked, and the last ACK block is also ECT(0) marked.

A block length can be zero which is simply ignored. It is never necessary to use a zero length block.



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


On 28 August 2018 at 16.29.02, Eric Rescorla (ekr@rtfm.com) wrote:

On Tue, Aug 28, 2018 at 7:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Mon, Aug 27, 2018 at 7:16 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I'm not saying that these are invalid complaints, but I don't reach
the same conclusion on the subjective assessment of balance of
concerns.

Sure. Sounds like a topic for New York.

=C2=A0
I don't think that this is significantly more complicated than
existing code. Rather than switch on all four values of the type, zero
(gap) and non-zero (acknowledged) is simple enough.

Maybe I'm looking at the wrong PR? It's not so much a matter of individual code complexity, but rather about embedding something in length that's not length. Aside from being odd, this makes having a uniform encoder/decoder hard, which is a real cost, especially if you use mechanically generated encoders.

=C2=A0
=C2=A0 Extension in the
future necessarily uses new frame types, which aren't constrained.

Right, that's my complaint. We know that this is a piece of the protocol we like to extend. Arguably ECN is an extension and we have at least one other extension that's been floated (timestamp), but the structure you've designed here has no internal extensibility points, so any *other* extensions require a huge change where we just have a different frame type. That seems like an overly rigid design.

Taking a step back, the "natural" design is just to have a type byte in front of every ACK block. I.e.,

enum { gap(0), unmarked(1), ... } AckType

struct {
=C2=A0 =C2=A0 AckType type;
=C2=A0 =C2=A0 varint length;
=C2=A0 =C2=A0 ...
} AckBlock;

As you observe, this costs us a byte for every block compared to your design, because we're stealing two bits from length, although that's only true to the extent to which one-byte lengths remain useful. If you are consistently pushed over into two-byte lengths for lengths in the range 65-255,

Correction: Ian pointed out to me that because of the two varint bits, we actually pay an extra byte whenever the range length would fit in 6 bits, but not 4, which is a lot worse, because lengths in the range 17-64 are going to be quite common.

-Ekr


then your encoding is equally efficient to the natural one. And as I said above, you're left with no extensibility.

I have two thoughts about this:
1. I'm actually not that worried about the extra byte here. It's true that ACKs are common, but one byte one way or another isn't going to kill us.
2. If we are that worried about the extra byte, we can address that problem by having "ACKs" and "Extended ACKs" where= ACKs don't have a type field and we use the frame type to distinguish them (I think this is what Ian is alluding to downthread).

So, IMO either the natural design or one which has an optional type byte is better than what you have here.

-Ekr

On Mon, Aug 27, 2018 at 11:02 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> Yes, this PR reflects what I believed you were proposing. I believe the objections I raised here continue to apply.
>
> -Ekr
>
>
> On Mon, Aug 27, 2018 at 1:11 AM, Martin Thomson <martin.thomson@gmail.com>= ; wrote:
>>
>> I think that this is simpler.=C2=A0 See
>> https://github.com/quicwg/base-drafts/p= ull/1706 for a draft.
>> On Mon, Aug 27, 2018 at 8:55 AM Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> > On balance I don't think I'm in favor of this bit-packing technique because it complicates the ordinary ACK frame even for people who don't care about ECN (and not doing so was part of why we decided to have another frame type in the first place). Moreover, it's not a scalable extension method, so anything *else* we want to add to the ACK frame will just need some other technique.
>> >
>> > -Ekr
>> >
>> >
>> > On Fri, Aug 24, 2018 at 7:51 AM, Magnus Westerlund <mag= nus.westerlund@ericsson.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Catching up. I have posted on github (https://github.com/quicwg/base-drafts/issues/1439) some consideration what this implies in regards to ack frame sizes for different cases discussed.
>> >>
>> >> I think Martins design here with being able to switch between each different type of marking as well as being able to reasonably efficient encode any range lengths without issues are a good one. My analysis on the github isssue showed that in low rate changes is is equivalent to a single byte design as well as being better capable of handling longer ranges of the same type.
>> >>
>> >> I think it is worth continuing with this one. If one wants to use the 2-bit type field for an explicitly encoded 4 alternative one or use the delta encoding can of course be discussed. I would prefer the delta encoding to avoid the information loss and the need for specifying what is the default ECT value and what to do in situations with a none expected one.
>> >>
>> >> Cheers
>> >>
>> >> Magnus
>> >>
>> >>
>> >>
>> >> Den 2018-08-13 kl. 08:29, skrev Martin Thomson:
>> >>>
>> >>> On Fri, Aug 10, 2018 at 6:15 AM Ian Swett <ianswett@googl= e.com> wrote:
>> >>>>
>> >>>> There are a few things I like about this proposal:
>> >>>> 1) It makes ECN and ACK_ECN either the same(or more similar)
>> >>>> 2) As Kazuho said, it provides more precise feedback about which packets were marked, which avoids some edge cases we've had to write up in the current text around ack loss and being unsure of exactly when recovery is exited.
>> >>>> 3) It doesn't get more expensive as the connection goes on.=C2=A0 This is an unfortunate property of the current design.
>> >>>>
>> >>>> I find Jana's variation on this particularly interesting, because if ECN isn't negotiated, I don't think there a reason to add any overhead.=C2=A0 From personal experience, if you find a form of feedback valuable(whether it's ECN or timestamps for one-way-delay), then you're happy to consume a few extra bytes to get better feedback.=C2=A0 If the extra information isn't useful for whatever reason, it's just wasted bytes.
>> >>>
>> >>> OK, 4 values is definitely easier to reason about.=C2=A0 Merging ECT(0) and
>> >>> ECT(1) into the same bucket is easy as long as we're OK with that.
>> >>> The simpler encoding is easier to describe and write code for, and we
>> >>> can just tolerate (or reject) two adjacent ranges of the same type,
>> >>> just as we might tolerate (or reject) a trailing gap.
>> >>>
>> >>>> So overall this seems like an improvement we should do, but I'd prefer a variant that doesn't increase the ACK frame size when ECN is disabled or there are no ECN marks to report.=C2=A0 FYI, if we need to steal a bit from the number of ack blocks, I'm ok with that since I expect more than 32 ack blocks to be very rare.
>> >>>
>> >>> This is very close to a variant I suggested on the issue, which we
>> >>> agreed pretty quickly wasn't great.=C2=A0 You can create two ACK frames,
>> >>> one with the full expressiveness, and another that has the potential
>> >>> to encode the ECN information.=C2=A0 Call the second one ACK_ECN...
>> >>>
>> >>> I'm not convinced that optimizing for the awkward space between 16 and
>> >>> 64 is worth the extra complexity of a variant encoding of the frame.
>> >>> There are other ways to optimize for the cost of that occasional octet
>> >>> that seem like they would be more fruitful (like truncating ACK frames
>> >>> more aggressively).
>> >>
>> >>
>> >> --
>> >>
>> >> Magnus Westerlund
>> >>
>> >> -----------------------------------------------------------------= -----
>> >> Network Architecture & Protocols, Ericsson Research
>> >> -----------------------------------------------------------------= -----
>> >> Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
>> >> Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0949079
>> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson= ..com
>> >> -----------------------------------------------------------------= -----
>> >>
>> >
>
>


--000000000000492ca30574804d99-- From nobody Tue Aug 28 08:18:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B39B130DF1 for ; Tue, 28 Aug 2018 08:18:04 -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, 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 p6eRxkLcgp66 for ; Tue, 28 Aug 2018 08:18:02 -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 C3A90130DE5 for ; Tue, 28 Aug 2018 08:18:02 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id c190-v6so3500683oig.6 for ; Tue, 28 Aug 2018 08:18:02 -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=6XacSgiy0QeuA71Ne0gYdKjvPsSvcDMDpK5OO5lEc2U=; b=bJa955N2ftxZ7DEuIMhwZ5obqmkP6TMeQg12UKiD/ob7EgnPq+/G4qGJY5hAacyQn7 goGXDJHLrfDFeTZ27FDZb0rP8/b9yDB7/maS+vqj989AGJs2YksMvI/FKHDxOGffz99l uOYBKbEdVBkS2rtu3lIN0PPuDFJDjX6VXO4FZ9utAHUGny3UViwPufJxdvj7Cj7jKrml 5avVc5q4BZM9rlHf5u6IimjI1WWX8ULUOT0sMvBy1ueTa4ACjmyNBa78UvE0YeW8GxVC Q3sx0hfthgknhLPLJfRPino2rCP/qn2Po3gYp08rmcG89dz9fi5CHUK/GHlysy7ObV6X +AuA== 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=6XacSgiy0QeuA71Ne0gYdKjvPsSvcDMDpK5OO5lEc2U=; b=T2PmHbvMFVNRpte8i7XeMIoiOC0cMBjtPpz+zIFWZ6dRpAnMW1oZG+9tRx6hYsANRU +Z0ppmkg81owR34OdnAYfrNl3u0XBSCR+6Pa3On/4JSfFkatCoB+ymxWGYZ7X9ijWujO q925RsO9lxB8RVAftla8uhNVSyEDv6tUtbyfrC/3wWtiBGz7WbPnt0jc8rrsvzBWeKbr jEDcEeSj+t5sWAKW9pLAZvxdkRMuKfDDjXXCaN2/zj5wpv8LrsJeswghKRIJJR68CGZ4 sPIZ0PpFx0+HiOTOjgigTbPHXuGw2iF4DCyVFZ3g91vvfvbFQEfg6Ks9ukSVTY9C/8Cd iwyA== X-Gm-Message-State: APzg51DFz89GjABrDiVZo//dZH+yOmiyN+nDhpuOPSUwZcQlDiE7QPgD MANBchk/eivdD7v2w67j6qtqR8aOZRcCRhYuDE0= X-Google-Smtp-Source: ANB0Vda/E1+v8p6+I2YGZlBAFZcw44iTTZ1fGZoQzPzscGSeAlVcamuw2vfRRUEzl8Msnf2SWzt0BdVb6vp3gseJAvQ= X-Received: by 2002:aca:524a:: with SMTP id g71-v6mr1700415oib.351.1535469482248; Tue, 28 Aug 2018 08:18:02 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 28 Aug 2018 08:18:01 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 28 Aug 2018 08:18:01 -0700 Message-ID: Subject: Re: Unified ACK frame encoding To: Eric Rescorla , Martin Thomson Cc: Jana Iyengar , QUIC WG , Magnus Westerlund , Ian Swett , Brian Trammell Content-Type: multipart/alternative; boundary="0000000000000d8e7d0574805934" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 15:18:05 -0000 --0000000000000d8e7d0574805934 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable More typos sorry, ACK_ECT_0(4), should read ACK_ECT_0, ACK(4) so the example becomes: block count(6) ACK_ECT_0, ACK(4), GAP (2), ACK_ECT_CE, ACK(1), ACK_ECT_0, ACK(4), GAP(20), ACK(10) Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 28 August 2018 at 17.14.44, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote: block count(6) ACK_ECT_0, ACK(4), GAP (2), ACK_ECT_CE, ACK(1), ACK_ECT_0(4), GAP(20), ACK(10) --0000000000000d8e7d0574805934 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = More typos sorry, AC= K_ECT_0(4), should read ACK_ECT_0, ACK(4) so the example becomes:

block count(6)

ACK_ECT_0, ACK(4),
= GAP (2),
ACK_ECT_CE,= ACK(1),
ACK_ECT_0, = ACK(4),
GAP(20),
ACK(10)
Kind Regards,
Mikkel Fahn=C3=B8e J=C3= =B8rgensen


On 28 August 201= 8 at 17.14.44, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

block count(6)

ACK= _ECT_0, ACK(4),
GAP (2),
ACK_ECT_CE, ACK(1),
A= CK_ECT_0(4),
GAP(20),
ACK(10)
 --0000000000000d8e7d0574805934-- From nobody Tue Aug 28 11:47:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA232129C6A for ; Tue, 28 Aug 2018 11:47:21 -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 YTZ1HnNKc4Jp for ; Tue, 28 Aug 2018 11:47:19 -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 7A950127148 for ; Tue, 28 Aug 2018 11:47:19 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx105.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1fuj1H-0009FE-MW for quic@ietf.org; Tue, 28 Aug 2018 20:47:16 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fuj1D-0007vv-KN for quic@ietf.org; Tue, 28 Aug 2018 14:47:12 -0400 Received: (qmail 7497 invoked from network); 28 Aug 2018 18:47:10 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.164]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Aug 2018 18:47:09 -0000 To: Eric Rescorla , Martin Thomson Cc: Jana Iyengar , Magnus Westerlund , Ian Swett , QUIC WG , Brian Trammell References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <9e734d00-101d-7955-c44e-948824bd7a6f@huitema.net> Date: Tue, 28 Aug 2018 11:47:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Unified ACK frame encoding X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jZjI26M7MeAOc8UQDEEZGp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViGqL/R468WEREDCbCXK4EmM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1VzUjpi3KNxdQZ39cmOPHk5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseygOIcx4SICe6nNcjjd/M50Y6QGVSvC9ATxEYI3bPwB8Xm5EPngXdEF uwGFfgAR6MtqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1Z+7sPmjIM3bM0ihYRE0YjPM ySEj7fwLz33nMnt8v2VAbTmKJq2ms5fD0VtmD1NhT2CP6KnOBvL4JpDTCrFGRy2NOxX1JE+ge4U8 zDlf/vBeZWnUiB5AwhE1R4SU1XnZoSHqAeeZGuerhbgzLuS7t5uqDaS+z0Zpk4m+5dZjvPBJzM60 voqUUzJmvILAkkfgINQ3oeBRL6kAeZ0071wHqiNXgjmuntq3xZgBxhdNFJUcZu3d9ZNXJQW8HUxK X5uYJmvDK3PKrieG7T6bf9hS7hR0q7xASYaBUaOtmtSkj3iuxJhh7EHDojb6D9Mx+gs1+GHf4ys4 4rg2B8/9FmK9a1O9x7lsssuZ/53sObhu0YJN X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 18:47:22 -0000 On 8/28/2018 7:27 AM, Eric Rescorla wrote: > > Correction: Ian pointed out to me that because of the two varint bits, > we actually pay an extra byte whenever the range length would fit in 6 > bits, but not 4, which is a lot worse, because lengths in the range > 17-64 are going to be quite common. > > -Ekr There is another cost, but it is only borne if the implementation actually supports ECN. Suppose the node receives a string of packets with alternating CE marking, something like ECT(1)-ECT(1)-CE-ECT(1)-ECT(1)-CE-ECT(1)-ECT(1)-CE, etc. This is not a theoretical case: in DC-TCP, equilibrium is reached when the queue size at the bottleneck hovers around the low water mark, and the algorithm is specifically designed to produced frequent feedback. Now, if you have that, you end up encoding a series of short ranges in the ACK, which makes it way longer than just saying "I received everything but 3 packets were marked as CE". This inflates not just the size of the ACKs, but also the number of ranges in the "SACK dashboard" that nodes have to keep to manage the sending of ACKs. When packets are received out of order, ranges can normally be coalesced, but with ECN they can only be coalesced if all packets had the same ECN marking. So there is indeed a cost. I also have some sympathy for EKR's argument about future extensions. ECN is just one of the signals that peers may want to use to manage congestion and recovery. If nodes want to make thoughtful decisions, they will certainly also look at RTT or one way delays, and maybe at out-of-order deliveries. Would we want to use bits in the "gap-range-length" to indicate that for packet number 73 the one way delay was longer than usual, or would we use some other extension mechanism? And if we have another extension mechanism, why not use it for ECN as well? -- Christian Huitema From nobody Wed Aug 29 22:48:55 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756B71252B7 for ; Wed, 29 Aug 2018 22:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjtHqxJZdvud for ; Wed, 29 Aug 2018 22:48:40 -0700 (PDT) Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.215]) (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 4EE24130F16 for ; Wed, 29 Aug 2018 22:48:40 -0700 (PDT) Received: from [67.219.246.198] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-c.us-east-1.aws.symcld.net id CA/8D-19816-735878B5; Thu, 30 Aug 2018 05:48:39 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleJIrShJLcpLzFFi42JJl3ulp2vW2h5 tcHyCjUXriveMDowej569YQ5gjGLNzEvKr0hgzWjY3c5cMNW04uuZXUwNjI8Muhg5OYQEXjBK TOlQ72LkArKnM0pMnv6cFSTBJqAtsW/mP0YQW0RAX+L2j1ssILawgJfE/u3/2SDiARI9M+8wd zFyANl6EgfW5oOYLAKqEqcbuEEqeAV8JG6+WA/WySggKzHt0X0mEJtZQFxi7rRZYJskBAQklu w5zwxhi0q8fPyPFWSMhIC8xJZZghDleRI3Vl5ggxgpKHFy5hOWCYwCs5BMmoWkbBaSMoi4jsS C3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6K0TSpKDM9oyQ3MTNH19DAQNfQ0EjXXNfSUi+xSjdZ r7RYNzWxuETXUC+xvFivuDI3OSdFLy+1ZBMjMCZSCtiTdzCebUk/xCjJwaQkyvtvWlu0EF9Sf kplRmJxRnxRaU5q8SFGGQ4OJQne783t0UKCRanpqRVpmTnA6IRJS3DwKInw2rcApXmLCxJziz PTIVKnGO05TjX3TGLmOHJvCpC8ACb/vJ86iVmIJS8/L1VKnPcQyFQBkLaM0jy4obBkcolRVkq Yl5GBgUGIpyC1KDezBFX+FaM4B6OSMG8kyHKezLwSuN2vgM5iAjqr614LyFkliQgpqQbGx7wH ffd88AvpSeR3LH718FEac9StwNl77AyY3kRfOlkbqH6ktF50q868+NZrAhVOutfubVrz9efzd RsLtlyLdd3ySG7TR9Flf5cnGhpq7We4bVfreP7JRoUzKdc7nqvNSCw5e3ju+c5Hu+S62C2Zwy YxPt/J1PrjwE0dvpIHS+fd+RuWJ9GSrMRSnJFoqMVcVJwIAJ5y+2QhAwAA X-Env-Sender: changzhi2@lenovo.com X-Msg-Ref: server-28.tower-406.messagelabs.com!1535608114!2737719!1 X-Originating-IP: [103.30.234.46] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24149 invoked from network); 30 Aug 2018 05:48:38 -0000 Received: from unknown (HELO apsmtp03.lenovo.com) (103.30.234.46) by server-28.tower-406.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 30 Aug 2018 05:48:38 -0000 Received: from CNMAILCH02.lenovo.com (unknown [10.96.97.130]) by apsmtp03.lenovo.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 257a_3e21_ee8720fa_220c_4f08_abe5_626ee9731c3e; Thu, 30 Aug 2018 13:48:28 +0800 Received: from CNMAILEX03.lenovo.com ([169.254.11.183]) by CNMAILCH02.lenovo.com ([::1]) with mapi id 14.03.0389.001; Thu, 30 Aug 2018 13:48:11 +0800 From: Zhi Zhi2 Chang To: "quic@ietfa.amsl.com" Subject: Questions about congestion control and version negotiation packet Thread-Topic: Questions about congestion control and version negotiation packet Thread-Index: AdRAEKgJWNLhgoLrRE+dKISqABIItw== Date: Thu, 30 Aug 2018 05:48:10 +0000 Message-ID: <7335E3E9AC2DE240988251CF62CAE90A0A2394AE@CNMAILEX03.lenovo.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.19.89] Content-Type: multipart/alternative; boundary="_000_7335E3E9AC2DE240988251CF62CAE90A0A2394AECNMAILEX03lenov_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 05:48:53 -0000 --_000_7335E3E9AC2DE240988251CF62CAE90A0A2394AECNMAILEX03lenov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all I have servel questions about QUIC congestion control and version negotiati= on packet. Here[1] is my GQUIC packets which are already uploaded into cloudshark. My = client IP address is 10.116.47.192 and the server's IP address is 10.121.22= 2.230. Question 1: In No.1 packet, client send ClientHello packet to server. No.2 = packet, client send encrypted packet to server immediately ? Client doesn't= have the server's certificate info right now, does it? The server send cer= tificate info to client in No.3 packet. What is the encrypted packet ( No.2 packet ) used for? Question 2: QUIC has flexible congestion control. Does it mean every QUIC c= onnection can own its congestion control method ? We can use 10 congestion = control method to manage 10 apps, can't we? Could someone give me some advice? Thanks Zhi Chang [1]: https://www.cloudshark.org/captures/11a8c6a1a1eb --_000_7335E3E9AC2DE240988251CF62CAE90A0A2394AECNMAILEX03lenov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all

 

I have servel qu= estions about QUIC congestion control and version negotiation packet.

 

Here[1] is my GQ= UIC packets which are already uploaded into cloudshark. My client IP addres= s is 10.116.47.192 and the server's IP address is 10.121.222.230.

 

Question 1: In N= o.1 packet, client send ClientHello packet to server. No.2 packet, client s= end encrypted packet to server immediately ? Client doesn't have the server= 's certificate info right now, does it? The server send certificate info to client in No.= 3 packet.

What is the encr= ypted packet ( No.2 packet ) used for?

 

Question 2: QUIC= has flexible congestion control. Does it mean every QUIC connection can ow= n its congestion control method ? We can use 10 congestion control method t= o manage 10 apps, can't we?

 

Could someone gi= ve me some advice?

 

 

Thanks

Zhi Chang

 

[1]: https://www= .cloudshark.org/captures/11a8c6a1a1eb

--_000_7335E3E9AC2DE240988251CF62CAE90A0A2394AECNMAILEX03lenov_-- From nobody Thu Aug 30 05:33:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F4078130E6F for ; Thu, 30 Aug 2018 05:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 HBcqXX5w8A7T for ; Thu, 30 Aug 2018 05:33:53 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002: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 BDB87130E6D for ; Thu, 30 Aug 2018 05:33:52 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id l16-v6so3302000ybk.11 for ; Thu, 30 Aug 2018 05:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4o135KqqA91qocO7X5ZZGBEy3TmQKintjWYxtyFJNWQ=; b=pAF51vbCeuvgVKq8OeyqW9sLrzClrkUzduHI1w4M68O9EQQFaMUvNsHwrW4B6AlI8m GmWxZZjdoosOUJyd/zXU+wWWKdE7oTyMbNEnYJWjJZ/xrhQ6nAMVxiJLZ/BIMJmYiAmM hNW6WlrbecbfbdtDaxOorBLRzeUFBIp8/4XlFLZ2yK8W4KuiCMMywg/dcGq1Lxftidyp sp58te/3T87A9KjNWWne/34azghYcI0OoeI7ClSOxFhjVfPvPV0LMzzBvRSowDI9kLCw zALIag5n9prJh8Se9M610+1iA6Z1zugKAZr6db1FKI+BFTpaLYYORY/bqZaZ/TFHdMHz LUhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4o135KqqA91qocO7X5ZZGBEy3TmQKintjWYxtyFJNWQ=; b=bkyDvNCQTzPG3FfmXLqD44eGaU1kkACLninkGhSYLllUo2zJTdOPJYZe8Ni0JvywOV L/cPnffslwh2A6j14Fp/V1MnkL0tINhs1pNWAuO0kAudQGQnYYIqsHf0nXROLJCCzbNt oxjtlBZVrTeLpjv/agCOrAGLPosMEiMoav+6fUJDtAhxvavEnLmf7/96KL+78kHsLeiN CMW4is7bYYSPhPpzazN8uY5qh9dQUTNuVy/ijOcHIfga1unZRlnVxNh0Nng59OPUQMY2 h3eCyMtbz7ge1ThK7p/jhqp6B4SYvP0YTEM8r36d9gvKRyUoD4Aslxl68jvItxv7lgev W4sQ== X-Gm-Message-State: APzg51CFSOQVAtIpKZm6a5GAhVJ78QJB4iUonX/3ANqq8dyHRUANtzjr BhnTVxoIdyhJf+ARTZqJ23KapkCf8lAT9i8uoPYDvpSOuRo= X-Google-Smtp-Source: ANB0VdYCAdtth/aKQ6QWtnnV3R2l+S4hGwG6WjdGkiYoHtaRm6wuY8dObbwxWS2XJTGKJG3zlXZx/9BcED92n79vwHE= X-Received: by 2002:a25:4a43:: with SMTP id x64-v6mr5733098yba.6.1535632431453; Thu, 30 Aug 2018 05:33:51 -0700 (PDT) MIME-Version: 1.0 References: <7335E3E9AC2DE240988251CF62CAE90A0A2394AE@CNMAILEX03.lenovo.com> In-Reply-To: <7335E3E9AC2DE240988251CF62CAE90A0A2394AE@CNMAILEX03.lenovo.com> From: Ian Swett Date: Thu, 30 Aug 2018 08:33:39 -0400 Message-ID: Subject: Re: Questions about congestion control and version negotiation packet To: changzhi2@lenovo.com Cc: quic@ietfa.amsl.com Content-Type: multipart/alternative; boundary="00000000000095e5c50574a6493c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 12:33:55 -0000 --00000000000095e5c50574a6493c Content-Type: text/plain; charset="UTF-8" I can't access the cloudshark link without an account, but I suspect packet number 2 is a 0RTT request if it's encrypted and the client hasn't received anything from the server. On Thu, Aug 30, 2018 at 1:49 AM Zhi Zhi2 Chang wrote: > Hi, all > > > > I have servel questions about QUIC congestion control and version > negotiation packet. > > > > Here[1] is my GQUIC packets which are already uploaded into cloudshark. My > client IP address is 10.116.47.192 and the server's IP address is > 10.121.222.230. > > > > Question 1: In No.1 packet, client send ClientHello packet to server. No.2 > packet, client send encrypted packet to server immediately ? Client doesn't > have the server's certificate info right now, does it? The server send > certificate info to client in No.3 packet. > > What is the encrypted packet ( No.2 packet ) used for? > > > > Question 2: QUIC has flexible congestion control. Does it mean every QUIC > connection can own its congestion control method ? We can use 10 congestion > control method to manage 10 apps, can't we? > You could, but you could also do that for TCP in the Linux kernel by using setsockopts. However, that could become a very complex deployment to manage and debug. > > > Could someone give me some advice? > > > > > > Thanks > > Zhi Chang > > > > [1]: https://www..cloudshark.org/captures/11a8c6a1a1eb > --00000000000095e5c50574a6493c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can't access the cloudshark link without an account,= but I suspect packet number 2 is a 0RTT request if it's encrypted and = the client hasn't received anything from the server.
On Thu, Aug 30, 2018 at 1:49 AM Zhi Zhi2 Chang= <changzhi2@lenovo.com> w= rote:

Hi, all

=C2=A0=

I have servel questi= ons about QUIC congestion control and version negotiation packet.

=C2=A0=

Here[1] is my GQUIC = packets which are already uploaded into cloudshark. My client IP address is= 10.116.47.192 and the server's IP address is 10.121.222.230.

=C2=A0=

Question 1: In No.1 = packet, client send ClientHello packet to server. No.2 packet, client send = encrypted packet to server immediately ? Client doesn't have the server= 's certificate info right now, does it? The server send certificate info to client in No.= 3 packet.

What is the encrypte= d packet ( No.2 packet ) used for?

=C2=A0=

Question 2: QUIC has= flexible congestion control. Does it mean every QUIC connection can own it= s congestion control method ? We can use 10 congestion control method to ma= nage 10 apps, can't we?


You could, but you could also do that for TCP in the Linux kernel by using= setsockopts.=C2=A0 However, that could become a very complex deployment to= manage and debug.=C2=A0

=C2=A0=

Could someone give m= e some advice?

=C2=A0=

=C2=A0=

Thanks=

Zhi Chang<= /u>

=C2=A0=

[1]: https://www..cloudshark.org/captures/11a8c6a= 1a1eb

--00000000000095e5c50574a6493c-- From nobody Thu Aug 30 19:14:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723B9130E00 for ; Thu, 30 Aug 2018 19:14: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMS7RvUbMQYq for ; Thu, 30 Aug 2018 19:14:18 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.2]) (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 5BF71130E0D for ; Thu, 30 Aug 2018 19:14:16 -0700 (PDT) Received: from [67.219.250.102] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.us-west-2.aws.symcld.net id 6C/19-22231-274A88B5; Fri, 31 Aug 2018 02:14:10 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJKsWRWlGSWpSXmKPExsWSLvdKT7dwSUe 0wYw+a4uHP78yWrSueM/owORxYtkVVo9Hz94wBzBFsWbmJeVXJLBm9P27yV7Q1cNY0fT4BHMD 45Quxi5GLg4hgeeMEruP7WOGcBYyStx+sJW1i5GTg01AW2LfzH+MILaIgInEkt9tTCA2s4C+x OYTO8HiwgLxEndPnWCCqEmQmPX4FSuEbSUx6fMVMJtFQFXi/fOHzCA2r4CPxJ+126CWTWKU2D LjGztIglMgUGLV/AUsIDajgKzEtEf3oZaJS8ydNgtskISAgMSSPeeZIWxRiZeP/wHFOYBseYk tswQhyvMkdrbdYoHYJShxcuYTlgmMwrOQTJqFpGwWkrJZQJOYBTQl1u/ShyhRlJjS/ZAdwtaQ aJ0zlx1ZfAEj+ypG86SizPSMktzEzBxdQwMDXUNDI11DY0NdI0O9xCrdRL3SYt3y1OISXSO9x PJiveLK3OScFL281JJNjMDoSyloFt3B+LEr/RCjJAeTkijva4eOaCG+pPyUyozE4oz4otKc1O JDjDIcHEoSvB2LgXKCRanpqRVpmTnANACTluDgURLhXQOS5i0uSMwtzkyHSJ1idOU41dwziZn jyL0pQPICmPzzfiqQvNM9bRKzEEtefl6qlDjvXJBmAZDmjNI8uNGwFHaJUVZKmJeRgYFBiKcg tSg3swRV/hWjOAejkjBvD8gUnsy8ErgLXgEdxwR0XNe9FpDjShIRUlINjAcec8fOOXJwpfvl9 vO7k0t2O33rSVY9MnGqe/oFG753TR3z+VeJPl8ydV/ZkVU/n0dcP2f7W3z34dXi1qppUy7frO xJPtN5U7qo5P7vN3nHZXvXf4nKmNp92LNyfiPX6ayyxz9strm5HrVaZ/AiUNRedELcD61K6SP RikUiF1TK6jskTJ9mPlJiKc5INNRiLipOBABLHMXSXAMAAA== X-Env-Sender: changzhi2@lenovo.com X-Msg-Ref: server-20.tower-326.messagelabs.com!1535681645!2982541!1 X-Originating-IP: [103.30.234.46] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15290 invoked from network); 31 Aug 2018 02:14:09 -0000 Received: from unknown (HELO mapsmtp01.lenovo.com) (103.30.234.46) by server-20.tower-326.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 31 Aug 2018 02:14:09 -0000 Received: from CNMAILEX04.lenovo.com (unknown [10.96.80.4]) by mapsmtp01.lenovo.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 75a6_8748_28e1b4c8_77b7_4be0_97f0_4f962ec4f1a9; Fri, 31 Aug 2018 10:14:04 +0800 Received: from CNMAILEX03.lenovo.com ([169.254.11.183]) by CNMAILEX04.lenovo.com ([169.254.12.35]) with mapi id 14.03.0389.001; Fri, 31 Aug 2018 10:10:22 +0800 From: Zhi Zhi2 Chang To: Ian Swett CC: "quic@ietfa.amsl.com" Subject: RE: [External] Re: Questions about congestion control and version negotiation packet Thread-Topic: [External] Re: Questions about congestion control and version negotiation packet Thread-Index: AdRAEKgJWNLhgoLrRE+dKISqABIItwACfd6AACzS+CA= Date: Fri, 31 Aug 2018 02:10:21 +0000 Message-ID: <7335E3E9AC2DE240988251CF62CAE90A0A2399AB@CNMAILEX03.lenovo.com> References: <7335E3E9AC2DE240988251CF62CAE90A0A2394AE@CNMAILEX03.lenovo.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.19.89] Content-Type: multipart/alternative; boundary="_000_7335E3E9AC2DE240988251CF62CAE90A0A2399ABCNMAILEX03lenov_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-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, 31 Aug 2018 02:14:20 -0000 --_000_7335E3E9AC2DE240988251CF62CAE90A0A2399ABCNMAILEX03lenov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIElhbi4NCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5Lg0KDQpZZXMsIHBhY2tldCBudW1iZXIg MiBpcyBhIGVuY3J5cHRlZCBwYWNrZXQuIEluIHlvdXIgb3BpbmlvbiwgdGhpcyBwYWNrZXQgaXMg YSAwUlRUIHJlcXVlc3QgZnJvbSBjbGllbnQgdG8gc2VydmVyLiBCdXQgdGhlIHF1ZXN0aW9uIGlz IHRoZSBjbGllbnQgZG9lc24ndCBrbm93IHRoZSBzZXJ2ZXIncyBjZXJ0aWZpY2F0ZS4gV2hpY2gg Y2VydGlmaWNhdGUgZG9lcyBjbGllbnQgdXNlZCBmb3IgZW5jcnlwdGluZyBwYWNrZXRzPw0KDQpG b3IgdGhlIHF1ZXN0aW9uIDIsIHNvcnJ5LCBJIGRvbid0IGtub3cgd2hhdCB5b3UgbWVhbi4gV2h5 IGRvIEkgdXNlIHNldHNvY2tvcHRzIGZvciB0aGUgVENQIGluIExpbnV4IGtlcm5lbD8gSSB3YW50 IHRvIFFVSUMgd2hpY2ggaXMgYmFzZWQgVURQLiBJcyB0aGVyZSBhbnkgcmVsYXRpb25zaGlwIGJl dHdlZW4gVENQIGluIHRoZSBMaW51eCBrZXJuZWwgYW5kIFFVSUM/DQoNCkhvcGUgZm9yIHlvdXIg cmVwbHkuDQoNCg0KVGhhbmtzDQpaaGkgQ2hhbmcNCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSWFuIFN3ZXR0DQpTZW50OiBUaHVyc2Rh eSwgQXVndXN0IDMwLCAyMDE4IDg6MzQgUE0NClRvOiBaaGkgWmhpMiBDaGFuZw0KQ2M6IHF1aWNA aWV0ZmEuYW1zbC5jb20NClN1YmplY3Q6IFtFeHRlcm5hbF0gUmU6IFF1ZXN0aW9ucyBhYm91dCBj b25nZXN0aW9uIGNvbnRyb2wgYW5kIHZlcnNpb24gbmVnb3RpYXRpb24gcGFja2V0DQoNCkkgY2Fu J3QgYWNjZXNzIHRoZSBjbG91ZHNoYXJrIGxpbmsgd2l0aG91dCBhbiBhY2NvdW50LCBidXQgSSBz dXNwZWN0IHBhY2tldCBudW1iZXIgMiBpcyBhIDBSVFQgcmVxdWVzdCBpZiBpdCdzIGVuY3J5cHRl ZCBhbmQgdGhlIGNsaWVudCBoYXNuJ3QgcmVjZWl2ZWQgYW55dGhpbmcgZnJvbSB0aGUgc2VydmVy Lg0KT24gVGh1LCBBdWcgMzAsIDIwMTggYXQgMTo0OSBBTSBaaGkgWmhpMiBDaGFuZyA8Y2hhbmd6 aGkyQGxlbm92by5jb208bWFpbHRvOmNoYW5nemhpMkBsZW5vdm8uY29tPj4gd3JvdGU6DQpIaSwg YWxsDQoNCkkgaGF2ZSBzZXJ2ZWwgcXVlc3Rpb25zIGFib3V0IFFVSUMgY29uZ2VzdGlvbiBjb250 cm9sIGFuZCB2ZXJzaW9uIG5lZ290aWF0aW9uIHBhY2tldC4NCg0KSGVyZVsxXSBpcyBteSBHUVVJ QyBwYWNrZXRzIHdoaWNoIGFyZSBhbHJlYWR5IHVwbG9hZGVkIGludG8gY2xvdWRzaGFyay4gTXkg Y2xpZW50IElQIGFkZHJlc3MgaXMgMTAuMTE2LjQ3LjE5MiBhbmQgdGhlIHNlcnZlcidzIElQIGFk ZHJlc3MgaXMgMTAuMTIxLjIyMi4yMzAuDQoNClF1ZXN0aW9uIDE6IEluIE5vLjEgcGFja2V0LCBj bGllbnQgc2VuZCBDbGllbnRIZWxsbyBwYWNrZXQgdG8gc2VydmVyLiBOby4yIHBhY2tldCwgY2xp ZW50IHNlbmQgZW5jcnlwdGVkIHBhY2tldCB0byBzZXJ2ZXIgaW1tZWRpYXRlbHkgPyBDbGllbnQg ZG9lc24ndCBoYXZlIHRoZSBzZXJ2ZXIncyBjZXJ0aWZpY2F0ZSBpbmZvIHJpZ2h0IG5vdywgZG9l cyBpdD8gVGhlIHNlcnZlciBzZW5kIGNlcnRpZmljYXRlIGluZm8gdG8gY2xpZW50IGluIE5vLjMg cGFja2V0Lg0KV2hhdCBpcyB0aGUgZW5jcnlwdGVkIHBhY2tldCAoIE5vLjIgcGFja2V0ICkgdXNl ZCBmb3I/DQoNClF1ZXN0aW9uIDI6IFFVSUMgaGFzIGZsZXhpYmxlIGNvbmdlc3Rpb24gY29udHJv bC4gRG9lcyBpdCBtZWFuIGV2ZXJ5IFFVSUMgY29ubmVjdGlvbiBjYW4gb3duIGl0cyBjb25nZXN0 aW9uIGNvbnRyb2wgbWV0aG9kID8gV2UgY2FuIHVzZSAxMCBjb25nZXN0aW9uIGNvbnRyb2wgbWV0 aG9kIHRvIG1hbmFnZSAxMCBhcHBzLCBjYW4ndCB3ZT8NCg0KWW91IGNvdWxkLCBidXQgeW91IGNv dWxkIGFsc28gZG8gdGhhdCBmb3IgVENQIGluIHRoZSBMaW51eCBrZXJuZWwgYnkgdXNpbmcgc2V0 c29ja29wdHMuICBIb3dldmVyLCB0aGF0IGNvdWxkIGJlY29tZSBhIHZlcnkgY29tcGxleCBkZXBs b3ltZW50IHRvIG1hbmFnZSBhbmQgZGVidWcuDQoNCkNvdWxkIHNvbWVvbmUgZ2l2ZSBtZSBzb21l IGFkdmljZT8NCg0KDQpUaGFua3MNClpoaSBDaGFuZw0KDQpbMV06IGh0dHBzOi8vd3d3Li5jbG91 ZHNoYXJrLm9yZy9jYXB0dXJlcy8xMWE4YzZhMWExZWI8aHR0cDovL2Nsb3Vkc2hhcmsub3JnL2Nh cHR1cmVzLzExYThjNmExYTFlYj4NCg== --_000_7335E3E9AC2DE240988251CF62CAE90A0A2399ABCNMAILEX03lenov_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ouetiee6vzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxA562J57q/IjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5Ouetiee6vzsNCgljb2xvcjojNDQ1NDZBO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5Ouetiee6vzt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6562J57q/O2NvbG9yOiM0NDU0NkEiPkhpLCBJYW4uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPlRo YW5rcyBmb3IgeW91ciByZXBseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6IzQ0NTQ2QSI+WWVzLCBwYWNrZXQgbnVt YmVyIDIgaXMgYSBlbmNyeXB0ZWQgcGFja2V0LiBJbiB5b3VyIG9waW5pb24sIHRoaXMgcGFja2V0 IGlzIGEgMFJUVCByZXF1ZXN0IGZyb20gY2xpZW50IHRvIHNlcnZlci4gQnV0IHRoZSBxdWVzdGlv biBpcyB0aGUgY2xpZW50IGRvZXNuJ3Qga25vdyB0aGUgc2VydmVyJ3MNCiBjZXJ0aWZpY2F0ZS4g V2hpY2ggY2VydGlmaWNhdGUgZG9lcyBjbGllbnQgdXNlZCBmb3IgZW5jcnlwdGluZyBwYWNrZXRz PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6 IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 Ouetiee6vztjb2xvcjojNDQ1NDZBIj5Gb3IgdGhlIHF1ZXN0aW9uIDIsIHNvcnJ5LCBJIGRvbid0 IGtub3cgd2hhdCB5b3UgbWVhbi4gV2h5IGRvIEkgdXNlIHNldHNvY2tvcHRzIGZvciB0aGUgVENQ IGluIExpbnV4IGtlcm5lbD8gSSB3YW50IHRvIFFVSUMgd2hpY2ggaXMgYmFzZWQgVURQLiBJcyB0 aGVyZSBhbnkgcmVsYXRpb25zaGlwDQogYmV0d2VlbiBUQ1AgaW4gdGhlIExpbnV4IGtlcm5lbCBh bmQgUVVJQz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/ O2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTrnrYnnur87Y29sb3I6IzQ0NTQ2QSI+SG9wZSBmb3IgeW91ciByZXBseS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87 Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5Ouetiee6vztjb2xvcjojNDQ1NDZBIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOiM0NDU0NkEiPlpoaSBDaGFuZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6IzQ0NTQ2 QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6 vztjb2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBR VUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5J YW4gU3dldHQ8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAzMCwgMjAxOCA4OjM0 IFBNPGJyPg0KPGI+VG86PC9iPiBaaGkgWmhpMiBDaGFuZzxicj4NCjxiPkNjOjwvYj4gcXVpY0Bp ZXRmYS5hbXNsLmNvbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRXh0ZXJuYWxdIFJlOiBRdWVzdGlv bnMgYWJvdXQgY29uZ2VzdGlvbiBjb250cm9sIGFuZCB2ZXJzaW9uIG5lZ290aWF0aW9uIHBhY2tl dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgY2FuJ3QgYWNjZXNzIHRoZSBjbG91ZHNoYXJr IGxpbmsgd2l0aG91dCBhbiBhY2NvdW50LCBidXQgSSBzdXNwZWN0IHBhY2tldCBudW1iZXIgMiBp cyBhIDBSVFQgcmVxdWVzdCBpZiBpdCdzIGVuY3J5cHRlZCBhbmQgdGhlIGNsaWVudCBoYXNuJ3Qg cmVjZWl2ZWQgYW55dGhpbmcgZnJvbSB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9u IFRodSwgQXVnIDMwLCAyMDE4IGF0IDE6NDkgQU0gWmhpIFpoaTIgQ2hhbmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpjaGFuZ3poaTJAbGVub3ZvLmNvbSI+Y2hhbmd6aGkyQGxlbm92by5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5I aSwgYWxsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBoYXZlIHNlcnZlbCBxdWVzdGlvbnMg YWJvdXQgUVVJQyBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIHZlcnNpb24gbmVnb3RpYXRpb24gcGFj a2V0Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGVyZVsxXSBpcyBteSBHUVVJQyBwYWNr ZXRzIHdoaWNoIGFyZSBhbHJlYWR5IHVwbG9hZGVkIGludG8gY2xvdWRzaGFyay4gTXkgY2xpZW50 IElQIGFkZHJlc3MgaXMgMTAuMTE2LjQ3LjE5MiBhbmQgdGhlDQogc2VydmVyJ3MgSVAgYWRkcmVz cyBpcyAxMC4xMjEuMjIyLjIzMC4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UXVlc3Rpb24g MTogSW4gTm8uMSBwYWNrZXQsIGNsaWVudCBzZW5kIENsaWVudEhlbGxvIHBhY2tldCB0byBzZXJ2 ZXIuIE5vLjIgcGFja2V0LCBjbGllbnQgc2VuZCBlbmNyeXB0ZWQgcGFja2V0IHRvIHNlcnZlcg0K IGltbWVkaWF0ZWx5ID8gQ2xpZW50IGRvZXNuJ3QgaGF2ZSB0aGUgc2VydmVyJ3MgY2VydGlmaWNh dGUgaW5mbyByaWdodCBub3csIGRvZXMgaXQ/IFRoZSBzZXJ2ZXIgc2VuZCBjZXJ0aWZpY2F0ZSBp bmZvIHRvIGNsaWVudCBpbiBOby4zIHBhY2tldC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5XaGF0IGlzIHRoZSBlbmNyeXB0ZWQgcGFja2V0ICggTm8uMiBwYWNrZXQgKSB1 c2VkIGZvcj88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5RdWVzdGlvbiAyOiBRVUlDIGhhcyBm bGV4aWJsZSBjb25nZXN0aW9uIGNvbnRyb2wuIERvZXMgaXQgbWVhbiBldmVyeSBRVUlDIGNvbm5l Y3Rpb24gY2FuIG93biBpdHMgY29uZ2VzdGlvbiBjb250cm9sIG1ldGhvZA0KID8gV2UgY2FuIHVz ZSAxMCBjb25nZXN0aW9uIGNvbnRyb2wgbWV0aG9kIHRvIG1hbmFnZSAxMCBhcHBzLCBjYW4ndCB3 ZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3UgY291bGQsIGJ1 dCB5b3UgY291bGQgYWxzbyBkbyB0aGF0IGZvciBUQ1AgaW4gdGhlIExpbnV4IGtlcm5lbCBieSB1 c2luZyBzZXRzb2Nrb3B0cy4mbmJzcDsgSG93ZXZlciwgdGhhdCBjb3VsZCBiZWNvbWUgYSB2ZXJ5 IGNvbXBsZXggZGVwbG95bWVudCB0byBtYW5hZ2UgYW5kIGRlYnVnLiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvdWxkIHNvbWVvbmUgZ2l2ZSBtZSBzb21lIGFkdmlj ZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5aaGkgQ2hhbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bMV06DQo8YSBocmVmPSJo dHRwczovL3d3dy4iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy48L2E+LjxhIGhyZWY9Imh0 dHA6Ly9jbG91ZHNoYXJrLm9yZy9jYXB0dXJlcy8xMWE4YzZhMWExZWIiIHRhcmdldD0iX2JsYW5r Ij5jbG91ZHNoYXJrLm9yZy9jYXB0dXJlcy8xMWE4YzZhMWExZWI8L2E+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7335E3E9AC2DE240988251CF62CAE90A0A2399ABCNMAILEX03lenov_-- From nobody Fri Aug 31 05:54:12 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D449130E8C for ; Fri, 31 Aug 2018 05:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 YZ7xS5lsYB-k for ; Fri, 31 Aug 2018 05:54:03 -0700 (PDT) Received: from mail-yw1-xc42.google.com (mail-yw1-xc42.google.com [IPv6:2607:f8b0:4864:20::c42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469F5130E48 for ; Fri, 31 Aug 2018 05:54:03 -0700 (PDT) Received: by mail-yw1-xc42.google.com with SMTP id x67-v6so5003015ywg.0 for ; Fri, 31 Aug 2018 05:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yl0DHL/HBsNvyzuoFyTh4F8Z+9OtPPqzbsK/Ot7eOWk=; b=K6hdCMp4QDrNaob9qfu3quH2+9kR9vQlf89vWbyqUBxyPoCZuAE4hlcIajEzLw9IM/ lLLxe4MekhHraJYdCnJvNvPfkmmlDz22euQRn8rgD9sCda2pSCx5p49mD9hlYNPl7VJN Go9g0Qe2EoLHDgSOj7i8GzMXVWB7DYrG05ayht1QvtEhT+beXfTj/V1Af3y138yrpspV FXnNiHZnI8vtOhUTG9ZN5re+kiyW/d2X4S7Q8/BI2xNU2bKx2U2/nfmZQrkDp71px7Wg XGxnsqhCJJEtt+zZd1ZsB2VDfu1lsot+6yRfgUdctsrakaEFGRFpnIH68Qw2ijRQRWyF +AzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yl0DHL/HBsNvyzuoFyTh4F8Z+9OtPPqzbsK/Ot7eOWk=; b=bWyF3yV+ZNY3U35cFR+S0iwTECzhjGDLm8YDwu7KOIxTR10Ar+gWrETZSB59B0Hqge k36Xm8h5xiw23CGPRGw+uaS+57tGzCWIzHEFgVP1sclFpWr8qoc1tvQjKWAIRc8y3yl+ dZ36S8uyrJZzoklgFMaSEJfrgqgUlIKKserZoONYG+WVRMTvcBnE1/Xj1zM59Hrc7q+b b5odq2qvPjsvbgrVVyxt3YNtZ4inM53deAnkFl1CV6VguHKkuGr0v0CRThtqSgcbKn3S gVHbwXSLxSDwC1T3pxhLsuRdLSs1bR5pYJWIJrgqcDr+6/OwW1J8I/VON6ueAhpAcxGw jSCg== X-Gm-Message-State: APzg51DOdsMw0okL3m+nPUH3kW4RidX1ip5MgSfBiBE77klBcHxHSP2U p//E+VC2Sv1MEahyebgf9HWPytFbLTX7Hl1GPU4F+Q== X-Google-Smtp-Source: ANB0VdZfUcUy5O6HtwSYgjYB2mYY22Ne25j19LlQ+vPEyytbE34oItZdHOu+qmmBY0ZBv2XA5VfDsSPOFFoeYN7w25k= X-Received: by 2002:a0d:d1c1:: with SMTP id t184-v6mr8561449ywd.241.1535720041003; Fri, 31 Aug 2018 05:54:01 -0700 (PDT) MIME-Version: 1.0 References: <7335E3E9AC2DE240988251CF62CAE90A0A2394AE@CNMAILEX03.lenovo.com> <7335E3E9AC2DE240988251CF62CAE90A0A2399AB@CNMAILEX03.lenovo.com> In-Reply-To: <7335E3E9AC2DE240988251CF62CAE90A0A2399AB@CNMAILEX03.lenovo.com> From: Ian Swett Date: Fri, 31 Aug 2018 08:53:49 -0400 Message-ID: Subject: Re: [External] Re: Questions about congestion control and version negotiation packet To: changzhi2@lenovo.com Cc: quic@ietfa.amsl.com Content-Type: multipart/alternative; boundary="0000000000008575b40574baaf54" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-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, 31 Aug 2018 12:54:10 -0000 --0000000000008575b40574baaf54 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 30, 2018 at 10:14 PM Zhi Zhi2 Chang wrote: > Hi, Ian. > > > > Thanks for your reply. > > > > Yes, packet number 2 is a encrypted packet. In your opinion, this packet > is a 0RTT request from client to server. But the question is the client > doesn't know the server's certificate. Which certificate does client used > for encrypting packets? > The key is from the server config obtained in a previous QUIC connection. > > > For the question 2, sorry, I don't know what you mean. Why do I use > setsockopts for the TCP in Linux kernel? I want to QUIC which is based UDP. > Is there any relationship between TCP in the Linux kernel and QUIC? > I was merely pointing out that both TCP and QUIC have the ability to change congestion control algorithms based on the app or whatever other criteria one wanted. > > > Hope for your reply. > > > > > > Thanks > > Zhi Chang > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Thursday, August 30, 2018 8:34 PM > *To:* Zhi Zhi2 Chang > *Cc:* quic@ietfa.amsl.com > *Subject:* [External] Re: Questions about congestion control and version > negotiation packet > > > > I can't access the cloudshark link without an account, but I suspect > packet number 2 is a 0RTT request if it's encrypted and the client hasn't > received anything from the server. > > On Thu, Aug 30, 2018 at 1:49 AM Zhi Zhi2 Chang > wrote: > > Hi, all > > > > I have servel questions about QUIC congestion control and version > negotiation packet. > > > > Here[1] is my GQUIC packets which are already uploaded into cloudshark. My > client IP address is 10.116.47.192 and the server's IP address is > 10.121.222.230. > > > > Question 1: In No.1 packet, client send ClientHello packet to server. No.2 > packet, client send encrypted packet to server immediately ? Client doesn't > have the server's certificate info right now, does it? The server send > certificate info to client in No.3 packet. > > What is the encrypted packet ( No.2 packet ) used for? > > > > Question 2: QUIC has flexible congestion control. Does it mean every QUIC > connection can own its congestion control method ? We can use 10 congestion > control method to manage 10 apps, can't we? > > > > You could, but you could also do that for TCP in the Linux kernel by using > setsockopts. However, that could become a very complex deployment to > manage and debug. > > > > Could someone give me some advice? > > > > > > Thanks > > Zhi Chang > > > > [1]: https://www..cloudshark.org/captures/11a8c6a1a1eb > > --0000000000008575b40574baaf54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Aug 30, 2018 at 10:14 PM Zhi Zhi2 Chang <changzhi2@lenovo.com> wrote:

Hi, Ian.

=C2=A0

Thanks for your reply.

=C2=A0

Yes, packet number 2 is a encrypte= d packet. In your opinion, this packet is a 0RTT request from client to ser= ver. But the question is the client doesn't know the server's certificate. Which certificate does client used for encrypting packets?


The key is from the se= rver config obtained in a previous QUIC connection.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=C2=A0

For the question 2, sorry, I don&#= 39;t know what you mean. Why do I use setsockopts for the TCP in Linux kern= el? I want to QUIC which is based UDP. Is there any relationship between TCP in the Linux kernel and QUIC?


I was merely pointing out that both TCP and QUIC hav= e the ability to change congestion control algorithms based on the app or w= hatever other criteria one wanted.=C2=A0

=C2=A0

Hope for your reply.=

=C2=A0

=C2=A0

Thanks

Zhi Chang

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Thursday, August 30, 2018 8:34 PM
To: Zhi Zhi2 Chang
Cc: quic@ie= tfa.amsl.com
Subject: [External] Re: Questions about congestion control and versi= on negotiation packet

=C2=A0

I can't access the cloudsha= rk link without an account, but I suspect packet number 2 is a 0RTT request= if it's encrypted and the client hasn't received anything from the= server.

On Thu, Aug 30, 2018 at 1:49 AM= Zhi Zhi2 Chang <changzhi2@lenovo.com> wrote:

Hi, all<= u>

=C2=A0

I have servel questions about QUIC congesti= on control and version negotiation packet.

=C2=A0

Here[1] is my GQUIC packets which are alrea= dy uploaded into cloudshark. My client IP address is 10.116.47.192 and the server's IP address is 10.121.222.230. =

=C2=A0

Question 1: In No.1 packet, client send Cli= entHello packet to server. No.2 packet, client send encrypted packet to ser= ver immediately ? Client doesn't have the server's certificate info ri= ght now, does it? The server send certificate info to client in No.3 packet= .

What is the encrypted packet ( No.2 packet = ) used for?

=C2=A0

Question 2: QUIC has flexible congestion co= ntrol. Does it mean every QUIC connection can own its congestion control me= thod ? We can use 10 congestion control method to manage 10 apps, can't we?=

=C2=A0

You could, but you could also d= o that for TCP in the Linux kernel by using setsockopts.=C2=A0 However, tha= t could become a very complex deployment to manage and debug.=C2=A0<= u>

=C2=A0

Could someone give me some advice?

=C2=A0

=C2=A0

Thanks

Zhi Chang

=C2=A0

[1]: https://www..cloudshark.org/c= aptures/11a8c6a1a1eb

--0000000000008575b40574baaf54-- From nobody Fri Aug 31 07:06:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA93C130DCC for ; Fri, 31 Aug 2018 07:06:20 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 AuWo6yEYtSTH for ; Fri, 31 Aug 2018 07:06:16 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E65127AC2 for ; Fri, 31 Aug 2018 07:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1535724373; s=strato-dkim-0002; d=zinks.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=hjjUG3mmK7Jn1jeVcp3BmdNBUZ1Xx1M4cWKNy9ZaNSo=; b=LkG4gep+IJE6ddnJGKYTE8RxUL/3hG012ff7IZh5J6snDveL13SdaRoHYFeJbDW7uX CIrD3G1V8CJeH10hVnGJQIhtCiKDzj1qWqhcNrWg+6wQO5mPsREYGVbdpgqocp5gfW8R cWZh9jG3AeBKmU0agC6stP26fmTg71lzknjKTpaU4LwV3Tx5Gajg03U0/fCJwYM+B18n eah3KzfhtiCPpMnq0q4rqJ4u4FI9CPEYRMKTMT+hE/eUPT/a71QMRmfkmXjRfdOIHtor 1AnEbU+r1D3XrGGT73pspn7yKqTMqfxMx9rR3F7RJ0v5UY9uzqN9zjW2lTyfTEL5iWWl QPOQ== X-RZG-AUTH: ":PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKt0Zib1EwEOzr8+BNkziyP+Oq0GMk6UuPO6TL2Djd61+J0Ac5LRw==" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2003:f4:73c1:2800:d9ef:9057:dc98:46e1] by smtp.strato.de (RZmta 43.21 AUTH) with ESMTPSA id f0bf12u7VE6DLaL (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 ; Fri, 31 Aug 2018 16:06:13 +0200 (CEST) Subject: Re: [External] Re: Questions about congestion control and version negotiation packet To: quic@ietf.org References: <7335E3E9AC2DE240988251CF62CAE90A0A2394AE@CNMAILEX03.lenovo.com> <7335E3E9AC2DE240988251CF62CAE90A0A2399AB@CNMAILEX03.lenovo.com> From: Roland Zink Message-ID: Date: Fri, 31 Aug 2018 16:06:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FCF0AF46B3CF3F9C5C0AFE36" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-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, 31 Aug 2018 14:06:21 -0000 This is a multi-part message in MIME format. --------------FCF0AF46B3CF3F9C5C0AFE36 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Am 31.08.2018 um 14:53 schrieb Ian Swett: > > > On Thu, Aug 30, 2018 at 10:14 PM Zhi Zhi2 Chang > wrote: > > For the question 2, sorry, I don't know what you mean. Why do I > use setsockopts for the TCP in Linux kernel? I want to QUIC which > is based UDP. Is there any relationship between TCP in the Linux > kernel and QUIC? > > > I was merely pointing out that both TCP and QUIC have the ability to > change congestion control algorithms based on the app or whatever > other criteria one wanted. The difference is that for TCP the congestion control is in the kernel and setsockopt allows you to choose amongst the available ones. In QUIC this is in userspace code and each app developer may choose to implement their own. The choosen congestion control is not necessarily fair to others. This is already true for TCP where for example BBR is shown to be unfair to CUBIC, see for example https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf. The below graph from this presentation shows Im Kreuzfeuer: Googles TCP-Flusskontrolle BBR the effect of running a CUBIC connection at the same time as a BBR one. CUBIC is the standard Linux congestion control algorithm and kernels since version 4.9 also offer BBR. For TCP there are a limited number of congestion control algorithms implemented in the kernel and in the network some checks may be applied. In the QUIC world every app developer can deploy their own congestion control algorithm on the server and client side and the network has no clue about what is happening. Regards, Roland > Hope for your reply. > > Thanks > > Zhi Chang > > *From:*QUIC [mailto:quic-bounces@ietf.org > ] *On Behalf Of *Ian Swett > *Sent:* Thursday, August 30, 2018 8:34 PM > *To:* Zhi Zhi2 Chang > *Cc:* quic@ietfa.amsl.com > *Subject:* [External] Re: Questions about congestion control and > version negotiation packet > > I can't access the cloudshark link without an account, but I > suspect packet number 2 is a 0RTT request if it's encrypted and > the client hasn't received anything from the server. > > On Thu, Aug 30, 2018 at 1:49 AM Zhi Zhi2 Chang > > wrote: > > Hi, all > > I have servel questions about QUIC congestion control and > version negotiation packet. > > Here[1] is my GQUIC packets which are already uploaded into > cloudshark. My client IP address is 10.116.47.192 and the > server's IP address is 10.121.222.230. > > Question 1: In No.1 packet, client send ClientHello packet to > server. No.2 packet, client send encrypted packet to server > immediately ? Client doesn't have the server's certificate > info right now, does it? The server send certificate info to > client in No.3 packet.. > > What is the encrypted packet ( No.2 packet ) used for? > > Question 2: QUIC has flexible congestion control. Does it mean > every QUIC connection can own its congestion control method ? > We can use 10 congestion control method to manage 10 apps, > can't we? > > You could, but you could also do that for TCP in the Linux kernel > by using setsockopts.  However, that could become a very complex > deployment to manage and debug. > > Could someone give me some advice? > > Thanks > > Zhi Chang > > [1]: https://www..cloudshark.org/captures/11a8c6a1a1eb > > --------------FCF0AF46B3CF3F9C5C0AFE36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Am 31.08.2018 um 14:53 schrieb Ian Swett:


On Thu, Aug 30, 2018 at 10:14 PM Zhi Zhi2 Chang <changzhi2@lenovo.com> wrote:
 

For the question 2, sorry, I don't know what you mean. Why do I use setsockopts for the TCP in Linux kernel? I want to QUIC which is based UDP. Is there any relationship between TCP in the Linux kernel and QUIC?


I was merely pointing out that both TCP and QUIC have the ability to change congestion control algorithms based on the app or whatever other criteria one wanted.

The difference is that for TCP the congestion control is in the kernel and setsockopt allows you to choose amongst the available ones. In QUIC this is in userspace code and each app developer may choose to implement their own. The choosen congestion control is not necessarily fair to others. This is already true for TCP where for example BBR is shown to be unfair to CUBIC, see for example https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf. The below graph from this presentation shows


Im Kreuzfeuer: Googles TCP-Flusskontrolle BBR


the effect of running a CUBIC connection at the same time as a BBR one. CUBIC is the standard Linux congestion control algorithm and kernels since version 4.9 also offer BBR. For TCP there are a limited number of congestion control algorithms implemented in the kernel and in the network some checks may be applied. In the QUIC world every app developer can deploy their own congestion control algorithm on the server and client side and the network has no clue about what is happening.


Regards,

Roland


 

Hope for your reply.

 

 

Thanks

Zhi Chang

 

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Thursday, August 30, 2018 8:34 PM
To: Zhi Zhi2 Chang
Cc: quic@ietfa.amsl.com
Subject: [External] Re: Questions about congestion control and version negotiation packet

 

I can't access the cloudshark link without an account, but I suspect packet number 2 is a 0RTT request if it's encrypted and the client hasn't received anything from the server.

On Thu, Aug 30, 2018 at 1:49 AM Zhi Zhi2 Chang <changzhi2@lenovo.com> wrote:

Hi, all

 

I have servel questions about QUIC congestion control and version negotiation packet.

 

Here[1] is my GQUIC packets which are already uploaded into cloudshark. My client IP address is 10.116.47.192 and the server's IP address is 10.121.222.230.

 

Question 1: In No.1 packet, client send ClientHello packet to server. No.2 packet, client send encrypted packet to server immediately ? Client doesn't have the server's certificate info right now, does it? The server send certificate info to client in No.3 packet..

What is the encrypted packet ( No.2 packet ) used for?

 

Question 2: QUIC has flexible congestion control. Does it mean every QUIC connection can own its congestion control method ? We can use 10 congestion control method to manage 10 apps, can't we?

 

You could, but you could also do that for TCP in the Linux kernel by using setsockopts.  However, that could become a very complex deployment to manage and debug. 

 

Could someone give me some advice?

 

 

Thanks

Zhi Chang

 

[1]: https://www..cloudshark.org/captures/11a8c6a1a1eb

--------------FCF0AF46B3CF3F9C5C0AFE36-- From nobody Fri Aug 31 09:11:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E09130E5A for ; Fri, 31 Aug 2018 09:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KdkQW-bb6KU for ; Fri, 31 Aug 2018 09:11:45 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE0B130E5D for ; Fri, 31 Aug 2018 09:11:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 42249q0SsGz15MNV; Fri, 31 Aug 2018 18:11:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmDkAGaCguQl; Fri, 31 Aug 2018 18:11:41 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.20] (nb-10688.ethz.ch [82.130.103.20]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 31 Aug 2018 18:11:41 +0200 (CEST) Subject: Re: Unified ACK frame encoding To: Christian Huitema , Eric Rescorla , Martin Thomson Cc: Jana Iyengar , Magnus Westerlund , Ian Swett , QUIC WG , Brian Trammell References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> <9e734d00-101d-7955-c44e-948824bd7a6f@huitema.net> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Fri, 31 Aug 2018 18:11:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9e734d00-101d-7955-c44e-948824bd7a6f@huitema.net> Content-Type: multipart/mixed; boundary="------------739EE6251B9162145F7D1B7C" Content-Language: en-US Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-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, 31 Aug 2018 16:11:47 -0000 This is a multi-part message in MIME format. --------------739EE6251B9162145F7D1B7C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Christian, I think DCTCP-like behavior is a different case and you might want to have an (private) extension with a different ACK format for that case anyway. I think the scenarios we should design for is that CE marks will show up in a similar pattern as loss with AQM (maybe slightly more because when you drop a packet, the queue actually shrinks, but I guess that can be neglected for now). Mirja On 28.08.2018 20:47, Christian Huitema wrote: > On 8/28/2018 7:27 AM, Eric Rescorla wrote: > >> >> Correction: Ian pointed out to me that because of the two varint bits, >> we actually pay an extra byte whenever the range length would fit in 6 >> bits, but not 4, which is a lot worse, because lengths in the range >> 17-64 are going to be quite common. >> >> -Ekr > > There is another cost, but it is only borne if the implementation > actually supports ECN. Suppose the node receives a string of packets > with alternating CE marking, something like > ECT(1)-ECT(1)-CE-ECT(1)-ECT(1)-CE-ECT(1)-ECT(1)-CE, etc. This is not a > theoretical case: in DC-TCP, equilibrium is reached when the queue size > at the bottleneck hovers around the low water mark, and the algorithm is > specifically designed to produced frequent feedback. Now, if you have > that, you end up encoding a series of short ranges in the ACK, which > makes it way longer than just saying "I received everything but 3 > packets were marked as CE". > > This inflates not just the size of the ACKs, but also the number of > ranges in the "SACK dashboard" that nodes have to keep to manage the > sending of ACKs. When packets are received out of order, ranges can > normally be coalesced, but with ECN they can only be coalesced if all > packets had the same ECN marking. > > So there is indeed a cost. I also have some sympathy for EKR's argument > about future extensions. ECN is just one of the signals that peers may > want to use to manage congestion and recovery. If nodes want to make > thoughtful decisions, they will certainly also look at RTT or one way > delays, and maybe at out-of-order deliveries. Would we want to use bits > in the "gap-range-length" to indicate that for packet number 73 the one > way delay was longer than usual, or would we use some other extension > mechanism? And if we have another extension mechanism, why not use it > for ECN as well? > > -- Christian Huitema > --------------739EE6251B9162145F7D1B7C Content-Type: text/x-vcard; name="mirja_kuehlewind.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mirja_kuehlewind.vcf" bnVsbA== --------------739EE6251B9162145F7D1B7C-- From nobody Fri Aug 31 09:18:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74551130E58 for ; Fri, 31 Aug 2018 09:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsZnqeZ9ZDXw for ; Fri, 31 Aug 2018 09:18:12 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D98130E20 for ; Fri, 31 Aug 2018 09:18:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 4224KG1ghdz15MMZ; Fri, 31 Aug 2018 18:18:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsES_tmH48z7; Fri, 31 Aug 2018 18:18:08 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.20] (nb-10688.ethz.ch [82.130.103.20]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 31 Aug 2018 18:18:08 +0200 (CEST) Subject: Re: Unified ACK frame encoding To: Kazuho Oku , Magnus Westerlund Cc: Eric Rescorla , Jana Iyengar , Ian Swett , Brian Trammell , IETF QUIC WG , Martin Thomson References: <116ABD4F-4707-4F15-B7D1-C4B4727534C6@trammell.ch> <50771662-342e-2236-5d80-dff32f979e40@ericsson.com> <0c1c0cd5-fac3-d272-4fce-f6d3c75945e0@ericsson.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <13152c93-3755-34da-2a08-7b3573c774e8@tik.ee.ethz.ch> Date: Fri, 31 Aug 2018 18:18:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------11AC9C468459CAC0B9D99B31" Content-Language: en-US Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-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, 31 Aug 2018 16:18:14 -0000 This is a multi-part message in MIME format. --------------11AC9C468459CAC0B9D99B31 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi! On 28.08.2018 15:58, Kazuho Oku wrote: >> I think usage of a single ECT code point are going to work fine. The >> reason has to do with how the ECT(0) and ECT(1) codepoints are defined >> for the experimental usage. In legacy the two ECT codepoint are the >> same, but by default a QUIC stack will mark only with ECT(0). Thus, >> reception of ECT(1) means a non-compliant path that does remarking that >> should not occur. ECT(1) will be used for alternative behaviours, >> including different ECN marking schemes such as in L4S. For a QUIC >> endpoint to use ECT(1) as marking when sending it needs to have >> awareness of the experiment and implement the correct response >> functions. It also needs to agree with the receiver about this >> capability. Although possible it could be limited to that the receiver >> only needs to know that ECT marking will be ECT(1) and that should be >> reported. However it might imply additional receiver behaviour changes. >> Thus, I fully expect that any such experiment in QUIC will require >> either a version or a Transport Parameter. > To clarify, my point is that if we could have an ACK frame that can > transmit all 5 modes (4 ECN types + gaps) precisely, the sender of the > packets and the middleboxes can use the ECN flags in the way they > want, without requiring an update on the receiver. Yes, I think it is important to have a feedback scheme that would make it possible to experiment with the use of ECT(1) without changing the receiver. So if we don't find a way to send separate feedback for ECT(1), I would rather encode ECT(0) and ECT(1) with the same type (instead of ECT(1) and Not-ECT). No matter what, if you don't send ECT(1) feedback separately, you will not be able to detect path mangling which either changes ECT(0) to ECT(1) or the other way around. Note that while ECT(0) and ECT(1) should not (anymore) be mixed up in the same connection, it can still be a valid case to send some of your packets as Not-ECT (also probably not recommended for QUIC but e.g. TCP does mark control packets and retransmission as Not-ECT). Mirja --------------11AC9C468459CAC0B9D99B31 Content-Type: text/x-vcard; name="mirja_kuehlewind.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mirja_kuehlewind.vcf" bnVsbA== --------------11AC9C468459CAC0B9D99B31--