Re: [Spud] One bit for latency bandwidth tradeoff

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) <roland.bless@kit.edu>:
> 
> 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. 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
> 
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud