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, 12:21 PM Toerless Eckert <[e-mail]> wrote:

> On Wed, Mar 06, 2024 at 12:04:45PM -0800, Tom Herbert wrote:
> > Toerless,
> >
> > Right, the flow label is already allocated to be twenty bits of flow
> > entropy and there's no standardizable means to repurpose the bits.
>
> Lets first look at technical points:
>
> If my packet has e.g.: my new QoS HBH header mandatory, a router not
> supporting that HBH header
> will discaard it.


I don't believe that's feasible, with RFC8200 even HBH Options is not
mandatory to process. A router can forward a packet just by inspecting IPv6
header with no regard as to what the next header is.

Tom




So it does not matter what tht router would have done with the flow label.
> And when the router adds support for that QoS HBH header, then the spec
> for that HBH header
> could say: ROUTER MUST NOT PERFORM WHATEVER  FLOW-LABEL PROCESSING IT
> THOUGHT WAS RIGHT, but only
> what the spec for that HBH header says.
>
> Stds wise this would mean the HBH header is an update to RFC8200 given how
> i don't think we have
> a more current spec for it.
>
> True/False/Thoughts ?
>
> > > > > The goal of the extension header i am proposing does include the
> feature to allow failure of
> > > > > QoS experiments, even those we may have worked to standardize (as
> opposed to experimental, informational etc..).
> > > >
> > > > Why limit it to QoS?  Why not make it a general “host to network
> signalling” capability?
> > >
> > > Divide and conquer.
> >
> > I think of host to network signaling as being a signal carrier and
> > signal content. Logically, what we want is one common carrier that can
> > carry different types of signals for different purposes. FAST is a
> > proposal for such a common carrier. It defines one new HBH option type
> > and has a base header format that includes a type field that describes
> > the format of the rest of the option contents (i.e. the signal
> > content).
>
> Sure, but that point does not address the issue i mentioned in that i
> would not want to enable
> FAST processing on P nodes, because its for example to complex, so enable
> it only on PE nodes, but
> the QoS functions i do want to enable on P nodes. Hence it seems i'd have
> a lot more complexity
> to manage if both where in the same HBH.
>
> > > But one of the results of having gained gaining experience is that
> some options may have been burned now,
> > > and may need to be redefined to serve their purpose best. Such as for
> example if we want to add flow label
> > > to IPv4, i think we're not at the stage of knowing a single target
> semantic, but we know that multiple
> > > semantics would conflict. So at best IMHO if we where to introduce
> flow label into IPv4, then it should
> > > have an additional multiplexer. But that would then create a better
> IPv4 solution than IPv6. Aka: i'd rather
> > > only do that after we have an IPv6 extension header for QoS that
> provides the same or superset function.
> >
> > Agreed. This is the point of draft-herbert-ipv4-eh. The goal is to
> > backport features like EH and flow label into IPv4, not to improve
> > upon them. If we make such features work better in IPv4 than IPv6 then
> > that makes transitioning to IPv6 more difficult which is really the
> > ultimate goal.
>
> Its just that we don't have a working interoperable Internet scope
> solution for Flow Label in IPv6,
> but at best working experiements in well controlled networks such as this
> CERN experiment. And that
> should mean something for what we write about it in your IPv4 extension
> header doc.
>
> > > Not 100% sure, but i think the risk of functional collision for Flow
> Label is smaller for packets with
> > > a new mandatory to support extension header. Therefore it might be
> possible to assign new semantics
> > > to the Flow Label for packets with such extension headers without
> creating deployment clasehes
> > > (to avoid wasting the 20 bits).
> >
> > That would be really difficult, there are two many devices that have
> > already burned in semantics of flow label. Besides, if interpreting
>
> Well... how would those devices work in a network using the CERN method ?
> Aka: any hard-burned
> semantics is a problem anyhow, especially because we as IETF wouldn't know
> for a standards track
> document like yous (AFAIK) be able to specify that functionality.
>
> But we can always override semantic for "new packets". Thats for example
> what we did for IPv4 Multicast. Those where packets with previously
> unassigned addresses, and
> when those are used, the whole semantic of forwarding changes for the
> packet and the
> interpretation of destination address. Likewise do i see no reason to now
> think along the same
> ways when i add a HBH header and hence change the meaning of flow-label
> for those fields.
>
> > the flow label correctly requires an EH, why not just put the
> > information in the EH and avoid touching the flow label?
>
> Sure. Is it worth the trouble saving 20 bits... ?
> But i see it differently: I always liked the idea of flow-label, so i'd
> hate for an unusable
> header to lay around in our base header in IPv6, and should your work
> progress equally in IPv4.
> It's ugly! ;-) So lets figure out how we could make best use of it...
>
> 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]
>