Re: [tsvwg] Draft diffuser to QCI v04 posted

[[e-mail]]

Hi Luis,

thanks for your mail. My take is that nobody objects to work on mapping QCI/QFI to DiffServ. There are different approaches.

My experience with network provider DiffServ support is, that a different choice of DSCP should be expected (or not come as a surprise). Commonalities may be found with the Per-Hop Behaviours or the differentiation of performance. I also think to have understood, that wireless schedulers are offering more technical features to differentiate traffic, than for example backbone routers do. The question to me is, whether and how to ensure best, that the expected treatment results from the standards being agreed. To me, codepoint assignment is secondary to that. Generic standardizing treatment of codepoints in the case of mappings is desirable, fixing too many details isn’t my preferred approach (fixing to many details from start doesn’t match with the production environment I’m in – but as with the codepoints, I don’t expect any other network to be operated and engineered the way like the one I’m working with).
You’ve mentioned some constraints, like problem detection, mix of many applications demanding differentiated transport. Mine are ability to engineer, configure and operate, across an end-to-end chain of hardware of different purpose and vendors. QoS isn’t a local feature. Solutions, which work on one section of an end-to-end path may fail at another.

Regards,

Ruediger


Von: tsvwg <[e-mail]> Im Auftrag von Luis M. Contreras
Gesendet: Samstag, 25. April 2020 12:48
An: [e-mail]
Cc: Jerome Henry (jerhenry) <jerhenry=[e-mail]>; LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>; Holland, Jake <jholland=[e-mail]>
Betreff: Re: [tsvwg] Draft diffuser to QCI v04 posted

Hi all,

sorry for jumping late.

I think we are missing part of the motivations for having  guidance on the mapping of QCI/QFI to DSCP. I think we all agree on the fact that this should be informational and that each operator can perfectly ignore or apply this partially or totally. However it is yet a valuable exercise, precisely to guide some (or all) mappings. These are some other arguments on favor of it, just to name a few:

.- some operators are not "single-network" operators. A guidance on how to map  QCI/QFI to DSCP across the footprint of affiliates can help in different ways, as e.g. to have a common ground for detecting problems in the design of a particular network, functioning of some equipments, etc;
.- in some cases different vendors have different implementations with respect to specific features. This happens, for instance, in the mobile arena where some vendors have the possibility of separating e.g. S1 interface from X2, or even S1-U and S1-C. This sometimes deal to different mappings when carried on the backhaul.
.- traffic carried is much more than external applications. Traffic tyoes such as synchronism, core network control, routing, traffic from fixed services, etc will be there. Even this is not in the scope of the draft, it helps to have a comprehensive overview will help also to understand how the rest of the traffic outside QCI/QFIs can me accomodated in a multi-service network .
.- This kind of exercise can also help for benchmarking and network migration/merging processes

The point is that we (operators) are in a point where 5G networks start to be deployed, so it is a good moment for reconsidering mappings since the networks have to be adapted to the new situation.

Best regards

Luis




El sáb., 25 abr. 2020 a las 2:07, Uma Chunduri (<[e-mail]<mailto:umac.ietf@gmail..com>>) escribió:
Hi Jake,

Quick comments below

On Thu, Apr 23, 2020 at 1:31 PM Holland, Jake <jholland=[e-mail]<mailto:40akamai.com@dmarc..ietf.org>> wrote:
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]<mailto:[e-mail]>>
Date: Monday, April 20, 2020 at 11:31 AM
To: "Holland, Jake" <[e-mail]<mailto:[e-mail]>>
Cc: "jerhenry=[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted
Date: Monday, April 20, 2020 at 11:31 AM
To: "Holland, Jake" <[e-mail]<mailto:[e-mail]>>
Cc: "jerhenry=[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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.

right; but I would note, even in single carrier scenario this could potentially give vendor agnostic behavior.

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

this should/need not be the case, say, if new code points are proposed (depending on the type of traffic we are talking, of course).
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>

very good start!

Best,

--
Uma C.


--
___________________________________________
Luis M. Contreras
[e-mail]<mailto:[e-mail]>
[e-mail]<mailto:[e-mail]>
Global CTIO unit / Telefonica