Subject: RE: [SUA issue 15]: Segmentation/Reassembly/Sequencing ( CL Issue s)

From: [email-masked]
Date: Wed, 5 Sep 2001 14:15:13 +0300

Hi Sandeep,

Thanks for including this, but the mail is a bit long.  I will
try to summarize, please correct me if I am wrong.  

There are 3 subissues & proposals to deal with them.

Comments?
John

Subissue 1: Should following paragraph be removed from the section 4.1
===========

Paragraph in 4.1

  If a SGP is operated in mated pair configuration, and it receives a
  non-first XUDT segment for which no reassembly process exists, it 
  should pass on this segment to it's mate; if the segment was already 
  received from the mated SGP or if no mated SGP is available, the return 
  on error procedures is invoked.

Resolution: Paragraph to be deleted.

Subissue 2: Should ASP be allowed to segment CLDT messages that it sends to
SG.

Add text to 4.1 to state:

ASPs may segment CLDT messages, based upon knowledge of segmentation
size supported at the SG(s) to which the ASP has routes to.

Subissue 3: Should segmentation parameter be included 
==========  in all CLDT messages sent by ASP.

Changes needed:

1 New optional parameter for CLDT message:

Segmentation

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Tag = 0x010x          |             Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | first/remain  |             Segmentation Reference            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first/remaining segments field is formatted as follows :
bit 8 (MSB) : indicates whether this is the first segment (1) or not (0)

bits 1-7 : indicate the number of remaining segments, value between 0 and 15

The field would thus be coded 1000 0000 (first, no remaining segments) for a
non-segmented CLDT.

The segmentation reference field is a 3 byte integer, assigned by the ASP.

Procedures to be added

ASP -> SG direction 

Text to add:

SGP/ASP/IPSP MUST be prepared to deal with segmented CLDT (reassembly, CLDS,
etc..); an SGP SHOULD support segmentation of unsegmented CLDT where
required;  an ASP SHOULD place segmentation parameter in CLDT where
segmentation might be required at an SGP and MAY always include it; an
ASP/SGP/IPSP MAY segment CLDT.

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

---

From: [email-masked]
Date: Wed, 5 Sep 2001 18:20:32 +0530

Hi John ,

Please see some comments below.

[email-masked] on 09/05/2001 05:45:13 PM

Please respond to [email-masked]

To:   "sigtran" <[email-masked]>
cc:    (bcc: Sandeep Mahajan/HSS)

Subject:  RE: [SUA issue 15]: Segmentation/Reassembly/Sequencing ( CL Issue s)

Hi Sandeep,

Comments?
John

Paragraph in 4.1

Sandeep >> This I think everybody agreed on ..

ASPs may segment CLDT messages, based upon knowledge of segmentation size
supported at the SG(s) to which the ASP has routes to.

Sandeep >> I do not think this issue was fully resolved.

>> Benefits
It may be useful for multiple SG case and for the case when ASP feels
segmentation may not be supported by SG.

>> Issues
How segmentation at ASP will be useful for avoiding segmentation disruption in
multiple SG case need to be further
explored?
As ASP may not have idea of segment size to be used by SCCP so it may involve
first a reassembly and then as re-segmentation at SG.

My view is segmentation at ASP will not be that useful and can be avoided.

Changes needed:

Segmentation

   0                   1                   2                   3

Procedures to be added

ASP -> SG direction

Text to add:

Sandeep >> I have following concerns for supporting this functionality.
Since there is a protocol conversion taking place at SG (from SUA to SCCP), it
is not very clear if inclusion of segmentation parameter will avoid interworking
issues. What interworking problems does the inclusion of segmentation parameter
avoids ?
Considerations also needed for enhancing interface boundary between
NIF/SUA and NIF/SCCP for passing this parameter across from SUA to SCCP.

Sandeep >> Two other issues related to connection-less segmentation/reassembly
procedures needs clarification.

4.   Should reassembly be supported at ASP.
In case SCCP at SG is a non terminating SCCP,  SCCP will not do reassembly
incoming SCCP messages, for this case we need to decide if reassembly needs to
be done by NIF or by ASP. This case is under consideration with IPSP - IPSP
case. As for all cases where SCCP is a terminating SCCP, SCCP at SG will perform
reassembly of messages, Can there be any other case where ASP needs to support
reassembly ?

5. Should SUA implementation perform and be allowed to perform segmentation be
in
an IPSP case
>>Benefits
An implementation may very well want to segment long CLDT into pieces
for better SCTP stream HOL blocking and IP fragmentation performance.
Issues
>> In a all IP network  SCTP should be best suited for segmentation/reassembly.
IMO segmentation by application for better SCTP stream HOL blocking and  better
IP fragmentation performance is not a established fact and needs to be proved.

Best Regards,
-Sandeep

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

---

---

From: [email-masked]
Date: Wed, 5 Sep 2001 16:05:18 +0300

HI Sandeep,

Some comments:
 
> Sandeep >> I have following concerns for supporting this 
> functionality. Since there is a protocol conversion taking 
> place at SG (from SUA to SCCP), it is not very clear if 
> inclusion of segmentation parameter will avoid interworking
> issues. What interworking problems does the inclusion of 
> segmentation parameter avoids ?

In some cases, the route that messages traverse to the
ASP may be via different SGs.  In that case, a single
SG could not re-assemble the messages.

> Considerations also needed for enhancing interface boundary 
> between NIF/SUA and NIF/SCCP for passing this parameter across 
> from SUA to SCCP.

I don't see what you think would be needed here.  Can
you propose something?

> Sandeep >> Two other issues related to connection-less 
> segmentation/reassembly procedures needs clarification.

> In case SCCP at SG is a non terminating SCCP,  SCCP will not 
> do reassembly incoming SCCP messages, for this case we need to 
> decide if reassembly needs to be done by NIF or by ASP. This 
> case is under consideration with IPSP - IPSP case. As for all 
> cases where SCCP is a terminating SCCP, SCCP at SG will perform
> reassembly of messages, Can there be any other case where ASP 
> needs to support reassembly ?

If we solve 3, I think the solution can be applied to this one.

> 5. Should SUA implementation perform and be allowed to 
> perform segmentation be in an IPSP case
> >>Benefits
> IMO segmentation by application for better SCTP stream HOL 
> blocking and better IP fragmentation performance is not 
> a established fact and needs to be proved.

For this issue, SUA will make no requirements nor any
restrictions.

---

---

From: [email-masked]
Date: Wed, 5 Sep 2001 20:53:24 +0530

Hi John ,

Please see some comments below ..

[email-masked] on 09/05/2001 07:35:18 PM

HI Sandeep,

In some cases, the route that messages traverse to the
ASP may be via different SGs.  In that case, a single
SG could not re-assemble the messages.
Sandeep >> John , issue here was to whether to include segmentation parameter or
not in CLDT messages from ASP to SG direction.
In your stated case
a) If SCCP at SG is acting as terminating SCCP Node for a message, SCCP would
reassemble the message before passing it to NIF/SUA. Normally SCCP in this case
on receiving first segment of this message would start a reassembly process.
b) SCCP uses sequence delivery (Protocol CLASS 1) for segmented CL messages, so
all segments of the same message should reach same SG. Only in case of a SS7
route/link failure can some segments of the same message can arrive at other SG.
In this case also as there is no way of passing this message to SCCP at other
SG, reassembly process at other SG would never complete and hence the message
can not be reassembled correctly.
So only those messages for whom SCCP Node at SG is acting as non terminating
SCCP (i.e. when GTT can not be resolved at SG), can be passed to SUA at ASP
without being reassembled.

Sandeep >> What I mean to say here was, if we could decide that inclusion of
segmentation parameter avoids some interworking issues and SUA at ASP should
include this in CLDT message. Upper Layer primitives as listed in section 1.6.1
should be modified to permit this parameter to be passed from SUA to SCCP.
Either SUA can add a optional segmentation parameter in N-UNITDATA indication
primitive or can have N-CLDT indication primitive.

If we solve 3, I think the solution can be applied to this one.
Sandeep >> Yes, SUA can support N-XUDT request primitive for letting SCCP or NIF
pass segmented messages to SUA , if we allow this case on SG,

Sandeep >> I think these two terms are conflicting. For example if there is no
restriction if a originating IPSP can segment or not. It becomes a requirement
on the receiving IPSP side to support reassembly atleast. So responsibilities
need to be assigned in this case.

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 5 Sep 2001 14:25:48 -0500

Sandeep,

Please see comments below...

> Subissue 1: Should following paragraph be removed from the section 4.1

There is certainly no reason to stop an implementation from segmenting
at the ASP if it is capable of doing so.  I always segment at the ASP,
because it is the only way to ensure that segmentation disruptions will
not occur.  It is a whole 10 lines of code.  All that is required in the
draft is a "MAY".

> 1 New optional parameter for CLDT message:

It avoids assignment of the same segmentation reference parameter (SLR) at
multiple SGs.  The segmentation reference must be assigned by the ASP to
avoid this.  This parameter also allows ASPs to segment if desired.

> reassembly of messages, Can there be any other case where ASP needs to support

It is clear that reassembly must be supported at the ASP for the "stream" case
where the "more" bit is always set.

> IP fragmentation performance is not a established fact and needs to be proved.

I agree with John's remarks here.  The draft should neither place requirements
nor restrictions in this regard.

--brian

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

---

---

From: [email-masked]
Date: Thu, 6 Sep 2001 13:50:07 +0530

Brian, John,

Comments below ..

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 09/06/2001 01:55:48 AM

To:   "sigtran" <[email-masked]>
cc:   [email-masked] (bcc: Sandeep Mahajan/HSS)

Subject:  Re: [SUA issue 15]: Segmentation/Reassembly/Sequencing ( CL Issue s)

Sandeep >> Can you please explain segmentation disruption scenario you have in
mind that can be avoided if segmentation is done at ASP and would have caused
problems if no segmentation was done?

Sandeep >> Thanks for clarification, I agree now that Originating SUA node (ASP
in this case) should assign unique SLR for each message and this parameter
should be part of CLDT message.
Now about usage of this parameter in CLDT, Do you think upper Layer primitives
as listed in section 1.6.1 should be modified to permit this parameter to be
passed from SUA/NIF to NIF/SCCP. Either SUA can either add a optional
segmentation parameter (or SLR) in N-UNITDATA indication primitive or can have
N-CLDT indication primitive. Similarly SCCP interface and procedures can be
adapted to use this parameter. Comments ?

Sandeep >> That will be for CO messages, my question was asking for CL messages.

Sandeep >> Why do you want specification to be silent on this ? I think if there
are scenarios where one or the other option will be useful, these can be listed
and implementation be allowed to choose what suits them best. At the same time
implementation at other end need to be ready for whatever option is chosen by
first side.
So I do not think it will not be enough to say SUA puts no restriction and no
requirement. More specifically saying if there is no restriction for originating
IPSP to allow/disallow segmentation; receiving IPSP side will have to support
reassembly. Are there compelling reasons to allow originating IPSP side to
perform segmentation ?

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 04:52:40 -0500

Sandeep,

On Thu, 06 Sep 2001, [email-masked] wrote:

[snip]
> problems if no segmentation was done?

Pardon, I was thinking reassembly (which requires the same paramter).

> adapted to use this parameter. Comments ?

See last note...

> Sandeep >> That will be for CO messages, my question was asking for CL messages.

For CL messages this is the disruption case.  Where there are multiple SG/STP
the SG/STP may fail to perform reassembly if the SLS stream that the
protocol class 1 segments shift to the other SG during reassembly.  This
disruption doesn't happen in the SS7 network, because reassembly is performed
only at the terminating SEP.  In our case, this disruption can be avoided
by having the ASP reassemble CL messages.

> reassembly. Are there compelling reasons to allow originating IPSP side to

Sandeep, I was really talking CO here.  In this case segmentation and
reassembly is required at the IPSP to support "streamed" connections.

--brian

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

---

---

From: [email-masked]
Date: Thu, 6 Sep 2001 13:18:16 +0300

Sandeep & Brian,

Trying to clear away everything, this is what I see.
The question for where to Segmentation / Reassembly
/ Sequencing is very related to the network that
the protocols are running in.

If you can assume that the ASP will be connected
to ONLY 1 SG, then the SG can handle the Segmentation
/ Reassembly / Sequencing.

If the ASP is connected to more than 1 SG, then we
cannot assume that the SGs will be able to co-ordinate
the Segmentation / Reassembly / Sequencing.
More over, if the multiple SGs are being used for 
loadsharing, then it would be almost impossible to 
handle the Segmentation / Reassembly / Sequencing.

However, in the IPSP case, I do think it necessary to 
add the following text for interoperability purposes:

   	The IPSP MAY send segmented data, but MUST be able
	to send non-segmented data.

My intent is this, Brian's IPSP sends segmented data, but 
Sandeep's IPSP does not perform reassembly.  Sandeep sends
Brian a 'Segmentation Not Supported' error, so Brian
sends non-segmented data.

best regards,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Sep 2001 05:54:45 -0500

John,

> / Reassembly / Sequencing.

For connectionless.  The SG should never handle segmentation
or reassembly for connection-oriented.

> 	to send non-segmented data.

Again, for connection-oriented, the IPSP should never attempt
to reassemble data provided segmented by its users (because
it does not know when a "stream" ends).  Therefore, the IPSP
must be permitted to send segmented data and cannot be required
to reassemble connection-oriented messages.  On the other hand,
for connection-oriented messages, the IPSP should be able to
receive segmented messages.

> Sandeep's IPSP does not perform reassembly.

The IPSP SHOULD support reassembly for CODT.  Again, the "stream"
case.

> Sandeep sends Brian a 'Segmentation Not Supported' error,
> so Brian sends non-segmented data.

There is no way to reassemble a stream with no end.  "Segmentation
Not Supported" will result in termination of the connection.

What you are saying here might be true for the Connection-less
case, but the reverse is true for the Connection-oriented case.

--brian

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

---