Re: [tsvwg] FQ & VPNs

[Sebastian Moeller <[e-mail]>]

Hi Tom,

> On Feb 21, 2021, at 23:33, Tom Henderson <[e-mail]> wrote:
> 
> On 2/21/21 11:10 AM, Jonathan Morton wrote:
>>> On 21 Feb, 2021, at 8:56 pm, Tom Henderson <[e-mail]> wrote:
>>> 
>>> 1) upstream a patch to the Linux kernel (and ask other OS vendors to do similarly) to treat ECT(1) as not-ECT
>>> 2) later add options to enable alternative semantics of ECT(1)
>>> 
>>> I don't see any reason to postpone the first step.
>> I do.
>> RFC-3168 specifies that routers "treat ECT(0) and ECT(1) as equivalent".  So implementing this first step would cause these Linux AQMs to violate RFC-3168.  I'm sure the kernel maintainers will be justified in rejecting patches on that basis.  Certainly I would raise such objections were such a patch to come to my attention.
>> To make that objection go away, you must first update and obsolete RFC-3168 so that it no longer contains that requirement.  That requires convincing the IETF that it's a good idea.  Again, I will maintain that it is a spectacularly bad idea.
> 
> Jonathan,
> I do not see any practical downside to disabling classic ECN response to ECT(1).  I have thought about writing a draft on this point or suggesting an errata to RFC 8311 on it, but decided to raise it here now.
> 
> There is a point in RFC 8311 (section 2.2 point 1) that says that treating ECT(0) and ECT(1) as equivalent is the preferred behavior.
> 
> However, point 3 says that hosts MUST NOT originate ECT(1) traffic according to old semantics.  Furthermore, the IANA protocol registry says that ECT(1) is for experimental use only.  I have been considering whether the above two points are sufficient in themselves to justify such a Linux patch.
> 
> The data that Pete Heist just published also would seem to support taking the step I suggested.  It seems to me that if the WG wants to support L4S experiments of any flavor, it would support first disabling the classic response to ECT(1).

	[SM] Why? Honest question. Sure L4S requires exclusive access to ECT(1) but in SCE promoting a weak ECT(1) to a stronger CE at a later node seems like exactly the right behavior. 

Sebastian



> 
> - Tom