Re: [Spud] [tsvwg] One bit for latency bandwidth tradeoff

[Brian Trammell <[e-mail]>]

> On 26 Jan 2016, at 10:59, Michael Welzl <[e-mail]> wrote:
> 
> 
>> On 26 Jan 2016, at 10:54, Brian Trammell <[e-mail]> wrote:
>> 
>> 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.
> 
> +1 - this is exactly Jianjie and I are asking about...  how difficult it would be, and if folks would consider this reasonable

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