Re: [EToSat] What we are looking for from QUIC

[Ted Hardie <[e-mail]>]

On Tue, Dec 3, 2019 at 11:52 PM Kuhn Nicolas <[e-mail]> wrote:

>
>
> *Considering FEC in QUIC has been proposed in NWCRG
> [https://tools.ietf.org/html/draft-swett-nwcrg-coding-for-quic-03
> <https://tools.ietf.org/html/draft-swett-nwcrg-coding-for-quic-03>] but it
> looks like going further in this discussion needs to consider the impacts
> between FEC and loss-based congestion control [which we tried to initiate
> in https://tools.ietf.org/html/draft-kuhn-coding-congestion-transport-00
> <https://tools.ietf.org/html/draft-kuhn-coding-congestion-transport-00>].
> If the congestion control is delay based, life is easier but otherwise,
> distinguishing congestion and random losses is a chimera to me, if there is
> no efficient in network signaling.  *
>
I think it's worth noting here that there are two basic design approaches
possible within the QUIC context.  In one, you add FEC capabilities to QUIC
itself, so that there are standardized transport methods of doing data
recovery without retransmission.  In the second, you layer a FEC-capable
application on top of QUIC's basic acknowledgement mechanisms and allow it
not to acknowledge data loss when FEC has recovered the data for the
application.  The first strategy ensures it is available; the second
ensures the FEC methods chosen match the application's needs as closely as
possibly (including, possibly, no FEC at all).

In the context of real-time communication, we've often seen FEC schemes
vary in suitability by the codecs in use, so we've tended to avoid making
over-arching selections for any general purpose system.  If we're going to
do something similar when those are layered on top of QUIC, I think loss
based congestion control will need what amounts to control frames that
distinguish between "data you should send again" and "data I didn't receive
but there is no need to send again".  From a design perspective my question
is whether those are the same messages you would use to tune the FEC or
different messages.  It would be handy if the same messages could tell the
application to change the K in a K-of-N FEC and tell QUIC something about
how much loss along the path is being absorbed by the FEC data recovery.

I agree that without network signaling there is very little you can do to
directly assess the source of loss.  You can sometimes infer it from jitter
when you have radio networks which do lower-layer retransmission to recover
losses, as the recovery at that layer is seen as jitter at the IP layer,
but it isn't a real good signal as path changes can give the same signal.
I think, though, that this is one of the reasons delay-based congestion
control is seeing more utility as we see more and more paths have at least
one radio link.

regards,

Ted Hardie