Subject: [quicwg/base-drafts] Confusion about number of outstanding CIDs (#1464)

From: Mike Bishop <[email-masked]>
Date: Wed, 20 Jun 2018 11:29:58 -0700

Suppose an endpoint is probing an alternate path to keep it available for future migration.  (Probing periodically over cellular in case Wi-Fi goes away, for example.)  The endpoint has N connection IDs outstanding and chooses to use one of them on a probing packet, which gets lost.  When the endpoint retransmits the probe, it uses a different CID because it has been quiescent for a while.  This probe gets through.

At this point, the endpoint believes it has N-2 remaining CIDs to work with, while its peer believes it has N-1 CIDs still issued.  Now the text about making sure your peer has outstanding CIDs becomes pointless, because the peers can't accurately estimate.  Repeat this a couple times, and you might find yourself stuck behind "MUST NOT send additional packets until a NEW_CONNECTION_ID frame is received" because you've run out and the peer thinks you haven't.

ACK tracking would let the endpoint detect that this has happened (all packets using CID A have been declared lost, so peer doesn't know I burned it), but that doesn't permit the endpoint to *fix* the problem.  I think this ultimately leads us to a NEED_MORE_CIDS frame, unless anyone else has an idea.  (Not quite CID_BLOCKED, because once you're blocked it's too late.)

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 20 Jun 2018 12:33:53 -0700

Somewhat OT, but it got me thinking - for long should a connection track a given path? Consider an drone traversing a futuristic public mesh wifi network there could be thousands of migrations over the lifetime of 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/1464#issuecomment-398869861

---

From: Mike Bishop <[email-masked]>
Date: Wed, 20 Jun 2018 13:37:10 -0700

Implementation specific.  I'm inclined to say that once you've lost the local address, you can forget all paths associated with it, unless you have some local reason to believe it will come 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/issues/1464#issuecomment-398888236

---

From: Nick Banks <[email-masked]>
Date: Wed, 20 Jun 2018 13:46:00 -0700

I do agree that it's implementation specific, but I still think it's something they spec should provide recommendations for.

For @mikkelfj's scenario, I'm more worried about the server side. It keeps giving out more CIDs and the client keeps using them. Should we have a way for the client to explicitly tell the server that a particular old CID is no longer in use? Otherwise the best I can see the server doing it having some timer (idle timeout period?) per CID to age it out or just a simple max number of simultaneous CIDs to allow at any one time, and as new CIDs are given out, if there is no more room, the oldest is automatically aged out.

-- 
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/1464#issuecomment-398890796

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Jun 2018 06:39:48 -0700

I think that we need a NEED_MORE_CIDS frame.

The issue I see with the approach proposed in #1465 is that it is hard to determine the number of spare CIDs is an endpoint expected to provide to the peer. I'd assume that 1 as the number of spare CIDs is too small, since if an endpoint tries to probe a path using the spare and fails, it would get out 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/issues/1464#issuecomment-399106812

---

From: ekr <[email-masked]>
Date: Thu, 21 Jun 2018 08:36:37 -0700

CID_BLOCKED!

On Thu, Jun 21, 2018 at 6:39 AM, Kazuho Oku <[email-masked]>
wrote:

> The issue I see with the approach proposed in #1465
> <https://github.com/quicwg/base-drafts/pull/1465> is that it is hard to
> determine the number of spare CIDs is an endpoint expected to provide to
> the peer. I'd assume that 1 as the number of spare CIDs is too small, since
> if an endpoint tries to probe a path using the spare and fails, it would
> get out of CIDs.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1464#issuecomment-399106812>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1ocl_rWMJrWThFaMJCO6ZAEavXeWKks5t-6IhgaJpZM4UvxS5>
> .
>

-- 
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/1464#issuecomment-399147142

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Jun 2018 17:45:56 -0700

Maybe the simplest way to deal with that is to require reciprocation.  If you get a NEW_CONNECTION_ID with a sequence number of N, then you have to provide that many connection IDs.  New issue inbound.

-- 
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/1464#issuecomment-399286416