Re: The internet architecture
Rémi Després <remi.despres@free.fr> Fri, 02 January 2009 10:16 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7988F3A6906; Fri, 2 Jan 2009 02:16:40 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1673A6906 for <ietf@core3.amsl.com>; Fri, 2 Jan 2009 02:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.489
X-Spam-Level:
X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457]
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 n3woc3dRpasT for <ietf@core3.amsl.com>; Fri, 2 Jan 2009 02:16:37 -0800 (PST)
Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 7BDA73A67FD for <ietf@ietf.org>; Fri, 2 Jan 2009 02:16:35 -0800 (PST)
Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id F095F4B01E6; Fri, 2 Jan 2009 11:16:19 +0100 (CET)
Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp2-g21.free.fr (Postfix) with ESMTP id 5784B4B019A; Fri, 2 Jan 2009 11:16:14 +0100 (CET)
Message-ID: <495DE8F6.90201@free.fr>
Date: Fri, 02 Jan 2009 11:14:14 +0100
From: Rémi Després <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: The internet architecture
References: <20081229162852.79C526BE581@mercury.lcs.mit.edu> <alpine.LSU.2.00.0812300259040.25321@hermes-1.csi.cam.ac.uk> <4039DE6E-5C48-476E-90B2-649189C7390A@multicasttech.com> <alpine.LSU.2.00.0812301733190.13329@hermes-1.csi.cam.ac.uk> <17882.1230674158@marajade.sandelman.ca> <alpine.LSU.2.00.0901010314200.2395@hermes-1.csi.cam.ac.uk> <20090101142659.GF80753@verdi> <alpine.LSU.2.00.0901011921070.31331@hermes-1.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.0901011921070.31331@hermes-1.csi.cam.ac.uk>
Cc: John Leslie <john@jlc.net>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0377603934=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
In my understanding, SCTP has a promising approach for this:But what we need is an addressing architecture that allows us to tell the difference between a hostname that has multiple addresses because they are required for application addressing, or because the destination has multiple points of connection. (I think IPv4 vs IPv6 is a special case of the latter.) This is another way of looking at the id/loc split.
- The DNS provides as usual a set of locators that may be tried successively to start an SCTP association, until one succeeds. They may be those of different hosts (e.g. for load sharing on a per connection basis).
- Once an SCTP association is established with an SCTP endpoint, both ends may exchange their lists of alternative locators. These locators being exclusive of endpoint physical hosts, this is adequate for multihoming support.
SRV resource records do provide indications for weighted load balancing, nicely distinct from normal vs backup.Given multiple addresses for the same hostname, a client has no way to make an informed decision about which is the best to connect to. This is why hosts that support IPv6 do not work as well as IPv4-only hosts.I guess I don't follow. Indeed, IPv6 hosts that follow RFC [3484] will defeat some attempts at load-balancing,This isn't about load balancing. One example is that RFC 3484 prefers IPv6 to IPv4 even when IPv6 connectivity relies on sub-optimal tunnels. Another is section 6 rule 1 says a client should "avoid unusable destinations" without specifying any way for a client to find out which destinations are usable.
IMO, their use could be extended for multihoming.
For this, alternative locators of a multihomed endpoint would be compared to those obtained in SRV RRs that , in the DNS, are given for the name of this endpoint.
For each address that matches an SRV RR, the weight it indicates can be used for intelligent load balancing.
Same view.There is no support for multiple instances of the same application per host (i.e. virtual hosting) unless the application has its own addressing.I'm not clear what Tony might see as such "support".Ned's message had some examples. I suppose that SRV records go some way to fixing the problems with well-known port numbers, so "no support" is an exaggeration - but we've failed to back-port this fix to older protocols.
In addition, if applications use Connect By Name, and resolvers make SRV queries when names have the service-name format, then:
- applications need not to be concerned
- transport modules can get the right remote application ports.
RD
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: The internet architecture Noel Chiappa
- Re: The internet architecture Keith Moore
- Re: The internet architecture Dave CROCKER
- Re: The internet architecture Iljitsch van Beijnum
- Re: The internet architecture Mark Seery
- RE: The internet architecture Hallam-Baker, Phillip
- Re: The internet architecture Keith Moore
- Re: The internet architecture Keith Moore
- RE: sockets vs. fds michael.dillon
- Re: The internet architecture Christian Vogt
- Re: The internet architecture Bryan Ford
- Re: The internet architecture Keith Moore
- Re: The internet architecture Noel Chiappa
- Re: The internet architecture Keith Moore
- RE: The internet architecture Hallam-Baker, Phillip
- Re: The internet architecture Noel Chiappa
- Re: The internet architecture Keith Moore
- Re: The internet architecture Keith Moore
- Re: The internet architecture Stephane Bortzmeyer
- Re: The internet architecture Stephane Bortzmeyer
- Re: The internet architecture Keith Moore
- Re: The internet architecture Keith Moore
- Re: The internet architecture Thomas Narten
- Re: The internet architecture Thomas Narten
- Re: The internet architecture Henning Schulzrinne
- Re: The internet architecture John Leslie
- Re: The internet architecture Dave CROCKER
- RE: The internet architecture michael.dillon
- Re: The internet architecture Melinda Shore
- RE: The internet architecture michael.dillon
- sockets vs. fds Dave CROCKER
- Re: The internet architecture John Day
- Re: sockets vs. fds Melinda Shore
- Re: The internet architecture John Day
- RE: The internet architecture John Day
- Re: The internet architecture John Day
- Re: The internet architecture Keith Moore
- Re: The internet architecture Keith Moore
- Re: The internet architecture Keith Moore
- Re: The internet architecture Keith Moore
- Re: The internet architecture Dave CROCKER
- Re: The internet architecture John Day
- Re: The internet architecture John Day
- Re: sockets vs. fds Tony Finch
- Re: The internet architecture Andrew Sullivan
- Re: The internet architecture Tony Finch
- Re: The internet architecture David W. Hankins
- Re: The internet architecture Thomas Narten
- Re: The internet architecture Keith Moore
- Re: The internet architecture Thomas Narten
- Re: The internet architecture Keith Moore
- RE: The internet architecture Hallam-Baker, Phillip
- Re: sockets vs. fds Florian Weimer
- Re: The internet architecture Masataka Ohta
- Re: The internet architecture Christian Vogt
- DNS query reliability (was Re: The internet archi… Dave CROCKER
- Re: The internet architecture Stephane Bortzmeyer
- Re: The internet architecture Stephane Bortzmeyer
- Re: DNS query reliability (was Re: The internet a… Stephane Bortzmeyer
- Re: The internet architecture Masataka Ohta
- Re: The internet architecture Stephane Bortzmeyer
- Re: The internet architecture Andrew Sullivan
- Re: The internet architecture Dave CROCKER
- Re: The Great Naming Debate (was Re: The internet… Keith Moore
- The Great Naming Debate (was Re: The internet arc… Bryan Ford
- Re: The Great Naming Debate (was Re: The internet… Joe Baptista
- Re: The Great Naming Debate (was Re: The internet… Marc Manthey
- RE: The Great Naming Debate (was Re: The internet… Hallam-Baker, Phillip
- RE: [tae] The Great Naming Debate (was Re: The in… Hallam-Baker, Phillip
- Re: [tae] The Great Naming Debate (was Re: The in… Keith Moore
- Re: [tae] The Great Naming Debate (was Re: The in… Melinda Shore
- Re: The internet architecture Scott Brim
- Re: The internet architecture Dick Hardt
- Re: The internet architecture macbroadcast
- Re: The internet architecture macbroadcast
- Re: The internet architecture Bryan Ford
- RE: The internet architecture Hallam-Baker, Phillip
- Re: The internet architecture TSG
- RE: The internet architecture John Day
- RE: The internet architecture John C Klensin
- Re: The internet architecture Rémi Després
- Re: The internet architecture Tony Finch
- Re: The internet architecture Marshall Eubanks
- Re: The internet architecture John Day
- RE: The internet architecture John Day
- Re: The internet architecture macbroadcast
- Re: The internet architecture Rémi Després
- Re: The internet architecture Noel Chiappa
- Re: The internet architecture John Leslie
- Re: The internet architecture John Day
- RE: The internet architecture michael.dillon
- Re: The internet architecture John Day
- Re: The internet architecture Randy Presuhn
- Re: The internet architecture Brian E Carpenter
- Re: The internet architecture John Leslie
- RE: The internet architecture Christian Huitema
- Re: The internet architecture - pointer to RRG di… Robin Whittle
- Re: The internet architecture Brian E Carpenter
- RE: The internet architecture Christian Huitema
- Re: The internet architecture Tony Finch
- Re: The internet architecture macbroadcast
- Re: The internet architecture Tony Finch
- Re: The internet architecture John Leslie
- Re: The internet architecture ned+ietf
- Re: The internet architecture John C Klensin
- Re: The internet architecture Tony Finch
- Re: The internet architecture Rémi Després
- RE: The internet architecture Fleischman, Eric
- Re: The internet architecture Michael Richardson