3 ms·

"Well, in TCP, window scaling needs to be OS-global to avoid flapping. This means TCP lives in the kernel. And this means, if you want a protocol with any prope

"Well, in TCP, window scaling needs to be OS-global to avoid flapping. This means TCP lives in the kernel. And this means, if you want a protocol with any property similar to window scaling, it also needs to live in the kernel." Sorry but this is a huge assertion with absolutely no supporting evidence or argument. What exactly do you mean by "flapping"? Why do we need to avoid it? And why does a protocol need to live in the kernel to avoid flapping? I suspect those assertions are based on an assumption that congestion control gets done in a cooperative manner across connections. (I'm assuming the "window" here is congestion window.) I've never seen or heard of a TCP stack that somehow takes into account all TCP flows in a system. As a matter of fact, even if that was the case, it would be too limited a view of the responsibilities of TCP congestion control. The congestion control algorithms are working on a global picture of congestion... as in across the entire network path between the two communicating nodes. Various cc algorithms (reno, vegas, bic, cubic etc.) are using their own techniques to probe the network path between the two endpoints (either using packet drops or round-trip delay increases as a signal of congestion). As such, the concern of congestion control extends beyond just the one node where the algorithm happens to be running. But the important point here is that each node on the network uses only the signals available locally at that node. And for the purposes of this argument, you can consider each of the TCP endpoints on a single machines as an independent node. I don't see any convincing case why two separate instances of these state machines can't be running independently in kernel and user space. Since ultimately, if they're competing for bandwidth over a common, narrow part of the pipe, they'd each use their own congestion signals to arrive at the same conclusion (assuming the protocols are designed for fairness).

jsnell 12y ago
> I've never seen or heard of a TCP stack that somehow takes into account all TCP flows in a system. Taking into account all flows is indeed not useful. But there's some useful middle ground between "all flows" and "each flow completely separately". At work we've got a transparent proxy with an integrated userspace TCP stack. When it's installed in a mobile operator's network, all of that operator's subscriber traffic will be going through it. Now, for each subscriber all the flows between the terminal and the proxy will be in the same "congestion domain"; they're guaranteed to be competing over the same network resources (whether it's backhaul or radio capacity). And in fact for the scarcest resource of the radio capacity each subscriber is essentially in their own congestion domain due to the way the radio base stations scheduling algorithms work. Having the custom TCP stack treat all of a single user's flows as a single unit rather than individually is a big win. (The original claim that TCP must in the kernel for "window scaling" doesn't make any sense to me, no idea of what it could be referring to).
- chetanahuja 12y ago
  Hmm... interesting insight from the core network. I guess another reason to use a UDP (encrypted) protocol would be to prevent such middle-box shenanigans ;-)

jsnell 12y ago

> I've never seen or heard of a TCP stack that somehow takes into account all TCP flows in a system. Taking into account all flows is indeed not useful. But there's some useful middle ground between "all flows" and "each flow completely separately". At work we've got a transparent proxy with an integrated userspace TCP stack. When it's installed in a mobile operator's network, all of that operator's subscriber traffic will be going through it. Now, for each subscriber all the flows between the terminal and the proxy will be in the same "congestion domain"; they're guaranteed to be competing over the same network resources (whether it's backhaul or radio capacity). And in fact for the scarcest resource of the radio capacity each subscriber is essentially in their own congestion domain due to the way the radio base stations scheduling algorithms work. Having the custom TCP stack treat all of a single user's flows as a single unit rather than individually is a big win. (The original claim that TCP must in the kernel for "window scaling" doesn't make any sense to me, no idea of what it could be referring to).

chetanahuja 12y ago
Hmm... interesting insight from the core network. I guess another reason to use a UDP (encrypted) protocol would be to prevent such middle-box shenanigans ;-)