Subject: [quicwg/base-drafts] Describe PMTU probing that includes source connection ID for routing … (#2402)

From: Igor Lubashev <[email-masked]>
Date: Sat, 02 Feb 2019 09:09:04 -0800

Describe PMTU probing that includes source connection ID for routing ICMP back the correct endpoints.

This should close #1243.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2402

-- Commit Summary --

  * Describe PMTU probing that includes source connection ID for routing ICMP back the correct endpoints.

-- File Changes --

    M draft-ietf-quic-transport.md (16)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2402.patch
https://github.com/quicwg/base-drafts/pull/2402.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402

---

From: MikkelFJ <[email-masked]>
Date: Sat, 02 Feb 2019 11:54:00 -0800

Sorry, but this sounds like a huge hack - coalescing with unused handshake packets. It also sounds like it is at risk of being ignored.

I'd rather see a specific permission for a probe packet with a longer header as the only long header permissible throughout the connection, and possibly require it to not be coalesced with anything.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-459994241

---

From: Igor Lubashev <[email-masked]>
Date: Sat, 02 Feb 2019 13:23:33 -0800

I tend to agree. Yet, the described method is what was determined at Kista to be the best way. I am happy to rewrite using a special long header packet type, if the wg decides to pivot toward that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460000272

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 03 Feb 2019 18:38:57 -0800

kazuho commented on this pull request.

Looks mostly fine to me.

Besides some minor comments (see below), I think it might be a good idea to add a reference to this section from "12.2. Coalescing Packets".

> @@ -3274,6 +3274,22 @@ The considerations for processing ICMP messages in the previous section also
 apply if these messages are used by DPLPMTUD.

+### PMTU Probes Containing Source Connection ID
+
+Endpoints that rely on the destination connection ID for routing QUIC packets
+are likely to require that connection ID included in PMTU probe packets in order
+to route resulting ICMP messages ({{icmp-pmtud}}) back to the correct endpoints.
+
+Only long header packets ({{long-header}}) contain source connection IDs, but
+long header packets will not be acknowledged once the connection has been
+established.  One way to construct a PMTU probe is to coalesce (see
+{{packet-coalesce}}) a Handshake packet ({{packet-handshake}}) with a short

It might make sense to:
* Call the datagram "a probe", rather than referring to the short header packet as "a probe".
* it might be better to suggest use of _any_ coalescible long header packet rather than specifically suggesting the use of a Handshake packet.

Therefore something like: _One way to construct a PMTU probe is to coalesce a Long header packet with a Length field and a short header packet into a single UDP datagram, If the datagram reaches the endpoint, the short header packet will be acknowledged. If the datagram elicits an ICMP message, that message will likely contain the source connection ID within the quoted portion of the datagram._

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#pullrequestreview-199424601

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 03 Feb 2019 18:42:03 -0800

@mikkelfj 
> Sorry, but this sounds like a huge hack - coalescing with unused handshake packets. It also sounds like it is at risk of being ignored.

My understanding is that the approach is perfectly fine; see what a receiver is supposed to do in section 12.2. OTOH I agree that servers might be interesting in greasing this feature (by coalescing every 1-RTT packet that the server sends with an invalid long header packet, for small portion of the connections it handles).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460115947

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 04 Feb 2019 13:33:25 -0800

igorlord commented on this pull request.

> it might be better to suggest use of any coalescible long header packet rather than specifically suggesting the use of a Handshake packet.

Here are the long header packet types:

1. Initial.
I hesitate to use _initial_, because it is plaintext (no decryption failures) and has an ability to actually create new connections due to unfortunate delays / mis-routing.  Load balancer infrastructure may treat them differently from other packets.

2. 0-rtt.
These are supposed to be client-to-server only.  Having servers send them may be a bit unexpected.

3.  Handshake.
That's what I picked.

4.  Retry.
This does not have length, so it is not eligible.

That leaves only Handshake as the best candidate.  And one type is enough.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#discussion_r253654693

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 04 Feb 2019 14:24:16 -0800

@igorlord pushed 1 commit.

d6fd46ab0004b2df17e72b9d542e1d6215f4c54f  Incorporate Kazuho's review.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402/files/d93a30d36c0e5402951074f3f3cb53d1db9d6b16..d6fd46ab0004b2df17e72b9d542e1d6215f4c54f

---

From: MikkelFJ <[email-masked]>
Date: Mon, 04 Feb 2019 22:58:53 -0800

@kazuho 

> Long headers are used for packets that are sent prior to the completion of version negotiation and establishment of 1-RTT keys. Once both conditions are met, a sender switches to sending packets using the short header (Section 17.3). 

Coalescing something with handshake packets is no different than not coalescing. You are sending long header packets post 1-RTT. Disregarding the actual text, I still find it inelegant and error prone.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460533439

---

From: MikkelFJ <[email-masked]>
Date: Mon, 04 Feb 2019 23:05:25 -0800

Another point, which is important at least to me:

The entire idea about not having long headers post 1-RTT, and to make a note of it, is to allow implementations to focus on short packets only for the reminder of the connection, and dropping all context about separate number spaces etc.. If that stops being the case, all the bootrapping mess comes back to haunt you.

I'd switch to different packet processor post handshake so there is no ACK special handling etc.

If you have a dedicated allowance for a probe packet, that is much easier to deal with because you know the context is the same is for the short headers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460534550

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Feb 2019 23:26:10 -0800

@mikkelfj 
> I'd switch to different packet processor post handshake so there is no ACK special handling etc.

The design does not require the receiver to actually handle the long header packet. Simply dropping it is fine, as long as the receiver processes the short header packet that is being coalesced with the long header packet.

I understand the fact that you want to have an optimized path for short header packets. That's fine.

OTOH, the receiver needs to handle a coalesced datagram that carries various types of long header packets and a 1-RTT packet, at least during the handshake. This is true even if you do not have a corresponding key (e.g. you need to "drop" a 0-RTT packet in a coalesced datagram even when you do not not have the 0-RTT key). 

Considering that, I am not sure if it a good idea to disable the logic to split coalesced datagram into multiple packets when dropping the Handshake key. Isn't it an additional complexity to disable the logic upon the completion of the handshake?

FWIW, the specification currently states: _Every QUIC packet that is coalesced into a single UDP datagram is separate and complete. Though the values of some fields in the packet header might be redundant, no fields are omitted. The receiver of coalesced QUIC packets MUST individually process each QUIC packet and separately acknowledge them, as if they were received as the payload of different UDP datagrams. For example, if decryption fails (because the keys are not available or any other reason), the the receiver MAY either discard or buffer the packet for later processing and MUST attempt to process the remaining packets._ ((section 12.2)[https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.12.2}]).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460538290

---

From: MikkelFJ <[email-masked]>
Date: Mon, 04 Feb 2019 23:50:18 -0800

> Considering that, I am not sure if it a good idea to disable the logic to split coalesced datagram into multiple packets when dropping the Handshake key. Isn't it an additional complexity to disabl…

To an extend yes, but if you do care about performance, it can be a simplification: You need the core functionality regardless, so it is mostly function calls to logic that must exist either way. And, it allows you to be more lazy performance wise when dealing with the complexities of the handshake where crypto overhead and low packet count does not make optimisations worthwhile. This means you can shift that focus to short packets.

This gets into biblical citations, but ...

>Every QUIC packet that is coalesced into a single UDP datagram is separate and complete.

but it also says that you cannot have multiple connections, and you cannot have long headers post 1-RTT. 

Technically you can coalesce a packet "sent" before the packet being coalesced, but if you have seen a short header, you can reasonably assume that any long headers are of no interest and therefore drop processing of that datagram ASAP.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460543273

---

From: MikkelFJ <[email-masked]>
Date: Mon, 04 Feb 2019 23:57:58 -0800

Some background that might illustrate why this is feasible: You can attach a state machine to connection. Each state has function that is called on new input. Once the state enters short packet state, it can be different function from handshake related. So you just look up the CID, and call a function. The same goes for draining etc.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460544891

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 05 Feb 2019 05:53:18 -0800

The coalescing logic requires you to skip long header packets after the handshake and process the coalesced packets in the UDP datagram. I.e. you need to wrap this is a loop. In Tokyo we decided that you can limit the number of times you will go through this loop per UDP datagram, if you want. (I think we said that the limit can be as low as 4, I think.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460645057

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 05 Feb 2019 05:58:17 -0800

> but it also says that you cannot have multiple connections, and you cannot have long headers post 1-RTT.

That's correct. You cannot coalesce QUIC packets belonging to multiple connections into the same UDP datagram. This is not changed.

It is also correct that a long-header packet past the completion of the handshake is not valid. So you need to do with that long-header QUIC packet what you would do with invalid packets -- drop it. (That's why the text says that such packets will not elicit an acknowledgement.) But then you should keep processing coalesced QUIC packets arriving in the same datagram, per text of the spec.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460646711

---

From: MikkelFJ <[email-masked]>
Date: Tue, 05 Feb 2019 06:02:29 -0800

I do not disagree, I'm just saying that, except for this probing edge case, you really have no motivation to keep processing such packets at that point in time. Anybody wanting piggyback other payload on meaningful short header content is probably playing some games. But you can't because of this special case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460648136

---

From: MikkelFJ <[email-masked]>
Date: Tue, 05 Feb 2019 14:05:33 +0000 (UTC)

But, if you actually drop the longer header and proceed to the short header probe, you loose your source ID, so for it to work, you need to go against the current spec and process long headers post 1-RTT.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460649137

---

From: MikkelFJ <[email-masked]>
Date: Tue, 05 Feb 2019 06:18:59 -0800

Umm, if you don't have the handshake keys anymore, how do verify the long packet. And if you don't, how can you trust that someone didn't throw in some other source id (not sure that would be an efficient attack, but still).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460653789

---

From: MikkelFJ <[email-masked]>
Date: Tue, 05 Feb 2019 06:34:44 -0800

Better, you cannot send Handshake packets at all when you no longer have the keys, and if you could, they would be open to MiTM because they keys aren't really that secure since the handshake as already been accepted and therefore cannot fail.

So that leaves sending handshake packets with 1-RTT keys, and I couldn't really find where this is prohibited, but I believe the idea is that each packet type identifies an encryption level.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460659340

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 05 Feb 2019 08:20:30 -0800

The long header packet is a Handshake packet because the first octet identifies it as such. It will not decrypt and is not meant to be decrypted (only short header packets are valid at this point in the connection). I guess a little more text is needed to make this point clear.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460701385

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Feb 2019 17:14:12 -0800

@igorlord I am fine with using a Handshake packet considering that this is an example (i.e., "One  way of...").

Though personally, I might be interested in sending an 0-RTT packet with zero-length payload (i.e. the Length field set to zero) even just to grease the client implementations.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#discussion_r254109241

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Feb 2019 17:16:27 -0800

@mikkelfj Regarding optimization, an endpoint would rarely send PMTU probes. Therefore, processing of the probe going into a slow path is not an issue. Almost all the packet that the receiver receives would be short header packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460868031

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Feb 2019 01:37:07 -0800

@kazuho the problem is not slow pathing rare packets, but fast pathing approved connections - so they never parse anything but short headers or fail.

However, if a probe uses a new CID this is indeed not a concern because the CID would not hit the fast path in the first place.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-460958095

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 06 Feb 2019 04:50:50 -0800

The probe is a part of the connection. Otherwise it will not elicit an ACK of the coalesced short packet.

I am a bit confused that we are discussing the cost of a single if statement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-461011918

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Feb 2019 13:16:39 +0000 (UTC)

> The probe is a part of the connection. Otherwise it will not elicit an ACK of the coalesced short packet.
But it will use a dedicated connection ID.

> I am a bit confused that we are discussing the cost of a single if statement.

Yes, but it still impacts the design because the first thing I would do would be to look up bytes 1-4 in a hash table and call a handler function that has no context for handshake. So it will now have to add an indirection and process packets it does not understand. It can't be the same logic as the one that handles handshakes, because it would start by verifying the packet.

Or that initial lookup would would have to first check the packet type and go slow path, but the context must be looked up by ID, and the general slow path expects context, or it will drop packets. But you can't do that here, because there is no context. So you have to special handle that.

So performance-wise it would be survivable, just pretty ugly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-461019172

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Feb 2019 05:27:54 -0800

I also don't understand exactly the purpose of the source id:
Is it
a) for the ending endpoint to make sense of ICMP, or
b) do you expect ICMP to be routed based on the QUIC headers?

If it is a), why would you not want the source ID to be authenticated?
I could see some interesting attacks sending bogus ICMP packets to manipulate the connection. For example by network operators that want to bandwidth limit QUIC packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-461022528

---

From: Lars Eggert <[email-masked]>
Date: Wed, 06 Feb 2019 05:32:56 -0800

Can we PLEASE have these discussions on the issue and not the PR?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#issuecomment-461024012

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Feb 2019 22:58:41 -0800

kazuho approved this pull request.

The PR looks good to me, but I think we might want to consider changes like below to better clarify how the design works.

> @@ -3274,6 +3275,22 @@ The considerations for processing ICMP messages in the previous section also

+### PMTU Probes Containing Source Connection ID {#pmtu-probes-src-cid}
+

How about changing "will not be acknowledged once the connection has been established" to "will not be decrypted or acknowledged by the peer once the handshake is complete"?

I think that might help readers trying to understand the design.

> @@ -3274,6 +3275,22 @@ The considerations for processing ICMP messages in the previous section also

+### PMTU Probes Containing Source Connection ID {#pmtu-probes-src-cid}
+
+Endpoints that rely on the destination connection ID for routing QUIC packets
+are likely to require that connection ID included in PMTU probe packets in order
+to route resulting ICMP messages ({{icmp-pmtud}}) back to the correct endpoints.
+
+Only long header packets ({{long-header}}) contain source connection IDs, but
+long header packets will not be acknowledged once the connection has been
+established.  One way to construct a PMTU probe is to coalesce (see
+{{packet-coalesce}}) a Handshake packet ({{packet-handshake}}) with a short
+header packet in a single UDP datagram.  If the UDP datagram reaches the
+endpoint, the short header packet will be acknowledged.  If the UDP datagram

Maybe we can add "regardless of if the Handshake packet was processed" at the end of the sentence.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#pullrequestreview-200939763

---

From: Mike Bishop <[email-masked]>
Date: Thu, 07 Feb 2019 10:44:01 -0800

MikeBishop approved this pull request.

Looks good.  To @mikkelfj's concern, that's covered by the requirement that you MUST process subsequent packets in the datagram, even if you choose to drop the first one.  An implementation that drops the entire datagram because it starts with a Handshake packet would be violating that requirement (and therefore should expect interop problems).

+elicits an ICMP message, that message may contain the source connection ID

The reality seems a little stronger than "may"; perhaps "will likely"?

> @@ -2670,9 +2670,10 @@ complete.  Though the values of some fields in the packet header might be
 redundant, no fields are omitted.  The receiver of coalesced QUIC packets MUST
 individually process each QUIC packet and separately acknowledge them, as if
 they were received as the payload of different UDP datagrams.  For example, if
-decryption fails (because the keys are not available or any other reason), the
-the receiver MAY either discard or buffer the packet for later processing and
-MUST attempt to process the remaining packets.
+decryption fails (because the keys are not available, the UDP datagram is a PMTU
+probe (see {{pmtu-probes-src-cid}}), or any other reason), the the receiver MAY

I'm not sure this needs to be called out separately.  If Handshake keys have been dropped, the keys won't be available and you've already covered this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#pullrequestreview-201256996

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 10 Feb 2019 18:20:01 -0800

138aded8776bd1647ffcf1d1d8a74cad4239d7ba  Additional clarifications for PMTU probes

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402/files/1c232702294c7ba60db0d1fa5fe36a03a8bac73d..138aded8776bd1647ffcf1d1d8a74cad4239d7ba

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 10 Feb 2019 18:20:43 -0800

Added in the latest commit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#discussion_r255370740

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 10 Feb 2019 18:21:09 -0800

Added something similar in the last commit series.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#discussion_r255370768

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 10 Feb 2019 18:21:29 -0800

Updated in the latest commit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#discussion_r255370783

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 10 Feb 2019 18:33:57 -0800

It looks technically redundant, but it works to point out this use case in the _Coalescing Packets_ section. The other alternative would be to mention PMTU probes earlier (in the in the second paragraph, for example):

```suggestion
Using the Length field, a sender can coalesce multiple QUIC packets into one UDP datagram.
This can reduce the number of UDP datagrams needed to complete the cryptographic
handshake and start sending data.  This can also be used to construct PMTU probes (see
{{pmtu-probes-src-cid}}).  Receivers MUST be able to probe (see {{pmtu-probes-src-cid}}),
or any other reason), the the receiver MAY process coalesced packets.
```

I do wonder if mentioning this too early would distract from the main purpose of coalesced packets -- reducing the number of UDP datagrams during handshake.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#discussion_r255371509

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 15 Feb 2019 09:34:24 -0800

@MikeBishop, I am trying to make sure there are no unanswered concerns left about this text.

I know you've approved the text they way it is.  So you you think it is ok as is (and we can Resolve this), or should we work on making a change similar to the one I've outlined above?  Or something else?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#discussion_r257326423

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Feb 2019 10:55:00 -0800

MikeBishop commented on this pull request.

The idea behind your suggested change reads better, yes.  The specific suggested change has other issues that I assume are caused in part by other lines having changed:

> Receivers MUST be able to probe (...), or any other reason), the the receiver MAY process coalesced packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#discussion_r257351086

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 28 Feb 2019 10:32:36 -0800

50f303e9a01e7c67a448e00e19c3f070365225b6  Incorporate Mike's feedback -- introduce PMTUD probes earlier

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402/files/138aded8776bd1647ffcf1d1d8a74cad4239d7ba..50f303e9a01e7c67a448e00e19c3f070365225b6

---

From: Igor Lubashev <[email-masked]>
Date: Thu, 28 Feb 2019 10:38:00 -0800

The new commit updates the text as requested / discussed.  Resolving this.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2402#discussion_r261328654