Subject: [SUA issue 23] Expedited data transfer Procedure

From: [email-masked]
Date: Thu, 16 Aug 2001 20:39:53 +0300

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: 16 August, 2001 11:11
> To: [email-masked]; Loughney John (NRC/Helsinki)
> Subject: Re: SUAv7: Expedited data transfer Procedure
> 
> 
> 
> 
> 
> Hi ,
> 
> Please consider this as a SUA last Call issue.
> 
> Best Regards,
> Sandeep
> 
> ---------------------- Forwarded by Sandeep Mahajan/HSS on 
> 08/16/2001 04:00 PM
> ---------------------------
> 
> 
> "Brian F. G. Bidulock" <[email-masked]> on 08/09/2001 
> 01:17:12 AM
> 
> Please respond to [email-masked]
> 
> To:   "sigtran" <[email-masked]>
> cc:   John Loughney <[email-masked]> (bcc: Sandeep 
> Mahajan/HSS)
> 
> Subject:  Re: SUAv7: Expedited data transfer Procedure
> 
> 
> 
> 
> John,
> 
> I too would like to know the answer to this question.  I see
> nothing stopping SUA permitting the SG to perform Expedited
> Data procedures.  How about a COED message? :)  Same format
> as the CODT, but for expedited data.
> 
> --brian
> 
> [email-masked] wrote:                            (Wed, 
> 08 Aug 2001
> 20:12:10)
> >
> >
> >
> > Hi,
> >
> > Section 1.6.1 lists the "N-Expedited Data" Request and 
> Indication primitive,
> but
> > the expedited data transfer procedure is not supported in 
> SUA (Support is
> > missing both in messages and in procedure details). Is 
> there a reason for not
> > supporting this feature in SUA ?
> >
> > Best Regards,
> > -Sandeep
> >
> >
> >
> >
> > ---
> > 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]
> 
> 
> 
> 

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

---

From: [email-masked]
Date: Tue, 28 Aug 2001 16:08:05 +0300

Hi All,

> > as the CODT, but for expedited data.

The CODT looks like:

    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 = 0x0006         |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Routing Context                         /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-  
   |         Tag = 0x0101          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              QoS                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0107          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0105          |             Length            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                 Destination Reference Number                  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Tag = 0x010D          |             Length            |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |                        Correlation ID                         |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
   |         Tag = 0x0003          |             Length            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   /                             Data                              / 
   \                                                               \ 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Parameters
	Routing Context			Mandatory
	QoS					Mandatory
	Sequence number			Mandatory *1
	Destination Reference Number	Mandatory 
	Correlation Id                Optional
	Data 					Mandatory

I had made an assumption that ED messages could be supported by this,
but I see it is insufficient.  

If a COED message was used, Sequence Number could be dropped.  However,
we would also need a COEA (Connection-Oriented Expedited Ack).  And
the thought of 2 more messages does make make me want to say ACK!!

Any better ideas - or do we go with the COED ;)

John

---

---

From: Verwimp Gery <[email-masked]>
Date: Tue, 28 Aug 2001 16:28:05 +0200

Hi John,

DT/DA/ED/EA can all be distinguished at the SG depending on the parameters
present in the CODT. Do we need to come up with separate message types ?

The distinction :

Protocol class 2 => only DT1, sequence number mandatory (contains "more"
indicator)

Protocol class 3

- if sequence number present => only DT2 (mandatory parameter, contains
P(S),P(R) and more indicator, not present in the other messages)
- if receive sequence number present => only DA (mandatory parameter,
contains P(R), not present in the other messages)

- neither of these seq. numbers are present, but data param. is => ED
- neither of these seq. numbers are present, nor any data => EA

In short, the absence of sequence nr. parameters indicates use of expedited
data procedures, the absence of data indicates acknowledgements.

Any comments ?

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: dinsdag 28 augustus 2001 15:08
To: sigtran
Subject: RE: [SUA issue 23] Expedited data transfer Procedure

Hi All,

The CODT looks like:

    0                   1                   2                   3 

Parameters

John

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Aug 2001 14:54:32 -0500

Gery,

Verwimp Gery wrote: (Tue, 28 Aug 2001 16:28:05)
> data procedures, the absence of data indicates acknowledgements.

If we do not use separate message types, we should place a description
such as yours in the text.  It will also be necessary to describe when
these parameter MUST or MUST NOT be placed in the message to indicate
the type of messages.

I'm ok with that just as long as it is spelled out.

--brian

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

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 10:07:36 +0530

Hi ,

I agree with Gery's approach. I think SUA should also be using the unordered
data delivery mechanism of SCTP for transporting Expedited  data and Expedited
acknowledgement messages.

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 08/29/2001 02:24:32 AM

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

Subject:  Re: [SUA issue 23] Expedited data transfer Procedure

Gery,

--brian

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 00:17:59 -0500

Sandeep, Gery,

As Gery's proposal doesn't really change anything much the draft,
and we all seem to be in agreement, could we draft a short descriptive
paragraph (or notes) to add to the CODT message in Section 3 which 
reflects Gery's mapping.

Please see comments below...

[email-masked] wrote:                     (Wed, 29 Aug 2001 10:07:36)
> 
> Hi,
> 
> I agree with Gery's approach. I think SUA should also be using the
> unordered data delivery mechanism of SCTP for transporting
> Expedited  data and Expedited acknowledgement messages.

Unordered delivery does not in itself provide for expedited
transport in SCTP.  SCTP does not provide an expedited data
service.  A particular SCTP implementation may provide for
expediting data with the unordered bit set, but that is not
provided for in RFC 2960.  In fact, an SCTP implementation may
delay unordered delivery messages longer than normal messages.

I think that whether unordered bit is set on SUA CL and CO
messages is really a matter for the implementation to decide.

--brian

> -Sandeep
[snip]
> > DT/DA/ED/EA can all be distinguished at the SG depending on the
> > parameters present in the CODT. Do we need to come up with
> > separate message types ?
> >
> > The distinction :
> >
> > Protocol class 2 => only DT1, sequence number mandatory
> > (contains "more" indicator)
> >
> > Protocol class 3
> >
> > - if sequence number present => only DT2 (mandatory parameter,
> > contains P(S),P(R) and more indicator, not present in the other
> > messages)
> > - if receive sequence number present => only DA (mandatory
> > parameter, contains P(R), not present in the other messages)
> >
> > In short, the absence of sequence nr. parameters indicates use
> > of expedited data procedures, the absence of data indicates
> > acknowledgements.
> >
> > Any comments ?
> 
> If we do not use separate message types, we should place a
> description such as yours in the text.  It will also be necessary
> to describe when these parameter MUST or MUST NOT be placed in the
> message to indicate the type of messages.
> 

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

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 09:19:27 +0300

Hi all,

> paragraph (or notes) to add to the CODT message in Section 3 which 

I shall craft the text, for your review.

With regards to unordered data delivery, I agree with Brian.  I do 
not believe it will help.  

John
 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 01:44:41 -0500

John,

Maybe you could mark this issue "In Progress" then? ;)

John Loughney wrote:                                  (Wed, 29 Aug 2001 09:19:27)

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

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 13:08:12 +0530

Hi ,

I have somewhat different opinion about the usage of unordered data delivery.
Considering
a) At the transmitting side SCTP implementation may choose to send unordered
message prior to other ordered messages of the transmit queue. So unordered
message gets dispatched earlier at transmitting side.  SCTP specs suggest this
but does not mandate this though.
b) At the receiving side a unordered message gets delivered to the User as it
arrives, So there are less chances of this message getting held up in the
receive queue due to head of the line blocking on the stream.  This is mandated
by SCTP.

I think there is a much higher probability of an unordered message reaching
faster to the user at the other end.

So SUA should recommend or atleast allow implementation to use unordered
delivery for expedited messages.  For all other connection oriented messages
ordered message delivery MUST be used.

Best Regards,
-Sandeep

[email-masked] on 08/29/2001 12:49:27 PM

Hi all,

John

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 03:14:22 -0500

Sandeep,

[email-masked] wrote:                     (Wed, 29 Aug 2001 13:08:12)
> 
> 
> 
> Hi ,
> 
> I have somewhat different opinion about the usage of unordered
> data delivery.  Considering
>
> a) At the transmitting side SCTP implementation may choose to send
> unordered message prior to other ordered messages of the transmit
> queue.

Or, might not choose to do so....  Nothing in RFC 2960 requires an
implementation to expedite unordered data around ordered data on
transmit.  In fact, the simple implementation uses a single transmit
buffer and is fully welcome to place unordered data at the tail of
the buffer, behind ordered data.  Contention for the association's
congestion window and the peer's receive window also means that
unordered data cannot necessarily be expedited around unacked data
in flight.

> So unordered message gets dispatched earlier at transmitting side.

This is SCTP implementation dependent.  Some implementations might
not expedite data at all based on the unordered delivery option.

> SCTP specs suggest this but does not mandate this though.

Bingo.  Some SCTP APIs might decide to permit an expedited data
request (i.e., URG in socket API, band 1 in STREAMS) which may have
little or nothing to do with the unordered bit.

SUA should leave it to the implementation to determine what
mechanisms are available to somehow expedite data and choose how to
invoke them.  Unordered delivery does not necessarily expedite.

> b) At the receiving side a unordered message gets delivered to the
> User as it arrives,

I would say that it gets queued to the user as it arrives.  There is
nothing in RFC 2960 which requires that unordered data be expedited
around ordered data already in queue to the user.

> So there are less chances of this message getting held up in the
> receive queue due to head of the line blocking on the stream.

There is less chance of it becoming blocked by an ACK gap, but there
is no correlation to when it is delivered to the peer SUA.  Also,
the results of setting the unordered bit and expecting the receiver
to expedite depends on implementation specifics at the receiver.
There can be no recommendation to blindly set the unordered bit at
the SUA sender without consideration for the implementation
specifics at the receiver.

> This is mandated by SCTP.

It is not mandated by RFC 2960 that the implementation expedite
unordered data around ordered data already in queue to the user.
If you do not see why that is true, I invite you to quote chapter
and verse from RFC 2960.

> I think there is a much higher probability of an unordered message
> reaching faster to the user at the other end.

Probability can only be guaranteed to increase on a noisy association
(one with gap acks).  Where probability of faster delivery becomes
measurable, the association is unsuitable for SUA use anyway (QOS
is way too poor).

> So SUA should recommend or atleast allow implementation to use
> unordered delivery for expedited messages.  For all other
> connection oriented messages ordered message delivery MUST be
> used.

I disagree completely.  SUA should make no recommendation pertaining
to unordered bits attempting to provide an expedited data service
which SCTP is not intended to support in this fashion.  If the
SCTP implementation supports priority streams per SCTP extension
draft, the SUA implementation would be far wiser to use that
facility (which is intended to support priority bands permitting
expedited delivery).  It is sufficient to leave it alone and allow
the SUA implementation to use whatever means it has at its disposal
to permit expedited data delivery.

Sandeep, you should note that expedited data delivery in SCCP does
not expedite data around data already in queue at MTP.  All that
SCCP expedited data provides is the ability to expedite data and
acknowledgement around normal data which is awaiting the opening
of the class 3 flow control window.  It is possible to perform the
SCCP expedited data service completely within SUA and not even
involve SCTP.  Data alrady submitted to SCTP is as data already
submitted to MTP.  MTP does not provide any expedited data service
either.

--brian

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

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 14:27:54 +0300

Brian,

Is this text OK for you?

John

3.3.1 Connection Oriented Data Transfer (CODT)

[some text]

In order for the CODT to represent DT1, DT2 and ED messages, the following
conditions MUST be met:

DT1 is represented by a CODT when:
	SS7 QoS parameter field is present and Protocol Class = 2
	Sequence Number parameter is present (contains "more" indicator)

DT2 is represented by a CODT when:
	SS7 QoS parameter field is present and Protocol Class = 3
	Sequence Number parameter is present (contains P(S), P(R) and more
indicator)

ED is represented by a CODT with:
	SS7 QoS parameter field is present and Protocol Class = 3
	Sequence Number parameter is not present

3.3.2 Connection Oriented Data Acknowledge (CODA)

[some text]

In order for the CODA to represent DA and EA messages, the following
conditions MUST be met:

DA is represented by a CODA when:
	SS7 QoS parameter field is present and Protocol Class = 3
	Receive Sequence Number parameter is present (contains P(S), P(R)
and more indicator)

EA is represented by a CODA with:
	SS7 QoS parameter field is present and Protocol Class = 3
	Sequence Number parameter is present (contains "more" indicator)

Protocol class 3

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 14:31:42 +0300

Hi Brian & Sandeep,

> submitted to MTP.  MTP does not provide any expedited data service

Agreed.  I believe that we should not change the semantics of ED.
ED should expidate the traffic around the flow control window 
present for protocol class 3.  We shouldn't start to tweak SCTP
for this.

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 06:55:18 -0500

John,

As protocol class is not required in CODT messages and not
present in DT1, DT2 or ED (it is implicit to the connection
and message type) strike the SS7 QoS parameter field being
present.  The sequence number should not be present in
CODA to represent EA.  See modified text below:

--brian

> DT1 is represented by a CODT when:
< 	The connection Protocol Class = 2
> DT2 is represented by a CODT when:
< 	The connection Protocol Class = 3
> ED is represented by a CODT with:
< 	The connection Protocol Class = 3
> DA is represented by a CODA when:
< 	The connection Protocol Class = 3
> EA is represented by a CODA with:
< 	The connection Protocol Class = 3
< 	Sequence Number parameter is not present

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

---

---

From: [email-masked]
Date: Wed, 29 Aug 2001 15:29:50 +0300

Brian,

> present.  

Will do.

> The sequence number should not be present in
> CODA to represent EA.  

I thought the text said that.

Just to be perfectly clear, if the text reads the following:

[some text]

 

[some text]

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 29 Aug 2001 07:54:08 -0500

John,

Looks good, and I believe consistent with Gery's proposal.
If nobody has a problem with this text, Issue 23 is done.

--brian

John Loughney wrote:                                         (Wed, 29 Aug 2001 15:29:50)

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

---