Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!apple!bbn!bbn.com!craig
From: craig@bbn.com (Craig Partridge)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: high cost of routing
Message-ID: <44940@bbn.COM>
Date: 29 Aug 89 14:11:49 GMT
References: <8908291343.AA07813@ucbvax.Berkeley.EDU>
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 36

In article <8908291343.AA07813@ucbvax.Berkeley.EDU> snorthc@RELAY.NSWC.NAVY.MIL writes:
>	There is a repeatable difference in the number of packets
>required to conduct an operation on the 45 cable alone or routed
>from the 45 cable to the 48 cable for certain applications.
>The difference is fairly high for xterm and telnet, it cannot be
>detected for ftp.
> ...
>examples:	45 CABLE		45 -> 48 CABLE
>	Traffic required to initiate an xterm connection:
>		60 packets		71 packets
>	Traffic telnet requires to transmit a known string:
>		37 packets		45 packets	
>
>YES! arps are stripped out and maintained as a separate stat.
>YES! the test has been run to/from similar hw/sw platforms *
>NO! fragments have not been observed... in fact in the case of
>xterm or telnet you tend to have small packets anyway.

In general, it would be much easier to diagnose this problem with
a packet trace, but...

    - Have you stripped out duplicate SYNs segments?  Some TCP's retransmit
	SYNs pretty quickly at the start.  As a result, you are likely
	to see a few more SYNs/SYN-ACKs in each direction during connection
	setup.  This is simply the cost of getting the connection calibrated
	to the path.  [Although note you can retransmit SYNs in more or
	less intelligent ways].

    - Similarly, does this problem of extra packets persist during the
	entire connection, or only at startup?  If only at startup you
	may just being seeing effects of the retransmit timer calibrating
	itself to the slightly longer delay.

Speculating in the absence of enough data....

Craig