Re: [tsvwg] Dual-Q Pol[i]cing

[Paul Vixie <[e-mail]>]

On Monday, 25 May 2020 17:08:55 UTC Gorry Fairhurst wrote:
> On 25/05/2020 17:33, Paul Vixie wrote:
> > On Monday, 25 May 2020 16:21:17 UTC C. M. Heard wrote:
> >> On Mon, May 25, 2020 at 8:50 AM Paul Vixie wrote:
> >>> On Monday, 25 May 2020 10:00:30 UTC Sebastian Moeller wrote:
> >>>> ... 
> >> 
> >> Because it may inform the conversation, is your current policy to disable
> >> ECN marking and/or to bleach ECN bits out of inbound traffic from the
> >> WAN?
> >> Per RFC 3168, those bits are intended to affect drop vs mark behavior of
> >> routers.
> > 
> > no. i'm following choice other, which is, don't enable those features.
> 
> Thanks. That's your choice, and I have seen networks that have made
> similar choices for various reasons, and ones that have not made those
> choices.

i've called this a datacenter/cloud signal pattern and some of you have 
wondered why. one reason is trust. see also rod grimes' reply up thread 
<[e-mail]> mentioning yandex and netflix. 
but none of these decisions is simple; we have to look at potential added 
risks as well as potential added benefits. if the latter seems orders of 
magnitude greater than the former, then we may decide to accept the risks.

in dualq i'd perhaps see microsecond delivery on the fast path and millisecond 
delivery on the slow path. that difference could be relevant for traffic which 
is both sourced and sunk nearby or inside my network. however, it will never 
be relevant for arriving WAN traffic, whose speed-of-light constraints while 
reaching me will far exceed the difference between my slow and fast queues.

so even if i had no fears of having the configuration of my switches or 
routers set, however briefly (on a packet by packet basis) by a non-contracted 
unidentified third party, i would also see no benefit to allowing congestion 
signaling as input to my network other than from my own nearby/internal hosts. 
that's also true of output from the network to my endpoints, since congestion 
notification signals are also game-worthy. but less so, and i can imagine at 
least looking at the SCE running fraction in my transport, and considering it 
as a possible reason to reduce window size. that will never happen for the L4S 
pattern when it comes from the WAN, for reasons as given.

-- 
Paul