[quicwg/base-drafts] Complicated Retransmission Corner Cases (#765)

[martinduke <[e-mail]>]

The basic case for retransmission is pretty straightforward. I detect a packet loss, so I take all the stuff in that packet and send it in a new packet. There has to be some sort of data structure in the PCB to track what's in the packet. I can clear that data structure once the packet is acked.

There are two ambiguities here:
(1) How long do I hold on to the packet data if lost? I can delete it immediately, hold it for _n_ retransmissions, or hold it until all acks and data in the packet are acked.

Deleting it immediately is very simple, but if the ack comes back for that packet later and the first retransmission is lost, I will needlessly resend that data.

Offline, Jana suggested keeping it for 1 retransmission. That is fine with me (minus the second item below) but I think some implementation guidance on when it is acceptable to throw away old packet data would be helpful.

(2) More importantly, fitting the whole retransmission into a single packet does not hold in the general case. There might be an MTU change; the updated ack might be bigger; optimizers like me might want to aggregate multiple small packets into a single retransmission; some ack frames might be supersets of other ack frames, so although there is no direct retransmission relationship acking one of those packets might obviate the ack frame of the other.

What all this implies is a many-to-many mapping where every time data or acks are acked, we have to clear that from all other packets that contain it. I started down this road before seeing that it was way too hairy to continue.

****

So we're at a point where the optimal wire performance -- never throw it away until acked, allow mix-and-match of retransmissions -- is close to unimplementable. Some implementation guidance about what it's OK to not worry about, and perhaps some judicious prohibitions on particularly gnarly stuff, might help some.

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