Transport-level protocols in user space
Transport-level protocols in user space
Posted Jun 23, 2016 19:42 UTC (Thu) by nybble41 (subscriber, #55106)In reply to: Transport-level protocols in user space by cwillu
Parent article: Transport-level protocols in user space
We're long past the point where it is reasonable to simply assume that every device and application will employ fair congestion algorithms. Effective traffic shaping policies at the border are a necessity, and render tight control over the endpoints' congestion algorithms unnecessary. In any case, it doesn't make sense to allow applications to use UDP (which has no built-in congestion control) and yet forbid them from taking charge of the TCP congestion algorithm.
Posted Jun 27, 2016 4:29 UTC (Mon)
by gdt (subscriber, #6284)
[Link] (9 responses)
To date most UDP algorithms have had flow-control. DNS, for example, has one packet in flight per query. Where UDP algorithms don't do congestion control then we already see congestion collapse, such as with high-rate videoconferencing systems taking out campus traffic. Rate-limiting of client-side interfaces isn't enough. To suggest otherwise is to think only of the case of congestion is where the bottleneck link is the link to the customer. But there are two client-side interfaces on any congested path, so the the suggestion of using ingress rate-limiting fails on its own terms, as it fails to address the issue of congestion on the *far* client-side link. In any case rate-limiting is too large a stick to be deployable. The customer has paid for 10Gbps. Rate limiting says they can't transmit at 10Gbps, even if that causes no congestion. What you are handwavingly asking for is that the client-side interface ask "is this connection's sending rate reasonable given the apparent congestion control parameters?" That is, the router needs to reverse-engineer the TCP algorithm's variables. Easy enough to do for a TCP stream, but to do it for UDP streams then the only reasonable way to do that is for the router to tunnel them in a TCP stream to the far client-side egress interface. It also adds a new performance parameter to interfaces: the number of concurrent client-side connections they can support; and it's not difficult to see how that can become an anchor for an effective denial of service (and yeah, you could soft-fail and not monitor connections, in which case the library mentioned in another comment starts by opening 100,001 connections).
Now maybe networks will have to do that. But let's not pretend it will be cheap, either finanically, in terms of robustness, or in terms of latency (a three-way TCP handshake before that UDP packet progresses into the network). The whole point of the TCP/IP protocols is that they found a better-performing and more robust design than "enforce congestion control in the network". Moving away from that design necessarily means less performance and less robustness. Maybe a failure of the commons will force us to that situation. But let's not pretend it is optimal.
Posted Jun 27, 2016 6:43 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (3 responses)
I don't think anyone suggested otherwise yet.
> it fails to address the issue of congestion on the *far* client-side link.
When you receive too much it's because you asked for it. For instance, this guy currently saturating your link with his brain-dead video conference application is almost always someone you know and someone you're trying to communicate with using the same brain-dead application. I bet you may both switch to a smarter and gentler application next time.
> What you are handwavingly asking for is that the client-side interface ask "is this connection's sending rate reasonable given the apparent congestion control parameters?" That is, the router needs to reverse-engineer the TCP algorithm's variables.
What's done in the network doesn't have to be that real-time, that fine-grained and that close to TCP: leave that to the applications.
> The whole point of the TCP/IP protocols is that they found a better-performing and more robust design than "enforce congestion control in the network".
What you and TCP are "handwavingly" asking is for everything to be nice and behave on the Internet. TCP's congestion control was a very smart afterthought, however gentlemen agreements can only last for so long:
Posted Jun 27, 2016 17:34 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (2 responses)
I'm not sure that's really true, so much in society depends on people doing the right thing even when an authority isn't watching, civilization seems to still exist. The network is just another facet of human interaction.
Posted Jun 30, 2016 3:51 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Whatever "real-world" agency is actually policing the internet has much bigger fish to fry than congestion control. Among many others, ransomware looks higher priority to me. Good luck with that one already.
I don't think anyone expects the internet to look anything like a civilization any time soon. I hope the Linux network stack maintainers are not under such an illusion.
Posted Jul 2, 2016 13:16 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
> I'm not sure that's really true, so much in society depends on people doing the right thing even when an authority isn't watching, civilization seems to still exist. The network is just another facet of human interaction.
The problem here is that the people feeling the pain are not the people inflicting it. Even within a household. And as soon as the choke-point moves "out there", all the evidence says that people are indifferent (at best!) to the pain they inflict on other people - if it's some impersonal "them", it's not seen as important.
I think the fairest thing to do is choke traffic by IP address. And if it's IPv6, you choke based on the network portion (iiuc, v6 comes as a network half and device half, and it's allocated by the network half). That way, cheating by opening multiple connections won't work :-)
Cheers,
Posted Jun 27, 2016 17:16 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link] (4 responses)
At the application level, which was the whole point. The proposal which has gathered so much opposition was merely to give applications control over the congestion algorithm for TCP, when they already have full control over the congestion algorithms (if they exist at all) for UDP-based protocols.
This is not an argument that congestion algorithms are useless, but rather that mandatory QoS is needed at the routers regardless of any congestion algorithms (well-behaved or otherwise) at the endpoints. You can't simply rely on the endpoints to do the right thing for the health of the entire network.
> In any case rate-limiting is too large a stick to be deployable. The customer has paid for 10Gbps. Rate limiting says they can't transmit at 10Gbps, even if that causes no congestion.
You don't set a fixed rate, you limit the amount of data in the buffer, prioritizing packets according some "fairness" policy and dropping anything that can't be transmitted in a reasonable time. This is exactly what adaptive AQM (e.g. CoDel) was designed for, and it works quite well. If there is no congestion then you can transmit at line rate; if congestion appears then you start dropping packets selectively to maintain the configured QoS policy.
Of course, you only get to set the QoS policy on your own routers. The endpoints are generally the lowest-bandwidth and thus most congested points, but if congestion does appear elsewhere in the network then the administrators of those routers will determine the policy. In my opinion the best default policy would be a fair division of available bandwidth according to source addresses for IPv4 or source /64 prefixes for IPv6—by user, in other words, to the extent that one can be readily identified.
Posted Jun 29, 2016 1:48 UTC (Wed)
by gdt (subscriber, #6284)
[Link] (3 responses)
The endpoints are generally the lowest-bandwidth and thus most congested points I see that assumption a lot in this discussion. For many nations the undersea capacity is the bottleneck; for Australia's NBN it is the links to the ISP connection point (the 'CVC'); for a campus network it might be the campus link, shared between thousands of downstream users; for a metro ethernet network it might be the link from the basement switch of the building, shared between all occupants of that multistory residential block. In short, congestion immediately north of the endpoint -- although common for US consumers -- isn't universal enough to anchor a design for congestion control enforcement .
Posted Jun 29, 2016 7:59 UTC (Wed)
by micka (subscriber, #38720)
[Link] (1 responses)
north of ? I'm confused... Does it say something about the orientation of landline or cable installations ?
Posted Jul 2, 2016 13:18 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jun 29, 2016 17:56 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link]
Short of the adoption of a protocol like Backward ECN (https://en.wikipedia.org/wiki/Network_congestion#BECN) there isn't much that *can* be done at the ISP or national level beyond attempting to ensure fair access for each end-user.
Posted Jul 1, 2016 21:25 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
I think you're assuming knowledge and ability way beyond what is actually available in most homes. My router is supplied by the telco, and I have no idea how to configure it - I have actually actively wanted to NOT get involved in messing with it.
Cheers,
Transport-level protocols in user space
Transport-level protocols in user space
http://www.stevesouders.com/blog/2008/03/20/roundup-on-pa...
https://trac.filezilla-project.org/ticket/2309
The per-connection "fairness" never made sense anyway: what's fair about someone or something multitasking getting more bandwidth?
Transport-level protocols in user space
Transport-level protocols in user space
Transport-level protocols in user space
Wol
Transport-level protocols in user space
Transport-level protocols in user space
Transport-level protocols in user space
Transport-level protocols in user space
Wol
Transport-level protocols in user space
Transport-level protocols in user space
Wol