Subject: [quicwg/base-drafts] Do retransmissions of STREAM frames need special prioritization rules (#114)

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Jan 2017 21:15:01 -0800

When talking about priority in #104, the question arose.  Say you have two streams and a STREAM frame to send on each, but only enough capacity to send one (due to flow control, congestion, or whatever).  Prioritization information helps us answer this question.  But what if the message is a retransmission of a packet that was determined to be lost.

I think that the right answer has to do with tracking how long since a packet was originally given to QUIC to send.  And that we don't necessarily need to concern ourselves with whether it was sent previously or not - that will shake out in time anyway.  If it was sent before, it was obviously high enough priority to be worth sending once already.

That said, the value of repairing a gap in a stream is pretty high in terms of the ration of bytes delivered to bytes transmitted, so that might have some say.

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 12 Jan 2017 22:38:25 -0800

In addition to repairing gaps in stream data, I think there are two more important point when it comes to prioritizing retransmissions:
* if the lost packet contained a WINDOW_UPDATE, the peer might become flow control blocked, although the sender has already committed to receiving more data. This is particularly severe if the WINDOW_UPDATE increases the connection-level flow control window
* if the lost packet contained a RST_STREAM, the peer might continue sending data on a stream that the sender is not interested in at all

For these reasons, we always prioritize retransmissions in [quic-go](https://github.com/lucas-clemente/quic-go).

I'd be in favor a sentence like the following (maybe in the [Packetization section](https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md#packetization-and-reliability-packetization)):

> A sender SHOULD give priority to any retransmittable data over transmitting new stream data.

Just another quick remark to your issue: flow control can *never* limit the capacity for sending a retransmission.

-- 
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/114#issuecomment-272372459

---

From: ianswett <[email-masked]>
Date: Fri, 13 Jan 2017 09:39:24 -0800

I would agree with Marten's suggested addition of "A sender SHOULD give priority to any retransmittable data over transmitting new stream data."

This is also what the proto-quic/Chromium implementation does.  I wouldn't spend a lot more text on it, because I don't think there's a reason to add MUSTs for retransmissions prioritizaion.

One note you reminded me of Marten is that WINDOW_UPDATES are currently retransmitted, but since they're cumulative, it's possible they should be treated more like ack frames.

-- 
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/114#issuecomment-272499042

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Jan 2017 13:12:07 -0800

I think that @marten-seemann gave good reasons to increase priority of WINDOW_UPDATE and RST_STREAM, not arguments for increasing priority of retransmissions.  Retransmission of STREAM frames for low priority streams doesn't make as much sense in my view.

-- 
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/114#issuecomment-272724093

---

From: mirjak <[email-masked]>
Date: Mon, 16 Jan 2017 02:17:44 -0800

I agree that resets and other control information should be re transmitted as quickly as possible. However, data frames could be retransmitted based on their frame priority.

-- 
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/114#issuecomment-272822608

---

From: Marten Seemann <[email-masked]>
Date: Mon, 16 Jan 2017 02:44:54 -0800

Streams currently don't have priorities in QUIC (there's a separate discussion about that in #104).
Even if they had, I'd argue that retransmitting lost stream data should be prioritized in some way, since a gap in stream data blocks the application from reading from that stream (and from advancing the flow control window, which might in consequence lead to this stream becoming blocked).
However, since the suggested addition here is a SHOULD, this is an implementation detail, and we don't have to worry about that here (unless we change it to a MUST).

-- 
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/114#issuecomment-272828558

---

From: ianswett <[email-masked]>
Date: Mon, 16 Jan 2017 05:15:24 -0800

+1 to marten's excellent clarification.  

This of course could change if prioritization moves into the QUIC transport from the H2 layer, but I think that's a much longer conversation.

-- 
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/114#issuecomment-272859200

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jan 2017 17:36:45 -0800

I don't think that we have to wait for the prioritization discussion to conclude.  QUIC can certainly be priority-aware even if it doesn't innately provide the messages that set priority.

I think that @marten-seemann is right to observe that retransmitting data is potentially more valuable than sending new ones.  But only if you are ignorant of priority.  Repairing a gap could end up freeing a large amount of data, which could be a great return on investment.  In an extreme example, retransmit a lost 10 octets and the receiver can now play out a megabyte of HoL-blocked data.

On the other hand, if the other side didn't want that data because that stream was dependent on a higher priority stream, it's still wasted effort.  For a concrete example, imagine that you are streaming video and two streams have consecutive chunks.  If there is a backend issue that delays the first chunk, you still want to send the second.  However, if a piece of the second goes missing while the backend is catching up, you have a choice between repairing chunk 2 or sending chunk 1.  You don't want to repair chunk 2 *unless* the flow control credit it releases is critical (it might be).

-- 
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/114#issuecomment-272999753

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Jan 2017 22:50:45 -0800

As discussed in Tokyo, only advisory text on what implementation might want to do

-- 
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/114#issuecomment-275032623

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Jan 2017 22:54:17 -0800

Advisory text might include:
1. priority might inform the choice of what packets are sent, including retransmissions
2. retransmission could result in greater utility than transmission of new packets because it allows any buffered by undelivered packets to be freed up from flow control windows
3. when flow control space is low, retransmissions might be preferred to avoid stalling
4. poor or suboptimal implementation of this will eventually resolve itself because retransmission is always possible, if the flow control window is closed, then you can always repair gaps

-- 
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/114#issuecomment-275033093

---

From: krasic <[email-masked]>
Date: Tue, 24 Jan 2017 23:01:03 -0800

My two cents:

If an application is very performance oriented, it should be responsive to data arriving and draining quickly, flow control should not be the limiting factor in that case.     OTOH, if an application is performance oriented and gone to the trouble of expressing priorities, it should expect those to be honored.   So in my opinion, I think expressed priorities should trump, and retransmission of lower priority data over newer higher priority data would be a mistake.

-- 
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/114#issuecomment-275033971