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 02:59:57PM -0800, Tom Herbert wrote:
> On Wed, Mar 6, 2024 at 2:30 PM Toerless Eckert <[e-mail]> wrote:
> >
> > On Wed, Mar 06, 2024 at 01:10:06PM -0800, Tom Herbert wrote:
> > > > 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.
> >
> > The Option Type identifiers are internally encoded such that their
> > highest-order 2 bits specify the action that must be taken if the
> > processing IPv6 node does not recognize the Option Type:
> >
> >       00 - skip over this option and continue processing the header.
> >       01 - discard the packet.
> >       10 - discard the packet and ..
> >       11 - discard the packet and ..
> >
> > What am i overlooking ?
> 
> >From RFC8200:
> "NOTE: While [RFC2460] required that all nodes must examine and
> process the Hop-by-Hop Options header, it is now expected that nodes
> along a packet's delivery path only examine and process the Hop-by-Hop
> Options header if explicitly configured to do so."

Right. So my thinking seem to only work if the nodes do support / enable
either HbH Options or Destination Options header and we insert a new option,
because then the text i was citing from RFC8200 would apply.

iI think the other approach to "better" use flow-label would be if one
can make the argument that the new encoding of information is reasonably
backward compatible. I think this is what the CERN experiment attempts
to achieve by having some amount of entropy bits.

Cheers
   Toerless


> Tom
> 
> 
> 
> >
> > Cheers
> >     Toerless
> > >
> > > 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]
> > > >
> >
> > --
> > ---
> > [e-mail]
> 

-- 
---
[e-mail]