Subject: Re: [Tsvwg] SCTP SAR limitations

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 22 Nov 2005 16:43:50 +0000

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Tuesday, November 22, 2005 02:33 PM
> To: 'Mark Butler'
> Cc: [email-masked]
> Subject: Re: [Tsvwg] SCTP SAR limitations
> 
> Mark:
> 
> A couple of comments in-line...
> 
> Mark Butler wrote:
> > The SCTP protocol currently requires that message fragments be assigned 
> > consecutive TSNs, which causes large messages to block the transmission 
> > of short messages because the transmitter cannot interleave message 
> > fragments.
> > 
> > This makes it inadvisable to generate SCTP messages larger than a small 
> > multiple of the PMTU in many applications.  If an application needs 
> > larger message sizes,  message segmentation and reassembly must be 
> > performed by a higher level protocol, such as DDP.  However, the "cell" 
> > tax of SCTP + DDP is excessive in applications with predominantly small 
> > message sizes.  Upper layer techniques generally require applications to 
> > implement an independent message segmentation and reassembly layer, 
> > complicating the programming model and causing unnecessary context 
> > switches.
> 
> As Caitlin pointed out... I don't really think that a
> socket API is going to be the most ideal for SCTP+DDP
> (or TCP+DDP for that matter). It becomes very difficult
> to pre-post buffers and do all the things that DDP/RDMA
> expect. Now that being said... as to adding a new DATA
> type to SCTP.. for that is what you would be doing ..
> SCTP is extensible.. write a draft that defines what
> you want it to do with any new feilds (offset etc)..
> 
> 
> > 
> > The latency/jitter problem could be solved by adding a SCTP protocol 
> > option that adds a fragment offset field to the header of fragmented 
> > message chunks, allowing transmitters to interleave message fragments 
> > from different streams as advisable, typically round robin fashion 
> > switching streams after each DATA chunk, rather than switching only 
> > after each message.
> > 
> > Does anyone else think such a protocol option would be a good idea?
> 
> I don't see that it is necessary to change the base protocol
> but I have no problem with you writting a new draft that
> proposes a new type of data chunk ;-)
> 

Such a data chunk would end up looking a *lot* like
an untagged DDP Segment over the DDP/SCTP adaptation.

So why re-invent the wheel? Simply implement untagged
only DDP over SCTP, and add full RDMA support when you
need that.

If you attempt to do this with ordered streams over
a socket interface you are going to encounter a whole
set of problems that can be avoided by re-using the
already defined DDP adaptation.

For example, where are the buffers going to come from
for partial messages? There can be one partial message
for each stream. That's 64K-1 messages that can be
tied down by a remote peer and not delivered to the
socket user because none of them are complete yet.

With an RDMA style interface, the messages are pre-posted
for each RDMA connection (and hence each SCTP stream).
The application fully controls how many messages can
be in flight, and there is no arbitrary drain on kernel/
stack buffering resources.

A socket-style interface implicitly uses system buffering.
As long as that is the case, limiting the number of
incomplete messages per association to one make sense.
Solving the protocol problem, without shifting off of
a socket interface, is just enabling a remote peer to
very effectively drain the buffer pool. RDMA interfaces
already deal with these issues, including credit limits
and thresholds on shared buffer pools.

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 22 Nov 2005 11:55:33 -0500

Caitlin:

Note, I am NOT proposing that I be an author
of this document (a new SCTP data chunk).. nor
do I see it as something I feel is needed..

I was only pointing out to Mark that he is
welcome to write a document.. but please do NOT
put my name on it :-D

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)