retransmission vs. loss?

[mirjak]

We have an Excessive retransmissions event (section 7.3.2) which says this is only available for reliable transport. However, QUIC with datagram would also be able to generate a loss notification (even though data would not be retransmitted as there are ACKs anyway). Shouldn't this be an Excessive loss event instead?

[abrunstrom]

I think we are making things to complicated now. I think we should leave the excessive retransmission for reliable transport. Talking about excessive loss there sounds awkward to me. Excessive loss sound more like multiple packets in a row (with possibly different content) being lost.

Then we can add a loss notification event if we want, but then that should just apply to a single packet and a single loss.

Maybe this is similar to what @mwelzl was saying in the pull request #650 but I found it hard to parse how that mapped to what was actually happening in the text updates.

[gorryfair]

I thought this was interesting to think through. However, after now thinking I'm really unsure "excessive loss" is a clear signal to provide or that it is desirable.

After thinking I also really do not like "excessive retransmissions". This isn't well defined. Is that a count of packets retx, losses, congestion events, whatever. Is this for the lifetime of the connection, or per RTT, or something in between. And finally what can application usefully do with this? If it is multi-streamed is this for the aggregate connection or the stream, and how does the app react in each case? Some transports don't tell you (or can't) and then how does the app. react? Then why not "excessive congestion" for cases with ECN or where FEC was used in some way? What does "excessive" mean wrt to audio? etc? To me, there are far too many questions to yield a useful signal.

My feeling is that this has its origins in RFC1122, from an old style Internet and should be safely consigned to the same fate as the unhelpfully ambiguous "source-quench". Both are a bad idea.

QUIC appears to complicate things, in reality this topic was already very complex for RTP, use of FEC, and SCTP, etc I think it is unhelpful to expose a signal that has no clear semantic or interpretation.

Can we please remove this from the API?

[abrunstrom]

If we want to remove it I have no objections, specific applications could always add something like this as extra functionality if they want. If we keep it, I agree we need to make it more clear.

[mwelzl]

Sorry, I think this was hard to see because it was scattered across text updates in the PR - but: if all my text updates are accepted, we'd be left with the following:

1. a notification of loss,
2. a retransmission threshold to notify about 1), which is only relevant for reliable transfers (this covers the RFC 1122 TCP thing).

Item 1) can be about a Message. The complex cases for RTP, FEC etc. are about signaling the right information back from the receiver - but this can be about every individual Message. Then, an application can construct a metric itself, like loss-per-second or max-number-of-consecutive-lost-messages-during-the-last-minute or whatever. Because it's an event, it's also easy to ignore.

Is that not easy enough? Again, if you like it, all my proposed text updates together already achieve this. Possibly, an efficient way to do it could be to accept them and merge the PR, and then fine-tune the text more if you want - if you agree with the general approach at all.

If we want to throw it out, sure, we can do this too... but I'm sceptical about throwing out useful QUIC abilities that TAPS users may want.

[mirjak]

We discussed this at the interim and decided to remove the excessive retransmission notification entirely.