Subject: Re: [Accord] presentation slot for draft-you-tsvwg-latency-loss-tradeoff

From: Brian Trammell <[email-masked]>
Date: Mon, 21 Mar 2016 10:59:58 +0100

Hi, David,

> On 21 Mar 2016, at 04:07, Black, David <[email-masked]> wrote:
> 
> I'd think that this draft is also planned for presentation in the ACCORD BOF - how is the discussion in TSVWG expected to differ from ACCORD?

In ACCORD, we're planning very short "here's what Lo and La mean, we have a draft that defines Lo/La-over-DSCP, we also have a use case (in draft-kuehlewind-spud-use-cases) for Lo/La-over-SPUD". The presentation in TSVWG would get into the details of why we think we need new DSCP codepoints for this.

If we assume everyone who might be interested in this will be in ACCORD anyway, we can compress our discussion of "why do we need new codepoints" into that single presentation.

> I'm concerned about the draft's brief dismissal of each existing Diffserv PHB as irrelevant with very little explanation.

As am I. But I personally consider that a problem with interdomain deployability of existing Diffserv PHBs: it's not really what they were designed for. I'd be happy to be shown counterexamples of n>2-domain deployments at scale involving networks not party to a contract involving DSCP-implemented SLAs, but it really does seem to be that all existing Diffserv PHBs have shown themselves to be irrelevant for the case we are addressing here -- applications on the content side signaling loss/latency tradeoffs to access networks across the open Internet.

The reason to ask for new codepoints is to make it *possible* to continue blocking all existing PHBs while not bleaching PHBs that are not tied in any network (whether by definition or by local configuration) to a request for "better" treatment. A firewall rule could be configured to pass La and Lo (along with other potential future explicit-tradeoff codepoints) while still bleaching other PHBs to DF.

We could potentially do a better job of clarifying this argument in a future draft revision.

> Here are some combinations of existing PHBs that have the potential to deliver something like the desired behavior:
> 
> - DF (Default) & EF
> - DF (Default) & AFx1 (have to pick an x value)
> - AFx1 & EF (have to pick an x value)
> - AFx1 & AFy1 (have to pick different x & y values)
> 
> In all cases, some specific queue configuration is involved to obtain the desired results, particularly for the queues that correspond to AFx1 & AFy1.  I've included EF because its queue behavior matches latency preference well - a queue for EF is supposed to deliver low latency in part by dropping traffic that it can't forward promptly.

Either of these against DF are "request for better treatment": we need some way to distinguish Lo from DF treatment. Though they'd basically be implemented the same way *today*, one can envision future networks where ubiquitous multipath connectivity using different radio technologies means that Lo really *is* a request to go over the lower-loss path.

So we can disregard La = AFx1 / Lo = DF as well as La = EF / Lo = DF.

> OTOH, EF's admission control requirement feels like a poor fit for what's wanted here.

Yep, so I think we can disregard La = EF / Lo = AFx1

AFx1/AFy1 is intriguing, though rereading 2597 it appears that the "assured" in assured forwarding doesn't quite fit (2597 section 2 para 3):

   A DS node MUST allocate a configurable, minimum amount of forwarding
   resources (buffer space and bandwidth) to each implemented AF class.
   Each class SHOULD be serviced in a manner to achieve the configured
   service rate (bandwidth) over both small and large time scales.

For now, a DS node allocates buffer to Lo and La (where the La minimum might be as small as a single packet), and will practically have to allocate a bandwidth floor for each. But, as above, the actual implementation in the future might rather involve completely different forwarding paths. While these would meet the letter of this paragraph, as there would be an implicit bandwidth floor on each next hop, conceptually the bandwidth requirement is orthogonal to the Lo/La tradeoff, and as such I don't think really fits what I read as the "spirit" of AF.

In addition, this use might collide with some providers' internal use for these codepoints. Of course, this is a potential problem with new codepoints in Pool 3, as well, since these were given over for potential local use in the IANA registry. And it doesn't solve the problem with declaring codepoints potentially unbleachable at all.

Thanks, cheers,

Brian

> I'm not trying to say that this is a solved problem, but I would like to see more attention paid to possible reuse and/or adaptation of what's been done before.

> Thanks, --David ++Sent from Android smartphone ...
> -------- Original message --------
> From: Gorry Fairhurst <[email-masked]>
> Date: 3/17/2016 11:02 AM (GMT-05:00)
> To: Brian Trammell <[email-masked]>, [email-masked]
> Cc: [email-masked]
> Subject: Re: presentation slot for draft-you-tsvwg-latency-loss-tradeoff
> 
> On 17/03/2016 14:49, Brian Trammell wrote:
> > Greetings,
> >
> > I'd like to request a slot (if one hasn't already been requested) to quickly present draft-you-tsvwg-latency-loss-tradeoff at the most appropriate tsvwg session in Buenos Aires.
> >
> > Thanks, cheers,
> >
> > Brian (for the authors of the loss-latency "one bit" draft)
> >
> I'll note the request. I did glance through the draft, and I'm not sure
> quite how this fits in to the DS architecture, but I'd need to look
> further and consult more to gte a better picture.
> 
> I need to speak to my co-chair about planning the Agenda, and we'll
> discuss - and get back next week.
> 
> Gorry

---

From: Brian Trammell <[email-masked]>
Date: Tue, 22 Mar 2016 14:50:16 +0100

hi Gorry,

> On 22 Mar 2016, at 10:23, [email-masked] wrote:
> 
> 
> I'm not finding this ID very easy to get into... and I think there may be
> various reasons, but I suspect David may be digging in a good place to
> start.
> 
> This looks and feels like a -00 draft.

As indeed it is. :)

> From the current, I still need to
> understand why the code points would be needed and why new ones would
> help.

Quoting myself, below:

>> ... it really does seem to be that all existing
>> Diffserv PHBs have shown themselves to be irrelevant for the case we are
>> addressing here -- applications on the content side signaling loss/latency
>> tradeoffs to access networks across the open Internet.

>> The reason to ask for new codepoints is to make it *possible* to continue
>> blocking all existing PHBs while not bleaching PHBs that are not tied in
>> any network (whether by definition or by local configuration) to a request
>> for "better" treatment. A firewall rule could be configured to pass La and
>> Lo (along with other potential future explicit-tradeoff codepoints) while
>> still bleaching other PHBs to DF.

To elaborate:

Every marking other than DF is an explicit request for treatment which will disadvantage DF traffic. There is no mechanism for tradeoff in the DS architecture outside legal contracts between two directly connected networks, which limits its deployability in the general (interdomain, open-Internet) case.

Lo and La are defined such that there is an *explicit tradeoff*. The hope is that by putting these new codepoints in part of the code space that is always subject to these explicit tradeoffs -- marking Lo or La need not disadvantage DF -- makes it possible to bleach the existing DS architecture codepoints, which are used internally but cannot deploy in the general interdomain case due to mark inflation, while passing the interdomain-friendly tradeoff-based codepoints, which are defined such that there is no incentive for mark inflation.

This is, I admit, perhaps laughably optimistic. But it would allow the treatment to deploy on current hardware, as DSCP-aware boxes can already make forwarding and queueing decisions based on DSCP codepoints.

> I think previous experience in TSVWG suggests a lack of precise
> language can surely end with rathole discussions.
> 
> I can see value in a heads-up for people who know and care about Diffserv
> deployment to be encouraged to show-up at ACCORD.

Yes, please. :)

> However, I continue to be really confused about which drafts may be linked
> to the ACCORD BOF, and what this could lead to, that doesn't stop me
> thinking that the BoF could be a good place to start discussion.

Broadly speaking, there are two things I hope we accomplish with the ACCORD BoF:

(1) Have a discussion about how radio access networks (RAN) work, and how this architecture doesn't fit with common IETF perceptions about what happens at layer 2.

(2) Determine the minimum set of information that RAN schedulers actually need (i.e., in deployed networks, not in the 3GPP architecture) about application traffic to function correctly in the absence of traffic classification provided by DPI.

We believe the loss-latency tradeoff bit to be a potential (partial) solution to the problem in (2), given how few different classes of traffic seem generally to be deployed.

Cheers,

Brian

>>> I'd think that this draft is also planned for presentation in the ACCORD
>>> BOF - how is the discussion in TSVWG expected to differ from ACCORD?
>> 
>> In ACCORD, we're planning very short "here's what Lo and La mean, we have
>> a draft that defines Lo/La-over-DSCP, we also have a use case (in
>> draft-kuehlewind-spud-use-cases) for Lo/La-over-SPUD". The presentation in
>> TSVWG would get into the details of why we think we need new DSCP
>> codepoints for this.
>> 
>> If we assume everyone who might be interested in this will be in ACCORD
>> anyway, we can compress our discussion of "why do we need new codepoints"
>> into that single presentation.
>> 
>>> I'm concerned about the draft's brief dismissal of each existing
>>> Diffserv PHB as irrelevant with very little explanation.
>> 
>> As am I. But I personally consider that a problem with interdomain
>> deployability of existing Diffserv PHBs: it's not really what they were
>> designed for. I'd be happy to be shown counterexamples of n>2-domain
>> deployments at scale involving networks not party to a contract involving
>> DSCP-implemented SLAs, but it really does seem to be that all existing
>> Diffserv PHBs have shown themselves to be irrelevant for the case we are
>> addressing here -- applications on the content side signaling loss/latency
>> tradeoffs to access networks across the open Internet.
>> 
>> The reason to ask for new codepoints is to make it *possible* to continue
>> blocking all existing PHBs while not bleaching PHBs that are not tied in
>> any network (whether by definition or by local configuration) to a request
>> for "better" treatment. A firewall rule could be configured to pass La and
>> Lo (along with other potential future explicit-tradeoff codepoints) while
>> still bleaching other PHBs to DF.
>> 
>>> Here are some combinations of existing PHBs that have the potential to
>>> deliver something like the desired behavior:
>>> 
>>> - DF (Default) & EF
>>> In all cases, some specific queue configuration is involved to obtain
>>> the desired results, particularly for the queues that correspond to AFx1
>>> & AFy1.  I've included EF because its queue behavior matches latency
>>> preference well - a queue for EF is supposed to deliver low latency in
>>> part by dropping traffic that it can't forward promptly.
>> 
>> Either of these against DF are "request for better treatment": we need
>> some way to distinguish Lo from DF treatment. Though they'd basically be
>> implemented the same way *today*, one can envision future networks where
>> ubiquitous multipath connectivity using different radio technologies means
>> that Lo really *is* a request to go over the lower-loss path.
>> 
>> AFx1/AFy1 is intriguing, though rereading 2597 it appears that the
>> "assured" in assured forwarding doesn't quite fit (2597 section 2 para 3):
>> 
>> For now, a DS node allocates buffer to Lo and La (where the La minimum
>> might be as small as a single packet), and will practically have to
>> allocate a bandwidth floor for each. But, as above, the actual
>> implementation in the future might rather involve completely different
>> forwarding paths. While these would meet the letter of this paragraph, as
>> there would be an implicit bandwidth floor on each next hop, conceptually
>> the bandwidth requirement is orthogonal to the Lo/La tradeoff, and as such
>> I don't think really fits what I read as the "spirit" of AF.
>> 
>> In addition, this use might collide with some providers' internal use for
>> these codepoints. Of course, this is a potential problem with new
>> codepoints in Pool 3, as well, since these were given over for potential
>> local use in the IANA registry. And it doesn't solve the problem with
>> declaring codepoints potentially unbleachable at all.
>> 
>> Thanks, cheers,
>> 
>> Brian
>> 
>>> I'm not trying to say that this is a solved problem, but I would like to
>>> see more attention paid to possible reuse and/or adaptation of what's
>>> been done before.
>> 
>>>> I'd like to request a slot (if one hasn't already been requested) to
>>> quickly present draft-you-tsvwg-latency-loss-tradeoff at the most
>>> appropriate tsvwg session in Buenos Aires.
>>>> 
>>>> Thanks, cheers,
>>>>

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 22 Mar 2016 15:48:55 +0100

Hi Gorry, hi David,

accord currently is a non-wg forming BoF and I personally don't see a working 
coming out of it. Currently the questions is rather, what do we want to do 
and where can we do it (and 'where' might be existing working groups). 
However, even if there would be a new accord wg or something like this, I 
would still see that a new DSCP should be allocated only in tsvwg because 
that's were the expertise is. So my current view is, even if we discuss and 
present this in accord (where the focus is clearly on what we want to do, and 
not the explicit codepodes itself), this doc would always stay a tsvwg doc. 
In this case, for me the questions is, do you have time on the agenda for a 
heads-up presentation that this new work might be coming up (and for us to 
get early feedback similar to what you provided already), or not...? Both is 
okay for us, as this is early work.

Btw. could we maybe restart this discuss on the tsvwg mailing list...? I 
think it would be very useful for us to have the discussion there and get 
feedback from the broader community.

Thanks!
Mirja

On 22.03.2016 10:23, [email-masked] wrote:
> This looks and feels like a -00 draft. From the current, I still need to
> help. I think previous experience in TSVWG suggests a lack of precise

---

From: [email-masked]
Date: Tue, 22 Mar 2016 09:23:36 -0000

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 22 Mar 2016 17:28:22 +0000

On 22/03/2016 14:48, Mirja Kühlewind wrote:
> Hi Gorry, hi David,
>
> accord currently is a non-wg forming BoF and I personally don't see a
> working coming out of it. Currently the questions is rather, what do we
> want to do and where can we do it (and 'where' might be existing working
> groups). However, even if there would be a new accord wg or something
> like this, I would still see that a new DSCP should be allocated only in
> tsvwg because that's were the expertise is.
 >
I concur with the above. One good thing is ACCORD could help motivate 
the use-case?

 >  So my current view is, even
> if we discuss and present this in accord (where the focus is clearly on
> what we want to do, and not the explicit codepodes itself), this doc
> would always stay a tsvwg doc. In this case, for me the questions is, do
> you have time on the agenda for a heads-up presentation that this new
> work might be coming up (and for us to get early feedback similar to
> what you provided already), or not...? Both is okay for us, as this is
> early work.
>
Let's add to the list of drafts requesting time.

> think it would be very useful for us to have the discussion there and
> get feedback from the broader community.
>
Yes.

However, I'm pretty much confused about whether there is merit in 
specifying these new PHBs.  This could be just because this is draft -00.

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 22 Mar 2016 17:32:49 +0000

>>>> discuss - and get back next week.
Thanks. For me, this helps me get some context. I'll let you continue 
with David on the actual questions for the moment.

Gorry

---

From: "Black, David" <[email-masked]>
Date: Wed, 30 Mar 2016 13:31:29 +0000

> > Lo and La are defined such that there is an *explicit tradeoff*. The hope is that
> by putting these new codepoints in part of the code space that is always subject
> to these explicit tradeoffs -- marking Lo or La need not disadvantage DF -- makes
> it possible to bleach the existing DS architecture codepoints, which are used
> internally but cannot deploy in the general interdomain case due to mark
> inflation, while passing the interdomain-friendly tradeoff-based codepoints,
> which are defined such that there is no incentive for mark inflation.

The Diffserv-Intercon draft (draft-ietf-tsvwg-diffserv-intercon) is trying to do something
better than bleaching all existing codepoints, but it is still contract-based.

Looking at the ACCORD BOF goals:

> > (1) Have a discussion about how radio access networks (RAN) work, and how
> this architecture doesn't fit with common IETF perceptions about what happens
> at layer 2.
> >
> > (2) Determine the minimum set of information that RAN schedulers actually
> need (i.e., in deployed networks, not in the 3GPP architecture) about application
> traffic to function correctly in the absence of traffic classification provided by DPI.
> >
> > We believe the loss-latency tradeoff bit to be a potential (partial) solution to
> the problem in (2), given how few different classes of traffic seem generally to be
> deployed.

It feels like the discussion in Buenos Aires ought to start in ACCORD, which is
(unfortunately) scheduled for Thursday, after the TSVWG sessions on Tuesday
and Wednesday.  I think it would be better for the problem discussion in ACCORD
to precede any TSVWG discussion of solution mechanics, so I'd lean against doing
anything in the TSVWG meetings next week aside from bringing attention to
the ACCORD meeting and discussion expected to occur there.

Longer-term, I absolutely concur that TSVWG is the right home for Diffserv work,
but ACCORD seems like the right place in Buenos Aires to better understand the
problem to be addressed.

Thanks, --David

> -----Original Message-----
> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Tuesday, March 22, 2016 1:33 PM
> To: Brian Trammell
> Cc: Black, David; [email-masked]; draft-you-tsvwg-latency-loss-
> [email-masked]; [email-masked]
> > Every marking other than DF is an explicit request for treatment which will
> disadvantage DF traffic. There is no mechanism for tradeoff in the DS architecture
> outside legal contracts between two directly connected networks, which limits its
> deployability in the general (interdomain, open-Internet) case.
> >
> > Lo and La are defined such that there is an *explicit tradeoff*. The hope is that
> by putting these new codepoints in part of the code space that is always subject
> to these explicit tradeoffs -- marking Lo or La need not disadvantage DF -- makes
> it possible to bleach the existing DS architecture codepoints, which are used
> internally but cannot deploy in the general interdomain case due to mark
> inflation, while passing the interdomain-friendly tradeoff-based codepoints,
> which are defined such that there is no incentive for mark inflation.
> >
> > This is, I admit, perhaps laughably optimistic. But it would allow the treatment
> to deploy on current hardware, as DSCP-aware boxes can already make
> forwarding and queueing decisions based on DSCP codepoints.
> >
> > (1) Have a discussion about how radio access networks (RAN) work, and how
> this architecture doesn't fit with common IETF perceptions about what happens
> at layer 2.
> >
> > (2) Determine the minimum set of information that RAN schedulers actually
> need (i.e., in deployed networks, not in the 3GPP architecture) about application
> traffic to function correctly in the absence of traffic classification provided by DPI.
> >
> > We believe the loss-latency tradeoff bit to be a potential (partial) solution to
> the problem in (2), given how few different classes of traffic seem generally to be
> deployed.
> >
> > Cheers,
> >
> > Brian
> >
> >
> >>> Hi, David,
> >>>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 30 Mar 2016 15:36:55 +0200

hi David,

Thanks -- we'll discuss in ACCORD, continue discussion on the tsvwg list, and should it make sense, bring something to tsvwg in Berlin. One comment below...

> On 30 Mar 2016, at 15:31, Black, David <[email-masked]> wrote:
> 

Which is the right way to do it, IMO. You *do* need to be able to do QoS where the tradeoffs aren't explicit. The one bit latency tradeoff and other DSCP applications shouldn't be mutually exclusive. Unfortunately, there's only one six-bit field in the IP header, unless you put the tradeoff bits somewhere else. (On which, see section 5.2 in draft-kuehlewind-spud-use-cases :) ).

Cheers,

Brian

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 31 Mar 2016 10:09:25 +0300

Hi David,

> I'd lean against doing

yes, I will give a very brief heads up about ACCORD at the TSVWG meeting
on Tuesday so that everyone is aware of it.

Cheers,

Gonzalo