Re: [tsvwg] Draft diffuser to QCI v04 posted

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

Hi Jerome,

I guess it depends what clamor you’re hearing.

I thought I understood you’re hearing clamoring for a need to coordinate the use of classes of service across different networks.

In response to that clamoring, I thought you came with a suggestion to solve it by doing some static codepoint assignments (or suggested values, at least) to achieve the coordination of classes of service.

Because we’ve seen before how poorly it goes when we try to suggest static codepoint assignments in the limited DSCP space, I thought I’d suggest addressing the need by letting networks continue to use local codepoint assignments without suggesting specific static values, and instead provide a standardized way to communicate the meaning of the localized assignments, so that service classes could still be coordinated between networks.

I guess if you don’t hear clamoring for the need to coordinate classes of service across networks, I’m not sure I understood your presentation.

The main premise of my responses in this thread is that I think the idea of static codepoint mappings seem doomed from the start and not worth working on here.

Of course dynamic mapping also is doomed if nobody is interested enough to invest in solving the underlying problem, but to me it seems less doomed because it wouldn’t mess up anyone’s existing assignments, and it would only need voluntary adoption where it’s useful, so incremental deployment would be possible wherever anybody chooses to roll it out, and vendors could develop solutions that would work for multiple different interconnects.  I assume only networks that have the need you described (to coordinate the use of service classes across networks) would be interested.

Anyway, I don’t mean to belabor the point, or to spend undue time and list space on fleshing out a brainstorming idea that doesn’t sound useful to you, I just wanted to offer the suggestion as a possible path forward, rather than suggesting that you abandon hope of finding a way to coordinate the classes of service across networks.

But best of luck with the problem, however you choose to approach it.

Best,
Jake

PS: In case it’s useful, in answer to your technical question:

I would imagine that to support different markings on different interfaces for a multi-homed mobile device, you would need a per-interface mapping that applies markings for the desired class differently to connections that use different outbound interfaces (or even sub-connections if there are multipath connections).  Or if there’s an overlay layer that hides the multi-homing from the app, the mapping would have to be handled there instead.

There are certainly technical complexities here that would need fleshing out in prototypes and testing in the networks that have a need to coordinate service classes, and the only reason I would consider suggesting it is because it’s less complex than convincing all the carriers to agree to a specific static mapping of codepoints.

I think enterprises with specific apps that need to work and specific carriers they’re integrating with can achieve this without operating a lookup service by statically building their apps to use hardcoded codepoints that work for their carriers, and negotiating with their carriers to get the interconnections and codepoints worked out in whatever way works for them.

But if this were easy for enterprises to arrange, I wouldn’t think you’d be reporting the need to solve the coordination problem I thought you were describing.

But like I said, I don’t want to push this idea if it doesn’t sound useful, so I’ll bow out now, hoping I’ve made myself adequately understood, with best wishes and a thank-you for the intriguing conversation.


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

Thank you Jake,

I think that I understand the logic better now , thank you for taking the time to explain. I think that the proposal has a lot of merit, and I wonder if it is a replacement, or an addition/customization of our current proposal.
There may be some difficulties of course, like with any scheme. One particular that comes to mind (causing the previous sentence) is a use case as follows (trying to be cautious so as not to expose customer-specific information):
Suppose a location where maintenance of large objects is performed. A/R is used to display the internal expected map and state of particular pieces of equipment (tablet with AR). Because the objects are large, multiple contractors are on the floor working on their respective parts. Several of them use dual path, through the local Wi-Fi and through LTE, each through the carrier(s) the individual contractor company  contracted with.
Wouldn’t we face the risk to see on the local network AR marked differently based on which carrier the contractor is using?
(this could be limited if there were a common marking reference the enterprise could turn to).

Also, on a personal note, I am of the impression that such service would be very useful, but is not something I hear carriers asking for (but my visibility is limited). I am not sure how enthusiastic the carrier community would be to have to implement a service in order to share a marking scheme (vs 101 negotiation with enterprises, or applying standard schemes, e.g. IR 34 or others). Would you have views on this point?

Take care

Jerome


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

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>