Re: architecture draft

[Allison Mankin <mankin@psg.com>]

Hi,

I'd like to provide a clarification about SCTP.

>         "One confusing question about the direction of this work is why
>          SCTP is being discussed as a "solution" to site multihoming,
>          when a clear requirement for a site multihoming solutions is
>          the ability to support existing TCP-based and UDP-based
>          applications."
>
> A cool aspect of SCTP is that it can both function in a way very 
> similar to TCP and in a way very similar to UDP. It should be possible 
> to create an adaption layer so that applications that expect to use TCP 
> or UDP are redirected over 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.  
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.

So, an adaptation layer that redirected applications of UDP over SCTP
would not provide access to their congestion control service requirements.

Allison

P.S. I suspect that discussions of evolving the transport protocol services
will not be on-topic.   We can redirect to the Transport Working Group
tsvwg@ietf.org, if desired.