RE: network controls are necessary

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Sat, 7 Dec 2002, Joel M. Halpern wrote:

> 1) We do not have paths that provide these properties

Sure we do, hosts such as laptops routinely have different interfaces
connecting to different services with different properties. Today, we
typically don't use those at the same time, but it's not a big leap to
expect this will happen more in the future. For instance, if I'm walking
around a convention center with my laptop while I'm downloading a file
and I'm looking at a device over a telnet/SSH connection, I would like
both of these applications to use wireless LAN connectivity if
available. But when I'm out of range of the wireless LAN, I'd want the
terminal connection to switch to GPRS or something similar, but the
download should simply stop and resume later when there is more/cheaper
bandwidth.

> 2) If we had such paths, the likelihood is that the host would not have
> enough information to determine which locator would give the desired
> properties.

In the example above it does. If selecting the path is done further
upstream (border router) then a host wouldn't automatically know this,
yes. The question then becomes: do we want the applications to know the
properties of different paths and then select one, or do we want the
applications to tag their packets with something that indicates the
desired service level, and let the routing infrastructure take it from
there?

I've heared arguments that hosts are plenty smart and can do everything
routers can. This would mean that the ultimate decision is the host's,
and that the routing infrastructure only provides the necessary building
blocks. But I don't buy this. People sitting in a bus can also be
excellent drivers, but that doesn't mean they get to second guess the
bus driver. Hosts need to look after the applications running on them,
routers need to look after the network as a whole. Getting routers to
work together is hard enough, getting hosts which are much more diverse
in every way to do the same is next to impossible. However, that does
not mean hosts should be kept stupid: any task a host can perform
autonomously without adverse effects on other systems should be
performed by the host and not by the network infrastructure.

> Yes, there is (and has been for many years) ongoing discussion of QoS.  We
> still have not found a sensible and useful way to provide differentiation
> in that dimension.

The same was true for interdomain multicast for a long time. But as far
as I can tell, it works fine now for those who have a transit provider
that supports it.

I think the QoS effort hasn't been as productive as it could have
because the focus has mainly been to split the bandwidth for a single
link (or sequential set of links) in creative ways. However, this is
only a useful approach if most of your traffic is bulk that can be
throttled back if there is higher priority traffic. But oversubscribing
regular traffic and then investing in equipment that can throttle it
back even further doesn't work nearly as well as simply putting that
money towards bigger pipes.

However, not all bandwidth problems can be solved with bigger pipes: you
can get only so many bits per second through a radio channel, especially
if there are antenna size, power, mobility and interference constraints.
So I think there is a future for QoS mechanisms that can make
applications run free over cheap/bandwidth-rich links but tome them in
over expensive/bandwidth-starved links.

An interesting observation: while hosts with biggest links now have
17,000 times as much bandwidth as those connected to the original
Arpanet, the hosts with the smallest links actually have 6 times _less_
bandwidth as those early Arpanet hosts 30 years ago.

> One of the reasons I want to keep hosts out of the routing space is that if
> we ever do find routing solutions that we want to use for new capabilities
> (QoS or otherwise) I would not want to have to upgrade the hosts as well as
> the routers to deliver such capabilities.

I agree 100%.

Iljitsch