Subject: [Tsvwg] Re: SCTP and Multicast

From: Mark Butler <[email-masked]>
Date: Wed, 30 Nov 2005 23:21:44 -0700

(Replying to a previous discussion)

Liangping,

SCTP could support reliable, sequenced multicast in one of two ways.  
The easier way is to leave the protocol alone, and add an interface that 
retransmits messages to a set of connected endpoints.  The draft SCTP 
socket api, as it stands, allows an application to keep track of who is 
currently attached to a one-to-many socket.  Then whenever you want to 
multicast a message, just scan the list and use sctp_sendmsg() or 
sendto() to send a message to each  connected endpoint. 

If bandwidth efficiency is the primary concern, then the SCTP protocol 
could be extended to support IP multicast  as follows:

    <>Clients establish associations with multicast server endpoints,
    with an INIT parameter indicating multicast capability. The server
    endpoint confirms multicast capability with an INIT ACK that
    contains a parameter indicating the multicast address it uses, and
    an initial multicast TSN. 

    The client would then attempt a layer 3 multicast join, using IGMP
    as necessary, and report presumptive reachability in the COOKIE_ACK
    response.
    <>
    <>The server would use different stream numbers for unicast and
    multicast streams. A message on a multicast stream would be sent
    over IP multicast to all IP multicast reachable clients, and over IP
    unicast to all the others.  Multicast data would be delivered in
    MDATA chunks that contain the sender's current multicast TSN.  MDATA
    chunks would otherwise behave like regular DATA chunks.
    <>

    If multicast data chunks are missed, each receiver would
    individually request retransmission.  From time to time, each
    receiver would MSACK what it has received, and the sender would
    update the multicast cumulative TSN.    If a presumptively multicast
    capable client MSACKs a considerable series of multicast messages,
    the server would change its layer 3 multicast status to disabled,
    and transmit multicast messages to that client using unicast instead.

    Interoperability with clients with existing SCTP stacks could be
    achieved using by using regular DATA chunks on those clients.

    Ordering between multicast streams and unicast streams would not be
    guaranteed. This could be fixed by adding a TSN and stream sequence
    number bearing BARRIER chunk that would specify an inter-stream
    ordering dependency.  This would be necessary for use of multicast
    in some applications, notably database clusters, filesystems, and
    cache coherency protocols. 

    Peer-to-peer multicast is a straightforward refinement.

Multicast SCTP would be an interesting project. I imagine that a 
reliable multicast layer on top of hardware RDMA would be more efficient 
for HPC applications, however, given adequate bandwidth.  Out of 
curiosity, what did you have in mind?

 - Mark
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg