Undeliverable Mail


RDMAILER ($EMD000%SDSUMUS@CUNYVM.CUNY.EDU)
SUN 25 SEP 1988 14:23:15 CDT


The following errors occurred while attempting to send this mail file.

Best guess - SENDER is: TCP-IP @SRI-NIC.ARPA

*14.23.10 FROM: Invalid user/address string

----------------------------- ORIGINAL MESSAGE -------------------------------

Received: from ADMIN.BYU.EDU by SDSUVM.BITNET (Mailer X1.25) with BSMTP id
 0099; Sun, 25 Sep 88 14:23:13 CST
Received: by BYUADMIN (Mailer X1.25) id 4112; Sun, 25 Sep 88 13:20:58 MDT
Date: Wed, 21 Sep 88 05:52:49 GMT
Reply-To: <TCP-IP@SRI-NIC.ARPA>
Sender: "(TCP-IP ARPA Discussions)" <Sender: "(TCP-IP ARPA Discussions)" <TCPIP-L@BYUADMIN>
Comments: Warning -- original Sender: tag was tcp-ip-request@SRI-NIC.ARPA
From: Darren Griffiths
              <pasteur!helios.ee.lbl.gov!lace.lbl.gov!dagg@UCBVAX.BERKELEY.EDU>
Subject: Re: Multiple TCP/IP servers on one host
X-To: tcp-ip@sri-nic.arpa
To: jeff consoer <To: jeff consoer <CC57000@SDSUMUS>

In article <8809151736.AA01161@fji.isi.edu> prue@VENERA.ISI.EDU writes:
>>> 1) If the second path was 25% of the speed of the first path then 25% of
>>> the packets could be sent that way. [...]
>>> if the two end sides were running the Van Jacobsen/Mike Karels code
>>> I believe this wouldn't be to much of a problem. [...]
>>
>>
>>The first thing (splitting load among routes) would screw up the
>>Jacobson/Karels improved TCP completely. They get a big win by
>>estimating the variance of the round trip time; using alternating
>>routes for different packets would drive this variance way up, causing
>>the timeout to be set high, causing long stoppages on lost packets.
>
>I disagree. The first path is four times as fast but has four times as
>many packets. The link delay is only 1/4 the second line but the queuing
>delay is four times as great. The variation of the delivery times for the
>five packets would be less than using a single line. As the queue sizes go
>up the variation in the network delay goes up.
>
>I do however agree with your other point, type of service routing could
>put the second path to very good use.

The first time I thought out loud about routing through two different paths
I did mention that it may mess up the van/mike tcp code. Fortunately this
was at the SIGcomm conference in Stanford and Van wasn't far away. He
quickly set me straight and with a little extra thought it is fairly obvious
that the code would stabalize around the acks of the faster line.

A couple of people have mentioned that instead of looking for well known ports
to decide whether to use a fast line or not that the TOS field should be used.
I agree, this would be much better, but I decided to watch a couple of packets
go by on the local LBL net. I didn't look to long, but I found very few
things actually touch that field.

Another possible thing to do would be to try and figure out which link is the
fastest, if it has one line that is 25% the speed of a second line then the
router could simply send 25% of the packets down the slow connection and the
rest along the fast connection (perhaps using a random number to see which line
the packet is going to go along.) I seem to remember that someone wrote a
paper on this but I can't remember who of the top of my head.

It would be interesting to try different routing algorithms and see which is
the more efficient, with efficient be defined by the perceived throughput to
the user as well as the number of packets going through. I can think of a
few methods that could be tried:

   1 - Leave things the way they are, and just taking the fastest path.

   2 - Choose the path depending on the TOS field, and hope someone uses it.

   3 - Choose the path based on the port (TELNETs go the fast way, SMTP goes
        the slow way.)

   4 - Send a percentage of the packets down one path and the rest down
        another.

Can anyone think of any others? Perhaps when I have some free time I'll do a
couple of tests and see what I come up with.

  Cheers,
     --darren

-------------------------------------------------------------------------------
Darren Griffiths DAGG@LBL.GOV
Lawrence Berkeley Labs
Information and Computing Sciences Division



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:31 GMT