Re: [tsvwg] 5G, DiffServ and new PHBs

[Uma Chunduri <[e-mail]>]

quick comments in-line..

(stuff in agreement is removed).

--
Uma C.

On Mon, Apr 27, 2020 at 12:18 AM <[e-mail]> wrote:

> Hi Uma, hi Jerome,
>

>
regarding codepoints, policies, PHBs and generic approaches, I’d like to
> add some thoughts…
>
Thx!


>
A first question is, whether you expect DSCPs to bear a standardized end to
> QoS information for traffic crossing the Internet. I do not. In my
> experience, the only environment where DSCPs remain unchanged end-to end
> are tunneled networks and VPNs.
>

>
>From what I can tell, in a backbone traffic is either loss and delay
> tolerant or it isn’t. In a backbone, a delay bound is a routing decision,
> not a scheduling decision, I think.
>

>
All consumer access Diffserv deployments I’m aware of come with one or more
> policy decision points.
>
Right; see below further on this.


...

> New PHBs may be reasonable. But the architecture where these apply should
> be defined. I think 3GPPs standards inform their reader, that QCIs and
> their QoS are only valid for the RAN and there for the wireless section,
> but not end-to-end.
>


Right and the assumption of only RAN and wireless section (aka their core
network) will be simply insufficient  as the transport network in between,
simply can't provide anything they are seeking (let alone preserve if any
processing benefits that traffic might have got there). Here assigning new
PHBs and consistent definition *may*  help for the end-to-end SLA
objectives (this is the one of the points  - end-to-end in not internet).

That is why GSMA IR.34 aggregates 9 QCI into 4 classes.
>
So, we can leave all 23.501/5QIs classification to leave it somebody or
make it generic (one aspect of the draft under discussion is doing
classification too and support that effort). But may not be necessary to
carve out the all new code points. I leave that to authors of the proposal
and you as being discussed in the other thread.


I’m not sure if and then how a datacenter determines (preferred) processing
> (I mean some way of attaining more resources or faster processing). I’m not
> sure, whether a DSCP is relevant or the only relevant information there.
>


Can be relevant in some places as policy input, see below.

>From my understanding of Segment Routing, there are other options to carry
> that information, address or label based, I think. I add this, as 5G also
> intends to support machine to machine communication.
>


Slightly off topic though (yes, loosely relevant). You have very little
possibility in SR-MPLS (no space) and for SRv6 you one can do lot of things
i.e., in the address itself (if used as SID), SRH bits or TLVs??. But only
if this is used/deployed as a preferred option as the TE mechanism in the
transport.  On the other hand, mapping this in the DSCP field in the
original IP header (v4/v6) or outer header if traffic is tunneled helps
policy  inputs as you alluded above but also can potentially achieve more
in the E2E model (beyond RAN and cellular core).




>
>
>