Re: architecture draft

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 4-mei-04, at 16:27, Allison Mankin wrote:

> I'd like to provide a clarification about SCTP.

> SCTP was designed with its TCP-algorithm congestion control built-in,
> because its original emphasis was stream flows with TCP-like 
> characteristics.
> An application expecting a pure UDP datagram cannot avoid this 
> congestion
> control, so SCTP does not emulate UDP service in that it can neither
> drop all congestion control nor allow alternative congestion control.

Ok, that's obviously a problem. However, considering that everything 
that's on the table is going to require major changes to *something*, I 
don't think it's a show stopper.

> This has been discussed many times because of the question of whether 
> SCTP
> could be a transport for video and audio; it turns out TCP-like 
> congestion
> control is a poor service for realtime media, while TFRC (RFC 3448) is 
> an
> example of an algorithm tailored for their use, over RTP and UDP.

The main thing is that SCTP allows several streams within a session 
(maybe I got the official lingo wrong here, but you know what I mean), 
where each stream can be either long-lived in itself or not, and there 
is no delivery order constraint between streams so in that regard there 
is at least potential for using SCTP for real-time communication.