Subject: Re: [Sigtran] M2PA : LS messages on stream 0

From: [email-masked]
Date: Mon, 22 Jul 2002 14:08:27 +0100

Tolga,

I agree, missequencing is possible between the stream carrying link status
messages and the stream carrying data messages. But sequenced delivery is still
maintained for the messages between the MTP3 peers. So what?

Can you provide a good example where missequencing between Stream 0 and Stream 1
makes the delivery of MSUs less reliable.

Preserving MTP2 behaviour is not a good enough reason to change the current
draft.
Are you also considering sending messages equivalent to FISUs to preseve MTP2's
behaviour? :-)

Cheers,
A.

"Tolga Asveren" <[email-masked]> on 22/07/2002 13:12:16

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

Subject:  [Sigtran] M2PA : LS messages on stream  0

Amish,

(I changed the name of the thread)

> -----Original Message-----
> From: Amish Chana [mailto:[email-masked]]
> Sent: Sunday, July 21, 2002 1:23 PM
> To: [email-masked]
> Subject: RE: [Sigtran] M2PA list of comments on draft version 5 -
> multiple links on the s
>
>
> Tolga,
>
> >[TOLGA] If you think that SCTP blocks the delivery of link
> status message
> >by
> >sending it from the same stream like data, then you probably also think
> >that
> >this happens also with MTP2.
>
> I am referring to blocking at the SCTP receiver, if an earlier
> data message
> was overtaken or corrupted. SCTP will not deliver the link status
> message to
> M2PA until the data message is successfully received. If the MTP2
> receiver
> discards a MSU because it is corrupted, it does not discard or block the
> subsequent LSSU - it processes it!
[TOLGA] IMO, you are comparing two different things. SCTP corresponds to the
wire, which carries the messages in case of MTP2. But in that analogy, SCTP
is a perfect wire, which does not have any corruption. The corruption, which
might cause SCTP retransmissions is on the layer below, and does not have
any corresponding entity in the physicall wire case with MTP2.
>
> >What we need to do is to mimic MTP2 behavior.
> >It is not blocking, it is just simulating a link in IP domain and
> >preserving
> >sequence. If a link status message is received after a data message with
> >MTP2, the same should happen with M2PA.
>
> What is the advantage of mimicing MTP2 behaviour with regards to the
> sequencing between MSUs and Link status messages? What do you gain/loose?
[TOLGA] I think to behaeve as MTP2 is one of the main goals. SCTPs role in
M2PA is giving services provided by a physicall wire. Missequencing is not
possible on a physicall wire. So, it should be the same with M2PA. It is not
just comparing what you gain/loose. IMO, it is not just against the M2PA
concept but also against the general layering model.
>
> You are simply introducing unnecessary delays at the receiving
> end by using
> a single stream.
>
> BTW, please note that sending a
> >message from stream0 might further delay it, IP network does not
> care about
> >streamIDs.
>
> Yes, and sending all the messages on the same stream does not
> mean the link
> status message will be delivered any faster (it will just take
> much longer
> if a preceding message is lost).
[TOLGA] The importance thing is sequencing. You might send message1 from
stream1, message2 from stream0 and message3 from stream1 , and it is very
well possible that message1 and then message3 are delivered to M2PA on the
receiving end before message2. But if they are sent on the same stream, it
is sure that they will be delivered to the M2PA at the receiving end in the
same order.

4.1.7 of M2PA refers to Q.703, to justify use of stream0 for link status
messages. IMO, it is obvious that the corresponding section in Q.703 talks
about prioritizing when sending messages from MTP2 and processing received
messages in MTP2. So, this corresponds to the behavior of M2PA, when sending
and processing messages, not to the behavior of SCTP. Once M2PA sends a
message, sequence should be preserved, like on a physicall wire.
>
> A.
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com

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

*******************************************************************************
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: Mon, 22 Jul 2002 09:42:55 -0400

Amish,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 9:08 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] M2PA : LS messages on stream 0
>
>
>
> Tolga,
>
[TOLGA] If LS and data is sent from the same stream, the sequence is also
kept, and not just for MSUs, but for all messages. Trying to make use of a
different stream for LS is just mixing responsibilities of layers.
> makes the delivery of MSUs less reliable.
[TOLGA] And can you give an example, where sending LS from stream0 increases
reliability of sending MSUs?
> Preserving MTP2 behaviour is not a good enough reason to change
[TOLGA] In fact I wonder why it was decided to follow this approach at the
beginning. For you it might not be a good reason to change the draft, but
IMO it is an important change, which will make each layer to provide
services, it is supposed to provide.
> Are you also considering sending messages equivalent to FISUs to
[TOLGA] FISU is used in MTP2 to make sure that your physicall connection is
fine. With SCTP you don't need it, because it simulates a perfect wire. The
same behavior does not mean sending exactly the same messages, it means,
providing the same services and acting the same way. MTP2 does the
prioritizing by itself, so I think this should be done by M2PA.