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

[Michael Parker]

Hi David, A while ago, I attempted the same thing -- writing a protocol that attempted to mimc TCP over UDP (since the latter is a lot easier to get through firewalls with). I didn't finish the implementation (had to focus on finishing up my Master's thesis instead -- oops), but I read a lot of the literature. From what I could tell, when you can't figure out what a parameter value should be, go with RFC 2581 -- I think it does a good job of giving you the values that will squeeze out most of the performance of your protocol. The other two algorithms you must implement or face serious performance degradation are Karn's algorithm (see "Estimating Round-Trip Times in Reliable Transport Protocols" by Karn & Partridge) and Nagle's algorithm (RFC 896). The only RFC I sought to implement as an optimization was limited retransmit (which is an easy change), or RFC 3042. Now trying to address some of your questions inline... On Oct 20, 2006, at 4:22 PM, David Barrett wrote: 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. I'd stick with RFC 2581 -- I'm always hesitant of those experimental extensions, since there are so damn many. For points 2 through 5, from the sender's perspective, it either detects loss using a timeout (which is bad), or a fast retransmit (which is more lenient). To generalize: If the RTO expires, set cwnd to 1 MSS and the ssthresh to half the amount of outstanding data. For a fast retransmit, ssthresh is again set to half the amount of data in flight, while the cwnd is set to sshthresh+3 and is increased by 1 (MSS) for each new ACK (the effect of this is to keep the amount of outstanding data constant until the retransmitted packet is received). RFC 2581 spells this out in gory detail, and addresses some points I've missed. 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. I would stick with the values and implementation found in the appendix of Van Jacobsen's paper "Congestion Avoidance and Control".  If you haven't read that already, do so. 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. I think 2.0 is the standard, and you can implement it with a shift to boot ;) When I have time tonight, I'll try and look this all up again... It's been awhile since I've poured over it. - Mike

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