Yeah. I just wish I understood all this stuff better. Having a PhD in control theory seems to help, I guess, but pretty much everyone in the TCP community ends up publishing a few variations of new proposals while they get all the details down and simulate, and that kind of tells me that we're all a little bit in the dark.
 
My best "working in spite of itself" TCP story was from David Clark, who talked about a TCP implementation that "worked", but the performance was so bad it made your teeth hurt. After looking at code and traces, someone finally noticed that the code skipped the part where you actually SEND THE PACKET, except after a timeout, so what happened was, the TCP did a timeout for every single packet that it SHOULD have sent, and then retransmitted it successfully.
 
But it still worked...
 
Good luck!
 
Spencer
----- Original Message -----
Sent: Monday, October 23, 2006 2:58 AM
Subject: RE: [p2p-hackers] TCP over UDP "magic number" questions

Wow, 4614 is a godsend.  2988 is also particularly useful.  Ok, so I think I’ll start with a basic NewReno implementation with Karn’s algorithm for RTT measurement (with fixed x2 backoff) and Van Jacobon’s technique of SRTT calculation.  I like Mill’s nonlinear filter, but I’ll need to do more research on it.  Nagle is out.  Hopefully this’ll get me a good start and I can get crazy after that.  Thanks for all your help!

 

-david

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Spencer Dawkins
Sent: Saturday, October 21, 2006 5:24 PM
To: theory and practice of decentralized computer networks
Subject: Re: [p2p-hackers] TCP over UDP "magic number" questions

 

If you're trying to figure out what TCP is really, you might also look at http://www.ietf.org/rfc/rfc4614.txt, which is the IETF's best shot at hacking through the 100 or so RFCs that talk about TCP.

 

I note that RFC 889 doesn't seem to be listed. I think you can ignore it (unless the functionality got picked up in RFC 1122, which tried to capture the working lore several years after TCP was redesigned for congestion avoidance, etc.).

 

And it's also worth mentioning that TCP will WORK, for some value of "work", with a lot of simplifying assumptions. I'm not sure Nagle matters for anything except Telnet/FTP control channel-style communication, and you may not even know anyone who uses these protocols anymore - they are *so* last-century :-). There just aren't that many protocols that rely on server-end echos any more, and that's the problem Nagle was solving.

 

Thanks,

 

Spencer

_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers

Reply via email to