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

[Brian Trammell <[e-mail]>]

Hi, David,

> On 21 Mar 2016, at 04:07, Black, David <[e-mail]> 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 <[e-mail]>
> Date: 3/17/2016 11:02 AM (GMT-05:00)
> To: Brian Trammell <[e-mail]>, [e-mail]
> Cc: [e-mail]
> 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