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

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,

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

---

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/