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

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.

сб, 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