Re: [tsvwg] Update to Position Statement on ECT(1)

["Holland, Jake" <[e-mail]>]

Hi Mike,

On 5/21/20, 8:07 PM, "C. M. Heard" <[e-mail]> wrote:
>> This sounds to me like “whoops, we have made a terrible mistake by
>> defining the tunnel semantics in such a way that only one wire signal
>> (CE) can be transported [...]"
>
> While I broadly agree with Jake's points, I don't think this last part
> is quite right. Some of the trimmed text provided what I understand to
> be the principal objection to the ECT1->0 proposal:

Thanks for the correction, Mike.  I agree having now looked closer that
in Section 4.2 of RFC 6040 an ECT(0)->ECT(1) transition in the outer
header is preserved at tunnel egress, but not an ECT(1)->ECT(0) signal.
https://tools.ietf.org/html/rfc6040#section-4.2

I guess with hindsight it's not clear to me why the outer signal
shouldn't have overwritten either one of those transitions for better
future compatibility with signals that hadn't yet been defined, but I
can see how in the context of PCN it would have been an unclear
decision, and introduces some risk of undoing a pre-congestion mark
in the inner tunnel's PCN domain, which has to be considered a downside.

> RFC 6040 adopted the rule that ECT(1) overrides ECT(1) at tunnel egress
> because ECT(1) was used at the threshold mark in the pre-congestion
> notification work leading up to RFC 6660. So indeed there is standards
> track work that would have to be deprecated in order for the ECT1->0
> proposal to move forward.

Agreed, I didn't mean to try to sweep that under the rug, and sorry if
that's how it came out.  Thanks for highlighting the point.

However, although I could be mistaken here, I don't think these points
would pose the same risks to effective congestion control that the
deprecation of the proposed RFC 3168 ECT(1)->CE transition (or more
precisely, the associated response of an L4S-compatible scalable flow
going through a classic queue and responding as if it's dualq marking;
it's not just TCP Prague, I think it's inherent to the generalized 1/p
response of the expected scalable congestion controllers described in
section 2.1 of aqm-dualq-coupled-11.)

> The choice of ECT(1) rather than ECT(0) as
> the PCN threshold mark (and the resulting tunnel egress behavior in
> RFC 6040) was a natural choice at the time and is perfectly compatible
> with SCE (without the bits reversed). It was in hindsight a suboptimal
> choice, but that was not in any was the fault of the L4S community.

Agreed, I didn't mean to imply any fault here.

Anyway, thanks for the overall support on the broader points raised,
it's nice to hear that someone thinks I'm making some sense on some
parts of this thread.  I'm not always completely sure from this
side... :)

Best regards,
Jake