Subject: [quicwg/base-drafts] DetectLostPackets not called in anti-deadlock case (#3298)

From: Lars Eggert <[email-masked]>
Date: Wed, 11 Dec 2019 06:01:49 -0800

Why is DetectLostPackets only called for the time threshold loss case? Shouldn't it at least also be called for the anti-deadlock case?

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

---

From: ianswett <[email-masked]>
Date: Wed, 11 Dec 2019 06:39:46 -0800

DetectLostPackets() is called when an ACK is received that acknowledges new packets or the loss detection timer fires, which I believe lines up with the text.

Why would it be called in the anti-deadlock case?  The only two loss triggers are packet threshold and time.  Packet threshold requires a new ACK, and the loss time is only set/changed when a new ACK is received.

-- 
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/3298#issuecomment-564574153

---

From: Lars Eggert <[email-masked]>
Date: Wed, 11 Dec 2019 08:31:04 -0800

What if you get no ACKs during the handshake? You never declare packets lost. You still RTX them, but that seems suboptimal. 

-- 
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/3298#issuecomment-564625347

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 11 Dec 2019 08:35:31 -0800

Why is that suboptimal? Does something unexpected happen?

On Wed, Dec 11, 2019 at 8:31 AM Lars Eggert <[email-masked]>
wrote:

> What if you get no ACKs during the handshake? You never declare packets
> lost. You still RTX them, but that seems suboptimal.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/3298?email_source=notifications&email_token=AEVHVSRC6VQ7CPVJLDEQG3TQYEIURA5CNFSM4JZPN44KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGTX7QY#issuecomment-564625347>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AEVHVSUIXEHJMHYPSCJNQUTQYEIURANCNFSM4JZPN44A>
> .
>

-- 
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/3298#issuecomment-564627354

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Dec 2019 18:32:03 -0800

It is by design that we don't mark things as lost until an ACK is received. That is, lack of feedback is not treated as loss to avoid undoing things later when the RTT may actually have changed. Receipt of an ACK is an important signal that the RTT is fine, and that it is actually likely that packets have been lost.

As Ryan asks, what happens that is suboptimal?

-- 
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/3298#issuecomment-564822615

---

From: Lars Eggert <[email-masked]>
Date: Wed, 11 Dec 2019 23:08:49 -0800

Well, if you have only a small amount of buffers (embedded device), and you RTX without freeing up the original TX (i.e., you con't declare it lost), you end up of of buffers pretty quickly.

Since anti-deadlock is only done during the handshake, there really isn't anything to undo?

-- 
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/3298#issuecomment-564879791

---

From: ianswett <[email-masked]>
Date: Thu, 12 Dec 2019 05:32:36 -0800

I'm not sure what you're buffering model is, but I'd expect a RTX to only create a small amount of extra metadata, not a copy of the entire packet.  How you do it depends upon whether you retransmit the payload of the original packet without changing it or use another approach, but it's intended to be low cost.

Is your concern on the client side or the server?

-- 
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/3298#issuecomment-565008101

---

From: Lars Eggert <[email-masked]>
Date: Thu, 12 Dec 2019 23:06:29 -0800

Since data is normally only RTX'ed after having been declared lost, I have (maybe prematurely) optimized for this case. So a series of RTXs without any incoming ACK will in fact occupy multiple buffers.

Maybe I just need to deal with this in my implementation and it doesn't require spec changes...

-- 
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/3298#issuecomment-565327912

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 Dec 2019 20:45:22 -0800

I suspect this is a special case. Our model has been to not mark anything as lost until we've received an ACK for something after it.  I can see that you might have a bit of a cost in following this model with your implementation. Calling DetectLostPackets() there if you'd like as an optimization for your case, I don't think you break anything by doing 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/3298#issuecomment-566378423

---

From: Lars Eggert <[email-masked]>
Date: Mon, 16 Dec 2019 23:53:48 -0800

Will do, thanks

-- 
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/3298#issuecomment-566425983

---

From: Lars Eggert <[email-masked]>
Date: Mon, 16 Dec 2019 23:53:48 -0800

Closed #3298.

-- 
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/3298#event-2888806811