Re: [quicwg/base-drafts] Should we allow ACK-only packets to be declared lost? (#3451)

[Kazuho Oku <[e-mail]>]

Let my paraphrase.

> There's a simpler one: if sending packets causes congestion such that loss (or ECN-CE marking) occurs, then ignoring that signal means that you will likely create more congestion.

Are you arguing that an endpoint SHOULD throttle the rate in which it sends ACK-only packets, when some of those ACK-only packets are being lost?

I would assume that your answer is no, and that is because send-rate of ACKs are not controlled by the endpoint. It is controlled by the peer that is sending data.

Up until now, CC is per-direction. An endpoint sends data at a rate controlled by ACKs sent by peer in response. The other side does the same thing, individually.

While I do not dispute the fact that *ideally* we should take the loss of ACK-only packets into consideration, my argument is that we are not at that point (yet), because we do not control the send-rate of ACK-only packets.

Using the loss of ACK-only packets without controlling the send-rate of ACK-only packets based on their loss essentially means that we are going to prioritize emission of ACKs above data. This would be a departure from the per-direction CC design that we have now.

As I stated in my previous comment, I am concerned about the negative impacts that the change in design might cause.

-- 
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/3451#issuecomment-585037874