Subject: Re: [quicwg/base-drafts] Retire My Own CID (#2645)

From: Jana Iyengar <[email-masked]>
Date: Wed, 08 May 2019 19:35:34 -0700

The mechanism for REPLACE_CONN_ID is not complicated, but I'm not yet convinced about its need. So, if we treat the two partitions as two servers, a commonly used strategy for migrating load is to send a GOAWAY to the client and have new connections be routed to the new server. Is this not adequate for you, @nibanks?

-- 
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/issues/2645#issuecomment-490720409

---

From: Nick Banks <[email-masked]>
Date: Wed, 08 May 2019 19:52:49 -0700

The partition can be on the same physical machine (different processor/numa node). Changing the partition ID allows for dynamic rebalancing of load across these more easily.

-- 
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/issues/2645#issuecomment-490723475

---

From: MikkelFJ <[email-masked]>
Date: Thu, 09 May 2019 00:15:44 -0700

I'm a bit torn here - I don't think internal process optimisation should be on the wire, but with 96 cores and counting, and possibly hardware optimized queue delivery, there is probably a reasonable case for it.

There may also be a case of handover on the internal network.

But this is only a use case consideration. I haven't considered whether @nibanks proposal is the right way to do 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/issues/2645#issuecomment-490776028

---

From: Nick Banks <[email-masked]>
Date: Wed, 15 May 2019 10:40:35 -0700

Allowing for an endpoint to edit/replace existing CIDs can allow all sorts of dynamic rebalancing logic on the LB side of things. Perhaps server ID is changed for a back end server and it wants to update all CIDs to encode the new ID appropriately.

The current design of give something to the peer and you're stuck with it forever, until they decide to stop using it seems overly restrictive. Additionally, if we support inplace CID replacement, the actual implementation logic to support this should be extremely trivial; just memcpy over the old one with the new one for the most part. The complexity only comes from endpoints that want to actually replace their own CIDs. They would need to have synchronization logic for it and so on. Endpoints that never need to do this don't accrue any additional cost.

-- 
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/issues/2645#issuecomment-492752485

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 May 2019 18:57:32 -0700

Even if you do a REPLACE for future IDs, you can't currently require that the client stop using the current CID. So given that you have to wait an arbitrary amount of time for connections to "drain" anyways, I'll go back to my earlier comment: why not send GOAWAYs for connections you want to shed to the new partition?

If you really want to have dynamic balancing, it seems to me that there'd be more to gain by forcing the client to stop using the existing CID and using a new one. You would want to REPLACE IDs as well, but without forcing the client to move off the current CID, most connections won't move since most connections are unlikely to use a new CID unless the client is migrating (an uncommon event).

-- 
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/issues/2645#issuecomment-492886642

---

From: Nick Banks <[email-masked]>
Date: Wed, 15 May 2019 22:12:27 -0700

Why can't I require the client update the CIDs? As discussed earlier in the comments, the design would be that the client MUST update and if the server receives an ACK for a packet with the REPLACE_CID and is still using an old CID, it will terminate the connection.

HTTP/3 is not my old QUIC protocol, but either way, I want a QUIC solution, not a higher layer protocol solution since QUIC is the layer doing this load balancing.

-- 
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/issues/2645#issuecomment-492919324

---

From: ianswett <[email-masked]>
Date: Thu, 16 May 2019 05:29:38 -0700

@nibanks I think your use case is real, and the implementation work client side seems quite small, but it is one more CID feature and I'm not sure what fraction of implementations want to use this?

I can imagine we'd use it on the server side if it was present, though.

-- 
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/issues/2645#issuecomment-493047139

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 16 May 2019 17:51:55 -0700

As I've pointed out, I don't think the mechanism you're asking for is adequately useful for the problem you're trying to solve. I'm not opposed to solving the problem, which is why I'm trying to understand the problem itself.

As I said, you would still want a mechanism to replace the existing CID, without which you are stuck draining open connections that aren't changing CID through the life of the connection. I expect this to be fairly common -- most clients are unlikely to change destination CIDs unless there's migration involved. Given this, I still don't see how simply replacing future CIDs is adequate.

@ianswett : Do you think the proposed mechanism _without_ replacing the current CID is still useful? Where do you think you might use 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/issues/2645#issuecomment-493279800

---

From: MikkelFJ <[email-masked]>
Date: Fri, 17 May 2019 00:07:08 -0700

There is also the concern of conflating migration with targeted load balancing. Even if you did replace the current CID, what happens if the client migrates frequently. All future CID's would be drawn from a pool of CID's that might point to the wrong endpoint process. This means you would have to split up the CID's into two parts: an address and a sequence number, both appearing random externally. You would then change the address part, but leave the sequence selection to the client. This appears to be rather overengineered. Alternatively the current CID could be replaced post migration which might just be few roundtrips of sub-optimal performance before hitting the proper destination, under the assumption that migration is is not that frequent. This also shows that having the server initiate a migration (which is not currently possibly) is insufficient unless the client future CID's are tied to a specific server 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/issues/2645#issuecomment-493346363

---

From: ianswett <[email-masked]>
Date: Fri, 17 May 2019 05:51:30 -0700

@janaiyengar The mechanism would have to include a way to request/force the client to change CID ASAP to be useful.  Only a way to retire outstanding CIDs is fairly useless in my opinion.  I assume the mechanism to enforce this would be a GOAWAY followed by a connection close containing a FAILED_TO_ROTATE_CID error if the client didn't change in time.

-- 
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/issues/2645#issuecomment-493441877

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 May 2019 07:53:29 -0700

Discussed in London; reservations about whether this is desirable / necessary, but @nibanks to make a proposal. Atomic nature a particular concern, as is the mandatory nature of 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/issues/2645#issuecomment-494837952

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 May 2019 07:55:38 -0700

REPLACE_CONN_ID sounds simple, though we need to remember that this frame might arrive out-of-order.

That means that this frame needs to have it's own sequence number and the receiver needs to retain the largest sequence number for each of the Connection ID that it maintains...

-- 
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/issues/2645#issuecomment-494838905

---

From: Eric Kinnear <[email-masked]>
Date: Wed, 22 May 2019 14:57:29 +0000 (UTC)

REPLACE_CONN_ID is interesting, but we need to go through the rest of the issues surrounding changing that base assumption. It's potentially worth working through the fallout from doing that and seeing how icky it gets.

-- 
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/issues/2645#issuecomment-494839764

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 07:57:46 -0700

I think we should not do this as this stage, thinking of how messy it was to evolve path migration. Also multi-path might complicate things further. Suggest v2.

-- 
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/issues/2645#issuecomment-494839907

---

From: Nick Banks <[email-masked]>
Date: Wed, 22 May 2019 15:04:42 +0000 (UTC)

I agree, that because of reordering, we can't require immediate usage of the new CID after the packet/frame is acknowledged. Instead, perhaps a 1-RTT timer, after the REPLACE_CONN_ID is acknowledged, then I just remove the old CID from my routing table, which means those packets would then be dropped.

On the side that receives the REPLACE_CONN_ID, it would have to ensure that it replaces immediately though, because if it continues to use the old CID after ACK'ing will eventually get a stateless reset.

I have several performance problems I am trying to solve with this right now, which I am trying to push a solution in v1. If the solution to this is ever optional (different version or extension) then it's not going to be a valid solution, I would have to go back to the drawing board.

-- 
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/issues/2645#issuecomment-494842855

---

From: Nick Banks <[email-masked]>
Date: Wed, 22 May 2019 08:37:55 -0700

I started writing up a PR for REPLACE_CONN_ID and I realized that the frame would end up being pretty much exactly that the same as NEW_CONN_ID. So, one way we could support REPLACE_CONN_ID semantics would be a smaller change to allow for NEW_CONN_ID to overwrite a CID sequence number. Practically that's exactly what REPLACE_CONN_ID would do, but adds a new frame and a good bit of new text.

So, would folks rather change NEW_CONN_ID to allow for overwriting, or add a completely separate 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/issues/2645#issuecomment-494856742

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 May 2019 08:45:00 -0700

> one way we could support REPLACE_CONN_ID semantics would be a smaller change to allow for NEW_CONN_ID to overwrite a CID sequence number. 

I am not sure if that is the case. Consider the case where the sender first decides to replace CID at sequence N with value X, then decides to replace that CID with value Y.

I think we need a way to distinguish if which of replace-to-X replace-to-Y was sent later. So, we need a sequence number for each of the CID that is being replaced.

-- 
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/issues/2645#issuecomment-494859592

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 08:45:43 -0700

If it only takes effect if the CID is still current it avoids a lookup to scan all queued CIDs.

This would also address @kazuho's concern I believe.

-- 
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/issues/2645#issuecomment-494859847

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 May 2019 08:46:52 -0700

@mikkelfj It doesn't, because NEW_CONNECTION_ID specifies the CID being replaced by using the sequence number, not the current value of the CID.

-- 
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/issues/2645#issuecomment-494860307

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 08:49:10 -0700

Yes, but there is a proposal to allow for a special case where the CID is used explicitly. I'm not sure that would cleanly map to the same frame given that, as you say, the other CIDs use numbers.

Also, it wouldn't allow a global reroute if a process moves. All other pending CIDs might be void. Hence a flush all CIDs if current CID match might be needed.

-- 
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/issues/2645#issuecomment-494861222

---

From: Nick Banks <[email-masked]>
Date: Wed, 22 May 2019 08:51:49 -0700

REPLACE_CONN_ID would have the exact same reorder problem.

One solution is that the sender must not update a connection ID until the previous packet/frame was acknowledged. The other possibility would that receiver keep track of the packet number the connection ID was received in. Always use the CID in the most recent packet number.

-- 
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/issues/2645#issuecomment-494862341

---

From: Marten Seemann <[email-masked]>
Date: Wed, 22 May 2019 15:54:03 +0000 (UTC)

> One solution is that the sender must not update a connection ID until the previous packet/frame was acknowledged. The other possibility would that receiver keep track of the packet number the connection ID was received in.

I’d really like to avoid doing any of these. This would create a lot of additional complexity.

-- 
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/issues/2645#issuecomment-494863268

---

From: Nick Banks <[email-masked]>
Date: Wed, 22 May 2019 08:54:50 -0700

I'd prefer to have the sender have the responsibility, and in that case, only implementations that actually want to change their CID gets the extra complexity.

-- 
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/issues/2645#issuecomment-494863568

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 May 2019 08:55:20 -0700

> One solution is that the sender must not update a connection ID until the previous packet/frame was acknowledged. The other possibility would that receiver keep track of the packet number the conne…

I do not think that either of the two would work considering the fact that an endpoint is permitted to retransmit out-of-date frames as they are.

Consider the case where an endpoint first sends packet(pn=x,REPLACE_CONN_CID(seq=y,new_value=a)), then sends packet(pn=y,REPLACE_CONN_ID(seq=y,new_value=b)). If pn=x is deemed lost, then the endpoint is permitted to send(pn=z, REPLACE_CONN_CID(seq=y,new_value=a)), where z is greater than y.

-- 
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/issues/2645#issuecomment-494863822

---

From: Nick Banks <[email-masked]>
Date: Wed, 22 May 2019 08:56:30 -0700

Again, if the responsibility is on the sender side, it's up to the sender on how to enforce it. If you support the feature, you cannot blindly retransmit these frames.

-- 
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/issues/2645#issuecomment-494864346

---

From: Nick Banks <[email-masked]>
Date: Thu, 23 May 2019 01:48:28 -0700

After talking to a few folks, I'm now leaning towards the following solution:

Update NEW_CONN_ID frame to have two frame types (or we can add a new, separate frame) where the second frame type indicates the presence of an additional field: `RetireSequenceNumber` (we can bike shed the name). This new field indicates the sequence number of a CID that is being replaced by this new CID (which has a new sequence number too).

The sender sends this frame for any/all outstanding, non-retired CIDs that is needs to replace. The receiver is expected to quickly, if not immediately respond with a RETIRE_CONN_ID for all the CIDs that the sender is replacing. Once the NEW_CONN_ID frame is ACKed the sender may drop all the retired CIDs from it's routing table after some time (3 RTT?) even if the peer hasn't retired them; OR it can send a HTTP goaway.

One note on the CID flow control: Even if the maximum number of CIDs have been given to the peer, an endpoint is allowed to retire one or all of them with this NEW_CONN_ID frame, and the peer is expected to accept these new CIDs; since they are replacing the old ones.

-- 
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/issues/2645#issuecomment-495126302

---

From: ianswett <[email-masked]>
Date: Thu, 23 May 2019 01:53:52 -0700

This seems sensible.  Why not always specify RetireSequenceNumber?  

This is nice because it further incentivizes peers to provide them in order, since they're retired in order.

If we wanted, this would make enforcing the active connection ID limits trivial(@marten-seemann ), because a receiver of NEW_CONNECTION_ID would compare the incoming ID to the RetireSequenceNumber and if the gap is larger than active_connection_id_limit, close the connection.

-- 
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/issues/2645#issuecomment-495128309

---

From: MikkelFJ <[email-masked]>
Date: Thu, 23 May 2019 02:10:57 -0700

I think the ACK optimisation should be avoided. A CID is retired when it is retired, not before. This also allows peers to opt in to their own schedule. They might have a complex distributed pipeline that is not synced with ACK logic. It is the senders headache since it is trying to force its own optimisation onto the peer.

While I can see the overall idea, I'm a bit concerned about race conditions here. If you retire 5 CID's the might not all take effect immediately so when the first one is retired, the next available CID is used even if it is scheduled to retire. Forcing the peer to sync on this requires processing multiple frames concurrently assuming they all land in the same packet for a start.

-- 
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/issues/2645#issuecomment-495134695

---

From: Nick Banks <[email-masked]>
Date: Thu, 23 May 2019 02:16:10 -0700

My primary goal of this is to force the peer to change. I'm OK if it takes a little time, but I need them to change. If they don't I will kill the connection. If we don't have any enforcement, then peers have no reason not to just ignore this and effectively nullifies the feature.

-- 
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/issues/2645#issuecomment-495136487

---

From: MikkelFJ <[email-masked]>
Date: Thu, 23 May 2019 02:16:17 -0700

You can get around the race condition by assigning an epoch to CIDs and retire an entire epoch at once. Obviously you'd need to prime with new CID's a new epoch first, but you can do that in the same frame as the one retiring an epoch. This might also work better on multi-path going forward.

-- 
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/issues/2645#issuecomment-495136526

---

From: Eric Kinnear <[email-masked]>
Date: Thu, 23 May 2019 02:17:26 -0700

Thanks for writing this up, @nibanks! I think this is going in a good direction.

Ideally, RetireSequenceNumber would either mean "SHOULD retire as soon as possible" or "MUST retire", we can debate that as necessary. 

To @ianswett's comment, there still needs to be a way to increase the number of CIDs that are active (especially at the beginning of a connection), but I think having the field always be present would be fine.

I think the key idea here is that, by asking the other side to retire the CIDs, we can manage to avoid any ACK-tracking or other draining scheme. Instead, we request the peer to use the existing mechanism to remove the old CIDs and all of the logic currently in place for that just works for this too.

Instead of asking the sender to track the ACK for NEW_CONN_ID, I'd rather have it just wait for the CID to be retired, and if it becomes untenable to do that, it can close the connection (either with no error, or we can define an error code saying "you didn't retire, please connect again").

-- 
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/issues/2645#issuecomment-495136925

---

From: MikkelFJ <[email-masked]>
Date: Thu, 23 May 2019 02:17:36 -0700

> My primary goal of this is to force the peer to change.

Yes, I think that is fine. It is just hard to place a hard limit on 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/issues/2645#issuecomment-495136986

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 May 2019 02:48:17 -0700

Why does the replacement need to be coupled to the retirement request?  Why not say "please retire all with seqno lower (or equal to) X", then provide a new 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/issues/2645#issuecomment-495148595

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 23 May 2019 02:52:30 -0700

@martinthomson I presume you mean @MikeBishop's proposal (https://mikebishop.github.io/please-retire/draft-bishop-quic-please-retire.html).

I think that can be considered as a simplification to the RETIRE_CONN_ID proposal, because "retire all with seqno lower than X" frame removes the need to retain per-CID sequence numbers.

-- 
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/issues/2645#issuecomment-495150022

---

From: Nick Banks <[email-masked]>
Date: Thu, 23 May 2019 02:53:15 -0700

@martinthomson my main problem with that design is the CID flow control. If an endpoint has currently maxed out the peers max number of CIDs, and it wants to replace them all, what then? If you don't have a single frame to both retire and replace, then it looks like we have a problem. You obviously can't just retire all outstanding CIDs. Then they have no CIDs to use. You also can't just give them more CIDs first, because the limit has been reached, so they will ignore the new ones.

-- 
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/issues/2645#issuecomment-495150293

---

From: MikkelFJ <[email-masked]>
Date: Thu, 23 May 2019 02:58:17 -0700

> Why does the replacement need to be coupled to the retirement request? Why not say "please retire all with seqno lower (or equal to) X", then provide a new connection ID?

This is one way to implement the epoch I was referring to in the above.

-- 
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/issues/2645#issuecomment-495152213

---

From: MikkelFJ <[email-masked]>
Date: Thu, 23 May 2019 10:03:43 +0000 (UTC)

@nibanks you can have two epochs: old and new each with a limit. This allows you to replenish CID's in new epoch before retiring the old.

-- 
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/issues/2645#issuecomment-495154195

---

From: Eric Kinnear <[email-masked]>
Date: Thu, 23 May 2019 03:06:47 -0700

@martinthomson I think I'd prefer to have a "please retire" come with a replacement since otherwise there's not any guarantee that they'll be replaced. Having them in the same frame also makes it easy to replace ones without depending on ordering between frames of a "retire" and then "add new one" if you're already at the limit (as @nibanks said).

-- 
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/issues/2645#issuecomment-495155326

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 May 2019 03:12:14 -0700

There is never any guarantee that the connection ID will be replaced.  Coupling them just complicates the design.

The idea that you can provide replacements without blowing the limit is strange.  You are still providing extra connection IDs.

For the case that @nibanks cares about, the low water mark is probably fine because you will want to send the retirement before filling up the active connection ID set.  I think that it is enough to provide a retirement signal and then wait for the peer to retire old ones and replace them on a regular cadence.  Worst case, that means that you have to wait a round trip; but that's not going to be a problem for the RSS scenario Nick described.

-- 
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/issues/2645#issuecomment-495157258

---

From: ianswett <[email-masked]>
Date: Thu, 23 May 2019 03:46:56 -0700

You're providing an extra ID and have the ability to retire at the same time, so you can easily avoid blowing the limit.

This might actually simplify my implementation, because I could store a fixed number of a CIDs in a ringbuffer of the size I specify instead of a hashmap.

-- 
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/issues/2645#issuecomment-495168173

---

From: Nick Banks <[email-masked]>
Date: Thu, 23 May 2019 03:58:36 -0700

I also think the simplest solution to implement is the NEW_CONN_ID frame that replaces an existing CID.

@ianswett if the `RetireSequenceNumber` is always there, what do you set to it when adding a new CID that isn't actually replacing 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/issues/2645#issuecomment-495171447

---

From: ianswett <[email-masked]>
Date: Thu, 23 May 2019 04:00:21 -0700

Set RetireSequenceNumber to 0?

-- 
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/issues/2645#issuecomment-495171893

---

From: Nick Banks <[email-masked]>
Date: Thu, 23 May 2019 04:00:54 -0700

Is that not the first CID exchanged during the handshake? We need to be able to replace that one.

-- 
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/issues/2645#issuecomment-495172039

---

From: ianswett <[email-masked]>
Date: Thu, 23 May 2019 04:03:13 -0700

We could make the semantics: Retire CIDs under this number?

-- 
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/issues/2645#issuecomment-495172619