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

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 13 Nov 2001 10:13:48 -0800

John,

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.

Cheers,

Lyndon

-------------------------------------------------------
Should applications above SCTP do their own fragmentation
because of this, or should applications rely on SCTP and/or
IP functionality.

thanks,
John

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

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 13 Nov 2001 12:38:35 -0600

Lyndon:

I think the basic HOL issue can be summarized in a very
simple statement.

SCTP, in its current form, addresses HOL on the receiver
side. It does NOT address HOL issues on the sender
side (caused by the queuing effect of the sender).

And has you state (and Laurent as well) different 
applications will encounter different types of
sending side HOL based on the sizes and distributions
of the sends over the various streams. 

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 13 Nov 2001 13:19:39 -0600

Lyndon,

I agree with you. 

Besides I think the whole SCTP stream usage discussion has been blown
out of proportion. I'd really like to ask people to think about some
basic questions, such as:

 - why do we want to do partial write to a message-oriented association?
   How often does this really become unavoidable?

 - If the app really wants to do partial write, what's wrong to let 
   it suffer from a little HOL blocking? (this is very reasonable to 
   prepare to pay a little extra cost for the extra convenience.)

 - If SCTP effectively alleviates HOL blocking 95% of the time, is it
   really NOT good enough for SIGTRAN? If so, then what is the reason 
   for SIGTRAN to require 100% HOL-blocking-free transport? We know 
   that it will not come free, what is (complexity) price SIGTRAN 
   willing to pay for that? and Why?

regards,
-Qiaobing

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 13 Nov 2001 15:26:12 -0600

Qiaobing,

Qiaobing Xie wrote:                                      (Tue, 13 Nov 2001 13:19:39)
>    How often does this really become unavoidable?

Partial write is avoidable by MTP/SCCP/TCAP.  This is what SCCP/TCAP
normally do for SS7: they segment and reassemble.  In the discussion
on segmentation/reassembly points for SUA, we thought that SCTP had
no problems in this regard, but it appears that it does.  To avoid
the situtation, MTP/SCCP/TCAP-users can perform segmentation/reassembly
in the manner that they are used to for SS7 and partial writes become
unnecessary.  This is what was proposed for M3UA/SUA.

>    prepare to pay a little extra cost for the extra convenience.)

MTP/SCCP/TCAP-Users are already capable of segmentation/reassembly.
No convenience is added to a MTP/SCCP/TCAP-User by telling it not
to segment/reassemble.

>    willing to pay for that? and Why?

There is no proposal to not use SCTP for SIGTRAN.  The proposal is to
allow MTP/SCCP/TCAP-Users to perform their own segmentation/reassembly
as they do today for SS7.

--brian

> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 13 Nov 2001 22:51:20 -0800

Randall,

One method of handling sender side fragmentation would be to key off of a
Payload Protocol Identifier and extend the existing SCTP header to include
an offset from a stream vector.  In the case of SCSI, a 32 bit offset should
be okay, and, for RDMA, a 64 bit offset appears to be desired.  This would
allow for fragmentation handling within the transport in that direct
placement is still possible.  In this case, it would be an optional
extension discovered by the PPI.  Each API will also likely wish to include
other information that will need to be isolated from the payload.  Perhaps a
generalized extensible form for doing so would allow greater freedom in
hardware adaptation.  This should not impact existing SCTP.  Using this
technique should also allow a closer API adaptation of TCP stream
application while still enjoying the smaller record native to SCTP.

Doug

---

From: Randall Stewart <[email-masked]>
Date: Wed, 14 Nov 2001 06:30:43 -0600

Doug:

As I have said all along, I am not convinced there is
ANY problem. SCTP was designed to reduce receiver side
HOL. All of this discussion as been on sender side
HOL and as Qiaobing pointed out... this CAN be
controled by a sender and often times are just moving the problem
around.

There are MANY ways one could change things... none of
them I am convinced need be done.. however a change, if
one were to postulate it, would need to NOT change any
of the data format.

R

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 14 Nov 2001 10:40:11 -0800

Randall,

We appear to be in agreement with respect to SCTP not needing a change.  My
suggestion however allows the application not to issue all sender side data
at once and in any order associated with an object.  The technique of
introducing an offset works for any mode of delivery and does not alter
SCTP.  This is the nature of existing applications and an offset is the
normal means.  This extends the SCTP chunk into a larger construct to map
chunks into greater objects as is the intent.  I do not wish to see
increased complexity within the SCTP transport created by altering the rules
for TSN or requiring the transport to track these larger abstractions.
Using a general template for introducing an offset does not alter SCTP but
would allow a simpler means of incorporating hardware for a larger variety
of applications.

This technique can be formalized by means of a payload protocol identifier
definition, but a generalized template would be useful as would tagging this
extended format in some way.

Doug