Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!bionet!agate!ucbvax!FUNET.FI!Juha.Heinanen
From: Juha.Heinanen@FUNET.FI (Juha Heinanen)
Newsgroups: comp.protocols.tcp-ip
Subject: When is a link saturated?
Message-ID: <9101151022.AA18309@funet.fi>
Date: 15 Jan 91 10:22:54 GMT
References: <9101150900.AA08526@jerry.inria.fr>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 52

Christian,

   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! 

This can't be true.  If I start a telnet session to another host,
isn't the destination port number equal to 23 in all TCP headers that
are sent from my host and the source port number equal to 23 in all
reply TCP headers?  

The current problem in Cisco's implementation is that the priority
queue mechanism can use IP extended access lists but the in an
extended access list one can only specify the destination TCP port
number, which in the case od a reply TCP packet is whatever number my
host has selected.  So even in the current implementation, my packets
be routed at high priority, but the replies come slow!

   One should also note that if IP segmentation is used, the TCP
   header is only present in the first segment... 

This should not be a major problem if we can assume that most of the
interactive packets are small as you say yourself below.

   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.

This won't help interactive users in a multiuser environment where
other users' file transfers can override the interactive user.

-- Juha