Subject: Re: [quicwg/base-drafts] Extension frames and congestion/flow control (#1811)

From: ianswett <[email-masked]>
Date: Mon, 01 Oct 2018 06:23:01 -0700

How would it prevent an unreliable stream?

The reason you don't acknowledge ACKs is that it can cause the connection to never go idle, or to take a long time to do so.    Additionally, ACK only packets don't count towards congestion control.

I don't want non-ACK frames to be excluded from congestion control unless doing so could cause a connection deadlock or some other major issue.  If a frame is congestion controlled, it should cause an ACK to be sent at some point(ie: at least once per RTT, but probably more), otherwise the congestion controller never gets any feedback.

Allowing a reduced rate of ACKs for frames which are not reliable is sensible, and is what the DATAGRAM proposal recommends.

-- 
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/pull/1811#issuecomment-425905564

---

From: Rui Paulo <[email-masked]>
Date: Mon, 01 Oct 2018 09:15:16 -0700

Yes, I'm not talking about ACKs for ACKs.

I believe there are two cases for unreliable streams:

1) Send and forget about the data itself but save metadata in memory: this is the case you're talking about and it's used to grow the cwnd when an ACK arrives.  It increases  bytes_in_flight.

2) Send and forget about everything: this is the more basic approach where sending doesn't elicit an ACK. I'm not sure if it should increase bytes_in_flight, but it should respect cwnd.  

Obviously 1) is better and I also prefer it for DATAGRAM streams.

I'm just wondering if the text isn't too restrictive since we're really talking about an extension.  Imagine an extension that improves the ACK frame but doesn't replace it (ACK_ECN comeback? :-)).

It's true that implementations can break these rules and implement private extensions that don't require ACKs.

P.S.: It looks like PADDING increases bytes_in_flight. This is confusing because bytes_in_flight will increase but nothing prevents a QUIC stack from just sending PADDING in one packet which would never be ACK'ed and bytes_in_flight won't ever be zero again. This would put us in perpetual loss detection mode.  Does that make sense?

-- 
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/pull/1811#issuecomment-425967750

---

From: Mike Bishop <[email-masked]>
Date: Mon, 01 Oct 2018 10:03:34 -0700

To your PS, I think the lack of clarity is the difference between "gets ACK'd eventually" and "elicits an ACK".  If you receive a packet with only PADDING and ACK, that doesn't elicit an ACK immediately.  However, when you do eventually sent an ACK, that packet is included in the range of acknowledged packets, which enabled bytes_in_flight to return to zero.

-- 
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/pull/1811#issuecomment-425984645

---

From: ianswett <[email-masked]>
Date: Mon, 01 Oct 2018 10:52:29 -0700

I'm of the opinion that even though QUIC can enable 2), it's neither a typical use case nor the one we should encourage, since I don't think it's feasible to respect CWND if you don't increase bytes_in_flight.

There's a specific exception in the text for ACK frame replacements and supplements:  "The exception is extension frames that replace or supplement the ACK frame."

PADDING is weird because people requested it behave as it does.  Admittedly, if it didn't have it's current behavior of increasing bytes_in_flight without eliciting an ACK, it would be identical to the PING frame.  It's certainly a potential footgun and there's some text in recovery noting that, though it could be a little stronger: "Note that this means PADDING frames cause packets to contribute toward bytes in flight without directly causing an acknowledgment to be sent.

-- 
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/pull/1811#issuecomment-426001039

---

From: MikkelFJ <[email-masked]>
Date: Mon, 01 Oct 2018 11:01:51 -0700

Can you deadlock on sending PADDING between endpoints? Perhaps a very slow death?

-- 
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/pull/1811#issuecomment-426004278

---

From: ianswett <[email-masked]>
Date: Mon, 01 Oct 2018 11:46:28 -0700

I'm not aware of any deadlocks, but you could end up stalled until the TLP fires.

-- 
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/pull/1811#issuecomment-426019089

---

From: Rui Paulo <[email-masked]>
Date: Mon, 01 Oct 2018 12:48:27 -0700

Oh, yes, it already says "supplements".  I've thought about this more and yes I agree it's fine the way it is right now.  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/pull/1811#issuecomment-426038829