Re: [multipathtcp] Multipath Address Family
Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Tue, 24 November 2009 21:08 UTC
Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 ABB1C3A6830 for <multipathtcp@core3.amsl.com>; Tue, 24 Nov 2009 13:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.356
X-Spam-Level:
X-Spam-Status: No, score=0.356 tagged_above=-999 required=5 tests=[AWL=-1.594, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033]
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 dkoX+7E-T9ev for <multipathtcp@core3.amsl.com>; Tue, 24 Nov 2009 13:08:27 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 9B3BE3A682D for <multipathtcp@ietf.org>; Tue, 24 Nov 2009 13:08:26 -0800 (PST)
Received: from [192.168.20.2] (tmo-109-243.customers.d1-online.com [80.187.109.243]) by mail-n.franken.de (Postfix) with ESMTP id 6EEE51C0B461B; Tue, 24 Nov 2009 22:07:59 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com>
Date: Tue, 24 Nov 2009 22:07:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C622F375-EE67-46AE-AC28-6617CFEF6D12@lurchi.franken.de>
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> <3c3e3fca0911240434p4d95ec7an34615ae218faa4f@mail.gmail.com>
To: William Herrin <bill@herrin.us>
X-Mailer: Apple Mail (2.1077)
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 21:08:28 -0000
Dear all, just one note: In SCTP we use sctp_connectx() to connect to multiple addresses. Kacheong pointed a couple of years ago out that a more generic connectx() would make sense to other protocols supporting multihoming as well (but there were no). So you might want to look at sctp_connectx() which the SCTP socket API uses to handle the problem. Best regards Michael On Nov 24, 2009, at 1:34 PM, William Herrin wrote: > On Mon, Nov 23, 2009 at 4:40 PM, Pasi Sarolahti <pasi.sarolahti@iki.fi> wrote: >> I think a new address family would be a minimal needed change to the current >> socket API, without extending the API with new operations, but yet provide >> an interface to handle multiple addresses in a socket. One potentially >> useful characteristic would be that this would allow name resolver to return >> multiple IPv4 and/or IPv6 addresses from the name server as a single >> sockaddr structure, that could be directly given as a parameter to a connect >> call, which would lead to trying which of the addresses are reachable for >> the MPTCP session. > > Hi Pasi, > > It seems like you want to preserve the connect() call's parameters by > altering the definition of sockaddr so that it can contain multiple > addresses. > > But functionally, what we really want to do is pass an array of > sockaddrs to connect(). > > Stupid question time: what makes redefining sockaddr superior to an > extended API call that supplants connect() and accepts an array of > sockaddrs? > > Poking around linux's include files (netinet/in.h, bits/socket.h) I > notice that they go to a lot of trouble to make all sockaddrs come out > to exactly the same number of bytes. Won't a variable length sockaddr > that holds a variable number of addresses make a mess of that? > > >>> SOCK_MULTISTREAM or using a combination socket type like SOCK_STREAM | >>> SOCK_MULTIPATH >>> from the following reasons. > > Found a quote I think bears on the topic at > http://lkml.indiana.edu/hypermail/linux/net/9904.2/0091.html : > >> The AF_ prefix stands for "address family" and the PF_prefix stands for >> "protocol family". Historicly, the intent was that a single protocol family >> might support multiple address families and that the PF_ value was used to >> create the socket and the AF_ value was used in socket address structures. >> But in actuality, a protocol family supporting multiple address families has >> never been supported and the <sys/socket.h> header defines the PF_ value >> for a given protocol to be equal to the AF_ value for that protocol. > > I think when we discuss allowing multipath TCP to use IPv4 and IPv6 > addresses interchangeably, we're talking about one protocol family > using multiple address families, are we not? > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp >
- [multipathtcp] API: which address to use Pasi Sarolahti
- Re: [multipathtcp] API: which address to use William Herrin
- Re: [multipathtcp] API: which address to use William Herrin
- Re: [multipathtcp] API: which address to use Pasi Sarolahti
- Re: [multipathtcp] API: which address to use SCHARF, Michael
- Re: [multipathtcp] API: which address to use Yoshifumi Nishida
- [multipathtcp] draft minute at IETF76 Yoshifumi Nishida
- [multipathtcp] Multipath Address Family Pasi Sarolahti
- Re: [multipathtcp] Multipath Address Family Olivier Bonaventure
- Re: [multipathtcp] Multipath Address Family William Herrin
- Re: [multipathtcp] Multipath Address Family Michael Tüxen
- Re: [multipathtcp] Multipath Address Family Michael Tüxen
- Re: [multipathtcp] Multipath Address Family Laganier, Julien
- Re: [multipathtcp] Multipath Address Family Joe Touch
- Re: [multipathtcp] Multipath Address Family Laganier, Julien
- Re: [multipathtcp] Multipath Address Family Joe Touch
- Re: [multipathtcp] Multipath Address Family Laganier, Julien
- Re: [multipathtcp] Multipath Address Family Joe Touch
- Re: [multipathtcp] Multipath Address Family Laganier, Julien
- Re: [multipathtcp] Multipath Address Family Pasi Sarolahti
- Re: [multipathtcp] Multipath Address Family Joe Touch
- Re: [multipathtcp] Multipath Address Family Yoshifumi Nishida
- Re: [multipathtcp] Multipath Address Family Laganier, Julien
- Re: [multipathtcp] Multipath Address Family Yoshifumi Nishida
- Re: [multipathtcp] Multipath Address Family Pasi Sarolahti
- Re: [multipathtcp] Multipath Address Family Andrew Yourtchenko
- Re: [multipathtcp] Multipath Address Family Pasi Sarolahti
- Re: [multipathtcp] Multipath Address Family Andrew Yourtchenko
- [multipathtcp] Multipath deployment and fate shar… Costin Raiciu
- Re: [multipathtcp] Multipath deployment and fate … Joe Touch
- Re: [multipathtcp] Multipath Address Family Laganier, Julien
- Re: [multipathtcp] Multipath Address Family Michael Tüxen
- Re: [multipathtcp] Multipath Address Family Michael Tüxen
- Re: [multipathtcp] Multipath Address Family Laganier, Julien
- Re: [multipathtcp] Multipath Address Family Yoshifumi Nishida
- Re: [multipathtcp] Multipath Address Family Pasi Sarolahti
- Re: [multipathtcp] Multipath Address Family Michael Tüxen
- Re: [multipathtcp] Multipath Address Family Michael Tüxen
- Re: [multipathtcp] Multipath Address Family Christian Vogt
- Re: [multipathtcp] Multipath Address Family Christian Vogt
- Re: [multipathtcp] Multipath Address Family Michael Tüxen
- Re: [multipathtcp] Multipath Address Family Yoshifumi Nishida
- Re: [multipathtcp] Multipath Address Family Christian Vogt
- Re: [multipathtcp] Multipath Address Family Yoshifumi Nishida
- Re: [multipathtcp] Multipath deployment and fate … Iljitsch van Beijnum
- Re: [multipathtcp] Multipath deployment and fate … Laganier, Julien
- Re: [multipathtcp] Multipath deployment and fate … Iljitsch van Beijnum
- Re: [multipathtcp] Multipath deployment and fate … Joe Touch
- Re: [multipathtcp] Multipath deployment and fate … Laganier, Julien
- Re: [multipathtcp] Multipath deployment and fate … Joe Touch
- Re: [multipathtcp] Multipath deployment and fate … Joe Touch
- Re: [multipathtcp] Multipath deployment and fate … Laganier, Julien
- Re: [multipathtcp] Multipath deployment and fate … Joe Touch
- Re: [multipathtcp] Multipath deployment and fate … Laganier, Julien
- Re: [multipathtcp] Multipath deployment and fate … Joe Touch
- Re: [multipathtcp] Multipath deployment and fate … Iljitsch van Beijnum
- Re: [multipathtcp] Multipath deployment and fate … Joe Touch
- Re: [multipathtcp] Multipath deployment and fate … Iljitsch van Beijnum
- Re: [multipathtcp] Multipath deployment and fate … Joe Touch
- Re: [multipathtcp] Multipath deployment and fate … Iljitsch van Beijnum
- Re: [multipathtcp] Multipath deployment and fate … Yoshifumi Nishida
- [multipathtcp] draft minute at IETF77 Yoshifumi Nishida