[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SCTP for multihoming
A few comments below..
>-----Original Message-----
>From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
>Sent: maandag 23 februari 2004 22:00
>To: Multi6 List
>Subject: SCTP for multihoming
>
>
>Lode and others,
>
>I've been reading the SCTP for multihoming draft. Here's my feedback.
>
>First a more general issue that comes up in the SCTP-related drafts:
>there is no way for two hosts to find out whether the paths that exist
>between them share any infrastructure. Would it be useful to see if we
>can come up with something that allows hosts to find out? I'm thinking
>something in the way of the record route option.
>
Maybe the tools for that already exist.
Use a TRACEROUTE on every IP address of the remote peer and try to detect
common IP addresses along the routes.
A IP address that show up in 2 or more traceroutes: 2 or more paths going
through that router(not taking into account the endpoints/host naturally)
This might look as a general tool for detecting shared infrastructure...
If traceroute does not fit the bill , then something along the record route
option might be usefull...
Bear in mind.. This will be a optional tool..
Not everybody is that interested in the routes through the network..
>I'm worried about the much more complex packet format (compared to TCP)
>that SCTP has, such as different chunks that can be in a single packet.
>Are there any figures available about SCTP implementation complexity
>and performance?
>
Complexity: I haven't seen any papers on that issue. I've heard some claims
being made about it and I've gone through the SCTP code itself(unfortunaly
not through the TCP code) but I am quite sure that the complexity of TCP and
SCTP is of the same order...
Performance: some papers have looked at the performance and the result are
encouraging, to say the least, esspecially if things start going wrong: if
the loss rate takes off, then SCTP will start outperforming TCP by at least
10 to 20%(blame/thank SACK for that..)
For more infor look at
http://www.sctp.be/ research paper corner(a bit down in the page..)
And specific:
http://www.eecis.udel.edu/~amer/PEL/poc/index.html
>
>I've been opposed to a strict transport layer solution because then all
>transport protocols need to be changed. Still, SCTP is here today so
>why not use it for multihoming in the situations where it suits the job
>at hand. Another problem with SCTP is that moving applications from TCP
>to SCTP means both protocols will have to run side by side for a long
>time. Would it make sense to modify SCTP such that it is possible for
>applications that expect to run TCP to be multihomed without changes,
>and also to be backward compatible? The latter could be done by
>exchanging some "I can do SCTP" options in TCP and then (try to) set up
>an SCTP session if the other also supports it, or even better, switch
>to SCTP in mid-flight.
>
Migration scenarios haven't been described in detail in the present draft
but that is something that will be expanded in the next iteration of the
draft.
It is safe to say that TCP and UDP will never disappear of the face of the
earth...
3 claases of applications can be found in the wild:
- applications that can run on SCTP(only): those are new applications that
need specific things... These application are only a small subset of the
universe...
- applications that can run on TCP and SCTP: Those are new and existing
applications.. They make up a part of the universe
- appplications that run on TCP: those are existing applications They make
up the other part of the universe...
The same can be said for UDP(but let's not go there for the moment...)
Distibution across the classes?:.. Time will tell..
Already existing applications have to do something (change some lines of
code when setting the socket for SCTP..)
Or something between the application and TCP/SCTP may do that.... But some
work needs to be one...
Hey ... There ain't such a thing as a free lunch...
>And I still think the heartbeats are both evil and most of the time
>unnecessary.
>
Sighn... Well then how are we going to know whether a IP address of the
remote peer endpoint is reachable???...
But sometimes you can beat the hell out of your remote endpoint with the
heartbeats.
(..And I will shut up about what I find evil....)
>BTW, it would be awesome to have HTTP over SCTP where each of the
>elements that make up a web page is loaded over a different stream so
>there is no head of line blocking but the session establishment
>overhead (both in unnecessary repeating data and in round trip times)
>that exists today is mitigated.
Well Randall Stewart has already ported Apache to run on SCTP. The site is
multihomed and you can try to access it..For more instructions on how to do
it, Look at http://www.sctp.org/
>
>Now that we're firmly in science fiction territory (Tony Hain once
>suggest we form an "Internet Fantasy Task Force", maybe not such a bad
>idea...) it occurs to me that SCTP could be wrapped around UDP for
>long-lived UDP associations and subsequently add multihoming to UDP and
>UDP-based transport protocols such as RTP. At least, if the stream
>setup mechanism can be changed to support "one packet streams"
>efficiently. What do you think?
>
Originally, SCTP was designed to be carried on top of UDP... But then the
IESG allowed us to treat it as a separate transport protocol. Funny how the
world goes around..
But the idea is still valid....
Now that Partial Reliability SCTP has been approved by the IESG recently,
what do you get when you set the the retransmission counter 0 for your
PR-SCTP messages/packets?
Answer: hey...isn't that UDP.... With congestion control....
And in PR-SCTP the knob can go from 0 retransmissions to a real big number
of retransmissions....
And is that usefull???:... Just use MPEG4 streams on PR-SCTP and the picture
looks beter...
This ain't a fantasy anymore but just plain hard fact...(allright,allright
I'm getting too exited...)
Implementations: look at http://www.sctp.org/
Hope this helps...
Yours sincerely
Lode