Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!fauern!fauern!eckert
From: eckert@medusa.informatik.uni-erlangen.de (Toerless Eckert)
Newsgroups: comp.protocols.tcp-ip
Subject: IP queuing for X.25 SVC's: conqestion and performance problems.
Message-ID: <2452@medusa.informatik.uni-erlangen.de>
Date: 21 Feb 90 13:06:18 GMT
Organization: CSD, University of Erlangen, W-Germany
Lines: 47

Hi.

I am experiencing some Problems with running IP on top of X.25 (RFC877).
We are currently running IP over 64kpbs X.25 trunks, with a
paket size of 128 byte, window size of 2( ;-() and a MTU of 576 byte.
When unloaded the performance is around 3kbyte/sec and turnaround
time is between 100msec and 200msec depending on the number of
X.25 switches between the two sites.

Now there are two problems:

1. Why is the maximum throughput so low ? I understand that increasing the
   paket size and especially window size on X.25 will increase it, and indeed
   that happens, but tests showed that it will not go beyond 3.5kbyte/sec.
   Has anyone observed better figures for this type of link ?
   I have not been able to trace this problem down.

2. If the network geets more loaded, the paket turnaround times go up
   to 30, 60 or even more seconds. This times are surely not reasonable.
   From what i heve seen, this problems happens, because of a combination
   of the following:
   - the throughput on the SVC used for IP goes down, possible because
     other SVC's use part of the bandwidth.
   - The queues on the IP level and on the SVC level become very long.
     
   Now i really don't understand why one has to build up a long queue
   on a link that is possible very slow. If one would use a much shorter
   queue (possible down to 1 paket), the throughput could be still the
   same, but the turnaround times (for those pakets who get through)
   would be in a normal range.

   The special problem if a X.25 SVC as a provider for the IP link
   is that the throughput on those SVCs may vary in a wide range,
   from unloaded to nearly 0. In this case it could be advantageous to
   measure the SVC throughput and change the queue length according
   to throughput.

   Am i wrong with my ideas - then what is the advantage of having
   a long queue, when this only causes the turnaround times to
   increase, but has not any effect on throughput.

   Any ideas about this ? What is the best way to handle those type of
   links ? 
-- 

Toerless Eckert     Internet: eckert@informatik.uni-erlangen.de
 		    X.400: /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/