Subject: RE: [Tsvwg] RE: SCTP and fragmentation

From: [email-masked]
Date: Wed, 14 Nov 2001 21:47:44 +0200

Hi all,

> It seems to me that it would be an overstatement to recommend
> that all applications above SCTP do their own fragmentation.
> Brian has pointed out an impact of fragmentation on the ability
> to use streams to bypass HOL blocking, but how significant this is
> seems very dependant on the particular application.

Rather than segmentation, should we discuss maximum message length
size in all the xUAs?  This can be mentioned as an implementation
issue.

best regards,
John

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

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 15 Nov 2001 00:25:44 -0800

John,

If an object being delivered on a stream is 500 MB in length as example,
then having a means of breaking up that object into smaller chunks is
important to maintain performance should more than one stream be in use.  To
allow the application an effective means of breaking up large objects would
be to provide a frame aligned vector that indicates payload placement within
these larger objects.  The SCTP chunk fragmentation could be seen as an
independent function that maintains MTU compliance whereas the API object
fragmentation that prepends an offset only needs to consider the size limits
of this larger object fragmentation based on performance impacts.  This API
fragmentation should be treated independently and should not be defined by
the SCTP transport itself.

With development of protocols that regularly use offsets into buffers
(associated with streams) it does make sense to indicate how this can be
resolved and to recommend a structure for doing so.  Again, I do not see
this as a modification of SCTP.  The only possible change that may be of
some merit would be either a PPI numbering convention or a flag to indicate
adherence to this convention only to allow hardware to make assumptions of
how to deal with unknown PPIs. By carrying this information within the API
fragment, less state information is needed to properly place data that can
be delivered in any mode.  With protocols such as SCSI, it would be
difficult to retrofit buffer behavior without this method.  With RDMA
schemes being considered, this buffer behavior would be impossible to
characterize.

I do not think it would be wise to expect the transport to deal with these
abstractions directly as it would get hairy.  Keeping the transport chunks
relatively small for performance and to allow a 9 GB movie to be handled by
an API fragmentation process that introduces an offset does not seem
unthinkable.  The behavior of a buffer should be allowed flexibility.  The
relative location of the payload could be quickly ascertained by examining
the first portion of a data chunk containing the PPI indicating inclusion of
a placement vector.

Doug