Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim

[Sebastian Moeller <[e-mail]>]

Dear All.

I fully understand the challenges of using DSCPs end to end, and yet DSCPs still seem to be the IETF's endorsed intra-domain and end-to-end marking mechanism (see RFC 2474). Any other marking use-case (like the LE PHB) could lay claim on ECT(1) by the same rationale as L4S as it would be currently more reliable. Sure, L4S could claim that it also uses functionally uses ECN and hence has a slightly stronger claim, but since the L4S arch draft explicitly mentions allowing non-responsive bounded-rate (and hence essentially non ECN-aware) flows in the LL queue it seems clear that ECT(1) in addition to all it's other issues is not really fulfilling L4S's marking needs exhaustively.

That said, the only real uses L4S is likely going to see any time soon, IMHO, are those that have an immediate monetary advantage for the ISP rolling out and operating the L4S infrastructure, and hence SLAs between content suppliers and ISP that make sure to conserve the L4S DSCPs seem like a natural solution to the issue. 
	In the spirit of walking before running it would IMHO behoove the L4S effort not trying to solve all potential problems a priori, but rather experimentally demonstrate that even a restricted scope L4S deployment has actual merits in real life. 

More below in-line.


On March 7, 2020 1:34:22 AM GMT+01:00, Bob Briscoe <[e-mail]> wrote:
> Steve,
> 
> I had audio problems during the chairs slides at the tsvwg interim.
> https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/session/tsvwg
> Now I see the following two comments of yours in the minutes, I'd like 
> to follow-up:
> 
>> - Steve Blake mentioned that L4S could be made compatible with each.
> Can you say more about what's behind this idea? or point me to where 
> you've already said it?
> 
>> - Steve Blake noted anyone running these experiments will tinker with
> 
>> boxes, so may handle the DSCP bleaching concern.
> Unfortunately, that's only partially true. It's fairly true for 
> CDN->user applications. However, for (say) conversational video or 
> online gaming, AR, VR, etc, which are particularly important targets 
> apps, the path is often either accessISP-accessISP or 
> accessISP-cloud-accessISP. Altho most access ISPs nowadays are pretty 
> tightly meshed with other access ISPs (with less intermediaries than 
> there used to be), there are still significant numbers of cases where 
> two access ISPs are not directly connected.
> 
> Anyway, if user B's downstream is the bottleneck for user A, even if
> ISP 
> B doesn't bleach Diffserv, the DSCP is still no use if ISP A bleaches, 
> or if an intermediary does.

	[SM] That really just would show that there is a business case for ISP A and B to connect directly in a DSCP conserving fashion....

> 
> See 
> https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-09#appendix-B.2
> 
> for write-up of the pros and cons.
> 
> Network traversal is already a difficult problem, even with just a very
> 
> few ECN problems. We really don't want to make this impossible. With a 
> 3-part (sender-bottleneck-receiver) L4S deployment, there is already 
> enough deployment barrier without adding Diffserv traversal to make 4
> or 
> more parts (sender-border-bottleneck-receiver). For SCE, there's
> already 
> 4-parts to deploy (tunnels added), so let's not countenance making that
> 
> 5 or more.

	[SM] As mentioned above hat same rationale affects all PHBs that desire end to end persistence. What makes L4S so much more deserving than other PHB's so that the IETF should grant it special preferential treatment? 

	It seems worth mentioning, that today bidirectional FQ on an end user's access link run on the CPE, does already achieve median inter-flow latency-under-load-increases of ~ 5ms, so the incremental gain for switching to L4S will be to get that latency increase down to ~1 ms for LL-flows, while increasing it to 15ms for non-LL flows. These are pretty moderate gains for considerable costs and side-effects! 
	I would love to learn which novel use-cases will be possible by shaving off these additional 4 ms of queueing related delay that will not work with a 5ms target delay? And wonder if any of those that apparently require hard real-time guarantees in the handful of milliseconds range from the network should be run over the shared internet to beginn with independent of the number of parts between the endpoints....?

IMHO, that is orthogonal to the question of how to make 1/p-cc-response type flows equitably share the internet with 1/sqrt(p) type flows. Conflating this by overloading the "I desire LL queueing" marker with the "I will respond in a 1/p-type fashion to CE markings" is really just creating additional unnecessary "coupling" with considerable side-effects. 
As the SCE proposal demonstrates, 1/p and 1/sqrt(p) signaling can concurrently equitably coexist (currently with a few restrictions on propagating signals when decapsulating tunnels), without needing to change the semantics of what CE means, so all this is left to do is solve the orthogonal problem of steering flows into "low-latency" or "besteffort-latency" queues. As far as I understand the IETF's solution for that is DSCP/PHB. 
And for a realistic scope* of an experimental deployment of L4S requiring at least to pair L4S's ECT(1) marking with a DSCP (for the experiment eg out of the "xxxx11" experimental / local use range) does not seem onerous but rather prudent and cautious.

Best Regards
	Sebastian


*) L4S is not going to work well over arbitrary internet paths, period. It does have a decent chance over well curated relativ "short" (measured in hops and/or ASs) path, but over these DSCPs can be made sufficiently reliable already.

> 
> 
> Bob