[e2e] congested links, QoS, routing, etc.

[RJ Atkinson]

On Sunday, Jun 8, 2003, at 17:39 America/Montreal, David P. Reed wrote:
> My rant is ECN coupled with cutting revenue to anyone who
> refuses to up the capacity of a bottleneck link,

Conceptually, I'd agree in the general case.
Of course, there are some special cases.

	My friends at DCA would observe that they'd happily increase capacity
of the bottleneck link into Afghanistan, except that in practical terms
they can't really do so (anytime soon or within real-world budgets):
	- more capacity would require either
		- an additional satellite to be built and orbited
		  (all available transponders have been leased long since)
		- or someone running fibre (requires long time to construct
		  and is not unlikely to get cut deliberately by someone;
		  nearest fibre drop today that I know of is a FLAG POP on the
		  southern coast of Pakistan).

	Similar issues exist with regards to capacity into other parts of
southwest Asia, though Afghanistan is probably the worst case,
or so I'm told.  The same basic situation exists into Antarctica,
where the choices are pretty much HF radio or SATCOM (even if fibre
could be run, it would not take long for icebergs/iceflows to break
the cable in the littoral waters of Antarctica).

	As near as I can tell, the bottleneck link into someplace where 
capacity
cannot be increased quickly or reasonably-economically is a place where
it makes a lot of sense to deploy QoS in order to ensure that lower
priority traffic is what gets dropped on the floor.  That sort of QoS
can usually be handled intra-domain and might not require much more than
CoS-based queuing on the routers at either end of the bottleneck link.
Usually reliable sources tell me that this technique was deployed in
parts of the old DDN (e.g. using Proteon routers and OSPF) ~15 years ago
and worked well.  I'm told that CoS-based queuing is not deployed today
in the DDN equivalent, though a current RFP indicates they are 
considering
using it in future.

> or who deliberately routes over a bottleneck link when there is 
> another choice.

	The one (interesting to me) use of MPLS would be to traffic-engineer
around a temporary bottleneck.  There is a research opportunity for 
someone
to develop a routing protocol enhancement to detect congested links and
automatically re-route an *appropriate* amount of traffic around them --
without creating an oscillation as to which link/path choice is 
congested.
Techniques such as OSPF Multi-path are interesting, but split load 
without
knowledge of which link is how congested.  Past proposals for QoS-based
routing protocols that consider the link congestion in path selction 
have
tended to suffer from temporal oscillation as to which link/path between
A and B is congested.

Ran
rja at extremenetworks.com