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.
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