RE: The internet architecture

[<michael.dillon at bt.com>]

> It may 
> well be that having applications be more brittle would be an 
> acceptable cost for getting a viable multihoming approach 
> that address the route scalability problem. (All depends on 
> what "more brittle" really means.) But the only way to answer 
> such questions in a productive manner is to look pretty 
> closely at a complete architecture/solution together with 
> experience from real implementation/usage.

I agree.
For instance, the cited DNS problems often disrupt communication
when there is a problem free IP path between points A and B because
DNS relies on third parties to the packet forwarding path. But 3rd
parties can also be used to make things less brittle. For instance
if an application whose packet stream is being disrupted could call
on 3rd parties to check if there are alternative trouble-free paths
and then reroute the stream through a 3rd party proxy. If a strategy
like this is built-into the lower level network API, then an application
session could even survive massive network disruption as long as
it was cyclic.

I have in mind the way that Telebit modems used the PEP protocol 
to test and use the communication capability of each one of several
channels. As long as there was at least one channel available and the
periods of no-channel-availability were short enough, you could get
end-to-end data transfer. On a phone line which was unusable for fax
and in which the human voice was completely drowned out by static,
you could get end-to-end UUCP email transfer. A lot of work related
to this is being done by P2P folks thFrom ietf-bounces at ietf.org  Fri Dec  5 07:10:47 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-web-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E5A7A28C168;
	Fri,  5 Dec 2008 07:10:46 -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 C9FC33A68DA
	for <ietf at core3.amsl.com>; Fri,  5 Dec 2008 07:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Bc6+-yum8fv2 for <ietf at core3.amsl.com>;
	Fri,  5 Dec 2008 07:10:43 -0800 (PST)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137])
	by core3.amsl.com (Postfix) with ESMTP id 3EB4328C168
	for <ietf at ietf.org>; Fri,  5 Dec 2008 07:10:42 -0800 (PST)
Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.65]) by
	smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 5 Dec 2008 15:10:37 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: The internet architecture
Date: Fri, 5 Dec 2008 15:10:38 -0000
Message-ID: <C0F2465B4F386241A58321C884AC7ECC09D91DA4 at E03MVZ2-UKDY.domain1.systemhost.net>
In-Reply-To: <200812051435.mB5EZFNp007644 at cichlid.raleigh.ibm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The internet architecture
Thread-Index: AclW5r4B0pilSI8WQ4OQGgZS1aJ2GwAA6mww
From: <michael.dillon at bt.com>
To: <ietf at ietf.org>
X-OriginalArrivalTime: 05 Dec 2008 15:10:37.0681 (UTC)
	FILETIME=[A1187E10:01C956EB]
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

> It may 
> well be that having applications be more brittle would be an 
> acceptable cost for getting a viable multihoming approach 
> that address the route scalability problem. (All depends on 
> what "more brittle" really means.) But the only way to answer 
> such questions in a productive manner is to look pretty 
> closely at a complete architecture/solution together with 
> experience from real implementation/usage.

I agree.
For instance, the cited DNS problems often disrupt communication
when there is a problem free IP path between points A and B because
DNS relies on third parties to the packet forwarding path. But 3rd
parties can also be used to make things less brittle. For instance
if an application whose packet stream is being disrupted could call
on 3rd parties to check if there are alternative trouble-free paths
and then reroute the stream through a 3rd party proxy. If a strategy
like this is built-into the lower level network API, then an application
session could even survive massive network disruption as long as
it was cyclic.

I have in mind the way that Telebit modems used the PEP protocol 
to test and use the communication capability of each one of several
channels. As long as there was at least one channel available and the
periods of no-channel-availability were short enough, you could get
end-to-end data transfer. On a phone line which was unusable for fax
and in which the human voice was completely drowned out by static,
you could get end-to-end UUCP email transfer. A lot of work related
to this is being done by P2P ese days, and I think there
is value in defining a better network API that incorporates some
of this work.

--Michael Dillon
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


folks these days, and I think there
is value in defining a better network API that incorporates some
of this work.

--Michael Dillon
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf