Re: [tsvwg] ECN as a classifier

[Bob Briscoe <[e-mail]>]

Jonathan,

On 31/12/2019 17:42, Jonathan Morton wrote:
>> On 31 Dec, 2019, at 6:55 pm, Bob Briscoe <[e-mail]> wrote:
>>
>> However, the original RFC3168 ECN architecture (that is incompatible with SCE) remains and will remain more widely supported in the Internet, probably for decades. Indeed, even today, the RFCs to make that change to all encapsulations (not just IP-in-IP tunnels) are not past the WG stage yet.
>>
>> Tunnels and encapsulations are everywhere. Jonathan M says it doesn't matter if the SCE signal gets black-holed in tunnels and encapsulations.
> It's not that it doesn't matter at all - erasing the SCE signal would degrade the behaviour to RFC-3168 standard.  But that's an acceptable fallback position which allows for incremental deployment, even before all the tunnels are upgraded to the new standard.
>
> Thus the existing RFC-3168 compliant architecture is *not* incompatible with SCE as you claim.  So please don't claim that, when it isn't true.
You can say SCE is backward compatible with 3168 tunnels. But it is 
disingenuous to say it the other way round - that 3168 tunnels are 
compatible with SCE. Because many/most people will understand this to 
mean that 3168 tunnels are compatible with what SCE aims to achieve.

(An analogy would be to claim that a bare FIFO queue is compatible with 
ECN, which it isn't. Yes, ECN is backward compatible with FIFO queues, 
but not the other way round.)

When you say the 3168 architecture is compatible with SCE, you have 
quietly defined what SCE aims to achieve as "either SCE or 3168 
performance". This allows you to make a statement that only reveals the 
good part of a truth that is mostly bad. I have noticed you play with 
words like this a lot, presumably because you think that you might fool 
some casual observers.


To state the whole truth you ought to say, if a 3168-architecture tunnel 
contains the SCE bottleneck, until the tunnel is updated to support the 
SCE architecture SCE will always fall back to 3168 performance.

This adds up to 4 independent upgrades being needed before SCE can 
provide any benefit: sender, receiver, bottleneck AQM and potentially 
tunnel as well. Worse, tunnel processing is typically implemented in 
hardware. But you always describe SCE as a minor change.

Happy New Year




Bob
>
>   - Jonathan Morton

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