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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf