Hi Jonathan,
thinking this over, I wonder whether a hypothetical carrier grade cake, might
not actually grow a classify-by-vlan-priority keyword to allow switching over
to using VLAN priority tags instead of dscps? That would avoid tempting
carriers to re-map deeep-encapsulated dscps if they can just ignore them for
good. And it scratches my pet itch, that 3 bits of classification should be
enough for >80 % of the cases ;)
What do you think?
Best Regards
Sebastian
P.S.: I reduced the CC list since I doubt that netdev is the right venue for
mere hypotheticals ;)
> On Jun 26, 2020, at 15:11, Jonathan Morton <[email protected]> wrote:
>
> Toke has already replied, but:
>
>> Sure, my proposal does not cover the problem of mangling the CE bit inside
>> VLAN-tagged packets, i.e. if we should understand if qdiscs should allow
>> it or not.
>
> This is clearly wrong-headed by itself.
>
> Everything I've heard about VLAN tags thus far indicates that they should be
> *transparent* to nodes which don't care about them; they determine where the
> packet goes within the LAN, but not how it behaves. In particular this means
> that AQM should be able to apply congestion control signals to them in the
> normal way, by modifying the ECN field of the IP header encapsulated within.
>
> The most I would entertain is to incorporate a VLAN tag into the hashes that
> Cake uses to distinguish hosts and/or flows. This would account for the case
> where two hosts on different VLANs of the same physical network have the same
> IP address.
>
> - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
