phil@shl.com (Phil Trubey) (03/13/91)
In an earlier posting to comp.dcom.lans, I mentioned a problem we were having telneting to an HP 3000 through a bridge using PC/TCP. Well, it turns out that the problem is not related to the bridge, and is actually composed of three separate problems. The original problem was that telneting from PC/TCP on a PC to the HP 3000 would occationally slow way down when the HP was outputing lots of text to the PC's screen. In the middle of transmission, it would start to display one line at a time every four seconds. With a protocol analyzer we were able to determine what was going on. The problem occurs when the PC drops a packet. The HP doesn't realize that this has occured, of course, and merrily blasts the TCP window size number of bytes to the PC. The PC meanwhile keeps sending an ACK that acks everything up to the dropped packet. So far so good. The HP realizes that the PC has dropped a packet when its timeout timer kicks in (4 seconds later). It then proceeds to retransmit the dropped packet and just the dropped packet. The PC, not having kept the packets after the dropped packet, calmly acks the retransmitted packet from the HP and waits for the HP to send the rest of the packets. The HP waits for another retransmission interval and then retransmits the next packet that it had sent. This continues until the HP has sent all outstanding packets - at a rate of one every four seconds. Questions: 1. Is it normal for PC TCP implementations to drop packets fairly frequently? Ie about one packet every 100 or so? 2. The original TCP spec seems to be silent here, but surely this can't be the 'standard' way retransmission works? I would have though that the retransmitter would send all outstanding packets all at once after an ack timeout, rather than one packet every timeout interval, the way the HP 3000 does. 3. Is it normal for TCP implementations to discard all out of sequence packets? Thanks for any info! -- 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
raj@hpindwa.cup.hp.com (Rick Jones) (03/14/91)
>In an earlier posting to comp.dcom.lans, I mentioned a problem we were >having telneting to an HP 3000 through a bridge using PC/TCP. Well, it >turns out that the problem is not related to the bridge, and is actually >composed of three separate problems. > ><<problem description deleted>> >Questions: > >1. Is it normal for PC TCP implementations to drop packets fairly >frequently? Ie about one packet every 100 or so? > It depends on a number of factors - not the least of which is the PC's interface... >2. The original TCP spec seems to be silent here, but surely this can't >be the 'standard' way retransmission works? I would have though that >the retransmitter would send all outstanding packets all at once after >an ack timeout, rather than one packet every timeout interval, the way >the HP 3000 does. > 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. >3. Is it normal for TCP implementations to discard all out of sequence >packets? > 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. >Thanks for any info! > no problem, I live to defend the honor of the MPE networking code ;-) ___ _ ___ |__) /_\ | Richard Anders Jones | HP-UX Networking Performance | \_/ \_/ Hewlett-Packard Co. | Was: MPE/XL Networking Person ------------------------------------------------------------------------ Being an employee of a Standards Company, all Standard Disclaimers Apply
jbvb@FTP.COM (James B. Van Bokkelen) (03/25/91)
One difficult tradeoff when deciding which packet to drop is which end of the TCP window to start from. Most VJ TCPs seem to react badly when you drop the more recent packets first, so since v2.04 we drop the older ones. This can interact badly with some TCP retransmit algorithms, but they're in the minority. In any case, reducing the PC's TCP window to 2048 or 1024 bytes should help. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
van@EE.LBL.GOV (Van Jacobson) (04/03/91)
> One difficult tradeoff when deciding which packet to drop is > which end of the TCP window to start from. Most VJ TCPs seem to > react badly when you drop the more recent packets first, so > since v2.04 we drop the older ones. James, Could you elaborate on this a bit? If something's broken, I'd like to fix it. - Van