Re: [p2p-hackers] TCP over UDP "magic number" questions

[Spencer Dawkins]

Grrr. No Diet Pepsi yet. Corrections in red. Sorry.   Spencer ----- Original Message ----- From: Spencer Dawkins To: theory and practice of decentralized computer networks Sent: Saturday, October 21, 2006 6:59 AM Subject: Re: [p2p-hackers] TCP over UDP "magic number" questions 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 sender 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 sender 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 p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers

_______________________________________________
p2p-hackers mailing list
p2p-hackers@lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers