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

[Toerless Eckert <[e-mail]>]

Thanks, Tim,

FAST:

Yes, i do remember fast and like the idea. It would be lovely if someone would build some high-speed
PoC for it.

However, i don't think the fast token would be a good element to add to every QoS hop-by-hop acted upon
extension header. Or for that matter any other HbH extension header that we do want to act upon on
every hop (monitoring comes to mind).

The reason is that the authentication action required might be quite expensive (linked with the out-of-band
signaling), and if we follow our current network designs, we would only do it on edge routers, such as
all ASBR into a domain, or any PE towards our own suscribers. But not on P nodes for example. Whereas
the QoS HbH extension header would be acted upon on every P hop.

This distinction, whether a router should examine/act or instead ignore a particular HbH extension header is
i think one of the strongest best reason to actually ever have more than one HbH extension header. 

YadaYada: I think authentication should be it's own HbH extension header.

But of course it would be lovely for experiments with QoS to also experiment with authentication,
although i think most business and research interests are intradomain for QoS (and we repeated get
pretty dismal numbers for how far or rather not HbH extension headers make it across the Internet anyhow).

Let me know what you think about this...

CERN packet marking:

This reminds me of the hazing i received from the IETF privacy community when i presented on
draft-eckert-intarea-flow-metadata-framework in 2013 to INTAREA and TSVWG. Effectively most of the
metadata proposed there about traffic was really QoS algo centric, and of course people still tried to make
an argument that applications shouldn't be trusted to tell the network anything. But where the privacy
argument does of course open an important question is when it exposes higher-up information about
the flow owner, such as application or user-group. Now, the industry has done application forever
via IPFIX and other mechanisms, but in the IETF, as soon as you bring up such privacy relevant
information elements, then your success of moving forward will vary widely. Think MADINAS vs. APN for example.

Aka: I explicitly do not want this discussion in the proposed QoS extensoin headers, so i wrote that the
QoS extension header needs to stick to parameters necessary for the QoS algorithm, nothing higher level and -
see rfc9419. And of course we can and should refine those guidelines. Of course, this is more strict
than would be IMHO the best solutions for intradomain applications, but someone else needs to make
that argument, i already got burned enough by past IETF experiences on this.

For something what CERN did, (user-group, application) identifiers, i would simply have application-host to
controller signalling providing mappings of flow tuple to such application metadata information, and then correlate this
in the controller infrastructure with IPfix or iMon information from the routers. 

Cheers
    Toerless

On Tue, Mar 05, 2024 at 02:41:24PM +0000, Tim Chown 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.
> 
> 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]