Re: [tsvwg] Draft diffuser to QCI v04 posted

[Uma Chunduri <[e-mail]>]

Hi Jake,

Quick comments below

On Thu, Apr 23, 2020 at 1:31 PM Holland, Jake <jholland=
[e-mail]> 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.

>