Subject: Re: [Tsvwg] SCTP_MAXSEG / SCTP_DISABLE_FRAGMENTS

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 30 Dec 2005 23:52:14 +0000

> -----Original Message-----
> From: Mark Butler [mailto:[email-masked]]
> Sent: Friday, December 30, 2005 11:15 PM
> To: 'Randall Stewart'
> Cc: [email-masked]
> Subject: Re: [Tsvwg] SCTP_MAXSEG / SCTP_DISABLE_FRAGMENTS
> 
> Randall Stewart wrote:
> 
> > Mark Butler wrote:
> >
> >> The RDDP SCTP draft says that fragmentation at the SCTP layer should 
> >> be avoided.  However the SCTP_MAXSEG option cannot be used to get 
> >> _less_ SCTP layer fragmentation, only _more_ SCTP layer 
> >> fragmentation.  What an RDDP SCTP implementation needs is a way to 
> >> determine the current maximum data chunk size that will not get 
> >> fragmented.  This can be done with a getsockopt(...,SCTP_STATUS,...) 
> >> call.  If the RDDP layer has better knowledge of the true PMTU, it 
> >> can reduce the message size by itself.
> >
> >
> > You miss my point I think..
> >
> > A RDDP implementation that DOES NOT want fragmentation will
> > do the following:
> >
> > setsockopt(...,SCTP_DISABLE_FRAGMENTS, on=1, sizeof(int));
> > setsockopt(...,SCTP_MAXSEG, sz=sizeof_there_segment, sizeof(int));
> >
> > Now, what will happen is they will get no more tha size_there_segment
> > chunks and all in a single message.. no fragmentation will occur.
> 
> I do not understand why one would want to set SCTP_MAXSEG if 
> fragmentation is disabled, unless as a crutch to make sure that you 
> cannot send messages larger than the specified size.
> 
> If a user actually wants to send data with fragmentation disabled, he 
> should read the current fragmentation point and reduce all sends to be 
> less than or equal to that size.   Otherwise he/she  is liable to get 
> immediate rejections and have to guess what the maximum is. And of 
> course if SCTP fragmentation is disabled, the stack may have to fragment 
> at the IP layer if the known PMTU goes down (another reason for MSS 
> negotiation).  That limits the utility of SCTP_DISABLE_FRAGMENTS - 
> generally speaking it is certainly better to fragment at the SCTP layer 
> if  necessary than at the IP layer.
> 

The relevant "user" for RDDP is the DDP Layer itself. It "wants" to
send a given message in as few DDP Segments (SCTP Messages) as possible,
but it wants each DDP Segment to traverse the network atomically (i.e.
in a single SCTP packet).

The requirement in the DDP spec is that the Lower Layer Protocol
(i.e the SCTP Adaptation Layer or MPA) inform the DDP Layer of
changes in the maximum DDP Segment size that conforms to the PMTU.

The *mechanism* by which the SCTP Adaptation layer gets this information
is not specified. It would certainly be nice if the SCTP layer just
told it, but there is no real requirement for that as long as the
SCTP Adaptation layer can infer it from existing interfaces.
Bumping your head against the brick wall is one method of drawing
such inferences, it is also fairly effective. Whether a more
elegant interface was called for would be an implementation 
decision at least partially based upon your estimation of 
how often the PMTU changes.

So while I agree that a MSS equivalent query would be a really
neat feature, I don't think you can use RDDP to justify that
everyone needs to add it to their SCTP layer.

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

---

From: Mark Butler <[email-masked]>
Date: Fri, 30 Dec 2005 18:25:23 -0700

Hello Caitlin,

   Comments inline.

- Mark

>everyone needs to add it to their SCTP layer.

Actually, I was interested in a different semantic than what RDDP 
normally needs.   You can get the maximum data segment size already - 
just use the SCTP_STATUS option and get the association current 
fragmentation point.  

What I was asking for is for SCTP_MAXSEG to be defined to limit the 
total SCTP payload size, instead of clamping the data fragmentation 
point, so that it would be equivalent to and used for the same purposes 
as TCP_MAXSEG.  The debate is about whether independently clamping just 
the data fragmentation point (so as to get multiple fragments of the 
same message in the same packet) is actually a useful option.  I think 
it is unusally obscure, and should use a new option (SCTP_MAX_DATA_SEG) 
if necessary and let SCTP_MAXSEG carry the common case.

The current means of doing this for SCTP is specified in terms of the 
MTU. I think exposing and controlling the association MTU is unclean and 
a layering violation, if its the IP MTU we are talking about. 

  - Mark