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

[Vasilenko Eduard <[e-mail]>]

Hi Toerless, a few comments.

1. The first comment is on scale.
I did never understand all these attempts to greatly expand the DSCP scale. What is the point of having more bits for QoS signaling if it would not be supported in hardware?
6 bits permit 64 schedulers/queues per virtual interface (BRAS could have 1/4M of schedulers per line card but it is still 8+ schedulers per subscriber virtual interface).
Do you know any switch or router that has more schedulers per virtual or physical interface?
Any plans to produce it? Why? What is the business case?
Middlebox could be software-based. It could have an unlimited number of schedulers. But it is just 1 hop from 7.
What is the value if only the middlebox would have >64 schedulers per virtual interface?

2. The second comment on the functionality.
Indeed, some schedulers could benefit from additional information (like "packet depreciation time").
Looking at the draft, it looks like functionality is the reason for the DSCP extension.
IMHO: this reason is valid.
But I have a doubt that it is possible to guess what particular type of schedulers the market would accept. The strong business case is needed for data plane extension.
And I do not see any discussion on BBR/CUBIC/DCQCN in the document.
QoS is more dependent on host's CCA then on router's AQM, but both have the influence.
It strange to see only AQM discussion without any reference to CCA assumed. IMHO: such discussion has no value.

3. New IPv6 header.
The only motivation that some routers would bypass QoS header.
Looks strange because it would additionally complicate CCA-to-AQM interaction if AQM would be different on different routers.
IMHO: The thing that looks reasonable is the request to "add headers in transit". Indeed, tunnels inside tunnels looks not good.

Eduard
-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Toerless Eckert
Sent: Monday, March 4, 2024 23:37
To: [e-mail]
Cc: [e-mail]
Subject: [IPv6] 6MAN: looking for feedback to draft-eckert-6man-qos-exthdr-discuss (Re: New Version Notification for ...)

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