Re: [Ecn-sane] Meanwhile, over on NANOG...

["Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>]

> Luca Muscariello <muscariello@ieee.org> writes:
> 
> > TCP anycast fails in this case and I would not blame the load balancer for
> > that.
> > Some people will have a different opinion on that.
> >
> > The current Internet just does not support well these use cases.
> >
> > At the same time this DNS service is supposed to be used in a different
> > way. So we may even blame the user? Toke in this case ?
> >
> > DNS anycast works as long as it uses UDP.
> > The IP address returned by the resolver should be unicast and TCP should
> > run over unicast addresses.
> >
> > Toke,  Looks like you are doing an HTTP GET directly toward an anycast
> > address. This is where things are supposed to break and they break.
> 
> I was just using 1.1.1.1 as a convenient example because it's easy to
> type. I get the same behaviour to an actual web site hosted on
> Cloudflare (which is how I discovered it in the first place). Cloudflare
> makes heavy use of anycast, including to its HTTP endpoints.
> 
> > If you traceroute over unicast addresses you should see the load
> > balancer providing stickiness.
> 
> As I replied to Rod, the non-stickiness was indeed user error on my
> part. The problem is that the load balancer is hashing on headers
> including the ECN bits.
> 
> I guess I'll go reply to the NANOG thread... :)

While your over dealing with the Operators, could you get a few of
them to show up on tsvwg and say how bad an idea using ECT(1) as
a traffic classifier for admission to a L4S service is?

It is that group of people that has the greatest experience with
how you can not trust end nodes in how to treat traffic, especially
when that treatment MAY have some form of advantage, no matter how
trivial that advantage.
 
We need this group to be vocal, or L4S is going to end up doing
just that, and it is the NOG's that are gona get hurt.

> -Toke
-- 
Rod Grimes                                                 rgrimes@freebsd.org