phil@shl.com (Phil Trubey) (03/16/91)
Thanks to all those that replied to me questions about TCP/IP retransmissions
relating to the interop problem we've been having regarding getting a
PC telneting robustly to an HP 3000.
I've put together a summary of what I've received for your general edification.
As an update: There exists patches to the HP 3000 software to do fast
retransmission and we are tracking down these patches. The Win/TCP
software for PCs used to hold onto
out of sequence packets in an earlier release, but they dropped
this feature in the latest release due to memory constraints!
Even if I'm (currently) no further along than before, at least I know
more! Thanks a lot to all those that responded!
---
1. Is it normal for PCs to drop packets...
The consensus here seems to be: yes - depending on the ethernet board
you're using. I was using a 3Com 3c523 (microchannel). At some point
I'm going to try using a Western Digital board and see if it changes
the drop rate.
---
From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston)
No, not in my experience. Unless you have a lousy Ethernet card or
a faulty transceiver connection, your packet loss rate should be
at least a couple orders of magnitude lower than this.
---
From: romkey@asylum.sf.ca.us (John Romkey)
It depends on your ethernet interface. If you're using an old card
like a 3COM 3C501, expect lots of lost packets. Packet loss will vary
with the type of card and load on the net. It may also be a function
of the driver.
---
From: mcc@wlv.imsd.contel.com (Merton Campbell Crockett)
Late '89 or early '90, my firm was working on a response to an RFP and had
a number of PC clones of various manufactures and operating systems in for
evaluation. Out of curiousity, I ran a small ping test with the following
command:
ping x.y.z 64 100
from a VAX 11/750 running 4.3BSD with a 3Com, shared memory, ethernet inter-
face and a VAX8250 running VMS 5.1 and WIN/TCP using a shared driver with
the DEBNI ethernet interface.
As a class, the PC clones were marvelously erratic in their response times.
As I recall, the response times ranged from somewhere around 16ms to 78ms
with average response times in the high 20's and low 30's. There were, gen-
erally, 2 to 8 dropped packets.
RISC machines that were being evaluated at the same time, dropped fewer pack-
ets--if they dropped any--but had greater variance in their response times.
I seem to recall some response times in excess of 100ms. The average response
times were, however, in the mid to high 20's range.
---
From: dotytr@nscultrix1.network.com (Ted R. Doty)
It really depends on how fast the packets arrive. Many (most?) of the
Ethernet boards for PCs don't handle back-to-back packets very well
(if two packets arrive very close together, the board can't keep up
with them and drops the second). I suspect that newer boards are
better, but since workstations are getting faster too, this problem
might be around until PCs can handle full media speed (the number I hear
is 14,800-ish packets per second). So if you get a bunch of Telnet
packets back-to-back, you might expect to see dropped packets.
---
2. Is it normal for TCP/IP implementations to retransmit only the lost
packet...
I read RFC1122 after I asked this - it recommends that when you retransmit,
you send a maximum sized paket containing whatever is in the retransmit
queue - not just retransmit the exact packet that was dropped.
---
From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston)
The retransmission behavior you see is "typical". No reason to waste
bandwidth if there's a chance the receiver already has the rest of the
packets. What's _not_ typical is the PC's behavior of not saving the
"extra" packets.
What the protocol spec actually says it that it's "suggested" that
senders retransmit only the next packet, "suggested" that receivers
save "extra" packets, but "required" that the two interoperate
(albeit at what performance is not specified) even if the other end
doesn't follow the suggestion.
---
From: raj@hpindwa.cup.hp.com (Rick Jones)
Eghads NO! !-) If you were to do that, it would be asking for your
network to go into congestive collapse ;-( When that timer pops (the
first one at least...) the ONLY thing that you can surmise is that the
first packet was lost - you really do not know if any of the other
packets were lost. When (if) you upgrade the MPE/V systems to an XL,
you will find that the XL code is much better in its handling of those
situations (it started-out like the V code, but I changed it ;-) It
does NOT do batch-rtx, but will clear-out the rtxq much faster than
the V code will.
---
From: romkey@asylum.sf.ca.us (John Romkey)
It depends on how you're trying to treat the intervening network. If
you're trying to avoid congestion, you penalize the one for the good
of the many. If you're not, you don't.
---
From: mcc@wlv.imsd.contel.com (Merton Campbell Crockett)
Strategies are left to the implementor and are not part of the protocol spec-
ification. How often and when should the receiving station send an acknowl-
edgement when it has detected the loss of a packet? How frequently should
the transmitting station send a packet to compensate for potential packet
loss? How does the transmitting station determine that the receiving station
does not buffer out of sequence packets when there is no requirement to send
an acknowledgement to an out of sequence packet?
---
From: dotytr@nscultrix1.network.com (Ted R. Doty)
Can you use your analyzer to see what size is negotiated for a TCP
window? I seem to recall a window of 512 bytes when we used Excelan
boards (TCP on the board). Check to see if one of the machines is
violating the window size. I don't think that the sender should have to
retransmit *all* unacknowledged segments, but when it gets the act for
the (single) missing one, it *should* send the others. (this is so you
don't waste lots of bandwidth retransmitting segments that the receiver
might have received and buffered, but couldn't ack because the first
segment was dropped)
---
3. Is it normal for TCP implementations to discard all out of sequence
packets?
No, but if marketing thinks it is more important to conserve memory on
an antiquated architecture (DOS), they'll tell the programmer to slash
'features' :-(.
---
From: raj@hpindwa.cup.hp.com (Rick Jones)
Only on little systems like PC's where there is not much memory for
the TCP code to hold onto. I think that newer PC code might be better
though.
---
From: romkey@asylum.sf.ca.us (John Romkey)
When the ratio of the amount you get yelled at is proportionate to how
much space your code takes up, many things are possible.
[I think John hit the nail on the head with this one - phil]
---
From: mcc@wlv.imsd.contel.com (Merton Campbell Crockett)
The specification states that you need the ability to receive out of sequence
packets and re-assemble the data in the proper order once the missing data
is received. Reality may have intruded in the implementation that you're
using--not enough memory space to store out of sequence packets.
---
From: dotytr@nscultrix1.network.com (Ted R. Doty)
No. If the PC were more robust (no flame here, just an observation), it
would buffer all out of sequence segments. for example: Suppose sender
S sends ten segments (1-10). Segment #1 is lost; segments 2-10 are
received by receiver R. R will not be able to ack receipt, since the
window starts at #1, and #1 was lost. S will time out and resend 1.
When R receives #1, it will ack #10. I'm not clear on whether S should
retransmit 1-10 or just 1. My suspicion is that it should *not*, since
dropped packets are frequently a sign of router congestion, and
retransmitting the entire window would exacerbate this. Check RFC 1122
and 813, 816, and 817.
-----
That's it. Thanks again to all those that responded.
--
Phil Trubey | Internet: phil@shl.com
SHL Systemhouse Inc. | UUCP: ...!uunet!shl!phil
50 O'Connor St., Suite 501 | Phone: 613-236-6604 x667
Ottawa, Ontario, Canada | Fax: 613-236-2043