Re: [multipathtcp] Multipath Address Family

Pasi Sarolahti <pasi.sarolahti@iki.fi> Tue, 24 November 2009 23:38 UTC

Return-Path: <pasi.sarolahti@iki.fi>
X-Original-To: multipathtcp@core3.amsl.com
Delivered-To: multipathtcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB3A3A67AF for <multipathtcp@core3.amsl.com>; Tue, 24 Nov 2009 15:38:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 iNFAfyJAVwZO for <multipathtcp@core3.amsl.com>; Tue, 24 Nov 2009 15:38:01 -0800 (PST)
Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 984AC3A672E for <multipathtcp@ietf.org>; Tue, 24 Nov 2009 15:38:01 -0800 (PST)
Received: from wifi172.ICSI.Berkeley.EDU (wifi172.ICSI.Berkeley.EDU [192.150.187.172]) by argo.otaverkko.fi (Postfix) with ESMTP id D15CE25ED06; Wed, 25 Nov 2009 01:37:55 +0200 (EET)
Message-Id: <6C8C1D51-70E5-4545-8661-196A94CDEA37@iki.fi>
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
To: Olivier.Bonaventure@uclouvain.be
In-Reply-To: <4B0BB35E.207@uclouvain.be>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 24 Nov 2009 15:37:53 -0800
References: <E9EE0C1A-C9D3-4EBC-97FD-E1B1628CD2E7@iki.fi> <3c3e3fca0911090542h54e45784qbdbf1f338a4c3e90@mail.gmail.com> <E03D46E1-51EA-4273-A8A7-4F37F88B2E92@iki.fi> <20091123.092214.140617438.nishida@sfc.wide.ad.jp> <48DA092B-F3BC-432E-A199-B265DDED39DA@iki.fi> <4B0BB35E.207@uclouvain.be>
X-Mailer: Apple Mail (2.936)
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Multipath Address Family
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2009 23:38:02 -0000

On Nov 24, 2009, at 2:20 AM, Olivier Bonaventure wrote:

> This could be interesting, but if we change de socket API, why don't  
> we
> define a new structure that can handle DNS names in addition to IPv4  
> and
> IPv6 addresses. This would allow some applications to simply call
> connect with a DNS name and let the transport protocol figure out
> whether single path IPv4, single path IPv6, multipath whatever ...
> should be used to reach this DNS name.

I agree that connecting by names would eventually be the right way to  
go for Internet protocols, but am not sure if that fits within the  
authority of this WG anymore. It may be something that needs to be  
discussed by a wider community. My proposal was less ambitious and  
more short-sighted: fix the shortcoming in the API that claims the  
socket is using only one address when it is in fact using many.

Another question is that even if we had an connect-by-name API, would  
we still need to be able express which address(es) are bound to the  
socket in the API?

- Pasi