Hi, Will,
> Thankfully my protocol doesn't have to interact with other TCPs in any > way - I'm just pinching the TCP flow control mechanism as I figure I'm > not going to come up with a better one. Since it has no need to be > bit-compatible with TCP, and since I'm coding for a specific app > rather than the general case, I can make some shortcuts such as not > having rwnd (the receiver will always want as much data as the sender > can throw at it), and building sack in rather than having it as an > option. > > Your point on defensive coding is well taken, and probably more so in > a p2p resource-sharing use case than in general. I'm surprised though > that 'blowing slow start wide open' as you describe actually results > in better performance - surely that means that when you reach the > limit of the connection, you'll lose a ton of packets, and take a long > while to recover? Or does sack mitigate this enough to not be a > problem? So, this is kinda where TCP research is today - if a specific environment is "different enough" from the environment where TCP works better than anything else we know about, it may be appropriate to do something different. The "and take a long time to recover" happens even with SACK, when you have a huge window that gets cut in half and then regained at one additional segment per RTT (and if you lose ANOTHER packet, it gets cut in half AGAIN, ...). The canonical math was satellites with (from memory) 200-segment windows and 500 ms RTTs (up/down in each direction) - lose a packet and that goes to 100 segments, and it takes 100 segments*500 ms before you have build the window back up. (I may have the math wrong, but the order of magnitude is correct - a full minute or two to recover from a single-segment loss) So in specifc environments, people may do something else. > I find it quite interesting that detecting congestion through packet > loss turns out to be a better performing solution than using > heuristics to spot congestion before it occurs. Simplicity wins, I > guess. Based on my limited experience with transport triggers, the other part of the problem is that loss is unambiguous (you know that you lost a packet and, since TCP is used over links with arbitrary RTTs, you know that you need to respond now, because continuing to transmit at local line speed may make things really bad, really quickly), but heuristics are ambiguous, and we moved pretty quickly into heuristics about what you do when the heuristic says you MIGHT be "getting close to" congestion. And then there's the "what if you're responding to a heuristic and lose a segment in the middle of your recovery - how does THAT interaction work?" problem. You can tie yourself in knots pretty quickly. So we're at "assume you don't have congestion until you know, for sure, that you do, and then back off hard" - kinda where TCP is today. Good luck. Spencer _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
