Sect 4.7: Also an MF-Classifier for QoS?

[gorryfair]

Sect 4.7: Speaks about QoS

The section mentions QoS and DSCPs, but one other operational point with traffic that uses any encrypted transport is that there is an often lack of detail in classifier information for on-path devices to provide a useful MF classifier for QoS. At least within some organisations, MF-Classifiers can be used to set QoS markings for traffic, which become impossible when using encryption - see sect 2.2.2 of draft-ietf-tsvwg-transport-encrypt-18.

[mirjak]

That seems like a bit to much info for this draft.

[gorryfair]

So my point, was to be clear this also applies to in-network classifiers. Here is something brief:

/A QUIC connection limits the fields that can be observed by an MF-Classifier. Such a device needs to be configured so that any marking and conditioning is consistently performed on all packets forming the QUIC connection./

After the sentence on endpoint marking: /Therefore it is not recommended to use different DiffServ Code Points (DSCPs).../

You could cite the ID above if you need more details.

[mirjak]

Isn't this already covered by the first sentence of this section

"It is expected that any QoS handling in the network [...] is applied on a per flow-basis (and not per-packet) and as such that all packets belonging to the same QUIC connection get uniform treatment."

?

[gorryfair]

I don't think so - we should explain both the case for the source endpoint, and the devices on-path that classify and manage the DSCP (etc) for QoS. They are different actors - MF classifiers and conditioning is often based on packet fields, or failing that heuristics about flows.

[mirjak]

Text on setting DSCP is the applicability statement, sec 10. This part in manageability is only about network handling.

[gorryfair]

Wait... that's a really odd split for this topic. I can see that applicability statement sect 10 says something helpful for the app - I don't argue with what that specific text says.

However, there's a non-trivial set of other devices and functions in the network that forward based on DSCPs; set DSCPs (such as classifiers); police their usage; condition to a PHB; etc. - the "guidance" in section 4.7 seems to suggest "leave this traffic alone" - and this current guidance isn't great help to network operators who are trying to balance traffic against service classes.

[mirjak]

Yes, there are devices that set DSCP but I don't think there is any QUIC-specific advice we can give here. Or what other advise are you thinking of?

[gorryfair]

So my observation was that several people came to the Mic in IETF meetings and noted that deployed classifiers did not see port information or other fields that they would expect to use in classification, and as such the traffic might/would get mapped to a default service. That might have unexpected results if the network traffic becomes mainly QUIC and is something to think about. I'm not asking to "detail-in" on this, simply to call-out the side-effect of making the traffic harder to classify.

[mirjak]

But QUIC is on top of UDP which has ports...? Or which other field are we talking about?

[mirjak]

@gorryfair ?

[gorryfair]

OK, let's close: I guess the information is elsewhere.