[cgl_discussion] SCTP PoC for Linux 2.4. kernel
mika at osdl.org
Thu Jul 24 13:59:36 PDT 2003
On Thu, 2003-07-24 at 12:39, Brian F. G. Bidulock wrote:
> Hey! Rich kid!
> Check out http://www.openss7.org/linux-sctp-0.2.16.tgz for Linux 2.4.18
> kernel patch for Linux native sockets SCTP.
Yes, see STD.4.0 requirement in our spec. From the first v1.0 drafts
SCTP has been our P1 requirement.
> This patch is supported by the OpenSS7 Project.
Which as an old SS7 developer I hold in high regard. Unfortunately there
are reasons (like some companies trying to sell commercial SS7 Linux
implementations) that have kept us distant from that project.
> Forget ethernet bonding: Lockheed Martin ATL sweat tested it and
> obtained 10ms average and 20ms high switchover times betwen interfaces
> on multi-homed hosts with a 100 HZ tick clock (expect 1ms average and
> 2ms high switchover times with 1000 HZ tick clock).
> Performance statistics at various packet sizes show like performance to
> NET4 TCP on same kernel with SCTP actually performing better than TCP at
> higher packet sizes. See
Frankly, I expect most companies use HW solutions (i.e. Network
Processors) for user plane traffic. At least to me the ethernet bonding
feature we have is aimed to be used to make the internal (i.e. cluster)
LAN tolerant to HW failures. And AFAIK nobody is planning to use TCP
> Some other things you'll find in our sandbox is Linux STREAMS, SS7,
> STREAMS SCTP, SIGTRAN UAs, ISDN, ... You know: carrier stuff. Unlike
> CGL which is starting to look like just another micro-distro (i.e.
> broken kernel minus all the useful stuff).
Repeat after me: "CGL is not a distro!". CGL is a specification like LSB
aimed to distribution companies. We did have a CGL-kernel for some time,
but decided to drop it a long time ago (yeah, SourceForge site still has
that, I guess we should erase those).
> Is that FUD? Did ya' wanna test something? What does the D in OSDL
> stand for again? What does the C in CGL stand for again?
> Wakeup up before D and C stand for something else.
Ah, thanks, I needed that. Nothing is better than a good flame mail to
get my juices flowing :-)
Inside OSDL (the company), there are several developers that are
pursuing areas of their interest in Linux kernel and doing development
with capital "D" (I think that issue is beyond question).
Unfortunately the intersection of their areas of interest and CGL
contains only me and maybe Mark (although of course a lot of their work
on stabilization etc. indirectly benefits CGL too). We are using our
limited (i.e. probably not even 50%) time on working on TIPC.
Outside OSDL (the company) but inside CGL there are few projects (I
guess OpenHPI is the most high profile), but I agree, there should be
more. This (PoC resourcing) has been my major headache for last 9
months, with no end in sight. Welcome to real world.
What comes to C, I fail to see your point. Please clarify.
> Software Live Upgrade. The PoC are so far away from carrier grade I can
> only laugh. Read an RBOC RFP some day. Start with any sentence
> containing the word Rollback.
We actually debated this Monday in our F2F to whether to scrap the whole
software installation and upgrade from our spec, because it is so far
from being usable.
The trouble here is that traditionally all of this has been done
with in-house tools, and it seems that nobody is willing to get involved
in projects like SiS to create a common solution.
We did agree to keep it still in, but you do raise a valid point.
> Linux HA. Strange, since the IBM HA the project was supposed to be
> reverse engineering was considered suitable for back office or low
> reliability service platforms, but NOT carrier grade.
Tell me about it ;-) There are some dark sides in committee work (you
know, getting a camel instead of a horse). See Zhu Yi's analysis:
Thanks for feedback :-)
More information about the cgl_discussion