Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!decwrl!ucbvax!MIRSA.INRIA.FR!Christian.Huitema
From: Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: When is a link saturated?
Message-ID: <9101150900.AA08526@jerry.inria.fr>
Date: 15 Jan 91 09:00:36 GMT
References: <9101150724.AA12358@mcsun.EU.net>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The Internet
Lines: 40

Cisco's response is one of the possible solution to the "link saturation"
problem. In fact, to state a complete definition, a link is saturated when in
cannot accept more traffic without degrading the overall quality of service
beyond acceptable limits. This relates directly to the problem of congestion
control in datagram networks.

Amongst the strategies for pushing the limits, one find indeed the separation
of traffic in different "priority" classes. This can be done by using a
priority parameter in the datagram headers, e.g. IP "class of service"
parameter. The effect is that priority traffic is treated as "foreground",
while non priority traffic is queued in background and only obtain what is left
after the priority traffic is served. In fact, that strategy should be
implemented carefully, as one must guarantee that at least some non priority
traffic is transmitted.

The scheme used by cisco does probably not rely on the IP "class of service", 
as most TCP and UDP implementations use the same "standard" class of service
for all connections. One can indeed use the "protocol identifier" (TCP, UDP,
ICMP..) and place different priorities to different protocols, but I am a bit 
puzzled by cisco's assertion that they give "telnet" traffic precedence over 
"ftp": after the first synchronisation, neither the IP headers nor the TCP 
header bear any indication of the application layer protocol. The only way to 
make this correlation is to "remember the first exchange"; but if parallel 
routes can be used, there is not even a garantee that the synchronisation 
packets and the data packets will follow the same route! One should also note
that if IP segmentation is used, the TCP header is only present in the first
segment...

A more conventional scheme relies on the separation of the traffic in classes
based on the packet size: interactive traffic use shorter packets than file
transfer; the shorter packets get routed first.

A promising scheme, which I heard several time, is to manage one queue per
source host. The idea here is to give an even share of the network to every
station; it is also an incentive to implement decent end to end flow controls
(e.g. slow start) as the rogue TCP which use very long queues will observe very
long transit delays and thus very poor performance, while the correct TCP will
work normally. I dont know whether cisco or others plan to implement that.

Christian Huitema