Subject: [quicwg/base-drafts] Pakcet loss problem in Quic (#4433)

From: LyraWang <[email-masked]>
Date: Wed, 09 Dec 2020 23:03:23 -0800

Quic protocol uses UDP to send packets, but I can't find the settings about UDP socket in the draft.
I checked [MVFST](https://github.com/facebookincubator/mvfst), [msquic](https://github.com/microsoft/msquic) and [quiche](https://github.com/flyaways/quiche), and they all set a non-block socket. In my test, I found that it will cause a serious packet loss problem to quic. When detecting bandwidth or throw a burst of data to the socket, the sender will put too much data into the socket, and the non-block socket will not reject the data. It will discard these packets and return success to quic, which means quic can not realize  this packet loss until a PTO later. I think this is a very bad phenomenon.
Will this phenomenon be an attribute of quic, or is there any way to improve 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/4433

---

From: Lars Eggert <[email-masked]>
Date: Wed, 09 Dec 2020 23:17:47 -0800

The QUIC congestion controller will detect and react to packet loss incurred in the local stack just as it will to packet loss incurred in the network. So QUIC will not be affected by the issue you describe, which can only happen if you send high-rate UDP flows without congestion control.

-- 
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/4433#issuecomment-742293177

---

From: LyraWang <[email-masked]>
Date: Thu, 10 Dec 2020 00:51:43 -0800

> The QUIC congestion controller will detect and react to packet loss incurred in the local stack just as it will to packet loss incurred in the network. So QUIC will not be affected by the issue you…

In TCP, if there is no buffer space, the packet cannot be sent successfully. For TCP, this event is known immediately.
Quic's congestion controller can indeed detect packet loss in the protocol stack. As you mentioned, it is the same as  packet loss incurred in the network, which means that packet loss in the protocol stack will also take some time to be detected.
Most of the time, congestion controller can control to avoid sending UDP packets too fast.
When BBR is implemented in quic, in its bandwidth probe stage, it may send data at a speed greater than the bottleneck bandwidth and last for a while, and the risk of packet loss at the stack will increase. If the cubic is implemented without a uniform sending rate, due to data burst, packet loss at the stack may happen and it may result in the decline of the congestion window. In my test, cubic in quic can hardly perform as good as it's in tcp. In addition, I think the higher packet loss risk will impede the update of flow control window.
In my test, packet loss rate of quic will be much higher than TCP within the same network environment, maybe my congestion control algorithm is not good enough.

And I found lager send buffer will relieve this problem, and a more uniform sending rate will help. When I set the socket to block mode, there comes no packet loss in stack any more, it may not appropriate that way.

-- 
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/4433#issuecomment-742376886

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 Dec 2020 01:18:39 -0800

I take it your stack does not pace?

-- 
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/4433#issuecomment-742391745

---

From: LyraWang <[email-masked]>
Date: Thu, 10 Dec 2020 04:34:02 -0800

I'm not sure how to pace the stack, I set quic paced when testing bbr,  but the measured bandwidth of bbr is not accurate, since there's ack aggregation, the measured bandwidth sometimes may be larger than the real bandwidth, especially happened in connection with low latency(eg. 0.2ms).  And it's hard to design a pacer to send data perfectly uniformly. So even with a pacer, packet loss in the stack may still happen. 

In my cubic test with a pacer, there is still many stack packets loss.  Maybe it's because my pacer is not fine enough.

-- 
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/4433#issuecomment-742493508

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 Dec 2020 04:40:36 -0800

Are you on the [QUIC slack](http://quicdev.slack.com/)? You might want to ask the other developers there; this doesn't seem like a specification issue.

-- 
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/4433#issuecomment-742496447

---

From: LyraWang <[email-masked]>
Date: Thu, 10 Dec 2020 05:34:22 -0800

ok, I will try to ask it there. Thank you.

-- 
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/4433#issuecomment-742523959

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 Dec 2020 05:37:11 -0800

Please do! I am closing this for now; we can reopen the issue if it turns out to be that spec text improvements are 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/4433#issuecomment-742525329

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 Dec 2020 05:37:11 -0800

Closed #4433.

-- 
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/4433#event-4095145098