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 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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
