Subject: RE: SCTP and fragmentation

From: [email-masked]
Date: Tue, 13 Nov 2001 11:10:47 +0200

Hi Randy,

> 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..

In summary, you seem to indicate that this is an
implementation-dependent issue.  Further more, messages
affected would be larger than 64K.

I've copied Allison & Scott on the message.  I would like
some direction from them on this issue:

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

thanks,
John

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 13 Nov 2001 03:25:01 -0600

John,

The effect (SCTP fragmentation and blocking of
interleaving) kicks in when a message is larger
than the association MTU minus tax.

--brian

John Loughney wrote:                                         (Tue, 13 Nov 2001 11:10:47)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

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

---

---

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

BTW, I should note that the SCTP questions that
have been brought up recently are coming from
various folks working on the adaptation layers
(esp. M2PA) and not any general conclusion of
the SIGTRAN group itself.  In fact, the adaptation
layers have all so far been designed to run over
SCTP, warts and all.

I probably should have made this clear earlier.

Cheers,

Lyndon

-----Original Message-----
From: Qiaobing Xie [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 11:20 AM
To: sigtran
Cc: [email-masked]; [email-masked]
Subject: Re: [Tsvwg] RE: SCTP and fragmentation

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

> "Ong, Lyndon" wrote:

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

---

---

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

Lyndon,

MTP/SCCP/TCAP-Users already do their own
segmentation/reassembly for SS7.

It is not a stretch to allow them to do
so also for SCTP to avoid this sender-side
HOL blocking.

--brian

Lyndon Ong wrote:                                          (Tue, 13 Nov 2001 10:13:48)

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

---

---

From: Ken Morneault <[email-masked]>
Date: Tue, 13 Nov 2001 21:23:40 -0500

Brian,

I agree with Lyndon.  Practically, the majority of all xUA 
messages are small (less than 272 octets).   Since the xUA 
message length is 16-bits, the maximum size message we 
can write into SCTP is a bit less than 64k.   (We are not talking
about huge messages here).  Further, SUA already provides 
a means for fragmentation of large messages with the 
Segmentation field.

Ken

At 03:29 PM 11/13/2001 -0600, Brian F. G. Bidulock wrote:
>You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 13 Nov 2001 23:42:46 -0600

Ken,

Ken Morneault wrote:                                          (Tue, 13 Nov 2001 21:23:40)
> a means for fragmentation of large messages with the 

Thus the recommendation to use segmentation where required
at the ASP (not the SG) for both M3UA and SUA.  If the MTP/
SCCP-User is informed of the segment size, there will never
be a message larger than the MTU.

As it stands, however, the recommendation is to have the
SG do segmentation (which is too late).

So, I take it you agree with the proposal for M3UA/SUA (that
the ASP, i.e. SS7-User, should perform segmentation when
required).

--brian

-- 
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

> 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
>
>
> "Ong, Lyndon" wrote:
> >
> > John,
> >
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
>

---

---

From: "Antonio Alonso-Alarcon (ECE)" <[email-masked]>
Date: Wed, 14 Nov 2001 09:36:37 +0100

Hi all !

   Some months ago (SCTP was not still a RFC) I though there
was a problem in the SCTP specification when segmentation in
sending side was performed. I did not see how the receiver side
can re-order all the received segements when more than three
segments were needed (take into account that the first and
the last ones can be detected with the BE bits, but the
middle ones are all coded with bits BE=00).

   Randall explained to me that all these DATA fragments
are coded using consecutive TSN values (that is the way
to reassembly all of them in the right order). And it looks
that this is the problem seen by Brian ('partial' writes in
a stream can cause HOL in other streams due to consecutive
TSN values must be used in the generated fragments).

  As we have a new SCTP draft (rfc2960-bis) we could solve
the reported "problem" using the 'Reserved bits' in the DATA
chunk header (currently we have 5 bits => 32 values).

   When a received user-data must be fragmented, all the fragments
would be with the same SSN values (as is done now) as follows:

 fragment 1 => TSN=TSN_1, SSN=x, BE=10, 'Reserved bits'=000000 (value 0)
 fragment 2 => TSN=TSN_2, SSN=x, BE=00, 'Reserved bits'=000001 (value 1)
   .
   .
   .
 fragment n => TSN=TSN_N, SSN=x, BE=01, 'Reserved bits'=xxxxxx (value n-1)

   And the following conditions must be fulfilled:

 TSN_1 >preceedes> TSN_2 >preceedes> TSN_3 .... TSN_N-1 >preceedes> TSN_N

   But now it is NOT necessary to use consecutive TSN values for each fragmnet.
In this case, the DATA chunk would be defined as follows:    
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0    |    SS   |U|B|E|    Length                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              TSN                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Stream Identifier S      |   Stream Sequence Number n    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Payload Protocol Identifier                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                 User Data (seq n of Stream S)                 /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    SS=Segment Sequence (not used if 'B' bit and/or 'E' bit are set)

   With this solution no extra fields are needed in the DATA chunk header, but
we have a restriction in the number of fragments (no more than 32 fragments
could be generated) ==> the max. user-data size which can be accepted
depends on the current assoc_PMTU (if we want to avoid this restriction, we
need to allow IP to fragment when user-data size received from the local user
is > 32*assoc_PMTU )

   Another solution (to avoid this restriction) would be to code a new field
in the DATA chunk header for the same purpose (but in this case more bytes
in the header are needed).

   This solution is not compatible with the existing SCTP implementations, but
the same is occurs with new 'checksum calculation' introduced in the draft
rfc2960-bis, so it is not a drawback just now.

   What do you think about this change ?

Regards / Antonio

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 10:26 PM
To: Qiaobing Xie
Cc: sigtran; [email-masked]
Subject: Re: [Tsvwg] RE: SCTP and fragmentation

Qiaobing,

--brian

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

---

---

From: Ian Rytina <[email-masked]>
Date: Wed, 14 Nov 2001 19:48:03 +1100

Hi Brian,

Just a quick comment.....when you say "when required", this implies
that a decision is required by the sender. What exactly is the
decision you are proposing ? And is it optional ?

/Ian.

"Brian F. G. Bidulock" wrote:

> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 04:02:51 -0600

Antonio,

Your proposal will work for ordered delivery but will
not work for unordered delivery where the SSN=0 and
the B/E-SS of one unordered message can be confused with
those of another.  For example:

    TSN UBE SS                          TSN UBE SS
    101 110 000000 -------------------> 101 110 000000
    102 101 000001 --------X         
    103 110 000000 --------X
    104 101 000001 -------------------> 104 101 000001
                                 (Do these belong together?)

Perhaps you could cycle the SS for unordered something like:

    TSN UBE SS                          TSN UBE SS
    101 110 000000 -------------------> 101 110 000000
    102 101 000001 --------X         
    103 110 000002 --------X
    104 101 000003 -------------------> 104 101 000003
                                (These don't belong together)

Assigning a different SSN to each fragment would also solve
the problem and not have the narrow range of the SS field you
suggest.  SSN could also be assigned separately to unordered
data for the purpose of fragmentation only.  That would require
no changes whatsoever to the DATA chunk header and only minor
changes to existing SCTP implementations.

The change to ordered data might be incompatible with existing
implementations but would required only minor changes.  The
change to ordered data also would required only minor changes,
I would suspect that most implementations that take their
determination of unordered off of the U bit and ignore the SSN
anyway.

SSN is fairly useless as a record-counter to the ULP anyway:
the ULP is fully capable of counting messages as they are
written to or read from SCTP.

--brian

Antonio Alonso-Alarcon (ECE) wrote:                       (Wed, 14 Nov 2001 09:36:37)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 04:11:16 -0600

Ian,

By "when required" I mean when logically necessary.  Certainly
an SS7-User that never sends messages larger than would fit
in an MSU is not required to perform segmentation even in the
SS7 network.  SS7-Users are, however, permitted to send very
large messages.  If an SS7-User sends such a message, it would
be necessary for it to segment that message in the same manner
as it does for SS7 today.

As SS7 permits very large MSUs (MTP3b, Q.703 Annex A), in some
circumstances, the SS7-User at the ASP will need to segment
messages to the SCTP association MTU (minus tax) as it would
for a smaller SIF-max SS7 route.

The recommendation is simply to have the SS7-User peform this
segmentation that it is already capable of before sending to
SCTP (rather than sending unsegmented and have the SG segment
before sending to the SS7 network) and have the SCTP MTU as
another consideration for setting the maximum segment size at
the SS7-User (the other consideration currently is the SIF-max
size of the SS7 route).

Does that answer your question?

--brian

Ian Rytina wrote:                                             (Wed, 14 Nov 2001 19:48:03)

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

---

---

From: Tuexen Michael <[email-masked]>
Date: Wed, 14 Nov 2001 11:20:35 +0100

Dear Brian,

I would like to know about what user message sizes
for M3UA you are talking. For MTP it is in the order 
of 272 bytes. For MTP3b it is in the order of 4000 bytes.
I would expect that a (good) SCTP implementation can handle
this.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> From:	Brian F. G. Bidulock [SMTP:[email-masked]]
> Sent:	Wednesday, November 14, 2001 6:43 AM
> To:	sigtran
> Cc:	[email-masked]
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Antonio Alonso-Alarcon (ECE)" <[email-masked]>
Date: Wed, 14 Nov 2001 11:22:31 +0100

Hi Brian !

   In your example you forgot to include the SSN field
in each DATA chunk (which is the same for all the fragments
of the same 'original' user-data)

SSN    TSN UBE SS                          TSN UBE SS
 x     101 110 000000 -------------------> 101 110 000000
 x     102 101 000001 --------X         
 x+1   103 110 000000 --------X
 x+1   104 101 000001 -------------------> 104 101 000001
                                 (Do these belong together?)

   The two received datagrams do not belong to the same 'original'
user-data as SSN is different.

   When the fragment with E bit set to 1 is received, the receiver
side can know how many fragments (with the SAME SSN value) must
be received before reassembling (so to cycle the SS field can
never be a solution).

Regards / Antonio

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, November 14, 2001 11:03 AM
To: Antonio Alonso-Alarcon (ECE)
Cc: sigtran; [email-masked]
Subject: Re: [Tsvwg] RE: SCTP and fragmentation

Antonio,

    TSN UBE SS                          TSN UBE SS

    TSN UBE SS                          TSN UBE SS

--brian

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

---

---

From: [email-masked]
Date: Wed, 14 Nov 2001 12:27:15 +0200

Hi Antonio!

> of the same 'original' user-data)

	Well, in unordered data, the SSN is meaningless, and it is set to
0... So Brian didn't forget it :-) Moreover, he was explaining just that...

	BR Iván Arias Rodríguez

> >  TSN_1 >preceedes> TSN_2 >preceedes> TSN_3 .... TSN_N-1 
> >preceedes> TSN_N
> > 
> >       |                              TSN                    
>           |
> >       \                                                     
>           \
> >       \                                                     
>           \
> > > To unsubscribe send a blank email to 
> [email-masked]
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 
> > To unsubscribe send a blank email to 
> [email-masked]
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 05:02:31 -0600

Michael,

For messages larger than an MTU-tax, the undesirable
HOL blocking effect of TSN fragmentation will exhibit
itself.  MTP-Users today segment down to SIF-max when
required.  What I am recommending is that M3UA MTP-Users
use the maximum segment size of the lesser of the
SIF-max and the MTU-tax (instead of just SIF-max).  In
the case of low-speed links this would normally be
segmenting to the SIF-max of 272.  But for MTP3b links
and IPSP operation, this would normally be to the MTU-tax
(as it is usually less than 4000 bytes).  SUA and SCCP-
Users should segment the same.

--brian

Tuexen Michael wrote:                                      (Wed, 14 Nov 2001 11:20:35)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 05:03:54 -0600

Antonio,

In my example you will notice that the U bit is set.  This
means that the SSN is set to 0.

--brian

Antonio Alonso-Alarcon (ECE) wrote:                       (Wed, 14 Nov 2001 11:22:31)

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

---

---

From: Tuexen Michael <[email-masked]>
Date: Wed, 14 Nov 2001 12:22:50 +0100

Dear Brian,

assuming a path MTU of approx. 1500 bytes and 
MTP3 payload of 4000 bytes (Maximum and not the
majority of the MTP3 payload) this would result
in 3 DATA chunks. I see the HOL problem for LARGE
SCTP user data in general, but 3 chunks are not
so much and the frequency of the long SS7 messages
is very low.

So I I do not see the need for segmentation in M3UA.
I'm not talking about SUA here, that may be a different
story, but I do not know so much about SCCP.

Best regards
Michael

> Sent:	Wednesday, November 14, 2001 12:03 PM
> To:	sigtran
> > > > >Lyndon Ong wrote:                                          (Tue, 13 Nov 2001 10:13:48)> 
> > > > >> John,
> > > > >> 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 06:22:04 -0600

Michael,

Tuexen Michael wrote:                                      (Wed, 14 Nov 2001 12:22:50)
> so much and the frequency of the long SS7 messages

If the current cwnd is 4000 bytes (as it is during
and shortly after slow start), approx. 100 msus
of 40 bytes will be blocked for at least the RTT.
That's bad.

> So I I do not see the need for segmentation in M3UA.

M3UA does not segment.  MTP-Users (above M3UA) segment.
The recommendation is that M3UA advertise an SIF-max
to its users which is the lesser of SIF-max or MTU-tax.
This does not require a change to the M3UA draft as the
M3UA draft does not mention SIF-max anymore.  (Something
for the AS.)

> story, but I do not know so much about SCCP.

SUA has a recommendation that the SG segment and reassemble
because we thought that SCTP would do the job of segmenting 
large CLDT.  That is not the case.  The recommendation should
be that the ASP/IPSP segment/reassemble (of which they are
already capable as an option).

I have already sent proposed text changes for SUA.

--brian

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

---

---

From: Tuexen Michael <[email-masked]>
Date: Wed, 14 Nov 2001 13:26:17 +0100

Dear Brian,
see my comments below.
Best regards
Michael

> Sent:	Wednesday, November 14, 2001 1:22 PM
> To:	Tuexen Michael
> Cc:	sigtran
	[Tuexen Michael]  I know, but this should not happen too often..
> M3UA draft does not mention SIF-max anymore.  (Something
	[Tuexen Michael]  OK, that is appropiate. Maybe I misunderstood
	you arguments. I thought that you want to change M3UA. 
> > > > > Brian F. G. Bidulock> 

---

---

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: Ken Morneault <[email-masked]>
Date: Wed, 14 Nov 2001 08:23:21 -0500

See comments below.

Ken

>        [Tuexen Michael]  I know, but this should not happen too often..

Yes, we are spending a lot of time talking about an event that
is highly unlikely to occur.  However, there is no harm in adding
a Implementation note or a sentence in an Applicability Statement
that notes an implementation may pass SIF max to the User.  Of
course, an implementation could do so without this note.

>> already capable as an option).

Exactly, since it is already an option, there is no need to change the 
text for the ASP.

---

---

From: [email-masked]
Date: Wed, 14 Nov 2001 16:02:24 +0200

Brian,

> Randall,
> 
> Consider downgrading the MUST to a SHOULD.
> 
> Regardless of whether the sender assigns sequential TSNs, the
> receiver knows that if a TSN gap exists between the opening
> and closing fragments that it cannot complete reassembly.
> Regardless of whether TSNs are assigned sequentially, the
> receiver knows that if there are no gaps that all fragments
> can be reassembled.  It is rather pointless to keep track of
> the TSN of the last received fragment on a per-stream basis
> (just uses up more bytes per inbound stream) to enforce the
> MUST.  If the sender does not assign sequential TSNs on
> partial writes, sure sender HOL blocking is exchanged for a
> low probability of receiver HOL blocking.  As a result,
> infrequent partial write could be supported.

	But if you must wait before all previous TSN gaps have been filled,
which is the meaning of having several streams (to avoid HOL blocking)?. I
don't think you will have a low probability of receiver HOL blocking, you
will have it almost always. I think the MUST MUST be a MUST :-)

	BR Iván Arias Rodríguez

> --brian
> 
> Randall Stewart wrote:                   (Wed, 14 Nov 2001 06:38:54)
> > Antonio:
> > 
> > It was decided quite some time ago that we are NOT doing
> > a BIS yet. The companion document "the sctp implementation
> > guide" is to be used instead. However this document is
> > NOT to restructure the protocol but to clearify various
> > points and mistakes in the RFC..
> > 
> > I still also maintain that we do NOT need to add some
> > additional fragmentation..
> > 
> > As to your idea.. this was a fundamental debate on this
> > when SCTP was being developed.. fragment at the stream
> > level OR fragment at the TSN level. The reason we
> > went with TSN level fragmentation was exactly as Brian
> > indicated (and I also earlier). If you do stream fragmentation
> > then message sent unordered could NOT be fragmented.
> > 
> > If I were inclinded to do something, WHICH I AM NOT, I would
> > sooner append the two additional bits I mentioned earlier. This
> > is compatabile and is flexible in that if you ARE worried about
> > HOL on the sender side you COULD lock your sender to the 
> > MTU level at the stream fragmentation level. Unordered could
> > still get fragmentation at the TSN level AND you could, in the
> > future, utilize the stream flow control better within a stream.
> > In particular the sender could easily use that to be its
> > fragmentation size (since it is in theory authorized to
> > have that many TSN's of the rwnd/cwnd anyway).
> > 
> > R
> > 
> > "Antonio Alonso-Alarcon (ECE)" wrote:
> > > 
> > > Hi all !
> > > 
> > >        0                   1                   2          
>          3

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 08:37:53 -0600

Ivan.Arias-Rodriguez,

[email-masked] wrote:        (Wed, 14 Nov 2001 16:02:24)
> will have it almost always. I think the MUST MUST be a MUST :-)

You must wait for all the TSN gaps to be filled before you can
reassemble either way.  The MUST does not substantially reduce
the wait at the receiver but does substantially increase the
wait at the sender.  A SHOULD would reduce the certain wait at
the sender in exchange for a probability of a slightly increased
wait at the receiver.

Besides, a MUST should not be used just to make an implementation
do something a certain way.  A SHOULD is sufficient that the sender
give careful consideration to the probability of increase of HOL
blocking at the receiver in exchange for the HOL blocking savings
at the sender.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 09:39:23 -0600

Ivan.Arias-Rodriguez,

[email-masked] wrote:        (Wed, 14 Nov 2001 16:55:41)
> 	I don't think you have to wait for all the TSN gaps to be filled if
> you don't allow mixing TSNs of different SSNs. If you are sure that once you
> have a complete series of TSNs from one having the B flag set to another
> having the E flag set you have the complete original SSN, you are not
> bothered about anything else, and lost TSNs belonging to another SSN (if it
> goes to another stream, obviously) are completely appart. Having a SHOULD,
> loosing a single TSN means that you can't deliver any SSN to the upper user
> if its TSN with the B flag set is previous to that TSN and its TSN with the
> E flag set was sent later than the lost TSN. With a MUST, this only affects
> one SSN...

Not sending sequential TSNs only risks receiver HOL blocking.  Sending
them is sure to introduce sender HOL blocking.  Why not let the sender
decide?

> 	But the point here is that if you don't have the MUST then you don't
> have anyway to reassemble the unordered SSNs... so it is more than an
> implementation issue...

Unordered is no different.  If a gap falls between B and E, the unordered
message cannot be reassembled in either case.

How is this more than an implementation issue?

What interoperability need is at stake?

--brian

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

---

---

From: [email-masked]
Date: Wed, 14 Nov 2001 16:55:41 +0200

Brian,

	BR Iván Arias Rodríguez

---

---

From: [email-masked]
Date: Wed, 14 Nov 2001 17:53:39 +0200

Brian,

	snip...

> them is sure to introduce sender HOL blocking.  Why not let the sender

	To be honest, I had never completely understood which is that sender
HOL blocking you mention... Does it have to do with the fact that if you
have a SSN composed of X TSNs you have to send those X TSNs before you can
send any TSN of another SSN directed to another stream that was handed off
to the SCTP engine later? If so, in my point of view, if you are trying to
send things faster than the network can assimilate you will always have to
wait...

	Otherwise, if you attempt to send some other stream's SSN before
sending all of the X TSNs you could think that the second SSN is producing
HOL blocking to the first SSN... If you can only send one think at a time,
then you can only send one thing at a time...

	In any case, if your problem is that, why not simply calculating how
many TSNs the big message is going to need and directly send the second SSN
with its correspondent TSN?... You will receive Gap ACK Blocks in the SACK,
but as those TSNs have never been sent, you won't have to trigger any Fast
Retransmit or anything... I think this is possible and I'm not sure if it
would violate any rule... I know that the RFC says that you can't send any
new TSN if you have TSNs marked for retransmission, but I don't think there
is anything there stating that new TSNs must strictly be sent in order...

	If the MTU is 1,500 and you give me a 15,000 byte message, I can
immediately infer that it will fit in 10 TSNs. If the upper user gives me
then another message, this one of 100 bytes, I can set its TSN to the first
one after those 10, and send it even before I have sent the whole first
message...

> What interoperability need is at stake?

	Well, if you mix TSNs belonging to several unordered messages going
to the same stream, then you don't have any way to know which TSNs are of
which message... no matter what your implementation does...

	BR Iván Arias Rodríguez

---

---

From: Ken Morneault <[email-masked]>
Date: Wed, 14 Nov 2001 12:26:06 -0500

Brian,

I don't see a strong need to change the working.  Again, at the
most an implementation note can be added as a reminder
to ASP implementors of a reason they MAY want to fragment.

Anyone else have an opinion?

Ken

At 08:29 AM 11/14/2001 -0600, Brian F. G. Bidulock wrote:
>Ken,
>
>Ken Morneault wrote:                                          (Wed, 14 Nov 2001 08:23:21)
>> 
>The text needs changing because the recommendation is backwards.
>SHOULD => MAY and MAY => SHOULD.
>
>--brian
>
>
>-- 
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/ 

---

---

From: [email-masked]
Date: Wed, 14 Nov 2001 19:38:52 +0200

snip...

> > with its correspondent TSN?...
> 
> Because that, too, would be against the RFC.  Initial transmission
> of DATA chunks must be sent in TSN order.

	Where in the RFC that is stated?... I have tried to find it, but I
don't even remember something like that... I might be wrong... :-/

> > You will receive Gap ACK Blocks in the SACK,
> Consider that the user provides only the first 2000 bytes of 
> the 15,000
> byte message, and then later the next 2000 bytes, ...

	If the user is going to give you the message in pieces, either

	- It will also give you which is its total length.
	- It can make several SSNs.

	I don't see why the user would give you a piece of a message that
should be send in a single SSN and it won't give you its length... I guess
you have to do some memory allocation and provide some space for the user to
copy you the message... Is any M*UA doing this?

> Consider slow start.

	:-/ What has this to do with fragmentation?

> Consider a bunch of short, higly interactive messages with large bulk
> messages.

	That's what I'm considering... What do you mean?

> SHOULD does not affect this.  There is no need to mix fragments within
> a stream, just between streams.

	Well... In think that it would case more damage if we mix the
TSNs... You wouldn't have any problem to reassemble the SSNs if their TSNs
are mixed but they belong to different Streams, but you cause HOL blocking
at the receiver no matter if you are avoiding or not HOL blocking at the
sender...

	I think you should be able to anticipate the length of an SSN and
calculate the TSN it will occupy... so no need to mix anything...

	BR Iván Arias Rodríguez

> I don't see an interoperability issue.  It is an 
> implementation decision.
> 
> --brian

---

---

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

---

---

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

Hi all,

> 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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 16:42:20 -0600

Ken,

See the thread "SUA-06: Segmentation/Reassembly/Sequencing", and
"[SUA Issue 15] Segmentation/Sequencing/Resassembly."

The recommendation is reversed.

--brian

Ken Morneault wrote:                                          (Wed, 14 Nov 2001 12:26:06)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 16:56:13 -0600

Ivan.Arias-Rodriguez,

[email-masked] wrote:        (Wed, 14 Nov 2001 19:38:52)
> don't even remember something like that... I might be wrong... :-/

Well, no, I couldn't find it in the RFC either, but it's pretty
obvious that sending TSN 1, 4578, 7364, 4579, 4580, 4581  would
be a bad thing to do and might even be perceived as a teardrop
attack.

> 	- It will also give you which is its total length.

It doesn't know tht total length yet.

> 	- It can make several SSNs.

This is application segmentation/reassembly.

> copy you the message... Is any M*UA doing this?

SS7 does this.

> 	:-/ What has this to do with fragmentation?

One fragment of the "big" message plugs the entire congestion window.

> 	That's what I'm considering... What do you mean?

That there is a non-linear impact on the variance of the queuing
delay for small interactive messages mixed wtih large bulk
messages that are fragmented in this way.

> calculate the TSN it will occupy... so no need to mix anything...

I don't see an interoperability issue.
It should be an implementation decision.

--brian

> To unsubscribe send a blank email to [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 17:00:15 -0600

Randall,

That would be a rididulous sequence to send.  However,
this make sense:

TSN=101 Flags=BU  Str=1 Seq=. (msg 1 part a)
TSN=102 Flags=BEU Str=2 Seq=. (msg 2)
TSN=103 Flags=U   Str=1 Seq=. (msg 1 part b)
TSN=104 Flags=BU  Str=3 Seq=. (msg 3 part a)
TSN=105 Flags=U   Str=1 Seq=. (msg 1 part c)
TSN=106 Flags=U   Str=3 Seq=. (msg 3 part b)
TSN=107 Flags=EU  Str=1 Seq=. (msg 1 part d)
TSN=108 Flags=EU  Str=3 Seq=. (msg 3 part c)

Yet is precluded by the MUST.

Why does the RFC need to force an implementation not
to do this?

--brian

Randall Stewart wrote:                                    (Wed, 14 Nov 2001 14:34:11)
> > [email-masked] wrote:        (Wed, 14 Nov 2001 17:53:39)
> > >       Brian,
> > >
> > >       snip...
> > >
> The problem with changing the MUST to a SHOULD is very simple. It
> breaks the protocol.
> 
> Consider:
> 
> If I send:
> 
> TSN=101 Flags=BU  Str=1 Seq=. (msg 1 part a)
> TSN=102 Flags=BEU Str=1 Seq=. (msg 2)
> TSN=103 Flags=U   Str=1 Seq=. (msg 1 part b)
> TSN=104 Flags=BU  Str=1 Seq=. (msg 3 part a)
> TSN=105 Flags=U   Str=1 Seq=. (msg 1 part c)
> TSN=106 Flags=U   Str=1 Seq=. (msg 3 part b)
> TSN=107 Flags=EU  Str=1 Seq=. (msg 1 part d)
> TSN=108 Flags=EU  Str=1 Seq=. (msg 3 part c)
> 
> I have NOT violated any part of the protocol (It may be
> a silly thing to do I will grant you). The protocol allows
> an implementation to validly send sequences that CANNOT
> be re-assembled IF the MUST becomes a SHOULD.
> 
> R
> 
> 
> 
> 
> 
> -- 
> Randall R. Stewart

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

---

---

From: Ian Rytina <[email-masked]>
Date: Thu, 15 Nov 2001 10:45:50 +1100

Hi Brian,

Yes it does answer my questions. You have clarified that
this is an optional implementation function internal to your
box. It is not a subject for normative standardisation.

This makes it either an Implementation Note in the relevant UAs,
or a paragraph in the Applicability Statement. Which would you
prefer ?

/Ian

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 14 Nov 2001 18:33:21 -0600

Ian,

Ian Rytina wrote:                                             (Thu, 15 Nov 2001 10:45:50)
> or a paragraph in the Applicability Statement. Which would you

So are you proposing removing the SHOULD and MAY altogether
from SUA v8 Section 4.7.1 and making it an implementation note?

That would be acceptable too.  But the SHOULD and SHOULD NOT
cannot stand as they are.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 15 Nov 2001 09:55:41 +0100

I'd like it to be an implementation note in SUA as well.

SUA on the ASP is allowed to do segmenting, but is not forced to. When
routing is on Global Title, the SUA on ASP cannot know the maximum supported
SIF length to the final destination. So the SG must do the segmenting here.

The implementation note should be something along the lines :

"When it is expected that signalling messages will not fit into a PDU of the
most restrictive transport technology used (e.g. 272-SIF of MTP3), then
segmenting/reassembly is mandatory. It is recommended for a SG to perform
segmenting. It is recommended for an ASP to perform reassembly."

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 15 november 2001 1:33
To: sigtran
Cc: [email-masked]
Subject: Re: [Tsvwg] RE: SCTP and fragmentation

Ian,

Ian Rytina wrote:                                             (Thu, 15 Nov
2001 10:45:50)

--brian

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Nov 2001 03:30:53 -0600

Gery,

Verwimp Gery wrote:                                       (Thu, 15 Nov 2001 09:55:41)
> SIF length to the final destination. So the SG must do the segmenting here.

There is no must about it.  The SG can also return a
"segmentation error" and never have to do segmentation.

> segmenting. It is recommended for an ASP to perform reassembly."

If it is an implementation note, don't use the words "mandatory" and
"recommended" as they may be confused with RFC keywords.  How about:

   "When it is expected that signalling messages will not fit into a PDU of
    the most restrictive transport technology used (e.g. 272-SIF of MTP3),
    then segmenting/reassembly could be performed at the SG, ASP or IPSP.
    If the SG, ASP or IPSP is incapable of performing a necessary
    segmentation/reassembly, it can inform the peer of the failure using
    the appropriate error in a CLDR or RESRE/COERR message."

--brian

> Fax: +32 14 25 3212

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

---

---

From: [email-masked]
Date: Thu, 15 Nov 2001 11:55:23 +0200

Hi Brian,

>    "When it is expected that signalling messages will not fit 
>     into a PDU of the most restrictive transport technology used (e.g. 
>     272-SIF of MTP3), then segmenting/reassembly could be performed at the
SG, 
>     ASP or IPSP. If the SG, ASP or IPSP is incapable of performing a
necessary
>     the appropriate error in a CLDR or RESRE/COERR message."

I actually think this brings a nice resolution to the problem.  Do you
suggest this to replace the text in section 4.7.x?  It seems
that our ADs would like simplification of operational text, and
I think that the above text listed as an implementation note
will be acceptable.

John

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 15 Nov 2001 11:00:15 +0100

Brian,

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 15 november 2001 10:31
To: Verwimp Gery
Cc: sigtran
Subject: Re: [Tsvwg] RE: SCTP and fragmentation

Gery,

Verwimp Gery wrote:                                       (Thu, 15 Nov 2001
09:55:41)

[GV] : Agreed.

> "When it is expected that signalling messages will not fit into a PDU of
the

[GV] : Agreed.

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Nov 2001 04:09:55 -0600

John,

John Loughney wrote:                                         (Thu, 15 Nov 2001 11:55:23)
> I think that the above text listed as an implementation note

Well, actually Ian suggested it, but I agree that the issue
is implementation dependent and there should be no requirements
laid on the implementation here.  It was my intention that
something like the above replace the text in 4.7.x as an
implementation note.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Nov 2001 04:13:59 -0600

Gery,

Good.  I believe we managed to get all of the elements
into the messages when we last discussed this.  CLDT
has a full segmentation parameter (and CODT supports
segmentation).  But what about CLDR?  Does CLDR need
the optional Segmentation parameter as well?

--brian

Verwimp Gery wrote:                                       (Thu, 15 Nov 2001 11:00:15)
> [GV]: Agreed.
> [GV]: Agreed.

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 15 Nov 2001 11:46:54 +0100

Brian,

Well, I'd say if it was received in a CLDT (segment or whole message) with
the return on error option set, it is reflected in the CLDR. Even in the
case "segmentation error".

However, because of the mandatory SCCP cause parameter in the CLDR, it could
be that the data parameter received in the CLDT doesn't fit anymore ... but
in that case truncation of the data is in order, NOT segmentation.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 15 november 2001 11:14
To: Verwimp Gery
Cc: sigtran
Subject: Re: [Tsvwg] RE: SCTP and fragmentation

Gery,

--brian

11:00:15)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Nov 2001 05:00:29 -0600

Gery,

What I was getting at is that if the ASP/IPSP sends segmented CLDT
with return on error, the SG needs a way of sending CLDR without
being force to reassemble the original unitdata.

That is (XL)UDTS has the optional segmentation parameter, why not
CLDR?

In fitting with the implementation/operator deciding what to
do visa vi segmentation, let's just add "Segmentation" as an
optional parameter to CLDR.

--brian

Verwimp Gery wrote:                                       (Thu, 15 Nov 2001 11:46:54)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 15 Nov 2001 12:58:58 +0100

No problem with that !

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: donderdag 15 november 2001 12:00
To: Verwimp Gery
Cc: sigtran
Subject: Re: [Tsvwg] RE: SCTP and fragmentation

Gery,

--brian

11:46:54)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Nov 2001 06:09:02 -0600

Gery,

With that I think we're done.

--brian

Verwimp Gery wrote:                                       (Thu, 15 Nov 2001 12:58:58)

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

---

---

From: [email-masked]
Date: Thu, 15 Nov 2001 14:42:59 +0200

Hi Brian,

> something like the above replace the text in 4.7.x as an

The text is added.

John

---

---

From: [email-masked]
Date: Thu, 15 Nov 2001 14:44:52 +0200

Hi Brian,

> optional parameter to CLDR.

It is added.

John

---

---

From: [email-masked]
Date: Thu, 15 Nov 2001 14:47:10 +0200

Hi Gery & Brian,

> Well, I'd say if it was received in a CLDT (segment or whole 
> message) with the return on error option set, it is reflected in 
> the CLDR. Even in the case "segmentation error".
> 
> However, because of the mandatory SCCP cause parameter in the 
> CLDR, it could be that the data parameter received in the CLDT 
> doesn't fit anymore ... but in that case truncation of the data 
> is in order, NOT segmentation.

Sorry, I just read this - does this means that the segmentation
IS NOT NEEDED in the CLDR?

John

---

---

From: Verwimp Gery <[email-masked]>
Date: Thu, 15 Nov 2001 14:07:52 +0100

Hi John,

No, it just means the sender of the CLDR isn't forced to perform reassembly
of all CLDT segments first. It can just send CLDR on each individual CLDT
(segment or not, and if return on error option set) just reflecting the
segmentation parameter (if present in the CLDT).

If for some reason the CLDR woudn't fit anymore into a transport PDU
(theoretical possibility because of added SCCP cause parameter), no attempt
for segmentation must be made but instead the data is truncated.

In SS7, SCCP will usually only mark the first segment with return on error.
User transaction IDs are commonly at the start of the user data (e.g. TCAP
message) which is necessary&sufficient for the error notification to the
user. Subsequent user data, and thus also non-first segments are pretty
useless in a (XL)UDTS or CLDR.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 15 november 2001 13:47
To: sigtran
Subject: RE: [Tsvwg] RE: SCTP and fragmentation

Hi Gery & Brian,

John

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

---