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 18:31, Tom Herbert <tom=[e-mail]> wrote:

On Tue, Mar 5, 2024 at 6:41 AM Tim Chown
<Tim.Chown=[e-mail]> wrote:
<snip>

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.

The flow label is big enough for the science use case; it’s split into experiment (community), activity (application area) and has 5 bits for entropy.  The use case is just understanding which experiments and activities are consuming capacity on expensive links.

As suggested at the SFO IETF we’d like to use HbH, as there’s far richer metadata that could also be included than fits in 20 bits.

I am interested in what you mean by " if then insertion penalty were
not so high".

Inserting the HbH reduces throughput, which is important for large scale data transfers. There’s an example in the paper Eric Vyncke published recently that shows it’s significant - https://netdevconf.info/0x17/docs/netdev-0x17-paper40-talk-paper.pdf.  Our experience is similar, but we have hooked up the person who did Eric’s implementation with the one who did ours to look again. Setting the flow label I recall reduced performance by something like 0.5%.

Tim

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