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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf