pace@spectra.COM (William B. Pace) (10/13/89)
A friend is implementing TCP/IP and has a couple of simple questions which someone out there in netland could help him with. He has looked through the RFC's but doesn't see his answers there. The environment is a common Ethernet lan. No gateways, routers, bridges, brouters, long-haul networks, beer, knockwurst or oompah bands are involved. 1) If a packet is not acknowledged, how many times should TCP retry sending the packet before giving up? 2) What is a reasonable time for a SYN packet to time out? 3) What is a reasonable fixed TCP/IP timeout for an Ethernet lan when you don't want to do fancy retry timing ala Karn's work? 4) When programming an Ethernet controller (e.g. Lance chip), how many times should the controller retransmit the packet when it detects collisions and other errors before giving up and reporting an error to the driver? Please send responses to pace@spectra.com. Thanks for the help. Bill Pace pace@spectra.com Disclaimer: My boss doesn't even know I exist. "I'm not a real programmer, but I play one on T.V."
craig@NNSC.NSF.NET (Craig Partridge) (10/13/89)
> A friend is implementing TCP/IP and has a couple of simple questions > which someone out there in netland could help him with. He has looked > through the RFC's but doesn't see his answers there. The environment > is a common Ethernet lan. No gateways, routers, bridges, brouters, > long-haul networks, beer, knockwurst or oompah bands are involved. Uh... first a pushy question. Is your friend implementing TCP, or something to run over an Ethernet? If he's running something over an Ethernet, fine, but don't call it TCP. Otherwise some poor soul will try sometime later to run it through a gateway, and will get badly flamed.... On a second point, doing the right thing (i.e. real TCP) for each question raised, isn't very hard. I don't know what your friend feels he's saving. > 1) If a packet is not acknowledged, how many times should TCP retry > sending the packet before giving up? 10 is a nice number, *iff* you do exponential backoff. > 2) What is a reasonable time for a SYN packet to time out? start with 1/2 second or so, and exponentially back off. > 3) What is a reasonable fixed TCP/IP timeout for an Ethernet lan when > you don't want to do fancy retry timing ala Karn's work? Phooey -- Karn's algorithm and Jacobson's algorithm are both very simple. Jacobson even gives the C code in his paper. Furthermore, if your Ethernet saturates, fixed timeouts will make the situation worse.... > 4) When programming an Ethernet controller (e.g. Lance chip), how many > times should the controller retransmit the packet when it detects > collisions and other errors before giving up and reporting an error > to the driver? Dunno... any Lance experts? Craig
desnoyer@apple.com (Peter Desnoyers) (10/13/89)
In article <242@spectra.COM> pace@spectra.COM (William B. Pace) writes: > 4) When programming an Ethernet controller (e.g. Lance chip), how many > times should the controller retransmit the packet when it detects > collisions and other errors before giving up and reporting an error > to the driver? I believe the retransmission you are talking about is part of the Ethernet spec. I seem to recall that it is something like 10 times with (random) binary exponential back-off, and another 6 at the maximum random back-off, and then report an error. Check the spec - this is essential to the correct operation of the Ethernet protocol. With linear backoff, the protocol is unstable and vulnerable to congestion collapse. With exponential backoff but off by some factor from the spec you could get squeezed out or hog the bus. Peter Desnoyers Apple ATG (408) 974-4469
BILLW@MATHOM.CISCO.COM (William Westfield) (10/14/89)
The environment is a common Ethernet lan. No gateways, routers,
bridges, brouters, long-haul networks, etc, are involved.
No. No. Please do NOT make any assumptions about the environment
a TCP will be located in. I can't tell you how many problems
assumptions like this have caused (they always end up used in an
environment other than the one they were designed for originally.
1) If a packet is not acknowledged, how many times should TCP
retry sending the packet before giving up?
Well, one philosophy says "forever", which is to say that this should
be controlled by the application, rather than by TCP. If the application
is telnet, you let the user decide when to abort. If it is something
like mail, the application might abort after several minutes.
2) What is a reasonable time for a SYN packet to time out?
0.5 seconds, with exponential backoff and retransmission, with a total
timeout of 30 seconds or so. The exponential backoff is real important
here. The short initial retransmission will let ARP drop packets.
3) What is a reasonable fixed TCP/IP timeout for an Ethernet lan when
you don't want to do fancy retry timing ala Karn's work?
Never use a fixed timeout. An exponential timeout is easy to implement.
Even Karn/Jacobson algorithms, although "fancy" turn out to be
wonderfully uncomplicated to implement.
4) When programming an Ethernet controller (e.g. Lance chip), how many
times should the controller retransmit the packet when it detects
collisions and other errors before giving up and reporting an error
to the driver?
This is fixed by the ethernet spec, and usually by the ethernet
controller. It is 16 times total. The LANCE does not permit you
to change this number, although some other controllers might.
Bill Westfield
cisco Systems.
-------karn@ka9q.bellcore.com (Phil Karn) (10/16/89)
In article <8910131633.AA12633@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: >Uh... first a pushy question. Is your friend implementing TCP, or something >to run over an Ethernet? If he's running something over an Ethernet, fine, >but don't call it TCP. Otherwise some poor soul will try sometime later >to run it through a gateway, and will get badly flamed.... AMEN!! >> 1) If a packet is not acknowledged, how many times should TCP retry >> sending the packet before giving up? > > 10 is a nice number, *iff* you do exponential backoff. Personally, I like (and use) "infinity", but I seem to be a minority... >> 2) What is a reasonable time for a SYN packet to time out? > > start with 1/2 second or so, and exponentially back off. I think this is too small. 5-10 seconds is more realistic; remember it doesn't hurt to use longer timeouts except when the network is losing lots of packets, and then you don't want to add to the confusion. In my own implementation, I keep a cache of IP address vs smoothed round trip times and mean deviations. These are kept on a global basis, i.e., they're computed in addition to the per-connection calculations. When opening a new connection, I first check to see if there's an entry in the cache. If so, I initialize my SRTT and MDEV values from the cache. If not, I use a default (typically SRTT = 5 sec and MDEV = 0). Phil
hwajin@wrs.wrs.com (Hwajin Bae) (10/18/89)
In article <8910131437.AA06523@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes: >> 4) When programming an Ethernet controller (e.g. Lance chip), how many >> times should the controller retransmit the packet when it detects >> collisions and other errors before giving up and reporting an error >> to the driver? When transmission fails due to the collision LANCE will attempt to retry up to 15 times. The famous "truncated binary exponential backoff" algorithm comes in to play between retries. When collision jam signal is subsided, LANCE will recalculate a delay before transmitting as an integral multiple of the slot time (512 bit). The number of slot times to delay before the nth retransmission is chosen as a uniformly distributed random integer in the range: 0 <= r <= 2^k where k = min (n, 10) according to the LANCE manual. If all 16 attempts fail, RTRY bit in TMD3 will be set. You can't control this logical from your driver so it's a given; you write your driver to conform to this feature. -- Hwajin Bae Wind River Systems, Emeryville, CA