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

[Toerless Eckert <[e-mail]>]

On Wed, Mar 06, 2024 at 01:05:08PM -0800, Tom Herbert wrote:
> Toerless,
> 
> The flow label is not usable and not a waste of header bits as some would

Do you meaan "unusable" ?

> seem to believe. It carries flow entropy that we use anywhere in the
> Internet (for ECMP, RSS, filtering, etc.,)

I know. But see Joel's Pechakucha re. problems arising when differnt devices in the
same nework have different understandings what exactly to do with a flow label.
That's why i am agreeing with his conclusion from back then to stop using it
in this "randomn interpretation" fashion (i do ECMP, you do RSS, he does filtering *aaarrrgghh*).

> It think what you want is a generic way to repurpose the flow label bits.
> IMO, that's going to be difficult.

I'd be happy to have an argument about that technically. I don't think it's true.
IETF stance re. standardizing something like that is of course a different issue,
but if the inability to find a technical issue counts...

But i don't think that for my QoS interests i would even need to go down to such
big changes. It would suffice for the QoS header to determine and override any of
the actions associated with the flow-label in any pre-existing (and inconsistent)
implementations. And of course, one could think of the flow-label then not
be solely a random big number without specific semantic other than hoping to
be an as unique as possible ID, but more like a structured classification of the
flow (which i am sure has also been done in before).

Cheers
    Toerless
> 
> Tom
> 
> 
> > Cheers
> >     Toerless
> >
> > > Tom
> > >
> > > >
> > > > Cheers
> > > >     Toerless
> > > >
> > > >
> > > > > Tim
> > > > >
> > > > > > Cheers
> > > > > >    Toerless
> > > > > >
> > > > > > On Tue, Mar 05, 2024 at 10:31:09AM -0800, Tom Herbert wrote:
> > > > > >> On Tue, Mar 5, 2024 at 6:41 AM Tim Chown
> > > > > >> <Tim.Chown=[e-mail]> wrote:
> > > > > >>>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> On 4 Mar 2024, at 23:02, Tom Herbert <tom=
> > [e-mail]> wrote:
> > > > > >>>
> > > > > >>> On Mon, Mar 4, 2024 at 12:37 PM Toerless Eckert <[e-mail]>
> > wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> Dear 6MAN-WG:
> > > > > >>>
> > > > > >>> I have just posted an extremely rough draft
> > draft-eckert-6man-qos-exthdr-discuss, to help start a discussion
> > > > > >>> about common IPv6 extension headers for (mostly) stateless QoS
> > beyond what we can do with just DSCP.
> > > > > >>>
> > > > > >>>
> > > > > >>> Hi Toerless,
> > > > > >>>
> > > > > >>> You might want to look at draft-herbert-fast and
> > > > > >>> draft-herbert-host2netsig. It looks like these have similar
> > goals.
> > > > > >>>
> > > > > >>>
> > > > > >>> And that is similar in spirit to what the CERN experiments are
> > doing with flow label semantics, which would/could be HbH header
> > information if then insertion penalty were not so high.
> > > > > >>
> > > > > >> Hi Tim,
> > > > > >>
> > > > > >> The CERN experiment might be okay as an experiment, but
> > overloading
> > > > > >> the twenty bit information of flow label is neither scalable nor
> > > > > >> standardizable. This is especially true for those proposals that
> > want
> > > > > >> to set some bits differently within the same flow and expect that
> > > > > >> routers will ignore those bits for ECMP hash.
> > > > > >>
> > > > > >> I am interested in what you mean by " if then insertion penalty
> > were
> > > > > >> not so high".
> > > > > >>
> > > > > >> 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]
> > > > >
> > > >
> > > > --
> > > > ---
> > > > [e-mail]
> > >
> >
> > --
> > ---
> > [e-mail]
> >

-- 
---
[e-mail]