Subject: Re: [quicwg/base-drafts] Rewrite text about Version Negotiation (#1039)

From: martinduke <[email-masked]>
Date: Mon, 12 Feb 2018 23:08:48 +0000 (UTC)

@martinduke pushed 1 commit.

b33d04e  Rewrote completely based on Martin's feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1039/files/256ad6b7e6bcfbcd0092fc1633ccfd06f6cc0341..b33d04e972bb073baf434d1d531130ba3661bee5

---

From: Marten Seemann <[email-masked]>
Date: Tue, 13 Feb 2018 02:46:04 +0000 (UTC)

marten-seemann commented on this pull request.

> -packets in anticipation of the Initial packet arriving later. This is
-especially useful for 0-RTT packets that routinely accompany Initial packets.
-
-Buffering ensures that data is not lost, which improves performance; conversely,
-discarding these packets could create false loss signals for the congestion
-controllers.  However, limiting the number and size of buffered packets might be
-needed to prevent exposure to denial of service.
-
-Servers MUST NOT send packets in response to these buffered packets until
-the initial packet arrives.
-
-In this version of QUIC, clients cannot send short form headers prior to a
-response from the server. Servers that do not support a version of QUIC that
-allows early short headers MUST either respond with a stateless reset or drop
-the packet silently.
+First, hosts try to associate the packet with an existing connection. If the

Wouldn’t you first look at the packet type, in order to handle Initial packets statelessly?

-- 
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/1039#pullrequestreview-96011680

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Feb 2018 18:53:55 -0800

martinthomson commented on this pull request.

That's a good point.  It certainly makes sense for a server to push any stateless processing to the front.

I don't know if it makes sense to consider that as an optional amendment, or whether it isn't just easier to reorder the processing.  It depends on whether it is easier to say "a server might move any stateless processing of potential Initial packets to the start of this process", or whether it is easier to rearrange the order from the outset.

-- 
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/1039#discussion_r167749160

---

From: Mike Bishop <[email-masked]>
Date: Mon, 12 Feb 2018 20:37:12 -0800

MikeBishop commented on this pull request.

"Initial" is a version-dependent concept, so you still check the version first.  If you understand the version, then you can check whether it's an Initial packet.  However, since that's for long headers, the version will always be explicitly present, so you don't have to look up the connection ID first.

-- 
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/1039#discussion_r167759111

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Feb 2018 04:59:05 +0000 (UTC)

MikeBishop approved this pull request.

Looks good.  Technically, I have no objections.  Minor editorial stuff.

> +connection IDs if they do not meet both of these criteria.
+
+
+### Client-Specific Behaviors {#client-specific-behaviors}
+
+If a client receives a packet with an unknown connection ID, and it matches
+the tuple of a connection with no received packets, it is a reply to an
+Initial packet with a server-generated connection ID and will be processed
+accordingly. Clients SHOULD discard any packets with new connection IDs that
+do not meet these criteria.
+
+Note that a successfully associated packet may be a Version Negotiation
+packet, which is handled in accordance with {{handle-vn}}. 
+
+Due to packet reordering or loss, clients might receive packets associated
+with a connection for which it does not yet have the keys to decrypt it.

This sentence is awkward.  Maybe "packets encrypted with a key which the client has not yet computed."?

> +accordingly. Clients SHOULD discard any packets with new connection IDs that
+do not meet these criteria.
+
+Note that a successfully associated packet may be a Version Negotiation
+packet, which is handled in accordance with {{handle-vn}}. 
+
+Due to packet reordering or loss, clients might receive packets associated
+with a connection for which it does not yet have the keys to decrypt it.
+Clients MAY drop these packets, or MAY buffer them in anticipation of
+later packets that allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version

"If a server receives a packet with... is long enough...." doesn't parse.

"...a packet which has an unknown connection ID, an unsupported version, and a sufficient length....", maybe?

> +Due to packet reordering or loss, clients might receive packets associated
+with a connection for which it does not yet have the keys to decrypt it.
+Clients MAY drop these packets, or MAY buffer them in anticipation of
+later packets that allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully

Lower-case "packet" for consistency, I think.

> +with a connection for which it does not yet have the keys to decrypt it.
+Clients MAY drop these packets, or MAY buffer them in anticipation of
+later packets that allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully
+conforming with the specification, the server MUST proceed with the

I think you want a different phrasing here.  The server is never obligated to proceed with the connection or the handshake; it can abort at any time.  Perhaps we should just ignore the normative language and say that the server proceeds?

> +
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully
+conforming with the specification, the server MUST proceed with the
+handshake ({{handshake}}).  This commits the server to the version that the
+client selected.
+
+If the packet is a supported version, and a Handshake or 0RTT packet, the

"0-RTT" is used elsewhere, I think.

> +If a server receives a packet with an unknown connection ID, an unsupported
+version, and is long enough to be an Initial packet for some version
+supported by the server, it SHOULD send a Version Negotiation packet as
+described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial Packet fully
+conforming with the specification, the server MUST proceed with the
+handshake ({{handshake}}).  This commits the server to the version that the
+client selected.
+
+If the packet is a supported version, and a Handshake or 0RTT packet, the
+server MAY buffer a limited number of these packets in anticipation of
+a late-arriving Initial Packet. In the event the server later generates
+a RETRY packet, this buffer should be purged. Servers MUST NOT send packets

We haven't all-capsed packet types elsewhere.  Also, is this really a "should", or is it a "MUST"?  Finally, the "MUST NOT send packets" seems superfluous, since the server doesn't have the context *to* respond without the contents of the Initial.  "cannot" might be sufficient.

 ### Sending Version Negotiation Packets {#send-vn}
 
 If the version selected by the client is not acceptable to the server, the
 server responds with a Version Negotiation packet ({{packet-version}}).  This
 includes a list of versions that the server will accept.
 
-A server sends a Version Negotiation packet for any packet with an unacceptable
-version if that packet could create a new connection.  This allows a server to
-process packets with unsupported versions without retaining state.  Though
-either the Client Initial packet or the version negotiation packet that is sent
-in response could be lost, the client will send new packets until it
-successfully receives a response or it abandons the connection attempt.
+This system allows a server to process packets with unsupported versions without
+retaining state.  Though either the Initial packet or the version negotiation

Capitalize "Version Negotiation", since that's a packet type.  Also, since we're talking about a hypothetical unknown version of QUIC here, we don't actually know that the packet which provokes version negotiation is of type "Initial" -- it might be worth lower-casing that (and maybe just saying "the client's packet" so someone else doesn't try to get you to capitalize it another time!).

> +handshake ({{handshake}}).  This commits the server to the version that the
+client selected.
+
+If the packet is a supported version, and a Handshake or 0RTT packet, the
+server MAY buffer a limited number of these packets in anticipation of
+a late-arriving Initial Packet. In the event the server later generates
+a RETRY packet, this buffer should be purged. Servers MUST NOT send packets
+in response to these buffered packets until the Initial packet arrives.
+
+Servers MUST drop incoming packets under all other circumstances.
+
+## Version Negotiation
+
+Version negotiation ensures that client and server agree to a QUIC version
+that is mutually supported. A server sends a Version Negotiation packet in
+response to a packet that might initiate a new connection, see

The point this text was making in the old location might be clearer if you say "in response to **each** packet", i.e. if the client sends six packets in its first flight, it will get 1 < N <= 6 VN packets back.

-- 
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/1039#pullrequestreview-96024240

---

From: Mike Bishop <[email-masked]>
Date: Tue, 13 Feb 2018 05:02:54 +0000 (UTC)

On second thought, the buffer purge might be irrelevant.  If the server processes these packets according to the normal rules once it receives the Initial and replies with a Retry, it would drop them, wouldn't it?  So it should just process these packets after it's gotten the delayed Initial, and do what it otherwise would.

-- 
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/1039#discussion_r167761318

---

From: Mike Bishop <[email-masked]>
Date: Mon, 12 Feb 2018 21:04:22 -0800

> +If there is no connection ID, but the packet matches the address/port tuple
+of a connection where the host did not require connection IDs, QUIC processes
+the packet as part of that connection. Endpoints MUST drop packets that omit

Your build break is trailing whitespace here, looks like.

-- 
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/1039#pullrequestreview-96026287

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 13 Feb 2018 05:36:34 +0000 (UTC)

kazuho commented on this pull request.

> -used - and they MUST be padded to at least 1200 octets.
-
-The server receives this packet and determines whether it potentially creates a
-new connection (see {{packet-handling}}).  If the packet might generate a new
-connection, the server then checks whether it understands the version that the
-client has selected.
-
-If the packet contains a version that is acceptable to the server, the server
-proceeds with the handshake ({{handshake}}).  This commits the server to the
-version that the client selected.
+with an existing connection, or - for servers - potentially create a new
+connection.
+
+First, hosts try to associate the packet with an existing connection. If the
+packet has a connection ID corresponding to an existing connection, QUIC
+processes that packet accordingly. Note that a NEW_CONNECTION_ID frame

> If the packet has a connection ID corresponding to an existing connection, QUIC processes that packet accordingly.

May I ask if this is true?

In current form of QUIC, a server is allowed to specify any Connection ID that it likes, which may collide with a Connection ID that a client chooses for a new connection.

I believe that a client needs to identify 1 RTT packets by their 5-tuple to avoid the issue.

-- 
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/1039#pullrequestreview-96029865

---

From: martinduke <[email-masked]>
Date: Mon, 12 Feb 2018 21:44:41 -0800

martinduke commented on this pull request.

"the server doesn't have the context to respond without the contents of the Initial. "

I was trying to make sure no acks were sent, but I see now that you're right. We can't decrypt (and therefore can't ack) 0-RTT packets, and we couldn't possibly receive other Handshake packets if we havent' seen the Initial. Good catch.

-- 
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/1039#discussion_r167766079

---

From: martinduke <[email-masked]>
Date: Tue, 13 Feb 2018 06:02:54 +0000 (UTC)

5271b59  Made Mike Bishop's changes

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1039/files/b33d04e972bb073baf434d1d531130ba3661bee5..5271b5952a5b68e9fcd5417d1c78cfe9812a4450

---

From: martinduke <[email-masked]>
Date: Mon, 12 Feb 2018 22:05:45 -0800

-

My instinct is that this is one of a few cases where extremely rare Connection ID collisions cause a decryption failure and a discarded packet. If a host has two connections with the same ID there's going to be trouble, so we might as well kill one of them off right away.

-- 
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/1039#discussion_r167768395

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Feb 2018 22:11:12 -0800

-

I think that this fits nicely with @marten-seemann's comment about handling Initial packets specially.  My pseudocode didn't do this, but this motivates moving the version and Initial packet checks right up front.

+
+

Computation isn't the problem, it's receipt of the server handshake.  Maybe "packets that are protected with 1-RTT keys prior to receiving handshake messages. Packet protection cannot be removed from these packets until the cryptographic handshake produces the necessary keys."

"and length sufficient for the packet to be an Initial packet in any version supported by the server" maybe

Yes, Initial packet.

The buffer purge is probably a bad idea.  If you consider how you might implement this, the 0-RTT buffer is likely to be global across the entire server.  You can't know when you receive them which connection to associate them with, so it has to be a little bit global.  Choosing to send Retry on one connection shouldn't cause other 0-RTT packets to be purged.  Also, choosing not to accept 0-RTT is another reason you might purge them.

It might be better not to get into details here.  I would probably instead maintain a deque of 0-RTT packets and let new 0-RTT packets push older ones out.  No point ever purging other than when you are scrubbing through looking for unclaimed packets.  Initiating a purge is CPU cycles you don't need to spend.

-- 
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/1039#discussion_r167767760

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Feb 2018 22:20:01 -0800

This is much better.  I think that we can address the stateless VN/Retry thing pretty easily by prefacing the server-specific packet handling section appropriately (you already have the text in the right order).

> +Due to packet reordering or loss, clients might receive packets for a
+connection encrypted with a key it has not yet computed. Clients MAY drop
+these packets, or MAY buffer them in anticipation of later packets that
+allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+
+If a server receives a packet that has an unknown connection ID, an
+unsupported version, and a sufficient length to be an Initial packet for
+some version supported by the server, it SHOULD send a Version Negotiation
+packet as described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial packet fully

I think that you can remove the if (supported(version)) check from these paragraphs.  You already did the early return on !supported

+Initial packet with a server-generated connection ID and will be processed
+accordingly. Clients SHOULD discard any packets with new connection IDs that
+do not meet these criteria.
+
+Note that a successfully associated packet may be a Version Negotiation
+packet, which is handled in accordance with {{handle-vn}}.
+
+Due to packet reordering or loss, clients might receive packets for a
+connection encrypted with a key it has not yet computed. Clients MAY drop
+these packets, or MAY buffer them in anticipation of later packets that
+allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}
+

This is probably where you need to finesse the stateless generation of VN and Retry packets.

-

I would agree, if it weren't for the point about stateless handling.  I think that's together it's worth addressing.  I think that all you need to do is put in a "Before attempting to identify an existing connection a server might process Initial packets and generate Version Negotiation or Retry packets.  Efficient and stateless generation of these packets can be important in reducing server load."  Or some such blather.

> +some version supported by the server, it SHOULD send a Version Negotiation
+packet as described in {{send-vn}}.
+
+Servers MUST drop other packets that contain unsupported versions.
+
+If the packet is a supported version, and an Initial packet fully
+conforming with the specification, the server proceeds with the handshake
+({{handshake}}).  This commits the server to the version that the client
+selected.
+
+If the packet is a supported version and a 0-RTT packet, the server MAY
+buffer a limited number of these packets in anticipation of a late-arriving
+Initial Packet. Clients are forbidden from sending Handshake packets prior
+to receiving a server response, so servers SHOULD ignore any such packets.
+
+Servers MUST drop incoming packets under all other circumstances.

What about regular packets for a connection?   I know that this section only lists the exceptional cases, but because it doesn't mention packets that are matched to a connection, this could be read as requiring servers to discard all packets that belong to connections.

> -{{handshake}}, but any Initial packet sent from the client to the server MUST
-use the long header format - which includes the version of the protocol being

Remove the first here and forward-reference the server-specific section.

+the tuple of a connection with no received packets, it is a reply to an
+Initial packet with a server-generated connection ID and will be processed
+accordingly. Clients SHOULD discard any packets with new connection IDs that
+do not meet these criteria.
+
+Note that a successfully associated packet may be a Version Negotiation
+packet, which is handled in accordance with {{handle-vn}}.
+
+Due to packet reordering or loss, clients might receive packets for a
+connection encrypted with a key it has not yet computed. Clients MAY drop
+these packets, or MAY buffer them in anticipation of later packets that
+allow it to compute the key.
+
+
+### Server-Specific Behaviors {#server-specific-behaviors}

s/Behaviors/Packet Handling/

A shorter anchor might be nice too.

-- 
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/1039#pullrequestreview-96033938

---

From: martinduke <[email-masked]>
Date: Tue, 13 Feb 2018 10:10:54 -0800

-

As @MikeBishop pointed out, Initial packets are a version-dependent concept. So although I think we have to be careful to check the version first, I can put something together along these lines.

On the other hand, an Initial packet might be a retransmission due to loss of the first server flight. Wouldn't we want this to be associated with the existing connection context, especially since there might be 0-RTT 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/1039#discussion_r167952603

---

From: martinduke <[email-masked]>
Date: Tue, 13 Feb 2018 18:15:19 +0000 (UTC)

My thinking was that this section is (no longer) pseudocode in prose, so we might as well be completely explicit. If you think this is too cumbersome, I can delete it.

-- 
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/1039#discussion_r167953802

---

From: martinduke <[email-masked]>
Date: Tue, 13 Feb 2018 18:17:09 +0000 (UTC)

I agree; this is the same point as the "supported version" above; if reading in sequence, it reads fine, but there's no reason not be explicit. I'll revise once we reach consensus on the other items.

-- 
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/1039#discussion_r167954216

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Feb 2018 14:56:35 -0800

I think that your previous paragraphs effectively close of all options for not-supported versions, so this is probably a little redundant.

-- 
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/1039#discussion_r168029836

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Feb 2018 22:58:17 +0000 (UTC)

-

I think that it would be OK for a retransmission of an Initial to be handled statelessly.  If that results in progressing to establishing a connection, then I think that it might pay to check if you don't already have one for the same client-chosen connection ID.  That is special logic, but probably necessary (unless the server copies the client connection ID).

-- 
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/1039#discussion_r168030202

---

From: martinduke <[email-masked]>
Date: Thu, 15 Feb 2018 23:41:54 +0000 (UTC)

-

I am fine with moving version checking to the front, and will shortly publish a revision to that effect.

But I *do* think processing the initial right off opens up several cans of worms.

For instance:
- What if the content of Initial #2 differs from Initial #1 (in the same Stream 0 sequence numbers)?
- If I process the second Initial, and then find I already have this connection with 0-RTT, I've passed this stuff up to TLS for no reason. If we check conn ID first, we've already thrown out the Stream 0 contents as duplicative.

-- 
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/1039#discussion_r168642437

---

From: martinduke <[email-masked]>
Date: Thu, 15 Feb 2018 23:42:52 +0000 (UTC)

-

Perhaps this requires more discussion, but I'd really like to commit this very large change and then haggle over the order of checking conn ID/processing Initials for supported versions in a separate issue.

-- 
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/1039#discussion_r168642576

---

From: martinduke <[email-masked]>
Date: Thu, 15 Feb 2018 15:43:56 -0800

OK, removed the reference.

-- 
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/1039#discussion_r168642743

---

From: martinduke <[email-masked]>
Date: Thu, 15 Feb 2018 15:44:18 -0800

VN handled, Retry not so much.

-- 
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/1039#discussion_r168642833

---

From: martinduke <[email-masked]>
Date: Thu, 15 Feb 2018 23:47:31 +0000 (UTC)

I think I'm fixing this is in the latest revision.

-- 
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/1039#discussion_r168643354

---

From: martinduke <[email-masked]>
Date: Thu, 15 Feb 2018 15:47:43 -0800

Fixed.

-- 
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/1039#discussion_r168643390

---

From: martinduke <[email-masked]>
Date: Thu, 15 Feb 2018 15:48:31 -0800

Fixed.

-- 
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/1039#discussion_r168643504

---

From: martinduke <[email-masked]>
Date: Thu, 15 Feb 2018 15:53:00 -0800

00a8009  Addressed Martin's Comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1039/files/5271b5952a5b68e9fcd5417d1c78cfe9812a4450..00a80090ef056e340e0cb6813870e0f41edcd11b

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Feb 2018 00:39:52 +0000 (UTC)

@martinduke, I agree, we should try to land this and then iterate.

>    What if the content of Initial #2 differs from Initial #1 (in the same Stream 0 sequence numbers)? What if I process, send a RETRY, and then it turns out I'd already responded to the Initial with a Server Hello?
>    If I process the second Initial, and then find I already have this connection with 0-RTT, I've passed this stuff up to TLS for no reason. If we check conn ID first, we've already thrown out the Stream 0 contents as duplicative.

I think that I mentioned that problem before.  The client should probably ignore Retry if it has moved on.  More generally, we should probably encourage (or insist on) consistent routing of Initial. #1115

-- 
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/1039#issuecomment-366110455

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Feb 2018 00:41:23 +0000 (UTC)

@martinthomson pushed 1 commit.

80a47db  Couple of typos

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1039/files/00a80090ef056e340e0cb6813870e0f41edcd11b..80a47db5b7b6fb28e2cdbb1879c21b9bfc9f5e59

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Feb 2018 00:47:00 +0000 (UTC)

Merged #1039.

-- 
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/1039#event-1477083840