Subject: [tsvwg] One bit for latency bandwidth tradeoff

From: Youjianjie <[email-masked]>
Date: Tue, 26 Jan 2016 07:30:24 +0000

Hi,

Existing work shows that having a latency-bandwidth trade-off decision would be useful.

For example: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=923942

http://people.networks.imdea.org/~sergey_gorinsky/pdf/RD_Services_SIGCOMM_2008.pdf

SPUD describes this as one of its use cases.

https://tools.ietf.org/html/draft-kuehlewind-spud-use-cases-00#section-4

We wonder: how should this be specified? Could we, for example, use the DSCP? If so, how - can we use an existing value, or should we define a new one?

Regards,
Jianjie

---

From: Brian Trammell <[email-masked]>
Date: Tue, 26 Jan 2016 10:54:03 +0100

hi Jianjie,

Our thinking on this in the context of the prototype is either (a) that the latency tradeoff be bound to a tube (which would require (1) more than one bit to encode the tradeoff and (2) that the forwarding/queueing decision also always do a lookup on the tube ID, which is not optimal), or (b) that one of the reserved bits in cmd/flags be used for this.

It does not appear that the current definitions of the DSCP codepoints would allow compatible reuse of either a single bit or any of the codepoints as a signal for this tradeoff. One could perhaps go to the effort to allocate a new set of codepoints in Pool 3, say 0bx11101, for "DSCP Loss/Latency Tradeoff" -- I'd want to get the opinion of someone with some DSCP expertise to say how difficult this would be.

Cheers,

Brian

> On 26 Jan 2016, at 08:30, Youjianjie <[email-masked]> wrote:
> 
> Hi,
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 26 Jan 2016 10:59:22 +0100

> On 26 Jan 2016, at 10:54, Brian Trammell <[email-masked]> wrote:
> 
> hi Jianjie,
> 

+1 - this is exactly Jianjie and I are asking about...  how difficult it would be, and if folks would consider this reasonable

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Tue, 26 Jan 2016 11:09:56 +0100

> On 26 Jan 2016, at 10:59, Michael Welzl <[email-masked]> wrote:
> 
> 

I consider it extremely reasonable, but have no idea how difficult it is. :)

Indeed, since a lot of how we're thinking about how tube properties get implemented by in-network functionality involves things like translating tube information down to DSCP, MPLS labels, etc, having an explicit DSCP *in addition to* a SPUD flag for this tradeoff is a win for everyone IMO.

Even if we designate 0b111101 as "latency sensitive / loss tradeoff" and 0b011101 as "loss sensitive / latency tradeoff", it'll be a (long) while before you get border devices deployed that would strip AF and EF codepoints but let these tradeoff codepoints through. For a lot of platforms I expect you'd need a new configuration language to even be able to tell your firewall to do that. So I still think we need bits in both places for a while.

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Tue, 26 Jan 2016 12:14:15 +0100

> On 26 Jan 2016, at 11:09, Brian Trammell <[email-masked]> wrote:
> 
> 

I agree with everything here.

Cheers
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jan 2016 08:20:02 +1300

> It does not appear that the current definitions of the DSCP codepoints would allow compatible reuse of either a single bit or any of the codepoints as a signal for this tradeoff. One could perhaps…

Can you define the relevant per-hop behaviours precisely? That's the only formal
requirement of RFC2474 section 5.

Are they implementable at line speed?

BTW, the choice between EF and not-EF is to a large extent a latency/throughput choice.
EF is supposed to provide bounded latency and jitter within bounded throughput.
RFC 3248 and RFC 3246 are all about bounded latency.

Low latency, low jitter, high throughput: pick any two.

    Brian C

---

From: Brian Trammell <[email-masked]>
Date: Tue, 26 Jan 2016 21:20:34 +0100

Hi Brian (C),

> On 26 Jan 2016, at 20:20, Brian E Carpenter <[email-masked]> wrote:
> 

There are a couple of possible definitions. The simplest I can think of, which probably has issues in the margins due to the fact that it has to be evaluated per-hop without any accumulated path information:

(1) if the Latency Tradeoff codepoint is set, the device should drop the packet if it would otherwise impart more than N (configurable?) queueing delay. (This is the "don't bufferbloat me!" codepoint, and is the default for hypothetical devices with very short queues and no AQM)

(2) if the Loss Tradeoff codepoint is set, the device should queue the packet for as long as it has buffer capacity. (This is the "please bufferbloat me!" codepoint, and indeed the default for devices with a single big queue and no AQM).

The simplest way to implement this is with two queues: one with a very short queue, one with a much longer queue, with a transmission algorithm that tends to drain the short one first, but does not assign strict priority to the short one. Lots of proposals in this space (indeed, I think discussed in TSV) that would point the way toward the right configuration here.

> Are they implementable at line speed?

Since in the two-queue case it's merely a queueing decision, yes.

> RFC 3248 and RFC 3246 are all about bounded latency.

Thanks for the reply... I briefly looked over these before answering and EF seemed also to request low loss for defined throughput, which is... not really the same thing.

Cheers,

Brian (T)

> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jan 2016 13:21:06 +1300

> (2) if the Loss Tradeoff codepoint is set, the device should queue the packet for as long as it has buffer capacity. (This is the "please bufferbloat me!" codepoint, and indeed the default for devi…

I don't see any intrinsic issue in writing PHB specifications for that. Of course, getting IETF
standards track consensus is another matter.

> Since in the two-queue case it's merely a queueing decision, yes.

Right, which is what I've always seen as the hallmark of deployable diffserv.

> Thanks for the reply... I briefly looked over these before answering and EF seemed also to request low loss for defined throughput, which is... not really the same thing.

True, EF wants a lot (which is why we always assumed it would only be granted a smallish
fraction of link capacity, so that its other requirements would leave plenty of space-time
for other flows).

    Brian