Subject: [quicwg/base-drafts] bytes_in_flight for TLPs and RTOs (#790)

From: Marten Seemann <[email-masked]>
Date: Sat, 23 Sep 2017 11:26:38 +0000 (UTC)

Currently, `bytes_in_flight` is only reduced in two cases: when the packet is acked, and when `DetectLostPackets` detects a packet as lost.
This leaves TLPs and RTOs uncovered. Shouldn't be `bytes_in_flight` reduced in those cases as well?

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

---

From: ianswett <[email-masked]>
Date: Mon, 25 Sep 2017 00:50:07 +0000 (UTC)

There is no need to reduce bytes_in_flight for a tail loss probe.  There is no RFC for TLP, only this experimental draft: https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01, but salient text would be 
  "TLP unifies the loss recovery mechanisms regardless of the position
   of a loss, so now with TLP a segment loss in the middle of a train as
   well as at the tail end can now trigger the same fast recovery
   mechanisms."

Traditionally, RTOs declared all packets in flight lost.  Because in QUIC there is always an unambiguous larger packet being acked for an RTO, I don't believe it should be necessary to ever declare packets lost when an RTO occurs, but I can imagine there being a problem with a large reordering tolerance combined with the reduction in CWND 'stalling' the connection.

Ideally, I'd like to unify TLP and RTO in QUIC and remove the reduction of CWND to min_cwnd(Which BBR already does), but I don't have a proposal for that I'm sufficiently happy with yet.

-- 
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/790#issuecomment-331752085

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 27 Sep 2017 16:02:03 -0700

TLP is not a loss, so you wouldn't reduce bytes in flight. It's very tempting to treat TLP as a loss and we had a bug as a result of this, but don't :)

-- 
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/790#issuecomment-332679669