Re: [grobj] Trying all addresses

Keith Moore <moore@network-heretics.com> Thu, 19 November 2009 22:35 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: grobj@core3.amsl.com
Delivered-To: grobj@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144133A6896 for <grobj@core3.amsl.com>; Thu, 19 Nov 2009 14:35:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 q9T1Z9+5pamj for <grobj@core3.amsl.com>; Thu, 19 Nov 2009 14:35:51 -0800 (PST)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 30A2F3A6894 for <grobj@ietf.org>; Thu, 19 Nov 2009 14:35:51 -0800 (PST)
Received: from lust.indecency.org (70-11-255-119.pools.spcsdns.net [70.11.255.119]) by m1.imap-partners.net (MOS 4.1.7-GA) with ESMTP id BBW22857 (AUTH admin@network-heretics.com); Thu, 19 Nov 2009 14:35:42 -0800
Message-ID: <4B05C837.1010609@network-heretics.com>
Date: Thu, 19 Nov 2009 17:35:35 -0500
From: Keith Moore <moore@network-heretics.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <4AFA91BF.2010808@viagenie.ca> <4AFB497D.1080901@employees.org> <4B055227.3090902@viagenie.ca> <0d9f01ca6946$76f42760$c2f0200a@cisco.com> <4B0593DC.3090104@viagenie.ca> <0de301ca694b$30e26ed0$c2f0200a@cisco.com> <4B059BC8.9020809@viagenie.ca> <4B05AB77.8040800@gmail.com>
In-Reply-To: <4B05AB77.8040800@gmail.com>
Content-Type: multipart/alternative; boundary="------------080009030003030602080503"
Cc: grobj@ietf.org
Subject: Re: [grobj] Trying all addresses
X-BeenThere: grobj@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss Generic Referral Objects <grobj.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/grobj>, <mailto:grobj-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grobj>
List-Post: <mailto:grobj@ietf.org>
List-Help: <mailto:grobj-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grobj>, <mailto:grobj-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2009 22:35:52 -0000

Brian E Carpenter wrote:
> On 2009-11-20 08:26, Simon Perreault wrote:
>> Dan Wing wrote, on 2009-11-19 14:04:
>>> If there are a lot of candidate addresses and 
>>> candidate transports it's time-consuming to try all of them.
>> Why not try all of them simultaneously? It would waste bandwidth, but probably
>> not a significant amount. If concerned you can impose a concurrency limit. Then
>> you use the equivalent of ICE's aggressive nomination but make it choose the
>> highest priority candidate (instead of the first successful one) that is
>> successful within a given time window following the first successful check.
>
> Actually this has been discussed quite a bit in the context of "what's wrong
> with RFC3484?" It's also been implemented in the REAP protocol which is
> associated with SHIM6. My student Habib Naderi is currently simulating
> REAP's behaviour when exploring various numbers of address pairs. The work
> isn't quite cooked enough yet to give numbers, but one of his conclusions
> is that the actual amount of probe traffic caused by REAP is not a big
> problem. However, the recovery time for a TCP session when an address pair
> fails can be pretty long (tens of seconds to minutes), and I suspect that
> using a probing method to make the initial choice of address pair would
> also be slow.
>
> So, circling back to the problem statement: the objective is to make the
> best possible initial guess at the best address pair to use, and the
> value of a GRO is to help the receiving entity make that best guess.
"Picking the best" address is not the only viable strategy.  It makes
sense, for some applications, to concurrently utilize multiple paths. 
e.g. If your application is transferring large data sets, and it finds
that it has multiple paths between the endpoints available to it, it
makes sense to send data over each of those paths, and adjust the amount
of data sent over each according to the characteristics of each path, to
get the fastest transfer.   As a bonus you get the ability to survive
failures of individual paths.

Keith