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

On Sat, Nov 28, 2020 at 3:15 AM Alexander Azimov <a.e.azimov@gmail.com> wrote:
>
> Gentlemen,
>
>> At the very least, one should analyze the case where in #1, a packet
>> gets delayed, you change the FL and retransmit, and finally you get a
>> response to the original packet (and/or to both packets).
>
> As the suggestion strictly speaks about changing FL upon RTO timeouts I don't see how it differs from getting two responses in case of RTO without FL change. Nothing special here.
>
>> If you have two links, then, upon change of the FL, you have 50% change
>> that the path will be different -- not good.  What would you do if the
>> failure continues? -- keep changing the FL?
>
> Yes, and if only one path is affected - you have a chance of hitting a good path with 1 - (1/2)^n. And it's much better than nothing.
>
>> > If a retransmitted SYN goes to another server/anycast point this won't bring much harm. At least we haven't experienced such problems in our datacenters.
>> I think depends on details that are definitively out of the IETF's scope. When exactly does the load balancing system assign a session to a given server, how much state does that create, what resources does it reserve, and when are the state and the reserved resources released?
>> Also, in some cases, I could imagine that the data centre will not see a problem, but the client might see one that they would not otherwise have seen.
>
> I can't say that these details look convincing to me. I also can't agree that operational considerations are out of IETF's scope. The protocols are designed with real operations in mind, aren't they?
>
>> Steering packets is the network's job. People like me who run the network expect to be in charge of that. We have fancy mechanisms that mean alternate paths are switched to very quickly.
>
> 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.

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. 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).

Tom

>
>
> сб, 28 нояб. 2020 г. в 11:42, Fernando Gont <fernando@gont.com.ar>:
>>
>> On 28/11/20 03:42, Mark Smith wrote:
>> >
>> >
>> > On Sat, 28 Nov 2020, 14:52 Fernando Gont, <fernando@gont.com.ar
>> > <mailto:fernando@gont.com.ar>> wrote:
>> >
>> >     On 27/11/20 21:32, Mark Smith wrote:
>> >      >
>> >      > On Sat, 28 Nov 2020, 10:32 Tom Herbert, <tom@herbertland.com
>> >     <mailto:tom@herbertland.com>
>> >      > <mailto:tom@herbertland.com <mailto:tom@herbertland.com>>> wrote:
>> >     [....]
>> >      >
>> >      > If hosts start trying to take control of steering traffic by
>> >     varying the
>> >      > flow label value within a flow, making the network's job harder,
>> >     and the
>> >      > network being blamed for the possibility bad network performance
>> >     that
>> >      > may result, the response will be both quick and easy - network
>> >     operators
>> >      > will switch off looking the Flow Label.
>> >
>> >     THat is *exactly* why I noted that I'm concerned that we seem to be on
>> >     the path of making the FLow Label unusable.
>> >
>> >
>> > I see the Flow Label as a hint, but only a hint, of what the hosts wants
>> > from the network. It's useful as an expression of what the host would
>> > like to have.
>>
>> As you correctly noted, it's supposed to be an identifier of the flow,
>> because it's hard to get for the port numbers.
>>
>> I don't think it can bee seen as ad expression of what the host wants to
>> ahve, because the Flow ID has no semantics, and the host doesn't even
>> know what's in the network.
>>
>>
>>
>> > However, if that hint causes me any trouble, I'll ignore it and then
>> > devolve to trying to deliver the packet based just on its destination
>> > address.
>>
>> If you *needed* (or could make use of) the FL, then, if it causes
>> trouble, you either resort to finding the five-tuple, or quite likely
>> end of dropping packets.
>>
>> Thanks,
>> --
>> Fernando Gont
>> e-mail: fernando@gont.com.ar || fgont@si6networks.com
>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> --
> Best regards,
> Alexander Azimov