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

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

Hi Alex,

On 5/8/20, 3:59 PM, "[e-mail]" <[e-mail]> wrote:
> However it occurs to me that the ECT(1) (and CE) could still be used as a classifier in the following way:
> Have the Prague sender premark 50% of packets with CE, in an order known to the receiver (eg, alternating).
> The L4S AQM and the RFC3168 would then only be able to mark different packets, so  the receiver can then determine with good confidence whether any CE marked packet was 'originally' ECT(1), and if so, it must have been marked by a RFC3168 
> AQM. (At this point the sender should revert to RFC3168 and stop sending premarked CE packets).
>
> This has the advantage of over A) that the classification signal is not lost after the first bottleneck. However it has the same problem with tunnels, and I can see some additional issues:

I'm not sure I follow the specifics here--neither a L4S AQM nor a classic
queue would re-mark anything that's CE.  Did you mean that there would be
ECT(0) in a known part of the packet stream that would be used as an active
probe for classic queue-marking?

An ongoing active probe is a potentially interesting idea I haven't seen
considered.  I think there are a lot of potential complications there, but
I can see that it might be possible to get a better signal on presence of a
classic queue at a bottleneck than from a purely heuristic detection algorithm.

> Although the classification would be preserved across L4S AQMs, conditions of an L4S AQM followed by an RFC3168 AQM (or vice versa) could cause some congestion marks to be "undone". However this could only occur until the RFC3168 AQM was detected. IT woudl not be caused my multiple AQMS of the same type.

Are you imagining an ongoing probe that permanently cuts over to a classic
marking style as soon as a classic queue is detected?

> CE has up till now been a fixed point (no transitions away from CE) so there may be other network elements which are surprised by transitions away from it.

Yes, if something transitions away from CE, it seems incompatible with
RFC 3168 queue markings.  I'm not sure offhand what the pathologies would
look like, but I'd be similarly skeptical it could end well.

> Anyway, hope that is of interest.

Thanks for the comment, I think there's maybe an interesting idea in there,
though I'm not sure I quite grasped how it would work.

Best,
Jake