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

Alexander Azimov <a.e.azimov@gmail.com> Sat, 28 November 2020 10:15 UTC

Return-Path: <a.e.azimov@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121263A09CF; Sat, 28 Nov 2020 02:15:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCLBI1v714-W; Sat, 28 Nov 2020 02:15:06 -0800 (PST)
Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ABD3A09D1; Sat, 28 Nov 2020 02:15:05 -0800 (PST)
Received: by mail-oi1-x243.google.com with SMTP id w15so8581353oie.13; Sat, 28 Nov 2020 02:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zbbSXTw6J2WlwBxKU5jp8a9Qh4yv9XE2pdrbPYNjLYw=; b=JYYpTQDlk7uZCVbajlVoKu/lqtTbwV2h9rZpefklzIhNiFu9RZ65W/Hhi9lHGl6VV6 ecdQlOpHLgD5AdAtiAwB1N4otAI4H8fZgMLIxKT+JaS03wLI/SkwyliOaliJK25lEHSc yKN5Vd836wcRqdRlkzgE1LTTxa2l2/U6UwZEaUVegZLhY+7YxScnjRMEpAHshYHzLgzh tNYWvzLmxRrNZ4lWyXt6J5+DC+sf8zM+ulS5bMzHjKeo8JdIiLXxJXOEs6sHw4ZQh5gn Zmt6GO4Ha0Mn+6ywECr9dwrEjQcRGrxC7gpavJJkn4tbaaLbVXlAGuiHiZYZgnHq/u9S //zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zbbSXTw6J2WlwBxKU5jp8a9Qh4yv9XE2pdrbPYNjLYw=; b=UOAt08Cl2Uef41CkURhOBB6pU6XmBvBvvf9dOyqdetBehAbUwyiIVeelve0GSXwgmC e7buq0vyAvFLLnGdTF5dCSmn0YHNUN7e7DYaV+PfftDRZxS/PgiWBmOv9rpa7QeKftz9 kfX9oK2zzubEYN2ty8Mf8W2gpFiMpAoIgGViEMoTQ3W0ePGW3eK4rxY8+SZhhKm1bGlt 7FuQYzk0TSy0u+/TX5l9eJa6zNh1B7VEsNxqV3STKFDf+iVxMjWe+/Wwnjw21OxYDIy7 5YWNfVQ5pVF2B7s5ZVsTPLgcnuSPlu8JxDQLSY/6+tbNRlwQ6WZN/VvCAl9LajVS/Hle Dw3Q==
X-Gm-Message-State: AOAM530nOpHkH/U8XrmBoNL0TukiD/S01dbAXXEsAHBxXfFmSB3rsKA1 NtdZIpU19s7jIf9/f5gk85o284VtxtO8YeS6Yls=
X-Google-Smtp-Source: ABdhPJzln2y//E7MWV1jfqXR2XXNBZmg9TR1Zwc5yDCgAbkseGhcHON7c8UiC0mYNpoVilNfMwplm5AXNoupTJyYg9c=
X-Received: by 2002:aca:55cb:: with SMTP id j194mr8397781oib.4.1606558505002; Sat, 28 Nov 2020 02:15:05 -0800 (PST)
MIME-Version: 1.0
References: <CAEGSd=DY8t8Skor+b6LSopzecoUUzUZhti9s0kdooLZGxPEt+w@mail.gmail.com> <d29042a7-742b-a445-cf60-2773e5515ae5@gont.com.ar> <CALx6S37+1duoNGR3dZWesHsZvx15kX9wCWufPMh=esvMaSMF_g@mail.gmail.com> <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <CALx6S37t4jump6S-R5_xdo5DF+RnHtT4rU5-RuiC-2GQ0PXxkQ@mail.gmail.com> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <CALx6S34uCrA1QdvLV8fpRKaJGLWMgtCmBCnrsBjU3TS+kXUs3Q@mail.gmail.com> <CAO42Z2xn_+7EVpjGyEU3aAdBmt1h=a4MPXFjjoTi_JeM2w9pkg@mail.gmail.com> <f66cbccd-55ed-375b-743b-7fc6c48a50c2@gont.com.ar> <CAO42Z2xqU4gs9iP=u_0Z16Qk+U24_YH0h5vTmJRJ5XZXZ0nweQ@mail.gmail.com> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar>
In-Reply-To: <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar>
From: Alexander Azimov <a.e.azimov@gmail.com>
Date: Sat, 28 Nov 2020 13:14:51 +0300
Message-ID: <CAEGSd=A_e-db8m2VN+2wEuXj9e+GTq7brYfY_fwW7tysUr19Ng@mail.gmail.com>
To: Fernando Gont <fernando@gont.com.ar>
Cc: Mark Smith <markzzzsmith@gmail.com>, Tom Herbert <tom@herbertland.com>, IPv6 Operations <v6ops@ietf.org>, tcpm <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000006b8e05b5280dd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Au0JjCE9wtS-_pV1j35vXS1jNXc>
Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Nov 2020 10:15:08 -0000

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