Re: [tsvwg] Draft diffuser to QCI v04 posted

["Holland, Jake" <[e-mail]>]

Hi Jerome,

I’m glad it’s possibly helpful.  I’ll try to answer your questions and expand a bit on the vision I had in mind, responses are inline with <JH></JH>


From: "Jerome Henry (jerhenry)" <jerhenry=[e-mail]>
Date: Monday, April 20, 2020 at 11:31 AM
To: "Holland, Jake" <[e-mail]>
Cc: "jerhenry=[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi Jake,

This is very useful feedback. In this effort, it seems that we want to arbitrate between different needs. In the scenario we envision, an enterprise has a series of assets of various types, and they leverage a dual connection (MPTCP, QUIC etc) between cellular and unlicensed (let’s call it Wi-FI, although it can be something else). As traffic reaches the other side (application server with at least a Diffserv path to the asset), the hope is that both sides would have treated the packets in an approximatively comparable fashion.

Would you mind exploring your idea a bit further? In all cases, the actor is likely an enterprise IT. They can negotiate an SLA with the carrier(s) they work with. This could result in a series of QCIs attached to the various traffic they would send. Now, their goal is to attempt to get the same intent on both legs. They may not be LTE experts.

<JH>
The “(s)” in “carrier(s)” is the trickiest part here, I think, and a major driver for proposing a dynamic approach.

I assume here that the different carriers might have different markings for similar PHBs that might be hard for them to change. (For instance, the choices might be from hardware-driven constraints from their vendors, or perhaps due to things like legacy internal use cases within the carrier that drove an assignment some time ago, which now can’t be easily changed.)

The proposal is intended as a way that the carrier has the ability, with a relatively simple deployment of a simple service, to advertise the right markings that should be used for that network, and that these can be different from network-to-network, yet still usable by hosts, with apps that have a use for specific, named PHBs for their traffic.
</JH>

In your proposal, how would the choreography work? Would the enterprise create their own mapping between the LCIs their carrier suggested and some DSCP, chosen from unaffected values?
(Would they need any guidance on what these QCIs represent? Do we assume that they are comfortable or familiar with the various IETF QoS RFCs?) Would they then use the service.domain logic below to ask the carrier to mark the matching traffic at the interconnect? Or would the host/asset mark the DIffserv side, based on putting in a library somewhere, that the host can access, a service/socket to DSCP table?

<JH>
I think the answer to these depends on exactly how the mobile devices are connected, and how the enterprise network is structured, and whether the enterprise itself has any constraints on the DSCP values.

I imagine the most typical (or at least simplest) case being a transparent pass-through, where the lookup service is operated by the carrier, and it provides carrier-chosen values, and all the enterprise does is propagate the search domain from the carrier and the appropriate DNS entries for service discovery, and then passes through the DSCP markings.

I imagine that for enterprises with more complex networks, it could get more complex.  One can certainly imagine enterprises with expertise who would choose to run their own mapping and their own classes of service, especially for internal connections.  These may or may not come with enterprise constraints on the markings that may or may not match the carrier’s constraints, so there would perhaps be a marking translation config at the interconnect (where inside markings are translated back and forth to outside markings for the same class of service), and this would either be manually configured based on reviewing the SLAs, or might be automatable using the same sort of discovery logic (or the bgp interconnect, if preferred).  In this kind of scenario, the enterprise would operate its own search domain and provide its own mapping service for the mobile devices to use, and it would take more expertise, but it would only be required if the enterprise has its own uses for the codepoints.  (I imagine in practice there’d be vendors providing some kind of integration here, but some shops employing experts and doing it themselves.)

Whether the host connects to an enterprise-owned service (by discovering the service in an enterprise-owned search domain), or the carrier-owned service (by the enterprise passing through the carrier’s search domain to the end hosts), if the service messaging for the traffic_class_name->codepoint lookup is defined with the same messaging between host and service (for instance, it could perhaps be done as a RESTCONF server using a YANG model defined in the spec, or if there’s some reason could instead define a specific set of messages and version detection, etc.).

But the point of the service would be that the host would be able to look up the codepoint to use in order to get a named PHB for the packets it’s sending.  If the traffic class names come from a registry that map them to PHBs (probably a “specification required” registry, I would think), then collisions can be avoided in the traffic class names, and the hosts will know what name to use to attempt to get a certain kind of PHB from the network, and whether they can in fact meaningfully use that class of service within the network they’re connected to (The ability to provide a null result will be important in this service.)

So with this approach, the host would always mark the DSCP according to what it learned from the service.

The simple deployment would just pass it through transparently (both the markings and the mapping service discovery), whereas a complex deployment could if necessary provide a translation layer (by providing their own mapping service, and configuring an interconnect that remaps codepoints where necessary).  So the place the host learns the mapping from would be the control point, and setting up the right search domain so that the host discovers the right service would need to be configured in the host’s dhcp server to match the intended operation for that network.

I hope that makes some sense and helps clarify the suggestion.  It’s of course not a fully specified proposal, so of course there are many unspecified details.

For instance, just like with the bgp carrier interconnect proposal, maybe there could be different available classes of service based on the intended destination, and maybe these need to be handled as part of the mapping service (so maybe the lookup needs to use a destination, as well, and maybe maintaining the service is not trivial in all cases).  As another complicating factor, maybe there’s different permissions on different hosts’ access to the classes of service for different individuals, which might need to be handled in some enterprises with some sort of 802.x-based enforcement on the allowed markings from that host, and/or with client identity via client certs for the mapping service connection.

Describing these details and how to make them satisfy the needed use cases are left as an exercise for the prospective authors of this proposal, but to my mind (without having tried to write it all out) there seem like reasonable and tractable approaches that can be defined in the same way as for other services, or listed as out-of-scope details that may or may not be required for implementations to support.

All that said, I should give a disclaimer and clarify that it’s possible some of these underspecified details might make the whole approach non-viable for some reason I haven’t thought of yet.  This is really just a brainstorming idea at this stage, not a fully realized proposal, so caveat emptor.  I don’t vouch for it entirely, I only claim that it sounds easier to me and more likely to succeed than making a static mapping actually work.

Best,
Jake
</JH>