Subject: Re: [Tsvwg] SCTP API (draft-ietf-tsvwg-sctpsocket-11)

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 21 Nov 2005 23:04:36 +0000

> -----Original Message-----
> From: Michael Tuexen [mailto:[email-masked]]
> Sent: Monday, November 21, 2005 10:30 PM
> To: 'Mark Butler'
> Cc: [email-masked]
> Subject: Re: [Tsvwg] SCTP API (draft-ietf-tsvwg-sctpsocket-11)
> 
> Hi Mark,
> 
> please find some comments in-line.
> 
> Best regards
> Michael
> 
> On Nov 21, 2005, at 2:50 PM, Mark Butler wrote:
> 
> > I have a few comments on the proposed SCTP API in the current  
> > sctpsocket draft:
> >
> > 1. Stack-level message reassembly  should be guaranteed for  
> > messages below some minimum size so that applications are not  
> > forced to implement message reassembly in all cases. Otherwise even  
> > simple UDP style code has to support manually reassembling short  
> > messages (if fragmentation is enabled).  Perhaps MSG_WAITALL could  
> > be used to request this if necessary.
> Sounds reasonable.
> >
> > 2. The current draft specifies "Only one message at a time can be  
> > partially delivered."  This seems to guarantee head of line  
> > blocking where one large partially received message might block all  
> > other streams in the same association for a considerable time.
> This is true in particular on the sending side. All fragments have to  
> have
> consecutive TSNs and not sending increasing TSN results in other  
> problems.
> 
> So yes, if you send large messages this streams blocks the other  
> streams.
> This is not related to the API issue.
> >
> > I suggest this problem be solved by adding the ability to perform  
> > receive operations against a particular stream, so that  
> > applications are not forced to de-multiplex the streams  
> > themselves.  That would eliminate inter-stream head of line  
> > blocking, simplify the application programming model, allow  
> > different threads to easily process different streams, and so on.
> I do not think that this is a good idea.
> Assume that you have one assoc with two incoming streams. The  
> receiver calls a blocking recv for stream 0. But only messages
> for stream 1 arrive. The receive buffer gets filled, zero window
> probing starts and we have a deadlock.
> 

There are some major advantages to being able to pre-post buffers
to a specific stream, but waiting for a specific stream gets into
the problems you cite.

But I think the pre-posting buffers to specific streams is something
best addressed in a fundamentally asynchronous API (like the extended
sockets API from the OpenGroup's ICSC) rather than in the core sockets
API.

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