Subject: [quicwg/base-drafts] Should retiring all CIDs be an error? (#2101)

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 05 Dec 2018 08:15:21 -0800

Retiring all CIDs that have been issued makes the CID issuer unreachable. Should this be a connection error?

It is possible to imagine that the CID issuer may send a new CID to the peer after all its CIDs are retired and then the connection can continue.

Either way, this case should be covered in the draft.

-- 
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/2101

---

From: Marten Seemann <[email-masked]>
Date: Fri, 07 Dec 2018 03:11:17 -0800

I don't think this is the case. An endpoint retires CIDs that it uses as destination CIDs. So if a peer retires all CIDs, it's shooting itself in the foot because it won't be able to send any more packets (until it receives a packet containing a NEW_CONNECTION_ID frame). Therefore, I don't think we need any error condition 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/issues/2101#issuecomment-445200872

---

From: Christian Huitema <[email-masked]>
Date: Sun, 09 Dec 2018 17:18:20 -0800

If there was an error, what CID would the node use to send the connection close message?

-- 
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/2101#issuecomment-445610333

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Dec 2018 17:04:14 -0800

You can send CONNECTION_CLOSE, even if you can't accept an ACK, because it's the not peer that has no connection IDs that sends that packet.  Or you can send more NEW_CONNECTION_ID frames.

The only potentially interesting case is that you can't send a packet with a long header, but that's not a problem in this protocol version.

I'm somewhat biased toward silence on this issue.  We encourage the replacement of connection IDs, which works here.  And if an endpoint just made it impossible to keep sending packets, that's a problem that solves itself really.

-- 
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/2101#issuecomment-446033780

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 11 Dec 2018 16:35:25 -0800

We can simply disallow RETIRE_CONNECTION_ID to refer to a CID that is being used in a packet containing that RETIRE_CONNECTION_ID frame.  This avoids this very interesting case and ensures that there is a CID to use, if this RETIRE_CONNECTION_ID frame needs to be retransmitted.

-- 
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/2101#issuecomment-446416766

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Dec 2018 16:42:22 -0800

Clever.  But I'm not sure that this relationship is maintained.  We used to have frame processing dependent on the packet header.  It wasn't popular and I think that was the very first thing we 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/issues/2101#issuecomment-446418073

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 11 Dec 2018 17:07:30 -0800

Frame processing dependent on the packet header is a requirement on the receiver.  Error detection by the receiver is not a MUST here.  A prohibition against RETIRE_CONNECTION_ID CID used by send RETIRE_CONNECTION_ID would be MUST for the sender.

(If we do not resolve this in the Transport draft, this would certainly need to make its way into Applicability draft as a warning against retiring all 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/issues/2101#issuecomment-446422882

---

From: janaiyengar <[email-masked]>
Date: Wed, 12 Dec 2018 19:08:32 -0800

I'm with @martinthomson on this one. There are many ways in which an endpoint can shoot itself in the foot, and this is one more.  I'll note that the onus here really is on the peer issuing CIDs.  Retiring is fine if it's the only one that the peer has issued, and it needs to be retired because of a change in the peer's address for example. A peer that doesn't issue new ones ahead of time is responsible.

That said, an endpoint that retires CIDs willy-nilly is simply hurting itself. I wouldn't be opposed to having something in the applicability draft, along with text for when something should be retired.

-- 
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/2101#issuecomment-446827065