SCTP allows one to have both IPv6 and IPv4 active
on the same socket at the same time:-D
Now we were rather ham-strung by the V6 API's as
well.. you can't change everything.. so yes
you end up getting addresses in AF_INET6 format
up the socket.. but the cool think (at least with
the BSD version) is you can get a V6 socket to
give you both V4 addresses and V6 addresses.. no
need to do the map to v6 (from v4) and then have
the kernel unmap the thing you just mapped:-0
Unfortunately any but the mildest changes, when
adding SCTP to sockets, would totaly change
the socket API's..
Now, on that front, if you want to do that, you
can always define a new socket like layer:-D
R
Saven:
MS does not really have anything to do with SCTP.
In fact they have refused to even consider
implementing it (yet), until they have a business
need. They were not part of its development nor
are they interested in implementing it AFAIKT.
It would be very hard for MS to do anything to
SCTP at this point. Oh, they could in theory define
their own chunk types that do special things and
not tell us what they are.. but they still
will have to inter-operate with the base protocol..
Of course that is assuming they ever get their
act together and build an SCTP version.
Its actually rather interesting since it is possible
that they will finally find the business need
and then have to try to rush to market with a
stack... which will put them at a serious performance
dis-advantage... after all look at lk-sctp its
at least 5 years old and it still has not been
fully performance tweaked yet... Of course MS
has never been shy about shipping something
that blue screens every few hours:-D
It takes time to develop a stable, reliable, good
performing, transport stack.. and when SCTP
finally hits MS it may hit them over the head:-D
R
AT&T and Bell Labs was never part of SCTP development.
It was developed in an IETF working group
and used MDTP as the base of the protocol (which
came from Motorola by the way).. which
of course changed much over the development of
the spec...
It contains the contributions of lots of folks
including Vern Paxson and Lixia Zhang..
R
Mark:
But that is the beauty of his shim...
1) It makes only one or two INIT transmits at the peer before
switching to TCP.. so timing wise its quick.
2) You setup what port ranges you want to do it on (with
the sysctl's).. the shim rules.
3) And presto you are using SCTP.
I watch'ed Ryan's presentation of his work and he
did a real cool demo with an internet radio player...
Can't remember which one.. but it was quite
impressive to see him just toggle a sysctl and
all of a sudden his player was fault tolerant
when he knocked out the cable..
I don't see being in the name-ctl thing is
that much needed.. just sysctl all of the
ports on and always try sctp first..
It adds maybe 2-3 seconds.. which for us humans
is not that much:-D
R
The host-name-parameter is a very ugly thing that
was added to SCTP by the IESG, not by the wg or
any of the authors:-0
The idea behind it, not that I have ever
supported it, was to allow SCTP to get through
NAT's in an multi-homed way. The problem with
this is it might have been a good idea but it
just can't work... at least I don't see how
to make it work:-D
There are far better ways of dealing with NAT's and
their are drafts on these if one is interested.
Now, as to this wonderful parameter. No one
implements it and no one uses it. I expect
it to disappear from the protocol when it
goes from Proposed -> Draft standard:-D
R
Mark:
I don't believe I have ever seen:
1. SYN
2. SYN ACK
3. REQUEST DATA
4. RESPONSE DATA
In any TCP trace I have ever observed in ethereal (which
as been many but not exhaustive:-D)
What I have seen is
1. SYN
2. SYN ACK
3. ACK
4 REQUEST DATA
5. RESPONSE DATA
Not to say that TCP could not do your method.. but
I believe its API stops you from it.. not allowing
the app to send data until the connect() has
complted (steps 1-3)...
R
Yep, the FreeBSD implementation
comes out of the KAME project.
It is in the process of being submitted to
base FreeBSD and we hope to see it show
up by the 6.2 release
The MacOS stuff is a port of the same code (which
by the way is quite good performance wise
see: http://sctp.fh-muenster.de/Performance/index.html
for some early results...
The one problem with the MacOS stuff is we have not
gotten the locking right for Tiger.. so it works
great for Panther.. but we still need to do some work
to get it to run properly for Tiger:-0
SCTP's method is a bit beyond the TCP
method for a number of reasons:
1) TCP has limited cookie information
it can use without actually storing
something on the server side, which you
do NOT want to do.
2) SCTP can put all sorts of stuff within its
COOKIE and then sign the cookie with whatever
it wants to (usually MD5 or SHA-1). If the
sender wants it can even encrypt the cookie.
3) SCTP has a 4-way handshake that helps with
the whole thing where as TCP still only
gets a 3-way handshake..
So no, TCP's cookie mechanism is not per-se a
clone of TCP.. it takes some of the ideas
from Simpson's early work in this area for sure
but it is not much like TCP:-D
R
No, it just offers another set of
features that SOME applications might
find useful. Does it overlap with TCP,
yes.. since you can change ANY TCP
app to use SCTP with minimal changes.
Will all TCP want to migrate to it.. I doubt
it.. it really depends upon if there are advantages
to it. Besides M$ has not yet seen a business
need for it... I have often wondered why they
did not jump on the band wagon.. since they
can do all sorts of neat extensions that would
be "proprietary" and I could just see them
not releasing any documentation on there extensions..
In a way this is a good thing, since it gets the
stack pretty much in place so that M$ can't bully
there way in and push out linux/BSD et.al...
As to if it is faster, well if you are using the
linux version nope not yet.. since the peformance
work as not gotten very far yet... the stack
is stable but does not perform well... yet.. I believe
that the lk-sctp folks know this and are working
on it.. (at least I hope they are:-D)
R
Hmm.. for working with SCTP I am surprised you
think of it only as something for telco land.
I guess it must be the fact that you were at NorTel at
the time since it is so much telcom minded... yes
I worked at BNR at one time or another so I understand:-D
SCTP it is true is used in SS7 or IP.. but it was designed
as something beyond that.. aka a replacement for TCP.
Will it ever reach that level.. don't know..
Will other apps ever use it? I think so.. but it takes
time.. just like TCP itself took time to become
available in lots of different places
R
Slashdot Mirror
SCTP allows one to have both IPv6 and IPv4 active on the same socket at the same time :-D
Now we were rather ham-strung by the V6 API's as
well.. you can't change everything.. so yes
you end up getting addresses in AF_INET6 format
up the socket.. but the cool think (at least with
the BSD version) is you can get a V6 socket to
give you both V4 addresses and V6 addresses.. no
need to do the map to v6 (from v4) and then have
the kernel unmap the thing you just mapped :-0
Unfortunately any but the mildest changes, when
adding SCTP to sockets, would totaly change
the socket API's..
Now, on that front, if you want to do that, you
can always define a new socket like layer :-D
R
Saven: MS does not really have anything to do with SCTP. In fact they have refused to even consider implementing it (yet), until they have a business need. They were not part of its development nor are they interested in implementing it AFAIKT. It would be very hard for MS to do anything to SCTP at this point. Oh, they could in theory define their own chunk types that do special things and not tell us what they are.. but they still will have to inter-operate with the base protocol.. Of course that is assuming they ever get their act together and build an SCTP version. Its actually rather interesting since it is possible that they will finally find the business need and then have to try to rush to market with a stack... which will put them at a serious performance dis-advantage... after all look at lk-sctp its at least 5 years old and it still has not been fully performance tweaked yet... Of course MS has never been shy about shipping something that blue screens every few hours :-D
It takes time to develop a stable, reliable, good
performing, transport stack.. and when SCTP
finally hits MS it may hit them over the head :-D
R
AT&T and Bell Labs was never part of SCTP development. It was developed in an IETF working group and used MDTP as the base of the protocol (which came from Motorola by the way) .. which
of course changed much over the development of
the spec...
It contains the contributions of lots of folks
including Vern Paxson and Lixia Zhang..
R
Mark: But that is the beauty of his shim... 1) It makes only one or two INIT transmits at the peer before switching to TCP.. so timing wise its quick. 2) You setup what port ranges you want to do it on (with the sysctl's).. the shim rules. 3) And presto you are using SCTP. I watch'ed Ryan's presentation of his work and he did a real cool demo with an internet radio player... Can't remember which one.. but it was quite impressive to see him just toggle a sysctl and all of a sudden his player was fault tolerant when he knocked out the cable.. I don't see being in the name-ctl thing is that much needed.. just sysctl all of the ports on and always try sctp first.. It adds maybe 2-3 seconds.. which for us humans is not that much :-D
R
The host-name-parameter is a very ugly thing that was added to SCTP by the IESG, not by the wg or any of the authors :-0
The idea behind it, not that I have ever
supported it, was to allow SCTP to get through
NAT's in an multi-homed way. The problem with
this is it might have been a good idea but it
just can't work... at least I don't see how
to make it work :-D
There are far better ways of dealing with NAT's and
their are drafts on these if one is interested.
Now, as to this wonderful parameter. No one
implements it and no one uses it. I expect
it to disappear from the protocol when it
goes from Proposed -> Draft standard :-D
R
Mark: I don't believe I have ever seen: 1. SYN 2. SYN ACK 3. REQUEST DATA 4. RESPONSE DATA In any TCP trace I have ever observed in ethereal (which as been many but not exhaustive :-D)
What I have seen is
1. SYN
2. SYN ACK
3. ACK
4 REQUEST DATA
5. RESPONSE DATA
Not to say that TCP could not do your method.. but
I believe its API stops you from it.. not allowing
the app to send data until the connect() has
complted (steps 1-3)...
R
Yep, the FreeBSD implementation comes out of the KAME project. It is in the process of being submitted to base FreeBSD and we hope to see it show up by the 6.2 release The MacOS stuff is a port of the same code (which by the way is quite good performance wise see: http://sctp.fh-muenster.de/Performance/index.html for some early results... The one problem with the MacOS stuff is we have not gotten the locking right for Tiger.. so it works great for Panther.. but we still need to do some work to get it to run properly for Tiger :-0
SCTP's method is a bit beyond the TCP method for a number of reasons: 1) TCP has limited cookie information it can use without actually storing something on the server side, which you do NOT want to do. 2) SCTP can put all sorts of stuff within its COOKIE and then sign the cookie with whatever it wants to (usually MD5 or SHA-1). If the sender wants it can even encrypt the cookie. 3) SCTP has a 4-way handshake that helps with the whole thing where as TCP still only gets a 3-way handshake.. So no, TCP's cookie mechanism is not per-se a clone of TCP.. it takes some of the ideas from Simpson's early work in this area for sure but it is not much like TCP :-D
R
No, it just offers another set of features that SOME applications might find useful. Does it overlap with TCP, yes.. since you can change ANY TCP app to use SCTP with minimal changes. Will all TCP want to migrate to it.. I doubt it.. it really depends upon if there are advantages to it. Besides M$ has not yet seen a business need for it... I have often wondered why they did not jump on the band wagon.. since they can do all sorts of neat extensions that would be "proprietary" and I could just see them not releasing any documentation on there extensions.. In a way this is a good thing, since it gets the stack pretty much in place so that M$ can't bully there way in and push out linux/BSD et.al... As to if it is faster, well if you are using the linux version nope not yet.. since the peformance work as not gotten very far yet... the stack is stable but does not perform well... yet.. I believe that the lk-sctp folks know this and are working on it.. (at least I hope they are :-D)
R
Hmm.. for working with SCTP I am surprised you think of it only as something for telco land. I guess it must be the fact that you were at NorTel at the time since it is so much telcom minded... yes I worked at BNR at one time or another so I understand :-D
SCTP it is true is used in SS7 or IP.. but it was designed
as something beyond that.. aka a replacement for TCP.
Will it ever reach that level.. don't know..
Will other apps ever use it? I think so.. but it takes
time.. just like TCP itself took time to become
available in lots of different places
R