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

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

Ivan.Arias-Rodriguez,

[email-masked] wrote:        (Wed, 14 Nov 2001 17:53:39)
> 	Brian,
> 
> 	snip...
> 
> > > > 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...
> > 
> > Not sending sequential TSNs only risks receiver HOL blocking.  Sending
> > them is sure to introduce sender HOL blocking.  Why not let the sender
> > decide?
> 
> 	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?...

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

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

Consider that the user provides only the first 2000 bytes of the 15,000
byte message, and then later the next 2000 bytes, ...

Consider slow start.

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

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

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

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

--brian

> 
> 	BR Iván Arias Rodríguez
> 
> > --brian
> > 
> > > 
> > > 	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/
> > > > 
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 

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

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 14 Nov 2001 14:34:11 -0600

> > > > > the sender in exchange for a probability of a slightly increased

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

---

---

From: Randall Stewart <[email-masked]>
Date: Wed, 14 Nov 2001 18:51:27 -0600

[email-masked] wrote:
....snip...
> with its correspondent TSN?... You will receive Gap ACK Blocks in the SACK,

Ivan:

Since this seems to be a floating question on the list I will comment
to you on it.

Sending TSN's out of order as you have outlined above is 
perfectly legal. However there are a couple of things to consider if
one wants to write an implementation that does this:

A) You MUST NOT strike gaps (for Fast Retransmit) against
   chunks you have not sent (This is obvious and you note it)

B) You WILL NOT grow your cwnd since the CUM-ACK point will
   not be moving forward. As such it carries an automatic
   penalty for doing this.. i.e. no cwnd growth until you
   send the lower TSN's and when the SACK comes in that
   fills the holes you will lose some of the cwnd growth
   you would have received.

Other than these two issues, there is nothing preventing
one from doing the above... One could even send (from
your example.. assume 1-10 went to our big message
and 11 went to our small one).

TSN1--->
TSN2--->
<small message needs sending>
TSN11-->
TSN3--->
TSN4--->
..
etc

Basically you could do this anytime  you recognized
the small message was ready to send.. keeping in
mind (A) and (B) above. 

R

---

---

From: Randall Stewart <[email-masked]>
Date: Thu, 15 Nov 2001 05:33:41 -0600

One thing I forgot to mention...

If a transport were to do this... the Fast Retransmit
algorithm would also need to be changed a bit more
as well... besides not striking things that have not
been sent. One would have to keep track of how many
packets I sent out of order ahead of any given TSN
and then add that value to the FR threshold...

See below near my example transport

> <small message needs sending>

Transport would need to note here that TSN11 needs
not 4 strikes but 12 (4 + (11-3)) before retransmit.

R

---