Subject: Re: [tsvwg] DualQ and DCTCP

From: Bob Briscoe <[email-masked]>
Date: Tue, 6 Nov 2018 10:04:10 +0000

Nicolas [and adding the tsvwg list with permission], inline...

On 05/11/2018 10:52, G Fairhurst wrote:
> Ask. Since you are an author of RFC 7928, I'd appreciate any questions 
> that may help understand if things need further/better explanation...
>
> Gorry
>
>
> On 05/11/2018, 15:31, Kuhn Nicolas wrote:
>>
>> Hi,
>>
>> You asked for opinions on the DualQ and DCTCP so as where/how to move 
>> it forward.
>>
>> Here are my 2cts. I am available during the week to speak about it if 
>> I am not clear.
>>
>> If this is relevant, let me know and I could push these questions to 
>> the list.
>>
>> -1 : Do we have papers and experiments on DCTCP performance when it 
>> is associated to a low class (e.g. background) in the Diffserv model ?
[BB] I'm not aware of any at all.

[Researcher hat on,
One of my goals in adding paced chirping to DCTCP (see iccrg @ietf-103) 
is so that it works much better over less effort (LE), even tho it's not 
my current focus.

Explanation: When foreground flows finish, background flows need to be 
able to bounce back fast, to use the empty periods quickly. So, as soon 
as a flow gets no congestion signals, it can start paced chirping and 
rapidly find the newly available capacity. The particular usefulness of 
scalable CCs like DCTCP is the generally frequent level of ECN marking 
(avg 2 marks/RTT), so detecting when congestion has stopped takes 
1-2RTT. With the sawteeth of say Cubic lasting hundreds of RTT, it takes 
hundreds of RTTs to know that you aren't going to get the next one.
]

>>
>> -2 : The proposed approach does not consider the SLA of each user – 
>> could it be relevant to present a multi-user view ?
[BB] An excellent point, that allows me to explain really clearly:

There is no SLA because the sender marks the packet not to mean, "I need 
x" or "I want x" but to mean "I am behaving as x".

The network provides as low delay as possible where there is not a 
queue, but it says "the queue is down to you (the sender), not me."
With queue protection, it also says "I will protect you from others 
building a queue, and I will protect them from you".

>>
>> -3 : For operators-level deployment of DCTCP along with DualQ, you 
>> may want to consider the TCP-proxy case in SATCOM or cellular networks.
[BB] It's a good point - that you only need good congestion control 
across the link(s) where the bottleneck is (given we don't have an e2e 
one that scales for all scenarios).

>>
>> I do not know if I am relevant but I can review some of the documents 
>> if needed.
[BB] Thank you very much. And, of course you are (very) relevant.
Not only do many people in rural areas depend on satellite but, as I 
just said in MAPRG, problems with high BDP on satellite are the canary 
in the coal mine for problems with future higher bandwidth links, even 
over more 'normal' terrestrial distances.

Bob

>> Cheers,
>> Nicolas KUHN
>> CNES/DSO/NT/ST
>> (+33)5 61 27 32 13

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Kuhn Nicolas <[email-masked]>
Date: Thu, 8 Nov 2018 02:14:16 +0000

Bob, 

Thanks for the reply. 
See inline for more comments. 

-----Message d'origine-----
De : Bob Briscoe <[email-masked]> 
Envoyé : mardi 6 novembre 2018 11:04
À : Kuhn Nicolas <[email-masked]>
Cc : G Fairhurst <[email-masked]>; Black, David <[email-masked]>; tsvwg IETF list <[email-masked]>
Objet : Re: DualQ and DCTCP

[BB] I'm not aware of any at all.
[NK] If anyone is the list has papers/pointers on this issue, this would be relevant for the discussion. QoS and other layer 2 mechanisms may induce strange loss/latency patterns that would impact congestion controls estimations (and e.g. the value of RACK reordering window or others metrics used by DCTCP).  

[Researcher hat on,
One of my goals in adding paced chirping to DCTCP (see iccrg @ietf-103) is so that it works much better over less effort (LE), even tho it's not my current focus.

Explanation: When foreground flows finish, background flows need to be able to bounce back fast, to use the empty periods quickly. So, as soon as a flow gets no congestion signals, it can start paced chirping and rapidly find the newly available capacity. The particular usefulness of scalable CCs like DCTCP is the generally frequent level of ECN marking (avg 2 marks/RTT), so detecting when congestion has stopped takes 1-2RTT. With the sawteeth of say Cubic lasting hundreds of RTT, it takes hundreds of RTTs to know that you aren't going to get the next one.
]
[NK] I agree with the issue of getting "up to speed" with loss-based CC. I see your point that when some QoS is brought up to the transport layer, you could simplify the QoS and may not need complexed diffserv architecture. However, operator want (?) QoS metrics for different type of traffics that may have other networks needs than just fairness between end user, such as low jitter for interactive traffic (speaking of end user fairness here, not flow rate fairness - I know your view on flow rate fairness :)). Even if works on LBE CC such as LEDBAT (or CDG with the good option) are interesting in single queue networks, if DiffServ-like QoS mechanisms are considered, a LBE code point would do the job. 

>>
>> -2 : The proposed approach does not consider the SLA of each user - 

There is no SLA because the sender marks the packet not to mean, "I need x" or "I want x" but to mean "I am behaving as x".

The network provides as low delay as possible where there is not a queue, but it says "the queue is down to you (the sender), not me."
With queue protection, it also says "I will protect you from others building a queue, and I will protect them from you".

[NK] I get it. Having senders providing more info on how they behave is interesting and could - indeed- be efficiently used within networks. 
The responsibility of providing a good service would then be in the hands of the server, not the operator.
My issue in this approach is that operators :
- provide jitter guarantees for certain type of traffic 
- have to prioritize some traffic (e.g. control messages)
- are the entry point to end users when there are performance issues
 
For these reasons, it may difficult for them to "get rid" of QoS mechanisms. 
In LTE access networks, when you have aggregates of users, it may be challenging - mostly because of this QoS issue.
  
You may want to provide more details on specific use-cases where this approach can be incrementally deployed.   
One use case could be home CPE before the Wi-Fi hop or tunnels. 

>> may want to consider the TCP-proxy case in SATCOM or cellular networks.
[BB] It's a good point - that you only need good congestion control across the link(s) where the bottleneck is (given we don't have an e2e one that scales for all scenarios).
[NK] For GEO satellite accesses, we can usually know where the congestion is. 

[BB] Thank you very much. And, of course you are (very) relevant.
Not only do many people in rural areas depend on satellite but, as I just said in MAPRG, problems with high BDP on satellite are the canary in the coal mine for problems with future higher bandwidth links, even over more 'normal' terrestrial distances.
[NK] Thanks for that ! 

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 8 Nov 2018 09:02:50 +0000

Nicolas,

> One use case could be home CPE before the Wi-Fi hop or tunnels.

You still have the choice to offer an SLA - see 4.2. DualQ Complemented 
by a Guaranteed Low Latency Service 
<https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-02#section-4.2> 
in the L4S-Diffserv draft.

Nonetheless, L4S is designed on the basis that statistical assurances 
end-up meeting requirements more often than guarantees (because they are 
simpler, well-understood and well-studied, whereas guaranteed services 
become niche market and require complex, brittle infrastructure).

For instance, an alternative for an operator would be to run the L4S 
service with virtual queue ECN-marking, sacrificing of 1-2% of capacity. 
It could then keep the load just slightly under capacity nearly all the 
time, so statistical assurances of low delay would be extremely strong.

Bob

---

From: Kuhn Nicolas <[email-masked]>
Date: Fri, 16 Nov 2018 07:50:50 +0000

Bob,

De : Bob Briscoe <[email-masked]>
Envoyé : jeudi 8 novembre 2018 10:03
À : Kuhn Nicolas <[email-masked]>
Cc : tsvwg IETF list <[email-masked]>
Objet : Re: DualQ and DCTCP

Nicolas,

You still have the choice to offer an SLA - see 4.2.  DualQ Complemented by a Guaranteed Low Latency Service<https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-diffserv-02#section-4.2> in the L4S-Diffserv draft.
[NK] Thanks for the clarification. This is an interesting approach to simplify QoS mechanisms within aggregation networks.

Nonetheless, L4S is designed on the basis that statistical assurances end-up meeting requirements more often than guarantees (because they are simpler, well-understood and well-studied, whereas guaranteed services become niche market and require complex, brittle infrastructure).

For instance, an alternative for an operator would be to run the L4S service with virtual queue ECN-marking, sacrificing of 1-2% of capacity. It could then keep the load just slightly under capacity nearly all the time, so statistical assurances of low delay would be extremely strong.
[NK] I see your point. Thanks for making that clear – it was not clear when I first wanted to have insights on impacts on SLA guarantees. This was in the draft but not in the presentations – my fault, sorry.

Bob

--