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

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,

Qiaobing Xie wrote:                                      (Tue, 13 Nov 2001 13:19:39)
> 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?

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.

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

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.

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

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

> 
> regards,
> -Qiaobing
> 
> "Ong, Lyndon" wrote:
> > 
> > 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
> 
> 
> ---
> 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/

_______________________________________________
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: Wed, 14 Nov 2001 06:38:54 -0600

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

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

---

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

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.

--brian

Randall Stewart wrote:                   (Wed, 14 Nov 2001 06:38:54)

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

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 14 Nov 2001 11:11:57 -0600

Brain,

All you are asking here is to gain some sender side convenience (to
allow you perform your favorite "infrequent partial write" __at the cost
of additional re-ordering delay as well as complexity on the receiver
side__.

What's the justification? Do you have any numbers to show us that this
change can result in any material performance gain in a specific
application? Otherwise, I would feel that this is simply asking the
protocol be changed to favor some particular implementations.

-Qiaobing