Subject: [Tsvwg] 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

_______________________________________________
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: 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)
> 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
> 
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 10:26 PM
> To: Qiaobing Xie
> Cc: sigtran; [email-masked]
> Qiaobing,
> Qiaobing Xie wrote:                                      (Tue, 13 Nov 2001 13:19:39)
> > Lyndon,
> > 
> > I agree with you. 
> > 
> 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.
> 
> 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.
> 
> 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
> > > 
> > > -------------------------------------------------------
> > ---
> > 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/
> 
> ---
> 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/

---

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

Hi Antonio!

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

	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

> 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
>    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
> 
> 
> Sent: Wednesday, November 14, 2001 11:03 AM
> To: Antonio Alonso-Alarcon (ECE)
> >  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: [email-masked]
Date: Wed, 14 Nov 2001 19:38:52 +0200

snip...

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

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

	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?

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

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

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