RE: [EToSat] Re-chartering for extension work

[Kuhn Nicolas <[e-mail]>]

Hi,

Thanks for your feedback – it helps us very much.
See inline for some comments to your email.

Cheers,

Nico

De : Christian Huitema <[e-mail]>
Envoyé : mardi 17 décembre 2019 20:49
À : Ian Swett <ianswett=[e-mail]>; Kuhn Nicolas <[e-mail]>
Cc : Gorry (erg) <[e-mail]>; [e-mail]; Mark Nottingham <[e-mail]>; [e-mail]; Lars Eggert <[e-mail]>; IETF QUIC WG <[e-mail]>
Objet : Re: [EToSat] Re-chartering for extension work


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.

[NK] I think that 0RTT document is not focusing particularly on satellite (even if it was driven by a satellite use case at the beginning). If QUIC is used as a tunneling solution, there may be a large BDP and a connection would be bi-directional transmission of data. In this case, sharing information from the client and the server could be beneficial. Another thing is the optimization of asymmetric links that is not specific to satellite – see my comment below.

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.

[NK] Thank you for these feedback. We have indeed provided regression tests in the QUIC 4 SAT document. We plan on showing some results at next IETF. We also plan to provide referenced values for each test.

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.

[NK] One thing that is not particularly related to satellite but to asymmetry in general could be done through the 0-RTT proposed extension – such as we proposed in the section 5 of the current version https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-05#section-5 .

-- 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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/etosat