Subject: RE: [Sigtran] M2PA list of comments on draft version 5 - multiple links on the same SCTP association

From: [email-masked]
Date: Fri, 19 Jul 2002 15:22:25 +0100

Tolga/Tom,

See below.........

"Tolga Asveren" <[email-masked]> on 15/07/2002 21:53:37

To:   [email-masked]
cc:    (bcc: Amish CHANA/EN/HTLUK)

Subject:  RE: [Sigtran] M2PA list of comments on draft version 5 - multiple
      links on the same SCTP association

Tom and all,

Some more comments/questions are below.

   Tolga

> > 10. 06/21/02 Javier Pastor-Balbas "[Sigtran] M2PA Comment:
> >     Multi-homing". Also 06/21/02 "[Sigtran] Multiplexed M2PA links on
> >     an association".  Should M2PA allow multiple links per
> >     association?
> >
> > A: The disadvantage of this is that if the association dies, you lose
> > all the links on the association. (According to the SCTP authors, it
> > is intended that all the streams in an association follow the same
> > physical path.) This is one of the main reasons I did allow for
> > multiple links in an association.

[Amish] Tom, I don't think v5 allows for "multiple links in an association."

> [TOLGA] What is benefit of allowing multiple links on an association? For
> SS7, if number of links between two nodes is increased, the
> reason is either
> redundancy or demand for higher bandwith or both. By carrying
> multiple links
> over the same association neither redundancy nor bandwith is increased.

[Amish] The following is one possible reason given Michael Tuexen:

"from a network management point of view having only one
assoc instead of N > 1 means less effort in configuration.

You also need some resources per assoc, so having less
associations may be better. But the difference as significant
as the management stuff."

Less configuration implies less room for human errors.
-----

[TOLGA] Currently the only benefit I could think of is, with multiple links
approach one can use multiple streams and so can avoid head-of-line
blocking. Whether this is a significant advantage over using separate
associations per link is another question.

BTW, in M2PA 1.7.4 it says:
"SCTP allows a user-specified number of streams to be opened during the
initialization.  It is the responsibility of the M2PA layer to ensure
proper management of the streams allowed within each association.

M2PA uses two streams in each direction for each association. Stream 0
in each direction is designated for Link Status messages. Stream 1 is
designated for User Data messages. Separating the Link Status and User
Data messages onto separate streams allows M2PA to prioritize the
messages in a manner similar to MTP2."

How are Stream 0 and Stream 1 used to prioritize Link Status messages? I
don't think sending messages from stream 0 will ensure that they arrive to
the destination faster than messages sent via stream 1, IP routing is
independent of streamId.

[Amish] Stream 0 message may be delivered to the user before stream 1 messages
if there is message corruption/loss. Different streams helps to reduce head of
line blocking of stream 0 messages. Maybe, the text should be reworded.
-----

Secondly, is this really matching with MTP2 behavior? With MTP2, when a User
Data message is sent and afterwards a Link Status message, there isn't the
possibility that LS arrives before UD to the destination, because they are
transferred over a dedicated physical medium, but by sending them via
different streams, there is the possibility of missequencing. What is the
reason for such a strategy?

[Amish] From the list in 2.3.2, the only LS messages that will be transmitted
over a link that is the "In Service" state are the Processor Outage, Processor
Outage Ended, Busy and Busy Ended message. What would be the effet of
missequencing if a Processor Outage or Busy was delivered to the remote M2PA
before other data messages? If sequencing is used, it is possible that the
delivery of these two messages may be delayed.
-----

Regards,
Amish

*******************************************************************************
Important.
Confidentiality: This communication is intended for the above-named person and
may be confidential and/or legally privileged. Any opinions expressed in this
communication are not necessarily those of the company. If it has come to you
in error you must take no action based on it, nor must you copy or show it to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in England No
2178917, with its address at St James Court, Great Park Road, Almondsbury Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 19 Jul 2002 10:51:46 -0400

typo in my last message. Please see below.

  Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tolga Asveren
> Sent: Friday, July 19, 2002 10:50 AM
> To: [email-masked]
> Subject: RE: [Sigtran] M2PA list of comments on draft version 5 -
> multiple links on the same SCTP association
>
>
> Amish,
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, July 19, 2002 10:22 AM
> > To: Tolga Asveren
> > Cc: [email-masked]
> > Subject: RE: [Sigtran] M2PA list of comments on draft version 5 -
> > multiple links on the same SCTP association
> >
> >
> >
> > Tolga/Tom,
> >
> > See below.........
> >
> >
> >
> >
> >
> >
> [TOLGA] This is not a real reason. This argument assumes that multiple
> associations are preferred. And the only reason I can think of to prefer
> multiple associations (multiple links) is to prevent head-of-line
> blocking.
> So, that seems to be the only benefit.
> > -----
> >
> [TOLGA] No, what you say is not correct. You can't control how
> datagrams are
> routed in IP network, which paths they follow. It is very well
> possible that
> there is no problem at all and a message from streamX jumps ahead of a
> message from streamY.
> > -----
> >
> [TOLGA] The primary important thing is to mimic behavior of MTP2, and so
> preventing sequence like in conventional MTP2 case. If a message is
[TOLGA] preventing ===>preserving
> delivered after another one with MTP2, I would prefer to keep the same
> sequencing with M2PA if possible. You say that if sequencing is used, that
> it is possible that the delivery of LinkStatus messages may be delayed. I
> disagree, it is not delaying, it is preserving sequence as in MTP2.
> > -----
> >
> > Regards,
> > Amish
> >
> >
> >
> >
> >

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 19 Jul 2002 10:49:55 -0400

Amish,

[TOLGA] This is not a real reason. This argument assumes that multiple
associations are preferred. And the only reason I can think of to prefer
multiple associations (multiple links) is to prevent head-of-line blocking.
So, that seems to be the only benefit.
> line blocking of stream 0 messages. Maybe, the text should be reworded.
[TOLGA] No, what you say is not correct. You can't control how datagrams are
routed in IP network, which paths they follow. It is very well possible that
there is no problem at all and a message from streamX jumps ahead of a
message from streamY.

---

From: Tom George <[email-masked]>
Date: Fri, 19 Jul 2002 10:58:08 -0500

I am sorry. This was a typo. I meant to say, "This is one of the main
reasons I did *not* allow for multiple links in an association."

tomG.

[email-masked] wrote:
  [...]
> [Amish] Tom, I don't think v5 allows for "multiple links in an association."
  [...]

-- 
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *