Weekly Edition
Return to the Kernel page
| |||||||||||||
How not to get a protocol implementation merged
The "Open Base Station Architecture Initiative" is a consortium of
companies which are trying to create an open market for cellular base
station hardware. One of the things this initiative has defined is the
UDPCP protocol - a UDP-based protocol used for communications between base
stations. UDPCP offers reliable transfer, multicast, and more. The Linux
kernel does not currently support UDPCP, but Stefani Seibold has posted a patch which would add that support to the
kernel's network stack.
There have been a number of comments about this code, but one observation by Eric Dumazet is noteworthy: the posted implementation only works with IPv4. The networking developers have made it clear that they are uninterested in accepting an IPv4-only implementation in 2011; IPv6 support is required for any new code. Stefani responded that no base stations currently provided IPv6 functionality and no customers were interested, so there was no point in adding that support at this time. The answer didn't change, though; the networking developers have no interest in merging code which is guaranteed to need fixing in the near future. Stefani has described this requirement as "dogmatic," but she also seems to have realized that it's not going to go away. So UDPCP stays out of the mainline for now, but we will, hopefully, eventually see a reworked version with support for IPv6. (Log in to post comments)
How not to get a protocol implementation merged Posted Jan 13, 2011 2:28 UTC (Thu) by busterb (subscriber, #560) [Link]
I find it amazing how telco gear seems to reinvent basic transport-level protocols for seemingly no particular reason. Does anyone know what problem this protocol even solves that couldn't be done with TCP, SCTP or DCCP (especially SCTP, which is already used in some telecom infrastructures like LTE)
Note that this protocol appears to provide no method to close a connection, for instance. Wow! Seems like OBSAI SIG had a case of NIH syndrome.
How not to get a protocol implementation merged Posted Jan 13, 2011 8:36 UTC (Thu) by dmk (subscriber, #50141) [Link]
>Note that this protocol appears to provide no method to close a connection, for instance. Wow! Seems like OBSAI SIG had a case of NIH syndrome.
It's udp based. UDP is a stateless protocol. No Close() is necessary. ?
How not to get a protocol implementation merged Posted Jan 13, 2011 13:43 UTC (Thu) by busterb (subscriber, #560) [Link]
It appears to be UDP only in the sense that SCTP and other reliable protocols can also be tunneled over UDP, presumably just to make it easier to get through firewalls and initial user-space implementations easier to build on existing socket apis (excluding raw sockets.)
However, it is definitely stateful because of the reliable transport it provides on top of UDP. DoS issues have been discussed on the mailing list, where spoofed UDP packets can flood the connection table:
How not to get a protocol implementation merged Posted Jan 13, 2011 11:20 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
That's actually a bit frustrating. Stream-oriented protocols like TCP and STCP are by now pretty solid and work fine (most of time).
However, that's not true for UDP-based transport protocols. They are often not stable or do not have desired characteristics. For example, DCCP does not have support for packet merging and preserves message boundaries. And sometimes the converse is necessary. Also, it doesn't support priorities.
There's just too much combinations. So everyone just invents their own UDP protocol :(
Oh yes, NIH is also present in copious quantities in telecoms.
How not to get a protocol implementation merged Posted Jan 13, 2011 20:07 UTC (Thu) by fredrik (subscriber, #232) [Link]
I'm not arguing for inventing new protocols. I just want to point out that one reason to base a protocol on udp instead of tcp is reduced latency. This is especially important, and noticable, in current mobile networks like GSM and UMTS.
How not to get a protocol implementation merged Posted Jan 13, 2011 21:54 UTC (Thu) by job (guest, #670) [Link]
Wouldn't SCTP suffice?
How not to get a protocol implementation merged Posted Jan 20, 2011 10:22 UTC (Thu) by renox (subscriber, #23785) [Link]
Well I'm not an expert but SCTP has an initial handshake which require at least one roundtrip before sending data, so the connection initiation isn't low latency..
I wonder why they did it this way?
*: only if the server isn't overloaded though.
How not to get a protocol implementation merged Posted Jan 13, 2011 18:48 UTC (Thu) by caitlinbestler (guest, #32532) [Link]
Do we really want the kernel cluttered with application protocols that
pose as transport protocols, but have the focus of an application protocol?
If you want to think like an application protocol,and actually focus on
If you do think you have the case for a general purpose transport protocol,
Not having IPV6 support is really just the tip of the iceberg that says
How not to get a protocol implementation merged Posted Jan 20, 2011 10:28 UTC (Thu) by renox (subscriber, #23785) [Link]
>> Do we really want the kernel cluttered with application protocols that
pose as transport protocols, but have the focus of an application protocol? <<
Well, if those application protocols can be "compiled out" in the kernel configuration, why not?
How not to get a protocol implementation merged Posted Jan 20, 2011 4:54 UTC (Thu) by pukunui (guest, #65961) [Link]
"no base stations currently provided IPv6 functionality"
If this is true, it's more than a bit of a worry - the first place that IPv4 addresses will run out and where operators will need to offer IPv6 addresses is the mobile space. After all, most of the smartphone handsets are already IPv6-capable.
So the first part of the market that needs to go IPv6 is the mobile part. And there are *no* base stations that do IPv6?
How not to get a protocol implementation merged Posted Jan 20, 2011 8:39 UTC (Thu) by ericc72 (guest, #41737) [Link]
I'm not an expert on this stuff, but my understanding is that most mobile operators, when it comes to stuff done that needs an IP address, often just uses addresses in the private space so really this in not an issue with conflict with the number of public IP addresses. It is kind of like a lot of DSL connections, where you are getting issued a private IP address by the provider and they do NAT at their central office onto the public internet.
How not to get a protocol implementation merged Posted Jan 20, 2011 11:11 UTC (Thu) by foom (subscriber, #14868) [Link]
Well, T-mobile USA, at least, doesn't use official private addresses, because they would conflict with the addresses on users' network's when people are connected via cell and via Wifi. T-mobile instead uses (unrouteable, NATed) addresses in the 25.* network, which is assigned to the UK Ministry of defense. But yes, they don't have to worry about running out of addresses at least...
How not to get a protocol implementation merged Posted Jan 21, 2011 7:33 UTC (Fri) by Imroy (guest, #62286) [Link]
> the first place that IPv4 addresses will run out and where operators will need to offer IPv6 addresses is the mobile space.
Maybe I'm understanding it wrong, but it appears that this protocol is a tunnelling/encapsulation protocol for transporting low-level packets between base stations and their components. It's not involved with the actual internet connectivity of the mobile phones - in the current 2.5G/3G network structure that happens in a specific component (with even more encapsulation - http://laforge.gnumonks.org/weblog/2009/10/27/#20091027-i...). So these base stations and other parts talking UDPCP will likely have private IPv4 addresses and would not cause a problem for IPv6 migration.
Of course, we'd like to move *everything* to IPv6 in the distant (or not so distant) future. But until then I don't see this IPv4-only implementation posing any problems.
|
|||||||||||||