Re: [Spud] One bit for latency bandwidth tradeoff

[Michael Welzl <[e-mail]>]

Thanks a lot Roland!

More below -

> On 26 Jan 2016, at 17:36, Bless, Roland (TM) <[e-mail]> wrote:
> 
> Hi Michael,
> 
> [see comments inline...]
> 
> Am 26.01.2016 um 10:11 schrieb Michael Welzl:
>>> On 26 Jan 2016, at 09:50, Bless, Roland (TM) <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> Am 26.01.2016 um 08:30 schrieb Youjianjie:
>>>> 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?
>>> 
>>> 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.
> 
>> 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.
> 
>>> 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.
> 
>> 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).

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