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

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

Brian,

> Ivan.Arias-Rodriguez,
> 
> [email-masked] wrote:        (Wed, 14 Nov 
> 2001 16:02:24)
> > 	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 :-)
> 
> 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.

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

> Besides, a MUST should not be used just to make an implementation
> do something a certain way.  A SHOULD is sufficient that the sender

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

	BR Iván Arias Rodríguez

> 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
> 
> > 
> > 	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 !
> > > > > 
> > > > >    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
> > > > 
> > > > -- 
> > > > Randall R. Stewart
> > > > [email-masked] 815-342-5222 (cell phone)
> > > > 
> > > > _______________________________________________
> > > > tsvwg mailing list
> > > > [email-masked]
> > > > http://www1.ietf.org/mailman/listinfo/tsvwg
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > > 
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/tsvwg
> > > 
> 
> -- 
> 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 09:39:23 -0600

Ivan.Arias-Rodriguez,

[email-masked] wrote:        (Wed, 14 Nov 2001 16:55:41)
> E flag set was sent later than the lost TSN. With a MUST, this only affects

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

> have anyway to reassemble the unordered SSNs... so it is more than an

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/