Re: [tsvwg] Draft diffuser to QCI v04 posted

["Luis M. Contreras" <[e-mail]>]

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]>)
escribió:

> Hi Jake,
>
> Quick comments below
>
> On Thu, Apr 23, 2020 at 1:31 PM Holland, Jake <jholland=
> [e-mail] <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]>
>> *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
>>
> *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.
>>
>
>>
> 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]
[e-mail]
Global CTIO unit / Telefonica