Subject: [Tsvwg] M3UA: SIF max

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 10 Nov 2001 19:53:16 -0600

Greg,

It has come up on TSV that SCTP is incapable of fragmenting
messages until the complete message has arrived.  This has
a significant latency impact on M3UA interworking into SS7
where SS7 has an SIF max (e.g. MTP-3b) which is larger that
the path MTU of the SCTP association (e.g., Ethernet).
As a result, MTP-Users at the ASP should not send MSUs that
are larger than the path MTU (minus tax) and this artificial
SIF max should be communicated to ASP MTP-Users in the same
fashion as it is done for normal MTP-Users.

M3UA needs to address this with a SHOULD somewhere in the
text, something like:

   The ASP (or IPSP) SHOULD NOT send DATA messages representing
   MSUs that are greater that the SIF maximum, which is calculated
   as the lesser of the SIF maximum provided by the SG for the
   specific route, or the path MTU minus SCTP message and Chunk
   tax.

TCP transport need not impose this requirement.  It only
applies to SCTP to address SCTP's deficiency in this regard.

--brian

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

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

---

From: Randall Stewart <[email-masked]>
Date: Sun, 11 Nov 2001 06:15:36 -0600

All:

I suggest anyone reading Brians comments go back
and read the thread on the tsvwg. He did not bother
to understand what I was telling him, and instead
has a rather interesting view of things... which
I believe are incorrect... 

In short to summarize my statements:

SCTP must have a complete message before it can 
fragment and assign TSN's. This does NOT mean that
partial writes will not work... it does mean that an
SCTP implementation has several choices.

a) It CAN collect the entire message in a stream
   output queue before starting TSN assignment.(which
   would not block a partial write from occuring).
b) It CAN, as Brian stated, not support a partial write.
c) It CAN, start assigning TSN's and sending the data
   but hold up all other streams if it does this since
   TSN's can NOT be inter-leaved during fragmentation
   between streams.

Now (c) causes head of line blocking. (b) may or may not
be a vaild choice. And (a) will work fine.

In any event the size of the message to see this type of
behavior would need to be above 64k (at least IMO). So
yes, when you start writting 64k or above messages in
one single sendmsg() you ARE probably putting a strain on
your user interface is this surprising, no.. I think we
talked about it in the past..

Regards
R 

R

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