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

[Brian E Carpenter <[e-mail]>]

On 07-Mar-24 09:04, Tom Herbert wrote:
> On Wed, Mar 6, 2024 at 11:31 AM Toerless Eckert <[e-mail]> wrote:
>>

...
> 
> Right, the flow label is already allocated to be twenty bits of flow
> entropy and there's no standardizable means to repurpose the bits.

Exactly, it's *defined* as stateless, pseudo-random and constant for
a given flow, and that is implemented in the mainstream TCPs these days.

End of story, except that there is verbiage in the RFC to allow a
negotiated and possibly stateful usage which "MUST NOT disturb nodes
taking part in the stateless scenario." The CERN/LHC usage just about
squeezes through that rule. As Tim will testify, the CERN/LHC team
heard plenty from one of the authors of RFC 6437 while designing their
solution.

     Brian

> 
>>
>>>> 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).
> 
> One feature of FAST that might be of interest is signal reflection.
> This allows a sender to include QoS signaling that is applied in the
> return path of communications,
> 
>>
>> 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).
> 
> FAST tickets are already modular :-)
> 
>>
>> 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.
> 
> 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.
> 
>>
>> 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
> the flow label correctly requires an EH, why not just put the
> information in the EH and avoid touching the flow label?
> 
> 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]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------