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 10:56:29AM +0000, Tim Chown wrote:
> Hi,
> 
> > On 5 Mar 2024, at 23:56, Toerless Eckert <[e-mail]> wrote:
> > 
> > Wrt to flow label, and that also goes a bit into the question of whether or how to stuff the
> > flow label back into IPv4 via Tom's draft (should we also inherit without additional warnings or
> > failsafes stuff that didn't work in IPv4 back into IPv4):
> 
> Well, not for the CERN experiments, as they’re a long way towards running IPv6-only.

I meant that the experience from Joel shows that Flow Label in IPv6 does not work anymore because too many
experiments where made, and most networks are not designable mission specific, which is what CERN did, and
which is why they might not have had issues. My higher level conclusion of Flow Label in IPv6 was that
all these experiments where great, but because we did not even have a field to indicate which experiment
the encoding uses, i burned the Flow Label. Hence also the use of such a selector field for the proposed QoS
header to enoucrage experiments - and then without having to change encoding, just have those survive which
work and have business allocated with them.

> > 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.

If we try to find a solution that supports e.g.: both QoS and application type metadata (as in CERN case
and my past experiences) and cryptographic authentication, then we chew on way too much in one go and IMHO
also run into logical issues, like i tried to explain about why i think a fast ticket needs to be modular
from the services it may authenticate (aka: different HbH header).

I wanted to start with QoS because thats just the broadest erea of forwarding plane functionality that
has IMHO been unable to innovate well because of the lack of an easy way to get per-packet QoS metadata
"standardized" (in quotes because IMHO experimental, informational and third-party options are all in
that bucket too).

If we write up the requiremetns for what fits the notion of QoS packet header metadata, then we will make it
a lot easier for QoS developers/researchers not to have to run into all those privacy issues that would
otherwise be pushing back against standardization of such a broad header. See Jaris RFC...

> > And with the extension header, such failures would only eat up one value of the method code-point in the extension
> > header, not a whole header field like we effectively did when the first two flow-label semantics started to
> > collide.
> 
> Hard to be too critical of not unreasonable choices made nearly 30 years ago.

Fully agree. I equally think that anyone who wants to be critical of IPv4 to IPv6 transition and
claims he could have done it better, should first be able to recite all the business reasons, successes and
failures of each of the 26 transition solutions we came up. Only then can you claim to have an
idea what pitfalls to overcome to migrate or introduce new technology in general. 

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.

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).

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]