Subject: [quicwg/base-drafts] Connection ID DT output (#1742)

From: erickinnear <[email-masked]>
Date: Wed, 12 Sep 2018 13:58:35 -0700

- Add new text around Connection IDs
- Add CONNECTION_ID_FINISHED frame
- Remove sequence number for Connection IDs

Short summary: 
An endpoint can issue as many CIDs to its peer as it chooses. It must always allow incoming packets on all outstanding CIDs. The only way to get rid of one from that "pool" is for the peer to indicate that the CID may be forgotten via the CONNECTION_ID_FINISHED frame. 

On the receiving side, you remember all the CIDs you get from your peer and can generally use any that you like at any time. If you get more than you think you need, you can ignore some. 
You're only allowed to use a CID on a single path, so you should probably retire any that you've moved away from via a _FINISHED frame. 

Receiving a _FINISHED frame indicates that you should generally "replace" the retired CID. There are a few recommendations in this area, mostly to ensure that it's straightforward to keep your peer from running out of CIDs to use. 
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * New text around Connection IDs, add CONNECTION_ID_FINISHED

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1742.patch
https://github.com/quicwg/base-drafts/pull/1742.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/1742

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Sep 2018 14:49:55 -0700

MikeBishop commented on this pull request.

> +({{frame-connection-id-finished}}).
+
+Implementations SHOULD ensure that peers have sufficient connection IDs
+available to reduce the possibility of peers exhausting their supply of
+available connection IDs.  An implementation could do this by always supplying a
+new connection ID for each connection ID retired with a CONNECTION_ID_FINISHED
+frame. When a receiver of a packet notices that its peer is now using a
+previously unused connection ID, it can choose to supply its peer with a new
+connection ID using a NEW_CONNECTION_ID frame to reduce the possibility of its
+peer running out of available connection IDs.
+
+An endpoint that receives a packet with a different remote address than
+previously used SHOULD also switch to sending with a different connection ID.
+This can help to ensure that different connection IDs will be used in both
+directions when an endpoint migrates to a new path or changes connection ID on
+an existing path.

Technically, it doesn't do anything for changes on the existing path, but that's okay because the session is linkable anyway if you're on an existing path.

-- 
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/1742#pullrequestreview-154858602

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Sep 2018 21:53:21 +0000 (UTC)

One item to note is that we've adopted EKR's suggestion to use IP:port (collectively "address" as in the migration section) changes instead of CID changes as the trigger to change your own CID.  Here's why:
  - If you switch CIDs without changing addresses they're already linked to any observers, so it doesn't matter whether the remote side changes.
  - If you switch addresses without changing CIDs, they're already linked to any observers, so it doesn't matter whether the remote side changes.
  - If you switch addresses and CIDs at the same time, you have an opportunity not to be linked.

The case we actually need to cover is ensuring that, if an endpoint changes address and CID at the same time, the peer absolutely does not respond with the old CID. Any rule that produces this is sufficient, even if it also produces some gratuitous changes along the way.

Part of what led to the changes in -13 is that switching on CID change makes it hard to avoid looping. Switching on endpoint address covers the scenario we need without requiring a fixed ordering of CIDs.

-- 
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/1742#issuecomment-420810463

---

From: MikkelFJ <[email-masked]>
Date: Wed, 12 Sep 2018 15:00:10 -0700

@MikeBishop this make sense, but in symmetric settings, both sides could have NAT rebindings, so there could a case for preemptive CID change at either endpoint after idletime - but perhaps that is 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/1742#issuecomment-420812154

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Sep 2018 15:02:59 -0700

That's already a recommendation in the existing text -- this is strictly talking about how to ensure that the CID coming back from the peer doesn't link, but also doesn't trigger a new CID rotation, which triggers a rotation, which triggers....

-- 
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/1742#issuecomment-420812871

---

From: Rui Paulo <[email-masked]>
Date: Wed, 12 Sep 2018 15:24:01 -0700

rpaulo commented on this pull request.

> +|   Length (8)  |          Connection ID (32..144)            ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+
+The fields are:
+
+Length:
+
+: An 8-bit unsigned integer containing the length of the connection ID.
+
+Connection ID:
+
+: A connection ID of the specified length.
+
+Receipt of a CONNECTION_ID_FINISHED frame containing a connection ID that was
+not previously sent to the peer MAY be treated as a connection error of type

I'm not sure how this works with packet loss / reordering.  If a new CID is retired shortly after it is issued, this problem will happen and I suppose that's why you wrote 'MAY' and not 'SHOULD'.
Can't we require implementations to wait for an ACK of the NEW_CONNECTION_ID before issuing a CONNECTION_ID_FINISHED?

+
+### Issuing Connection IDs
+
+An endpoint issues connection IDs to its peer for the peer to use when sending
+packets. This allows the endpoint control over the strategy used to interpret
+connection IDs of packets that it receives.  These connection IDs are
+communicated to the peer using NEW_CONNECTION_ID frames
+({{frame-new-connection-id}}).
+
+The initial connection ID issued to the peer is sent by the endpoint as the
+Source Connection ID during the handshake, ensuring that the peer always begins
+the connection with at least one connection ID to use when sending.  An endpoint
+SHOULD supply its peer with additional connection IDs via NEW_CONNECTION_ID
+frames. While each endpoint can choose how many connection IDs to issue, a
+recommended number of outstanding connection IDs is eight.

I wonder if recommending a specific number is helpful.  Do we have any operation experience about suggesting 8?

+

I guess the problem is that this paragraph implies the remote peer did not change CID but the address changed (perhaps NAT binding).  If we switch CIDs, does it really require the remote end to switch CIDs?  The likability problem is still there, 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/1742#pullrequestreview-154860197

---

From: MikkelFJ <[email-masked]>
Date: Wed, 12 Sep 2018 15:36:06 -0700

mikkelfj commented on this pull request.

Umm aren't you reversing direction of CONNECTION_ID_FINISHED. One end sends ID's, the other end finishes them so ACK shouldn't matter. On the MAY: if the endpoint tracks generated CID's via an algorithm such as hashing a counter. With relatively short CIDs there are possible collisions and you might not want to actually store the CIDs already generated.

-- 
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/1742#discussion_r217211077

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Sep 2018 17:50:41 -0700

martinthomson requested changes on this pull request.

Obviously, I think that this is a good balance of the concerns, because I was involved with the decision.  I do have some editorial concerns that.

I'm willing to help address these. I suggest that we start with a round of discussion, during which we might decide to split off some new issues.

+

I think that 8 is the right recommendation, but we should contextualize it more.  The primary consideration being that it is important to support a number of failed connection migrations on the way to a successful migration.

That context is later, so I think we should just move this recommendation.

+

It's not always the case that use of an existing path implies linkability.  Though it might be a strong signal, if I'm behind a NAT with a large number of other people, I can imagine the NAT being used as an mixing point.  Changing connection ID in that context might re-establish anonymity within that set.  Especially if the NAT understands connection IDs and I am able to use one for packets I receive as well.  In many cases we think about, the NAT is small and the value of re-mixing low, but you can imagine building that sort of aggregator for privacy purposes.

+

A recent PR highlighted the risks associated with that.  That text now belongs here.  See [this caution](https://github.com/quicwg/base-drafts/commit/17ccc69ecd0c652bc8f35c5db5fb3a37b0f7c67c#diff-db016291106766877c4921a79f8596e0R2380), which suggests that this change adds duplicated text...

+previously used SHOULD also switch to sending with a different connection ID.
+This can help to ensure that different connection IDs will be used in both
+directions when an endpoint migrates to a new path or changes connection ID on
+an existing path.
+
+
+### Consuming Connection IDs
+
+If an endpoint's peer has selected a non-zero-length connection ID, the endpoint
+maintains a set of connection IDs received from the peer that it can use when
+sending packets.  All connection IDs issued by the peer are considered valid for
+use by the endpoint when sending packets until the connection ID is retired by
+the endpoint.  Endpoints can choose to stop using a given connection ID to send
+packets at any time and signal this to the issuing endpoint via a
+CONNECTION_ID_FINISHED frame.  This frame indicates the connection ID that is no

I don't like this name (never have).  But until I read this text again and saw it use "retire", I didn't have an alternative I liked enough to suggest.  RETIRE_CONNECTION_ID is better (not awesome, but certainly better).

Yes, that's opinion.  Also, don't bother changing it.  I am prepared to do that.

+directions when an endpoint migrates to a new path or changes connection ID on
+an existing path.
+
+
+### Consuming Connection IDs
+
+If an endpoint's peer has selected a non-zero-length connection ID, the endpoint
+maintains a set of connection IDs received from the peer that it can use when
+sending packets.  All connection IDs issued by the peer are considered valid for
+use by the endpoint when sending packets until the connection ID is retired by
+the endpoint.  Endpoints can choose to stop using a given connection ID to send
+packets at any time and signal this to the issuing endpoint via a
+CONNECTION_ID_FINISHED frame.  This frame indicates the connection ID that is no
+longer in use and serves as a request for the peer to issue additional
+connection IDs via a NEW_CONNECTION_ID frame.

from "and serves as a request ..." is a new concept and doesn't belong to this paragraph.  It needs a new paragraph explaining things more fully.

Rather than frame this as an implicit request, I would say that you address the text at the endpoint that issues the connection IDs.  That is, rely on the text in the previous section and don't mention that function here at all.

+
+### Consuming Connection IDs
+
+If an endpoint's peer has selected a non-zero-length connection ID, the endpoint
+maintains a set of connection IDs received from the peer that it can use when
+sending packets.  All connection IDs issued by the peer are considered valid for
+use by the endpoint when sending packets until the connection ID is retired by
+the endpoint.  Endpoints can choose to stop using a given connection ID to send
+packets at any time and signal this to the issuing endpoint via a
+CONNECTION_ID_FINISHED frame.  This frame indicates the connection ID that is no
+longer in use and serves as a request for the peer to issue additional
+connection IDs via a NEW_CONNECTION_ID frame.
+
+An endpoint that retires a connection ID should retain knowledge of that
+connection ID for a reasonable time after sending the CONNECTION_ID_FINISHED

s/reasonable time/period/

I think we can leave the use of the word "reasonable" to lawyers.  It implies judgment.

+### Consuming Connection IDs
+
+If an endpoint's peer has selected a non-zero-length connection ID, the endpoint
+maintains a set of connection IDs received from the peer that it can use when
+sending packets.  All connection IDs issued by the peer are considered valid for
+use by the endpoint when sending packets until the connection ID is retired by
+the endpoint.  Endpoints can choose to stop using a given connection ID to send
+packets at any time and signal this to the issuing endpoint via a
+CONNECTION_ID_FINISHED frame.  This frame indicates the connection ID that is no
+longer in use and serves as a request for the peer to issue additional
+connection IDs via a NEW_CONNECTION_ID frame.
+
+An endpoint that retires a connection ID should retain knowledge of that
+connection ID for a reasonable time after sending the CONNECTION_ID_FINISHED
+frame, or until that frame is acknowledged.  A recommended time is three times

The acknowledgment point here is a tricky one.  The risk you describe is that a retransmission of NEW_CONNECTION_ID(X) arrives after RETIRE_CONNECTION_ID(X) is sent, which makes it appear as though X is a wholly new connection ID.  If it is then used, it might trigger stateless reset.  Defense against that is to wait for the ACK of the ACK for NEW_CONNECTION_ID, or to start the timer from when NEW_CONNECTION_ID is received, not when RETIRE_CONNECTION_ID is sent.

However, based on comments below, I think that we should recommend retention of the connection ID at the peer that uses it for 3xRTO as well and NOT short that timer when the RETIRE_CONNECTION_ID frame is acknowledged.  The reason for that is not use of the ID (that should have stopped before sending the frame), but acceptance of the stateless reset.  Packets in flight before the connection ID is retired might generate a stateless reset.

The risk I'm more concerned about is the receipt of delayed packets with X after RETIRE_CONNECTION_ID(X) is *received*.  In which case the recipient of RETIRE_CONNECTION_ID needs to remember X and not generate a stateless reset for some period.

That keeps it simple: remember a connection ID (and its associated reset token) from the time of sending or receiving RETIRE_CONNECTION_ID plus 3xRTO.

> +longer in use and serves as a request for the peer to issue additional
+connection IDs via a NEW_CONNECTION_ID frame.
+
+An endpoint that retires a connection ID should retain knowledge of that
+connection ID for a reasonable time after sending the CONNECTION_ID_FINISHED
+frame, or until that frame is acknowledged.  A recommended time is three times
+the current Retransmission Timeout (RTO) interval as defined in
+{{QUIC-RECOVERY}}.  This prevents potential retransmissions of a
+NEW_CONNECTION_ID frame from overlapping with the CONNECTION_ID_FINISHED frame
+for the same connection ID.
+
+Additionally, each connection ID MUST be used on packets sent from only one
+local address.  At any time, an endpoint MAY change to a new connection ID on a
+local address already in use.  An endpoint that migrates to a new local address
+SHOULD retire all connection IDs that were used on the previous address
+using the CONNECTION_ID_FINISHED frame.

This isn't quite right.  The point here is that you should retire connection IDs when you stop using the path, not when you move to a new one.  This text doesn't set us up very well for multipath, for instance.  

Also, an endpoint might decide to retain the connection ID for a period in case it has to switch back.  Think about a mobile device that hits a wifi access point.  It might keep the connection ID it used on the cellular path for a time in case it remains mobile.  Switching connection ID on each network change might be better, but maybe only if significant time passes.

> @@ -3257,6 +3287,49 @@ the Source Connection ID used by the peer during the initial
 handshake, it MUST treat that receipt as a connection error of type
 PROTOCOL_VIOLATION.
 
+## CONNECTION_ID_FINISHED Frame {#frame-connection-id-finished}
+
+An endpoint sends a CONNECTION_ID_FINISHED frame (type=0x1b) to indicate that it
+will no longer use a connection ID that was issued by its peer.  This also
+serves as a request to the peer to send additional connection IDs for future use
+(see {{connection-id}}).  New connection IDs can be delivered via the
+NEW_CONNECTION_ID frame ({{frame-new-connection-id}}).
+
+Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates any
+stateless reset tokens associated with that connection ID.

This implies that there are multiple tokens.

"Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates the stateless reset token associated with that connection ID."

> @@ -3257,6 +3287,49 @@ the Source Connection ID used by the peer during the initial
 handshake, it MUST treat that receipt as a connection error of type
 PROTOCOL_VIOLATION.
 
+## CONNECTION_ID_FINISHED Frame {#frame-connection-id-finished}
+
+An endpoint sends a CONNECTION_ID_FINISHED frame (type=0x1b) to indicate that it
+will no longer use a connection ID that was issued by its peer.  This also
+serves as a request to the peer to send additional connection IDs for future use
+(see {{connection-id}}).  New connection IDs can be delivered via the
+NEW_CONNECTION_ID frame ({{frame-new-connection-id}}).
+
+Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates any
+stateless reset tokens associated with that connection ID.

As an open issue, we should decide how long to allow the old token to be effective.  I would suggest that we use the same 3xRTO timer for that as well.  Then we have 3xRTO everywhere in this.

Yeah, @mikkelfj got it.  You can retire a connection ID before NEW_CONNECTION_ID is acknowledged even.

As for the short connection IDs, I think that's a reason not to allow shorter values more than an argument against this text.  Yes, over time, you might cycle really old IDs back into circulation such that they get re-issued to a connection that had it in the past.  That would be valid, but allowing it would complicate the protocol.  The protocol here uses the connection ID as its own identifier, so for that to work properly, we need it to be unique.

+
+Length:
+
+: An 8-bit unsigned integer containing the length of the connection ID.
+
+Connection ID:
+
+: A connection ID of the specified length.
+
+Receipt of a CONNECTION_ID_FINISHED frame containing a connection ID that was
+not previously sent to the peer MAY be treated as a connection error of type
+PROTOCOL_VIOLATION.
+
+An endpoint MUST NOT send this frame if it is currently sending packets with a
+zero-length Destination Connection ID.  Changing the length of a connection ID

It cannot send this frame because it won't have any connection IDs to put in it.  I think that we can shorten this paragraph to: "An endpoint cannot send this frame if it was provided with a zero-length connection ID by its peer.  An endpoint that provides a zero-length connection ID MUST treat receipt [...]"

+
+: A connection ID of the specified length.
+
+Receipt of a CONNECTION_ID_FINISHED frame containing a connection ID that was
+not previously sent to the peer MAY be treated as a connection error of type
+PROTOCOL_VIOLATION.
+
+An endpoint MUST NOT send this frame if it is currently sending packets with a
+zero-length Destination Connection ID.  Changing the length of a connection ID
+to or from zero-length makes it difficult to identify when the value of the
+connection ID changed.  An endpoint that is receiving packets with a zero-length
+Destination Connection ID MUST treat receipt of a CONNECTION_ID_FINISHED frame
+as a connection error of type PROTOCOL_VIOLATION.
+
+

We want to point out, purely for the purpose of completeness, that the connection ID provided during the handshake can be retired with this frame.

+SHOULD supply its peer with additional connection IDs via NEW_CONNECTION_ID
+frames. While each endpoint can choose how many connection IDs to issue, a
+recommended number of outstanding connection IDs is eight.
+
+When an endpoint issues a connection ID, it MUST accept packets using this
+connection ID for the duration of the connection or until its peer invalidates
+the connection ID via a CONNECTION_ID_FINISHED frame
+({{frame-connection-id-finished}}).
+
+Implementations SHOULD ensure that peers have sufficient connection IDs
+available to reduce the possibility of peers exhausting their supply of
+available connection IDs.  An implementation could do this by always supplying a
+new connection ID for each connection ID retired with a CONNECTION_ID_FINISHED
+frame. When a receiver of a packet notices that its peer is now using a
+previously unused connection ID, it can choose to supply its peer with a new

s/can choose to/can/

-- 
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/1742#pullrequestreview-154889508

---

From: erickinnear <[email-masked]>
Date: Thu, 13 Sep 2018 18:06:53 +0000 (UTC)

erickinnear commented on this pull request.

+

Agreed, let's pull that text into this section? 

-- 
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/1742#discussion_r217481857

---

From: erickinnear <[email-masked]>
Date: Thu, 13 Sep 2018 11:07:29 -0700

Sure, RETIRE_CONNECTION_ID works just as well. 😄 

-- 
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/1742#discussion_r217482049

---

From: erickinnear <[email-masked]>
Date: Thu, 13 Sep 2018 11:13:16 -0700

Yeah, we've got text in the previous section for the issuer, we could remove all reference to that from this section. 

-- 
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/1742#discussion_r217483790

---

From: erickinnear <[email-masked]>
Date: Thu, 13 Sep 2018 11:19:02 -0700

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/1742#discussion_r217485466

---

From: erickinnear <[email-masked]>
Date: Thu, 13 Sep 2018 11:20:50 -0700

+1, I like moving towards 3xRTO for everything

-- 
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/1742#discussion_r217486080

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Sep 2018 16:38:57 -0700

martinthomson commented on this pull request.

+

SGTM

-- 
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/1742#discussion_r217565591

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Sep 2018 10:40:34 -0700

I think it's correct as written, actually, though we could make it more explicit if needed.  If a packet with the old CID was delayed and the recipient drops the CID immediately upon receipt, you'll get a SR that you ought to ignore.  So unless we're *also* adding a 3xRTO requirement on the server to continue accepting the retired CID, the sender needs to immediately stop recognizing the SRT associated with the CID.  You might miss a SR from an old packet if the race lands wrong.  But the packet being sent now has a new, still-valid CID and will presumably elicit a current SR of its own, so that's okay.

-- 
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/1742#discussion_r217789739

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Sep 2018 10:46:00 -0700

Ah, GitHub was hiding this comment initially.  Remembering retired CIDs for 3xRTO on both sides (accepting SRs, but not generating them) is certainly another solution -- it's more state for the endpoints, but causes Stateless Reset to tear down more quickly.

-- 
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/1742#discussion_r217791178

---

From: Christian Huitema <[email-masked]>
Date: Sat, 15 Sep 2018 17:53:10 -0700

huitema commented on this pull request.

I think we will have an interesting conversation. My main concern is whether to introduce a concept of paths, i.e. pairs o connection IDs. It would simplify my code significantly, rather than trying to implement paths using low level components like NEW CONNECTION ID, PATH CHALLENGE and PATH RESPONSE.

+

In practice, that recommendation amounts to the server initiating a migration upon receiving packets from a new client address, so that a given pair of CID is tied to a single pair of addresses. That can work, but we have to consider security issues. Addresses are outside the cryptographic envelope, attackers can take good packets and just replace the address by something else. That mean attackers can easily trick servers into starting migrations.

I am not sure of the balance between aggravated DOD risk and moderate privacy gain. The beans are already spilled in the packet from the client with the changed address and the constant CID. If we do nothing, the client will notice that its own address changed upon receiving the first reply from the server. It can then chose to start a migration. That seems more robust.

@martinthomson do we still have a reset risk if the client retires the stateless reset value that it received with the retired connection ID?

I would actually disable the reset token asap. The only down side of doing that is to fall back to timer based termination if the connection breaks. But we probably need more text on the behavior of the reset token. Assume that a path is defined by a pair of CID. At any given point, a node will have a "main path" on which it is sending data, and a set of paths in various alternate paths in different stages of validation. Let's look at the following scenarios:

1) Node sends a normal packet, on the main path, and receives back a reset.
2) Node sends a probe with a fresh CID and new addresses and receives back a reset
3) Node sends a probe response with a fresh CID in response to a probe and receives back a reset
4) Node has parked an old path that it does not actively use and receives a reset on that path.

Do we want to treat all these scenarios the same, as in tear down the connection? Or do we want to just accept resets on the path that is actively used?

+

We want to say whether it can or cannot...

-- 
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/1742#pullrequestreview-155728483

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:21:35 -0700

Yeah, that was the original intent, but that got lost in this wording. 

-- 
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/1742#discussion_r217901660

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:33:33 -0700

@erickinnear pushed 1 commit.

1fdbecd  Move caution text, review comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/14020735ae126961bc364334d28d5dc2f943941b..1fdbecd39492547b83807237e56cd39e547fbd3f

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:34:33 -0700

+

Added note to this effect in 1fdbecd

-- 
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/1742#discussion_r217901799

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:36:18 -0700

+
+Length:
+

Changed this for FINISHED, works more nicely with what's in NEW now. 

-- 
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/1742#discussion_r217901825

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:36:50 -0700

+

Changed in 1fdbecd

-- 
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/1742#discussion_r217901829

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:36:54 -0700

+

Moved and merged with the text that's here in 1fdbecd

-- 
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/1742#discussion_r217901831

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:37:59 -0700

325c21e  Minor textual nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/1fdbecd39492547b83807237e56cd39e547fbd3f..325c21e34d452a0639369f5dacad623cd78f39a2

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:39:27 -0700

Reworded this to indicate you should retire when you're done with the local address (what we've been saying for "path" so far). We can explain more about this if necessary, but it seems pretty evident that you may migrate back, for example, and it's no harm if you use a new CID when migrating back (if you've got enough, of course). 

-- 
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/1742#discussion_r217901873

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:39:36 -0700

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/1742#discussion_r217901874

---

From: erickinnear <[email-masked]>
Date: Sat, 15 Sep 2018 21:39:49 -0700

Changed in 325c21e

-- 
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/1742#discussion_r217901877

---

From: erickinnear <[email-masked]>
Date: Sun, 23 Sep 2018 22:44:50 -0700

cfb11b5  Merge branch 'master' into connection_id

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/325c21e34d452a0639369f5dacad623cd78f39a2..cfb11b5d3cce7b6e52f5368103bc2f043dc682fc

---

From: erickinnear <[email-masked]>
Date: Sun, 23 Sep 2018 22:48:51 -0700

This is done

-- 
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/1742#discussion_r219733293

---

From: erickinnear <[email-masked]>
Date: Sun, 23 Sep 2018 23:06:25 -0700

a22f0aa  Bring back TP, this time for max_connection_ids

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

---

From: erickinnear <[email-masked]>
Date: Sun, 23 Sep 2018 23:08:21 -0700

Added `max_connection_ids` TP as discussed in NYC. This allows the consumer of CIDs to put a cap on how many the server will send. 

-- 
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/1742#issuecomment-423883470

---

From: erickinnear <[email-masked]>
Date: Sun, 23 Sep 2018 23:17:32 -0700

The remaining issue here is the re-introduction of a sequence number, which will work as follows: 
- Each CID comes with a sequence number, every CID that you send must have a sequence number higher than any you've previously sent
- This does *not* requiring anything to happen in lockstep as before, however this solves a big edge case in that you can now forget CIDs immediately instead of waiting for 3xRTO when you retire them, since any NEW_CONNECTION_ID frame crossing paths with the retirement frame will contain a sequence number. Instead, you just remember the highest sequence number NEW_CONNECTION_ID that you've received. 

For example: 
1. Peer sends NEW_CONNECTION_ID and you use it, then immediately retire it with RETIRE_CONNECTION_ID. 
2. Ack of NEW_CONNECTION_ID gets lost.
3. RETIRE_CONNECTION_ID frame is still in flight when the peer retransmits NEW_CONNECTION_ID.

If you've got a sequence number you can keep track of the highest sequence that you've gotten and, since this one will not advance the sequence number, you can safely ignore the duplicate NEW_CONNECTION_ID frame. 

-- 
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/1742#issuecomment-423884441

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 17:14:54 -0700

@janaiyengar pushed 1 commit.

6a67f0c  Revert "Bring back TP, this time for max_connection_ids"

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/a22f0aa6f52360b696745afcfc414a9a1cdf4fd0..6a67f0c5ef6ead104075bce5fa41fbf0f42879ac

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 17:20:49 -0700

923b024  replace CONNECTION_ID_FINISHED with RETIRE_CONNECTION_ID

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/6a67f0c5ef6ead104075bce5fa41fbf0f42879ac..923b024085df0f58ea736772c054afb246362884

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 17:22:09 -0700

ae3ba4f  stragglers

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/923b024085df0f58ea736772c054afb246362884..ae3ba4f23552694653b44c7f4d14c1f2bd74f35b

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 17:40:34 -0700

6dc077f  cleaned up section on issuing connection IDs

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/ae3ba4f23552694653b44c7f4d14c1f2bd74f35b..6dc077fbc4763687cb1c8400e4d9466ab7a906a9

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 18:01:35 -0700

b64b73c  finished section on consuming and retiring connection IDs

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/6dc077fbc4763687cb1c8400e4d9466ab7a906a9..b64b73cb29bdea47c266dee579f768785ec08c5b

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 18:05:39 -0700

978abd8  final bits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/b64b73cb29bdea47c266dee579f768785ec08c5b..978abd8333d35663df22fdc897c5ee6aac39d152

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 18:07:28 -0700

93052d0  nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/978abd8333d35663df22fdc897c5ee6aac39d152..93052d0c45eed5c298c5480d05f49e66f5c7fd04

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 18:09:48 -0700

### Issuing Connection IDs
 
-An endpoint issues connection IDs to its peer for the peer to use when sending
-packets. This allows the endpoint control over the strategy used to interpret
-connection IDs of packets that it receives.  These connection IDs are
-communicated to the peer using NEW_CONNECTION_ID frames
-({{frame-new-connection-id}}).
+The initial connection ID issued by an endpoint is the Source Connection ID
+during the handshake.  Subsequent connection IDs are communicated to the peer
+using NEW_CONNECTION_ID frames ({{frame-new-connection-id}}).  While each
+endpoint independently chooses how many connection IDs to issue, a recommended
+number of outstanding connection IDs is eight.

endpoints SHOULD provide and maintain at least 8 connection IDs......

-- 
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/1742#pullrequestreview-158348635

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 18:10:32 -0700

> -new connection ID for each connection ID retired with a RETIRE_CONNECTION_ID
-frame. When a receiver of a packet notices that its peer is now using a
-previously unused connection ID, it can supply its peer with a new connection ID
-using a NEW_CONNECTION_ID frame to reduce the possibility of its peer running
-out of available connection IDs.
-
-Endpoints that use connection IDs with length greater than zero could have their
-activity correlated if their peers keep using the same destination connection ID
-after migration.  An endpoint that receives a packet with a different remote
-address or destination connection ID than previously used SHOULD also switch to
-sending with a connection ID that has not previously been used.  The goal is to
-ensure absence of correlation between the pairs of client and server connection
-ID used on different paths.  To fulfill this privacy requirement, endpoints that
+An endpoint SHOULD ensure that its peer has a sufficient number of available and
+unused connection IDs.  The endpoint can do this by always supplying a new
+connection ID when a connection ID is retired by its peer or when the endpoint

Maybe move the recommendation for 8 in between the two sentences here.

-- 
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/1742#pullrequestreview-158348724

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 18:11:07 -0700

-sending with a connection ID that has not previously been used.  The goal is to
-ensure absence of correlation between the pairs of client and server connection
-ID used on different paths.  To fulfill this privacy requirement, endpoints that
+An endpoint SHOULD ensure that its peer has a sufficient number of available and
+unused connection IDs.  The endpoint can do this by always supplying a new
+connection ID when a connection ID is retired by its peer or when the endpoint
+receives a packet with a previously unused connection ID.
+
+
+### Consuming Connection IDs
+
+An endpoint that receives a packet with a different remote address or
+destination connection ID than previously used SHOULD also switch to sending
+with a connection ID that has not previously been used.  The goal is to ensure
+absence of correlation between the pairs of client and server connection ID used

The goal is to ensure that traffic on different paths cannot be correlated.

-- 
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/1742#pullrequestreview-158348791

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 18:12:07 -0700

> @@ -1242,46 +1242,37 @@ the connection ID via a RETIRE_CONNECTION_ID frame
 An endpoint SHOULD ensure that its peer has a sufficient number of available and
 unused connection IDs.  The endpoint can do this by always supplying a new
 connection ID when a connection ID is retired by its peer or when the endpoint
-receives a packet with a previously unused connection ID.
-
-
-### Consuming Connection IDs
+receives a packet with a previously unused connection ID.  Endpoints that
+initiate migration and require non-zero-length connection IDs SHOULD provide
+their peers with new connection IDs before migration, or risk the peer closing
+the connection.

closing the connection...when they run out of connection IDs.

-- 
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/1742#pullrequestreview-158348921

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 18:12:21 -0700

-: If both endpoints change connection ID in response to seeing a change in
-  connection ID from their peer, then this can trigger an infinite sequence
-  of changes.
+An endpoint can arbitrarily change the connection ID it uses for a peer to

s/arbitrarily//

-- 
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/1742#pullrequestreview-158348960

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 18:14:25 -0700

An endpoint that retires a connection ID should retain knowledge of that
-connection ID for a period of time after sending the RETIRE_CONNECTION_ID
-frame, or until that frame is acknowledged.  A recommended time is three times
-the current Retransmission Timeout (RTO) interval as defined in
-{{QUIC-RECOVERY}}.  This prevents potential retransmissions of a
-NEW_CONNECTION_ID frame from overlapping with the RETIRE_CONNECTION_ID frame
-for the same connection ID.
+connection ID for a period of time after sending the RETIRE_CONNECTION_ID frame,
+or until that frame is acknowledged.  A recommended time is three times the
+current retransmission timeout (RTO) interval as defined in {{QUIC-RECOVERY}}.
+This prevents confusion from receiving retransmissions of a NEW_CONNECTION_ID

This prevents a retransmission of a NEW_CONNECTION_ID from incorrectly renewing a previously retired 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/1742#pullrequestreview-158349202

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 18:16:34 -0700

94c6a0e  mt review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/93052d0c45eed5c298c5480d05f49e66f5c7fd04..94c6a0eb69baf56e09ae331d557da0af4ad29984

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 18:18:48 -0700

48ff3e7  fix

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1742/files/94c6a0eb69baf56e09ae331d557da0af4ad29984..48ff3e7050c3298008929ce40d130bd1bc745e0e

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 18:20:15 -0700

I've made some editorial fixes to the text, and also tried to reflect what we agreed on in NYC.

-- 
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/1742#issuecomment-424175862

---

From: janaiyengar <[email-masked]>
Date: Mon, 24 Sep 2018 18:20:25 -0700

Merged #1742 into master.

-- 
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/1742#event-1864528341