Re: [v6ops] [tcpm] Flow Label Load Balancing

[Fernando Gont <[e-mail]>]

Tom,

On 28/11/20 15:27, Tom Herbert wrote:
[....]
>> While not questioning innovative technologies that take care of traffic, a 'good' repair time counts in seconds. 'Bad' repair time, when the control plane becomes broken or a famous silent drop happens counts in minutes and requires a network engineer to be summoned. If TCP can fix itself in milliseconds - it's great. And it is needed by real operations. You also missing part when something happens outside of your domain, where you can't instantly summon an engineer. If you tell me that you've been never affected by the network outage of your peering partner I will be greatly suprised.
>>
> +1
> 
> I would also point out this feature has been in deployment for at
> least five years in at least two hyperscalers-- there has been no
> major meltdown. We'll make the feature opt-in because we may be
> exposed to non-conformant devices in the network that make incorrect
> assumptions, but I have yet to see any convincing argument that we
> should remove the feature becauses it's fundamentally harmful or not
> providing benefits.

It breaks FL-based load-sharing.



> As for the mentality of "the network will fix the problem", that's
> obviously an easy statement to make from a router vendor point of
> view, but that luxury simply doesn't match the realities of how host
> stacks are implemented deployed at global scale.

Not sure what you mean. We rely on that for the current Internet (hosts 
do not do source-routing).



> This starts with the
> fact that there is no such thing as "the network"; Linux stack for
> instance needs to run on every network on Earth and I have no idea
> which of these networks provides adequate security, fault detection
> and repair, are well managed, or even have devices that conform to the
> standards (non-conformant network devices are common). The only
> recourse we, i.e. host side developers, have is to stick with the
> least common denominator in the general case, and allow optional, but
> still protocol conformant, features in limited use cases such as
> limited domains (hence why the flow label modulation feature should be
> optional as we've already established in this thread).

Modulo the comments I've already made, I'm afraid we might be in the 
path of making the FL unusable...

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1