Re: [IPv6] 6MAN: looking for feedback to draft-eckert-6man-qos-exthdr-discuss (Re: New Version Notification for ...)

[Tom Herbert <[e-mail]>]

On Wed, Mar 6, 2024 at 12:04 PM Toerless Eckert <[e-mail]> wrote:
>
> On Wed, Mar 06, 2024 at 11:45:14AM -0800, Tom Herbert wrote:
> > Much better to set them on the
> > socket (still working to get full Linux support for that).
>
> Whats the current state of this. Work, but requires admin privileges ?

I have the patches, just need to find the time take another run to
push them upstream...

>
> Unfortunately, i don't think we can point Linux kernel folks to an IETF RFC
> that explains that applications sockets should in IETF opinion be permitted to
> set extension headers. And i am not sure that if we tried to write it,
> everybody even here in 6MAN would agree. We've never scoped functionality
> of extension headerws around what "untrusted" applications should likely
> be allowed to do. That would be a useful exercise IMHO.

That's okay, Linux kernel folks never look at RFCs for sockets APIs
anyway ;-) In any case, I'm the most likely person to do this work
(there might be a couple of others but I work closely with them).

>
> Of course, it would be better if linux had a better than "all in" control option,
> but have not tried to figure out what best access schema to use. As an ETOOOOLD
> hacker i'd probably create a magic group exthdr, and only if the process has that
> that group would extension header setting be permitted ;-))

The patch set has pretty good controls to maintain control over what
users can put in packets down to at least specific option types. If
you're interested, I can send a link to the patches offline.

Tom

>
> Cheers
>     Toerless
>
> > Tom
> >
> > >
> > > Tim
> > >
> > > Tom
> > >
> > >
> > >
> > > https://www.ietf.org/archive/id/draft-cc-v6ops-wlcg-flow-label-marking-02.html
> > >
> > > And there are others, each doing something slightly different, when we’d ideally have one EH to rule them all.
> > >
> > > Tim
> > >
> > >
> > > Right now this is a discussion draft not intended to become RFC because it's my impression that the
> > > 6MAN community might benefit from some useful summary of how DetNet (and potentially other WGs) might
> > > use this work, but this would not be part of a final spec draft, and likewise i have a wide range of
> > > open questions instead of answers, and i included those questions into the draft seeking for feedback from
> > > 6MAN.
> > >
> > > Overall, i didn't want to go down a possible rabbit hole of working on details of the spec if it just
> > > turns out to involve insurmountable IETF process obtacles to go this route. For example, we could continue to
> > > standardize all advanced forwarding functions only into MPLS and ignore IPv6 as DetNet has done so far
> > > (*mumble ;-).
> > >
> > > The lack of such extension headers has IMHO held back innovation into better (stateless) QoS, especially
> > > in many controlled networks since at least 25 years, for example when draft-stoica-diffserv-dps
> > > was abandomed because it was too painfull trying to get to through all the IETF IPv6 bureaucracy -
> > > for just one algorithm, when there are so many that would deserve experimentation in specific
> > > networks. But given the good recent/ongoing work for example into  I-D.ietf-6man-hbh-processing,
> > > i would hope that we're closer now to actually wanting our extensibility of IPv6 actually be used
> > > by the industry (instead of all this happening only in MPLS).
> > >
> > > With DetNet we are too in the situation that we have multiple candidates on the table and IMHO
> > > it will not be very useufl trying to run a lottery for a single "winner" and standardize just that.
> > >
> > > I have seen a lot more success in the industry by just letting different algorithms compete with
> > > each othrer in products and let the market decide. That was quite a lot happening in e.g.: packet
> > > scheduling in routers at least since the end of the 90th when in my impression every new
> > > hardware forwarding router implemented it's own new packet scheduler based on the just hired lead
> > > engineers PhD thesis. And over a period of 20 years, a lot of commonality and industry
> > > knowledge evolved in that space. For this type of scheduling, this innovation was possible because it did not
> > > require new packet headers, but just a lot of (ab)use of DSCP and/or more or less horrenduous
> > > QoS configurations. But for those solutions that do require additional in-packet-QoS metadata,
> > > we never created a viable method where it was easy for the  innovators/implementers to concentrate
> > > on the novelties of the algorithm in question and get all the knucklehead "how to packetize and what generic
> > > requirements/functionalities" be provided as much as possible by an existing framework/RFC.
> > >
> > > So, i'd be very happy to find interest to help progress this work, aka: writing something
> > > that ultimately would become a draft-ietf-6man-common-qos-exthr or the like. I have tentatively
> > > asked for a slot for IETF119 6MAN to present and get feedback, if you think that would be time well
> > > spent, pls. chime in.
> > >
> > > Cheers
> > >   Toerless, for the authors
> > >
> > > On Mon, Mar 04, 2024 at 12:30:53PM -0800, [e-mail] wrote:
> > >
> > > A new version of Internet-Draft draft-eckert-6man-qos-exthdr-discuss-00.txt
> > > has been successfully submitted by Toerless Eckert and posted to the
> > > IETF repository.
> > >
> > > Name:     draft-eckert-6man-qos-exthdr-discuss
> > > Revision: 00
> > > Title:    Considerations for common QoS IPv6 extension header(s)
> > > Date:     2024-03-04
> > > Group:    Individual Submission
> > > Pages:    27
> > > URL:      https://www.ietf.org/archive/id/draft-eckert-6man-qos-exthdr-discuss-00.txt
> > > Status:   https://datatracker.ietf.org/doc/draft-eckert-6man-qos-exthdr-discuss/
> > > HTMLized: https://datatracker.ietf.org/doc/html/draft-eckert-6man-qos-exthdr-discuss
> > >
> > >
> > > Abstract:
> > >
> > >  This document is written to start a discussion and collect opinions
> > >  and ansers to questions raised in this document on the issue of
> > >  defining IPv6 extension headers for DETNET-WG functionality with
> > >  IPv6.
> > >
> > >
> > >
> > > The IETF Secretariat
> > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [e-mail]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
> > >
> > >
> >
>
> --
> ---
> [e-mail]