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

[Tim Chown <[e-mail]>]

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.

> For me, the final word on IPv6 flow label is still this here:
> 
> https://bapk-videos.mamadrum.net/pk/IETF-099-Prague-videos/03-joel-jaeggli-8.mp4
> 
> And yet we did afterwards still have attempts to introduce new flow label semantics through configuration
> in the ietf. Can we please upgrade the level of this pechakucha's conclusion to proposed standard ?
> 
> 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?

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

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]