Subject: [Spud] 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: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 26 Jan 2016 09:50:16 +0100

Hi,

Am 26.01.2016 um 08:30 schrieb Youjianjie:
> For example:
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=923942
> 
> 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?

I think one should distinguish between different cases, e.g.,
- Application wants low latency transport
- Application needs bulk transfer and insensitive to latency
- Application uses a congestion control algorithm for achieving low latency
- etc.

Moreover, there may exist high-bandwidth applications that also require
low latency, so that you don't have a tradeoff situation.
One bit isn't enough to distinguish that properly.

In the DiffServ architecture you better should exactly describe what
kind of per-hop behaviour (PHB) you want for packet treatment. Then
you could use a DSCP that points to that PHB. The EF PHB is also
offering a low delay service, but usually requires admission control,
policing and non-bursty flows. An indication of the transport protocol
that it's going to use a low-delay congestion control mechanism
is a completely different thing.

I think it would be useful to have a possibility to separate
flows with incompatible congestion control mechanisms, i.e.,
to put them into separate queues. We did some experiments
and were able to achieve bandwidth fairness while keeping the
delay for the low-delay congestion controlled flows much lower
compared to the loss-based congestion controlled flows.

Regards,
 Roland

---

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

> On 26 Jan 2016, at 09:50, Bless, Roland (TM) <[email-masked]> wrote:
> 
> Hi,
> 
> policing and non-bursty flows.

The idea is to provide something simple that avoids having to use admission control etc. - no QoS in the sense: "you pay more, you get more", but a trade-off where there's no incentive to lie, and the more routers support it, the better, generally.

> An indication of the transport protocol

This sounds as if you're thinking about something slightly different than us. The question isn't about "how can I protect my delay-based congestion control mechanism from loss-based mechanisms" but about "how could I say: drop me if you must, but don't delay me, I prefer that". That seems pretty binary to me, and as the papers that Jianjie pointed at show, this simple binary logic can be good enough for a beneficial outcome.

So... any DSCP value that could reasonably be used for that?  I mean, in a way, what this is asking for is to simply give some packets a high drop precedence, but without associating them with a specific (usually admission controlled) DiffServ PHB, I guess...

Cheers
Michael

---

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: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 26 Jan 2016 17:36:55 +0100

Hi Michael,

[see comments inline...]

> The idea is to provide something simple that avoids having to use
> admission control etc. - no QoS in the sense: "you pay more, you get
> more", but a trade-off where there's no incentive to lie, and the more
> routers support it, the better, generally.

I was just pointing to the fact that there are many ways of achieving a
low latency service and that a DSCP normally points to a PHB definition.

> This sounds as if you're thinking about something slightly different
> than us. The question isn't about "how can I protect my delay-based
> congestion control mechanism from loss-based mechanisms" but about "how
> could I say: drop me if you must, but don't delay me, I prefer that".

Thanks for clarification. I just gave an example that the latency vs.
throughput could mean various things and it's better to exactly define
the intended behavior. We already had a very fuzzy indication with the
ToS bits and that didn't work out very well in practice. So the "drop
me if you must, but don't delay me, I prefer that." policy can be
realized in various ways and one should be more precise what that means.

> That seems pretty binary to me, and as the papers that Jianjie pointed
> at show, this simple binary logic can be good enough for a beneficial
> outcome.
> 
> So... any DSCP value that could reasonably be used for that? I mean,
> in a way, what this is asking for is to simply give some packets a high
> drop precedence, but without associating them with a specific (usually
> admission controlled) DiffServ PHB, I guess...

Usually, admission control is only required for achieving strict
guarantees, so a PHB definition doesn't require that. However,
specifying queues, their behavior/management and scheduling mechanisms
for such a forwarding strategy is exactly what a PHB definition
describes (at least).

Regards,
 Roland

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 26 Jan 2016 17:52:47 +0100

Hi,

the idea for signaling here is to use a field/bit in some kind of new spud shim-layer/header where the intention is to have a way to explicitly communicate with middleboxes (instead of using whatever they can find in other headers). Other than DSCP, we do not assume any guarantees or specific treatment regarding what the network/middlebox will do with this information; it’s simply an indication by the endpoint to the middle. 

Further having a low latency vs. low drop signal, always provides a trade-off. Of course that’s not optimal for all applications but could help a lot of them a lot. And having this trade-off there is also no incentive and no advantage in lying about this information (as an application would simply get the wrong treatment while there nothing like a priority assigned here).

Mirja

> Am 26.01.2016 um 09:50 schrieb Bless, Roland (TM) <[email-masked]>:
> 
> Hi,
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

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

Thanks a lot Roland!

More below -

> On 26 Jan 2016, at 17:36, Bless, Roland (TM) <[email-masked]> wrote:
> 
> Hi Michael,
> 
> [see comments inline...]
> 

Ah ok! If I interpret this correctly, this means that if we need something probabilistically, we should just go ahead and DSCP-mark as desired, maybe using table 1 in https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-10  right?
(not at all unreasonable, I think)

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)

---

From: Michael Welzl <[email-masked]>
Date: Tue, 26 Jan 2016 21:37:34 +0100

> On 26. jan. 2016, at 17.52, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi,
> 

Just like draft-ietf-tsvwg-rtcweb-qos, I’d think?! Also no guarantees there…

> Further having a low latency vs. low drop signal, always provides a trade-off. Of course that’s not optimal for all applications but could help a lot of them a lot. And having this trade-off there…

To me, that’s what makes the idea so attractive (as in the papers Jianjie pointed to). It makes me wonder, are there lying incentives in draft-ietf-tsvwg-rtcweb-qos ?

Cheers,
Michael

---

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