On Sat, 21 Oct 2006, Spencer Dawkins wrote:
> Hi, David, > > If I can make one suggestion, don't dork with most of these numbers. > > It used to be, back in a quieter and gentler day, that TCP senders thought > TCP receivers were basically honest, but no more. After Stefan Savage's [1] > paper on misbehaving receivers that do ack-splitting, etc. at least some TCP > developers started getting very snotty about TCP behavior that didn't look > like standard TCP, and I don't know that they've stopped. > > So you may find yourself at the wrong end of a TCP implementation that > behaves badly because it KNOWS that you should have dropped the congestion > window in half after a loss, and if you didn't, you're cheating and the > receiver will try to enforce what it KNOWS you should be doing. > > ... and, since standard TCP is entirely ACK-clocked, there's no way to know > what the receiver will do as an enforcement - anything you see would be ad > hoc. You might see senders ignoring some ACKs and then timing out before > retransmitting, because the sender "knows" you couldn't have really gotten > the transmitted bytes yet. The downside potential is large and not > well-defined. > > I worked for a start-up that did TCP accelerators for wireless, and we > started seeing VERY interesting behaviors on TCPs that we were dorking with, > sometime around 2003. I'm not active in the space now, but assume that the > weirdness has continued. I remember Linux being one of the first TCPs to add > these checks (but I've slept since then). > > If you haven't read [1], it's available at > http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf, and it is, very honestly, > hilarious - showing tricks like, "optimistic ACKing" (if you don't want an > HTTP sender to be flow controlled, heck, just send ACKs ahead of sequence > numbers you receive and then use byte ranges at the HTTP level to fill in any > holes that you missed because of loss - wheeeee!). If you are asking > questions like the ones below, read it before you act on any of the answers > you receive (including this one!). > > Thanks, > > Spencer > ----- Original Message ----- > From: David Barrett > To: 'theory and practice of decentralized computer networks' > Sent: Friday, October 20, 2006 6:22 PM > Subject: [p2p-hackers] TCP over UDP "magic number" questions > > > Following up on my earlier question, TCP has a bunch of "magic numbers" > whose best values vary depending upon the source you consult. I'm curious if > you have any input on: > > > > 1) What's a good initial value for the cwnd, whether starting from > scratch or after a RTO? I know RFC2581 says one thing, and 3465 says > another, and others say other things. I'm curious what you actually use and > like, and why. > > > > 2) To what do you set the ssthresh in response to a RTO? To a > fixed-fraction of pipe (say, 50%) or some fraction of something else? > > > > 3) How far do you "fall back" the cwnd in response to a RTO? To a > fixed value (say, 1472 bytes) or to some fraction of something else? > > > > 4) To what do you set the ssthresh in response to a drop? To a > fixed-fraction of pipe (say, 50%) or some fraction of something else? > > > > 5) How far do you "fall back" the cwnd in response to a RTO? To > 'ssthresh' or something else? > > > > 6) What ALPHA value do you use for RTT smoothing? RFC 793 (3.7) > recommends between .8 and .9; any preference? (updatedRTT = ALPHA*oldRTT + > (1-ALPHA)*newRTT) I'm using .85 for lack of a better idea. > > > > 7) What BETA value do you use for RTO calculation? RFC 893 (3.6) > recommends between 1.3 and 2.0; any preference? (retransmitTimeout = BETA * > rtt) I'm using 1.65, for no particular reason. > > > > Sorry for the big dump of questions; can you offer any guidance on any of > these? > > > > -david > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
