Re: The internet architecture

[Brian E Carpenter <brian.e.carpenter at gmail.com>]

Hi Christian,

On 2008-12-30 11:55, Christian Huitema wrote:
>>> I would agree with this, except I defer to the 'get down off an
>> elephant'
>>> principle. If both points of attachment are bound to a single
>> transport level
>>> entity, then it ought to be relatively easy, and not involve the
>> routing at
>>> all, to detect that both points of attacFrom ietf-bounces at ietf.org  Mon Dec 29 16:49:07 2008
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 E033328C2B7;
	Mon, 29 Dec 2008 16:49:06 -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 C0B1228C2B7
	for <ietf at core3.amsl.com>; Mon, 29 Dec 2008 16:49:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 
	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 m3Ihz6BV09it for <ietf at core3.amsl.com>;
	Mon, 29 Dec 2008 16:49:04 -0800 (PST)
Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189])
	by core3.amsl.com (Postfix) with ESMTP id 75DCE28C0DC
	for <ietf at ietf.org>; Mon, 29 Dec 2008 16:49:04 -0800 (PST)
Received: by ti-out-0910.google.com with SMTP id a6so3525028tib.25
	for <ietf at ietf.org>; Mon, 29 Dec 2008 16:48:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from
	:organization:user-agent:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding;
	bh=ivMo1pU2CT22IuF0Yv/+iX+JpzUJhs2NXMwcsEWbujM=;
	b=bq/uHAHnH837kMbD0WABU7DxOgluBOAgKWrspTPh0RKFV4APzdwAxd0cBpyq1ABiT9
	9FDvvVOqKyByVZP/4n3f6JPPG/gJ0y948JIY8G1xw8rhIecjpfkB4wg3YsJ/5DUXrgmo
	v+krX9bt0QlBhPFuc+xWIqEcPljZzgSLPVkN8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:organization:user-agent:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	b=QF3TzHhLuy3N6j58tppPGxQIiU/SPFF5cvAtMnW3+xzHqnPjwUNhVxLQ71SYLH9GBA
	Juqvmvir4nFEcrzg/d7JJX2IM5bTf0ZqPHfVj1N6xLyR+Wdf/HUqsWJ7hizqpeHK5O1R
	dFyidXVQTd0l7zKJsm0evqEWIKT58jOn3MeZk=
Received: by 10.110.16.9 with SMTP id 9mr15050972tip.39.1230598129595;
	Mon, 29 Dec 2008 16:48:49 -0800 (PST)
Received: from ?10.1.1.4? (118-92-210-205.dsl.dyn.ihug.co.nz [118.92.210.205])
	by mx.google.com with ESMTPS id a4sm17974510tib.7.2008.12.29.16.48.46
	(version=SSLv3 cipher=RC4-MD5); Mon, 29 Dec 2008 16:48:48 -0800 (PST)
Message-ID: <49596FEA.6040909 at gmail.com>
Date: Tue, 30 Dec 2008 13:48:42 +1300
From: Brian E Carpenter <brian.e.carpenter at gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Christian Huitema <huitema at windows.microsoft.com>
Subject: Re: The internet architecture
References: <20081229162852.79C526BE581 at mercury.lcs.mit.edu>
	<49592B28.6060001 at gmail.com>
	<8EFB68EAE061884A8517F2A755E8B60A19D2E66F03 at NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A19D2E66F03 at NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
Cc: "ietf at ietf.org" <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

Hi Christian,

On 2008-12-30 11:55, Christian Huitema wrote:
>>> I would agree with this, except I defer to the 'get down off an
>> elephant'
>>> principle. If both points of attachment are bound to a single
>> transport level
>>> entity, then it ought to be relatively easy, and not involve the
>> routing at
>>> all, to detect that both points of attachment lehment lead to the same entity.
>> It ought to be, but unfortunately we have confounded the transport
>> entity
>> namespace with the network entity namespace with the point of attachment
>> namespace.
> 
> Not really. Many applications are actively managing their network connections, and for a good reason. A network connection is not an interface to an abstract "unified network". On the contrary, a network interface implements a contract with a specific network.

It seems to me that you're agreeing with me. It's exactly because the three
namespaces I mentioned are mashed together by TCP/IP that applications have
to do what you describe, rather than just saying "open a connection to
Christian's laptop."

    Brian

> Take the example of a laptop with Bluetooth, Wi-Fi, WIMAX and 3G. Four connections, with four different providers. Wi-Fi, through the access point, communicates with a broadband provider, maybe a cable company such as Comcast. WIMAX communicates with the Internet through a wireless provider, maybe Clearwire. 3G also offer some kind of Internet access, possibly through a different provider such as AT&T. And Bluetooth typically does not communicate with the Internet, but provides access to some local devices. You will note that the different providers have different rules for managing traffic. Behind each interface lies a different contract, a different type of service.
> 
> Is it possible to manage all these interfaces as if they were a single abstract point of attachment? Maybe. That would require a common management system. Can that management system be part of "the network"? Frankly, I doubt it. The management system will have to make arbitration between different services, deciding which part of the traffic goes which way. These decisions have economic consequences. Do you really believe that different providers will delegate these economic decisions to some kind of cooperative distributed system? If that was realistic, we would have network wide QOS by now...
> 
> On the other hand, the end system is in a very good position to implement these arbitrations. It has direct access to the requirement of the applications, and to the terms of each specific interface contract. Moreover, it can actually measure the quality of the offered service, allowing for informed real time decisions.
> 
> We can debate which part of the end system should implement these decisions, whether it should be the application or a common transport layer. I can see arguments either way. But the business reality essentially precludes an implementation in the network layer. Even if we did reengineer the network layer to implement a clean separation between identifiers and locators, the business reality will still be there. We will end up with separate identifiers for the different "provider contracts", and applications, or the transport layers, will have to arbitrage between these contracts.
> 
> -- Christian Huitema
> 
> 
> 
> 
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


ad to the same entity.
>> It ought to be, but unfortunately we have confounded the transport
>> entity
>> namespace with the network entity namespace with the point of attachment
>> namespace.
> 
> Not really. Many applications are actively managing their network connections, and for a good reason. A network connection is not an interface to an abstract "unified network". On the contrary, a network interface implements a contract with a specific network.

It seems to me that you're agreeing with me. It's exactly because the three
namespaces I mentioned are mashed together by TCP/IP that applications have
to do what you describe, rather than just saying "open a connection to
Christian's laptop."

    Brian

> Take the example of a laptop with Bluetooth, Wi-Fi, WIMAX and 3G. Four connections, with four different providers. Wi-Fi, through the access point, communicates with a broadband provider, maybe a cable company such as Comcast. WIMAX communicates with the Internet through a wireless provider, maybe Clearwire. 3G also offer some kind of Internet access, possibly through a different provider such as AT&T. And Bluetooth typically does not communicate with the Internet, but provides access to some local devices. You will note that the different providers have different rules for managing traffic. Behind each interface lies a different contract, a different type of service.
> 
> Is it possible to manage all these interfaces as if they were a single abstract point of attachment? Maybe. That would require a common management system. Can that management system be part of "the network"? Frankly, I doubt it. The management system will have to make arbitration between different services, deciding which part of the traffic goes which way. These decisions have economic consequences. Do you really believe that different providers will delegate these economic decisions to some kind of cooperative distributed system? If that was realistic, we would have network wide QOS by now...
> 
> On the other hand, the end system is in a very good position to implement these arbitrations. It has direct access to the requirement of the applications, and to the terms of each specific interface contract. Moreover, it can actually measure the quality of the offered service, allowing for informed real time decisions.
> 
> We can debate which part of the end system should implement these decisions, whether it should be the application or a common transport layer. I can see arguments either way. But the business reality essentially precludes an implementation in the network layer. Even if we did reengineer the network layer to implement a clean separation between identifiers and locators, the business reality will still be there. We will end up with separate identifiers for the different "provider contracts", and applications, or the transport layers, will have to arbitrage between these contracts.
> 
> -- Christian Huitema
> 
> 
> 
> 
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf