Re: [EToSat] Re-chartering for extension work

[Christian Huitema <[e-mail]>]

The 0RTT draft is a simple extension defining new transport parameters.
It is a fine draft, but it is only part of the solution, and I don't
know whether we need to engage the charter extension process just for
that. IMHO if we start adopting "satellite" work in QUIC, we should
start by the problem statement rather than the proposed solution.
Nicolas, you have a draft in progress defining "satellite scenarios". I
think that would be a very good starting point.

I am half way through the work to make the picoquic implementation work
well on satellite, and I found the scenario definitions very useful. I
did find the issue mentioned by you, Emile, John and Gorry in your
presentations, but I also found a bunch of other ones. The high BDP
tests stress parts of the code that are not exercised in the other
scenarios, such as reordering out of sequence arrival of frame data in a
very long list of buffers, managing ACK-of-ACK when the SACK list is
long and full of holes, or performing spurious loss detection when the
list of repeated packets is much longer than usual. These are of course
purely implementation issues. Of course, other implementations may or
may not have these specific issues. Maybe they will find different
issues. But the point remains that having a good set of well defined
tests will advance support for the satellite scenarios.

Another issue that I found was dealing with high variance of RTT
measurements induced by asymmetry between the upload and download
capacity. Gorry presented the issue in terms of "load on the ACK path"
and suggested reducing the ACK rate, which should definitely be part of
the recommended solution. But this is not just a load issue, it also
impacts RTT measurements which in turn impact a variety of algorithms --
especially if the implementation relies on delay based congestion
control to be robust in the presence of random packet losses. I dealt
with the RTT measurement issue by defining a one way delay measurement
extension, which has other usages than satellite and might also be a
candidate for WG adoption -- once I manage to actually write it in a
draft of course. There may be more work required to deal with the asymmetry.

-- Christian Huitema

On 12/17/2019 7:37 AM, Ian Swett wrote:
> I think the satellite use case is an important one, but I have a
> number of concerns with the approach in that draft, so I don't believe
> it's ready for adoption.
>
> On Tue, Dec 17, 2019 at 12:29 PM Kuhn Nicolas <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi Mark, Lars,
>
>     Many meetings discussed the impacts of QUIC encryption on
>     satellite Performance-enhancing proxy (PEP) and the benefit of
>     exchanging additional transport parameters.
>     draft-kuhn-quic-0rtt-bdp was mentioned as a possible extension
>     during « Quick QUIC Update » presentation.
>
>     We have updated draft-kuhn-quic-0rtt-bdp-05 as an extension of QUIC.
>     We propose to include it in the re-chartering discussion.
>
>     Regards,
>     Nicolas, Emile and Gorry
>
>     https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvarea-quick-quic-update-mark-nottingham-00.pdf
>
>     https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-05
>
>     -----Message d'origine-----
>     De : QUIC <[e-mail] <mailto:[e-mail]>>
>     De la part de Mark Nottingham
>     Envoyé : mercredi 11 décembre 2019 22:38
>     À : IETF QUIC WG <[e-mail] <mailto:[e-mail]>>
>     Cc : Lars Eggert <[e-mail] <mailto:[e-mail]>>
>     Objet : Re-chartering for extension work
>
>     We've just put out Calls for Adoption for extensions to QUICv1, as
>     we believe that the group has some capacity to discuss them as it
>     finishes work on the core protocol.
>
>     However, our charter [1] precludes work on at least some
>     extensions. The specific text in question is:
>
>     """
>     Extensions that will support partial reliability, and negotiation
>     and use of Forward Error Correction schemes, are out of scope in
>     this version of the working group charter.
>     """
>
>     *If* we do decide we'd like to adopt, we'll need to update it to
>     something like:
>
>     """
>     Additionally, the Working Group will deliver [ adopted extensions
>     ]. The Working Group may consider other extension work, but
>     adopting further extensions requires updating this charter.
>     """
>
>     Please take a look and discuss any concerns; we'll be asking our
>     ADs for such a modification (with appropriate changes to the list
>     of extensions adopted) once our Calls for Adoption complete.
>
>     Cheers,
>
>     1. https://datatracker.ietf.org/wg/quic/about/
>
>     --
>     Mark Nottingham   https://www.mnot.net/
>
>
> _______________________________________________
> EToSat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/etosat