Re: The internet architecture

[Tony Finch <dot at dotat.at>]

On Thu, 1 Jan 2009, John Leslie wrote:
>
>    I'm not at all clear what "support" of "multihoming" Tony is asking
> for...

I'm not clear either, because I don't know what mechanisms could make it
work, especially not mechanisms that are deployable.

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.

Then there must be a way for an endpoint to make an informed decision
about which of its links to use (source address) and which of the possible
destination links to use. There also needs to be a way to migrate
connections between the available links either pro-actively for seamless
mobility or re-actively for fail-over.

>    RFC 3484, of course, is "Default Address SelectioFrom ietf-bounces at ietf.org  Thu Jan  1 13:02:52 2009
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 83D053A6AC2;
	Thu,  1 Jan 2009 13:02:52 -0800 (PST)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4663F3A6AC0
	for <ietf at core3.amsl.com>; Thu,  1 Jan 2009 13:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.444
X-Spam-Level: 
X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 lEtjzWY4w6AY for <ietf at core3.amsl.com>;
	Thu,  1 Jan 2009 13:02:49 -0800 (PST)
Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130])
	by core3.amsl.com (Postfix) with ESMTP id 8613A3A698C
	for <ietf at ietf.org>; Thu,  1 Jan 2009 13:02:11 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52664)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1LIUg2-0005CT-2R (Exim 4.70)
	(return-path <fanf2 at hermes.cam.ac.uk>); Thu, 01 Jan 2009 21:01:58 +0000
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1LIUg2-0003BS-Nr (Exim 4.67)
	(return-path <fanf2 at hermes.cam.ac.uk>); Thu, 01 Jan 2009 21:01:58 +0000
Date: Thu, 1 Jan 2009 21:01:58 +0000
From: Tony Finch <dot at dotat.at>
X-X-Sender: fanf2 at hermes-1.csi.cam.ac.uk
To: John Leslie <john at jlc.net>
Subject: Re: The internet architecture
In-Reply-To: <20090101142659.GF80753 at verdi>
Message-ID: <alpine.LSU.2.00.0901011921070.31331 at hermes-1.csi.cam.ac.uk>
References: <20081229162852.79C526BE581 at mercury.lcs.mit.edu>
	<alpine.LSU.2.00.0812300259040.25321 at hermes-1.csi.cam.ac.uk>
	<4039DE6E-5C48-476E-90B2-649189C7390A at multicasttech.com>
	<alpine.LSU.2.00.0812301733190.13329 at hermes-1.csi.cam.ac.uk>
	<17882.1230674158 at marajade.sandelman.ca>
	<alpine.LSU.2.00.0901010314200.2395 at hermes-1.csi.cam.ac.uk>
	<20090101142659.GF80753 at verdi>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Cc: ietf at ietf.org
X-BeenThere: ietf at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

On Thu, 1 Jan 2009, John Leslie wrote:
>
>    I'm not at all clear what "support" of "multihoming" Tony is asking
> for...

I'm not clear either, because I don't know what mechanisms could make it
work, especially not mechanisms that are deployable.

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.

Then there must be a way for an endpoint to make an informed decision
about which of its links to use (source address) and which of the possible
destination links to use. There also needs to be a way to migrate
connections between the available links either pro-actively for seamless
mobility or re-actively for fail-over.

>    RFC 3484, of course, is "Default Address Selection for IPn for IPv6". I
> guess that Tony is referring to Section 10.5

I was thinking of the whole thing, actually, because it specifies an
uninformed (therefore broken) version of what I wrote above.

> > OK, so what is Internet multihoming? If the DNS resolves a hostname
> > to multiple IP addresses then those are assumed to be multiple links
> > to the same host.
>
>    That is sometimes true, and often not.

Right. My point is that the above seems to be the architectural model, but
actual practice is almost always different.

> > but the Internet architecture says that the "dumb" network need not
> > explain its workings to the intelligent but ignorant hosts.
>
>    ... which seems about right. Layer 3 is supposed to find an
> interconnection from one network in the Internet to another. There
> seems to be little point in "explaining" how it does this to the
> endpoints.

The endpoint doesn't need to know how: it needs to know if a link is
working, or even better, how well it is working compared to the other
alternatives.

>    Round-robin seems mostly unrelated -- it was never guaranteed to be
> particularly good at load-balancing.

True, but it often works well enough in practice and has been widely used
for 15 years. The reason for talking about it is it's an example of a
widespread practice that goes against the architecture. It is not
documented in an RFC and is not supported by the IETF to the extent that
the IETF feels free to break it (in RFC 3484 section 6 rule 9).

> > A host has no way to use multiple links to provide redundancy or
> > resilience
>
>    This would be nice to fix, but it's not clear there's a sufficient
> constituency interested in fixing it.

Almost every bit of portable network-capable consumer electronics has the
hardware to benefit from this fix.

> > 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.

> > 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.

> > There is no support for distributing an application across multiple
> > hosts (or multiple links to the same host) because address selection
> > is blind to availability and reachability - whether you consider them
> > to be binary or fractional values.
>
>    Again, I'm not clear.

This is RFC 3484 section 6 rule 1 again. It doesn't work in practice which
is why the real world uses load-balancing routers or anycast or whatever.

>    Does Tony have an alternative to suggest?

As I said, it was a rant and not intended to be constructive :-) Far
better minds than mine are working on the problem and I'm following their
work with interest - especially whether the proposed improvements to
addressing and routing help with these application-level problems.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
LUNDY FASTNET: EAST OR SOUTHEAST 5 TO 7. MODERATE OR ROUGH. MAINLY FAIR, RAIN
AT FIRST IN FASTNET. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST.
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


v6". I
> guess that Tony is referring to Section 10.5

I was thinking of the whole thing, actually, because it specifies an
uninformed (therefore broken) version of what I wrote above.

> > OK, so what is Internet multihoming? If the DNS resolves a hostname
> > to multiple IP addresses then those are assumed to be multiple links
> > to the same host.
>
>    That is sometimes true, and often not.

Right. My point is that the above seems to be the architectural model, but
actual practice is almost always different.

> > but the Internet architecture says that the "dumb" network need not
> > explain its workings to the intelligent but ignorant hosts.
>
>    ... which seems about right. Layer 3 is supposed to find an
> interconnection from one network in the Internet to another. There
> seems to be little point in "explaining" how it does this to the
> endpoints.

The endpoint doesn't need to know how: it needs to know if a link is
working, or even better, how well it is working compared to the other
alternatives.

>    Round-robin seems mostly unrelated -- it was never guaranteed to be
> particularly good at load-balancing.

True, but it often works well enough in practice and has been widely used
for 15 years. The reason for talking about it is it's an example of a
widespread practice that goes against the architecture. It is not
documented in an RFC and is not supported by the IETF to the extent that
the IETF feels free to break it (in RFC 3484 section 6 rule 9).

> > A host has no way to use multiple links to provide redundancy or
> > resilience
>
>    This would be nice to fix, but it's not clear there's a sufficient
> constituency interested in fixing it.

Almost every bit of portable network-capable consumer electronics has the
hardware to benefit from this fix.

> > 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.

> > 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.

> > There is no support for distributing an application across multiple
> > hosts (or multiple links to the same host) because address selection
> > is blind to availability and reachability - whether you consider them
> > to be binary or fractional values.
>
>    Again, I'm not clear.

This is RFC 3484 section 6 rule 1 again. It doesn't work in practice which
is why the real world uses load-balancing routers or anycast or whatever.

>    Does Tony have an alternative to suggest?

As I said, it was a rant and not intended to be constructive :-) Far
better minds than mine are working on the problem and I'm following their
work with interest - especially whether the proposed improvements to
addressing and routing help with these application-level problems.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
LUNDY FASTNET: EAST OR SOUTHEAST 5 TO 7. MODERATE OR ROUGH. MAINLY FAIR, RAIN
AT FIRST IN FASTNET. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST.
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf