[netconf] Re: Open questions for quic-client-server

[Per Andersson <[e-mail]>]

On Wed, Mar 19, 2025 at 1:44 PM Marc Blanchet <[e-mail]> wrote:
>
>
>
> > On Mar 18, 2025, at 08:00, Per Andersson <[e-mail]> wrote:
> >
> > Hi!
> >
> > Regarding the quic-client-server draft, the following
> > things needs to be discussed.
> >
> > Should we generate IANA YANG modules for
> > quic-versions [0] and quic-transport [1] as basis for
> > QUIC versions and transport parameters used in
> > the YANG groupings?
>
> Looks sensible.

I put it as a question, but I think we should. :-)


> > Should all the transport parameters currently in the
> > draft be modelled, or should some be left out (e.g.
> > only model the permanent but leave out the
> > provisional)? If they should be kept, motivation might
> > needed for those that are not permanent in
> > quic-transport. [1]
> >
> > Should there be a possibiility to configure any
> > transport parameter by passing the raw transport
> > parameter, e.g. configuring arbitrary values?
>
> Responding to the last 2 paragraphs. Quic is evolving. We shall be able to update for more transport related parameters as they are defined by quic wg.
>
> I guess provisional is more a state where it was seen as needed but not yet fully standardized. However, if standardized or well implemented, not sure people take the time to request a status change in IANA.
>
> initial_rtt is paramount to be set for long delay connections (like deep space). Setting it is supported in the API as transport config by Quinn and there is a PR against Neqo for it, Cloudflare quiche is being updated for a PR too. Not setting it just make the connection not working at all for deep space use case.
>
> For our use case (deep space networking), the current "permanent" ones and initial_rtt are enough. However, there is min_ack_delay being provisional but is from draft-ietf-quic-ack-frequency which is in WGLC and will be used and relevant.
>
> So I don't have a good suggestion, but just the permanent ones are not enough.

I reviewed another generated IANA YANG module and they took
the entire parameter registry, with experimental parameters.
I think that is the sensible approach.

However, maybe it is too much to be able to push down
raw transport parameter values, if they are not in the
quic-transport registry. (Reflecting a comment I heard in
a session: that we should support current use cases,
not all possible future use cases.) FWIW both initial_rtt
and min_ack_delay is in the quic-transport registry as
provisional.


--
Per