Re: Pseudorandom Flow Labels

Thomas Narten <narten@us.ibm.com> Wed, 06 April 2011 13:23 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9C128C122 for <ipv6@core3.amsl.com>; Wed, 6 Apr 2011 06:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.666
X-Spam-Level:
X-Spam-Status: No, score=-106.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WctO9169-Do0 for <ipv6@core3.amsl.com>; Wed, 6 Apr 2011 06:23:14 -0700 (PDT)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id DBBC63A69A6 for <ipv6@ietf.org>; Wed, 6 Apr 2011 06:23:13 -0700 (PDT)
Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p36D3vqb023573 for <ipv6@ietf.org>; Wed, 6 Apr 2011 09:03:57 -0400
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 01B7B38C803C for <ipv6@ietf.org>; Wed, 6 Apr 2011 09:24:41 -0400 (EDT)
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p36DOmI8177434 for <ipv6@ietf.org>; Wed, 6 Apr 2011 09:24:49 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p36DOmag007799 for <ipv6@ietf.org>; Wed, 6 Apr 2011 10:24:48 -0300
Received: from cichlid.raleigh.ibm.com (sig-9-65-245-36.mts.ibm.com [9.65.245.36]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p36DOkaw007407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2011 10:24:47 -0300
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p36DOiRY026957; Wed, 6 Apr 2011 09:24:44 -0400
Message-Id: <201104061324.p36DOiRY026957@cichlid.raleigh.ibm.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Pseudorandom Flow Labels
In-reply-to: <4D9C13D5.1030800@gmail.com>
References: <BD901061-96AC-4915-B7CE-2BC1F70861A5@castlepoint.net><201104052036.p35KaoHV019253@cichlid.raleigh.ibm.com><19204E85-5B6E-409C-B450-7E3AC5EF47FA@apple.com><201104052148.p35LmM9g019765@cichlid.raleigh.ibm.com><9ED6022F-6863-4267-A268-C73240098539@apple.com> <201104060008.p3608OlC022133@cichlid.raleigh.ibm.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301391466@XMB-RCD-109.cisco.com> <4D9C13D5.1030800@gmail.com>
Comments: In-reply-to Brian E Carpenter <brian.e.carpenter@gmail.com> message dated "Wed, 06 Apr 2011 19:18:45 +1200."
Date: Wed, 06 Apr 2011 09:24:44 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
Cc: 6MAN Working Group <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 13:23:14 -0000

> I have a quite strongly held belief that trying to be mathematically
> precise (not to say pedantic) has never worked well in IETF
> protocols.

Agree completely. :-)

> We do seem to agree that the important point is that the final output
> of the hash function used to select between alternate routes is
> uniformly distributed. Asking for flow label values that are reasonably
> well distributed as input to that hash function is enough.

Right. But now let me flip-flop a bit. In order to understand what
"reasonably well distributed as input" actually means, we need to
understand what algorithms are being used by routers when doing ECMP
and the like. If we had data about what algorithms are actually used
(or are reasonable to implement) we can talk about the distribution
properties that are needed on the input side of the hash.

Is there any such data? What do the router implementor say to this?

I feel like much of the discussion so far about what kind of
distribution is needed has been handwaving.

To be clear, what I'd like is simple rules on how to set the Flow
Label, but no simpler than is necessary to make the ECMP stuff work
well in practice.

Thomas