Re: [tsvwg] Question regarding acceptable sharing behavior between "normal traffic" and L4S traffic --> "see These L4S issues reported are not show stoppers"

[Sebastian Moeller <[e-mail]>]

Hi Koen,


> On Nov 18, 2019, at 12:36, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> Hi Sebastian,
> 
> See mail "These L4S issues reported are not show stoppers". In short: the TCP-Prague requirement "less RTT dependency" covers this. 
> This effect has been reported from the beginning. Not everyone is convinced this is even a problem, rather a feature, as it is the "Normal Internet behavior since 40 year".

	Koen, I believe you might want to re-read my email. I am not arguing about RTT dependence per se, but rather whether L4S meets the consensus "coexisting conditions" to merit roll-out into the internet, given that effectively it will build a low latency, higher bandwidth route between end hosts at the expense of both latency and bandwidth of non-participating flows. 
	Due to the unfortunate design decision to employ a loose coupling between the two queues instead of stricter isolation the artificially inflated RTT for a for normal flows (that dualq introduces under saturating load) puts them a distinct disadvantage in regards to L4S flows, the question hence is:

Does the TSVW community believe that this is acceptable, to declare a new design as "safely coexisting" and "ensur[ing] coexistence" if all that is guaranteed is not to starve the existing traffic?
 
IMHO neither the observed behavior, nor arguing the objections away instead of looking at the fundamental root cause that behavior strikes me as the most efficient/productive possible way forward.
I do want to add, that I even gave a pointer about how the issue might be ameliorated.
	But is it a correct representation of your position that demonstrated unequal sharing  is as designed and hence will not be reconsidered for improvements?


Best Regards
	Sebastian


> 
> Regards,
> Koen.
> 
> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Sebastian Moeller
> Sent: Monday, November 18, 2019 10:18 AM
> To: tsvwg IETF list <[e-mail]>
> Subject: [tsvwg] Question regarding acceptable sharing behavior between "normal traffic" and L4S traffic
> 
> Dear All,
> 
> I have been making an argument repeatedly on this list in different threads to which I received inconsistent feed-back. So, I would very much like to raise this issue explicitly to the full list, as I believe this to be important to address in regards to L4S.
> 
> It has been observed by two independent measurements that the reference dual queue AQM demonstrates RTT-dependent unfairness between L4S and standard TCP traffic, the shorter the RTT the more of a bandwidth-advantage L4S gets.
> At a nominal RTT of 0ms (which as far as I can tell just means no additional netem delay, so a real RTT in the <1ms range) TCP Prague gets ~5-times more bandwidth than TCP cubic:
> The L4S team's measurement:
> https://l4s.cablelabs.com/l4s-testing/key_plots/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_var.png
> The SCE-team's measurement:
> https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-11-11T090559-r2/l4s-s1-2/batch-l4s-s1-2-cubic-vs-prague-50Mbit-0ms_fixed.png
> 
> That leads to my questions:
> 
> A) Is/was everybody aware of this unequal sharing over a nominally equal path? 
> 
> I ask because the following two statements from the L4S-arch and the dualq-coupled I.D.'s seem to indicate a different kind of more equal sharing to me:
> 
> https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-10 :
> "This specification defines `DualQ Coupled Active Queue Management
>  (AQM)', which enables these Scalable congestion controls to safely
>  co-exist with Classic Internet traffic.
> Analytical study and implementation testing of the Coupled AQM have
>   shown that Scalable and Classic flows competing under similar
>   conditions run at roughly the same rate."
> 
> and
> 
> https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-04 :
> "Further, the network part is simple to
>  deploy - incrementally with zero-config.  Both parts, sender and
>  network, ensure coexistence with other legacy traffic."
> 
> In the limit, the dual queue AQM will share traffic between the L4S queue and the normal queue approximately 15:1. Unless coexistence is considered to mean "does not starve" I fail to understand how claims and observed data match up.
> 
> B) Does everybody here think that this what is implied by the above stanzas and that this is an acceptable guarantee to merit allowing/endorsing the use of dual queue AQM over the internet?
> 
> 
> 
> 	Oliver Tilmans helpfully explained, that this behavior is draft-compatible but relies on a specific interpretation of "under similar conditions", once the queue under load is taken into consideration the RTT ration goes from 1:1 to 1:15 and hence the observed bandwidth sharing is considered acceptable due to conditions not being similar enough any more. 
> 
> I have two issues with that rationale:
> 
> 1) this does not seem to be the natural way to read that claim (Oliver mentioned that he had the same question/observation when he started to look into dualq, so my reading of the text is not completely outlandish)
> 
> 2) It is to a large degree a consequence of a design decision in the dual queue AQM that does not seem to have been sufficiently thoroughly considered.
> 	The point is that dual queue simply copies the recommendation to set the target for the "normal queue's" pie instance to 15 milliseconds (simply copying from QDELAY_REF in https://tools.ietf.org/html/rfc8033#appendix-B) without taking the consequence into consideration how this affects bandwidth sharing behavior between the two queues at short RTTs. According to codel's theory (https://tools.ietf.org/html/rfc8289#section-4.3) target should be set to ~5-10% of the interval, so instead of 15 ms, 5 ms probably should do to maintain bandwidth utilization while at the same time addressing part of the root cause for unequal sharing at low RTTs. It is well possible that 5ms will not wrk for a PIE derivative shaper like dualQ, but this should at least be explored before designing an undeserved advantage for L4S into the specifications.
> 
> 
> Best Regards
> 	Sebastian
> 
> 
> 
>