Subject: AW: [Sigtran] Proving Message

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Mon, 28 Apr 2003 14:18:06 +0200

dear all,

see below

greetings

HannsJuergen

> -----Ursprüngliche Nachricht-----
> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Montag, 28. April 2003 13:32
> An: pardeep
> Cc: Rohan Pascal S Goveas; Tom George; SIGTRAN e-mail list
> Betreff: Re: [Sigtran] Proving Message
> 
> 
> pardeep,
> 
> On Mon, 28 Apr 2003, pardeep wrote:
> 
> > Brian
> > As you have written that Proving was included in the 
> original drafts some
> > years ago. May be you are refering to Q.703. In case of 
> Q.703 checking of
> > link reliabilty & integrity was its job, but in case of 
> M2PA we are using
> > the services of SCTP which is "RELIABLE".
> 
> SCTP is only "reliable" until the association fails.
> 
> > 
> > As you have written that SCTP does not provide any 
> assurances of grade of
> > service or carrying
> > capacity of an association implementation may want to 
> ensure that the
> > association is usable before sending actual MTP3 traffic 
> (in changeback or
> > intial alignement) .
> > 
> > But I don't think this is required because all these 
> functionality of SCTP
> > stack will be tested during functional/ load testing of SCTP Stack.
> 
> No, it is required due to prevailing network conditions and 
> has nothing
> to do with SCTP stack function/load testing.
> 
> > Load/Stress testing of SCTP shouldn't be the part of M2PA 
> functionality. If
> > SCTP association is established sucessfully then M2PA 
> should trust that it
> > is usable for carrying traffic.
> 
> On the contrary, just because an association is established, 
> has exchanged
> the alignment messages, does not mean that it is usable.  It 
> may fail, for
> example, due to congestion when offered traffic.

and we expect the proper operation of the association even in case proving has been carried out during a period of extremely low traffic when there was no congestion at all.
(BTW I'm not arguing for adding preventive proving)

> 
> This is also true for Q.2140.  Did you think that SCTP was so 
> different
> from SCCOP?
> 
> --brian
> 
> > 
> > Thanks
> > 
> > ----- Original Message -----
> > From: "Brian F. G. Bidulock" <[email-masked]>
> > To: "Rohan Pascal S Goveas" <[email-masked]>
> > Cc: "Tom George" <[email-masked]>; "SIGTRAN e-mail list"
> > <[email-masked]>
> > Sent: Monday, April 28, 2003 1:28 PM
> > Subject: Re: [Sigtran] Proving Message
> > 
> > 
> > Rohan,
> > 
> > Proving was included in the original drafts some years ago.
> > 
> > The reasons for proving are the same as for Q.703 and 
> Q.2140.  Because
> > SCTP does not provide any assurances of grade of service or carrying
> > capacity of an association it is wise to ensure that the 
> association is
> > usable before performing changeback at MTP3.  Otherwise, an unusable
> > association would be offered traffic and then fail, 
> reducing the overall
> > message transfer reliability of the network due to 
> potential losses and
> > missequencing resulting from the changeover procedure at 
> MTP3.  (Even
> > Q.2140 provides for a proving period with loading at 
> approximately 50%
> > of the cell rate as a normal procedure even though the SAAL provides
> > much stronger assurances of the quality of service of of 
> the link than
> > does SCTP.)
> > 
> > If you question the need for proving in M2PA, consider that it has
> > purpose in both Q.703 and Q.2140: the reduction of message loss and
> > missequencing due to changeback/changeover oscillation from repeated
> > failure under load.
> > 
> > --brian
> > 
> > 
> > On Mon, 28 Apr 2003, Rohan Pascal S Goveas wrote:
> > 
> > > All,
> > >     Can anyone give me a pointer to the mail discussions 
> thread which led
> > to
> > > the introduction of Proving state in M2PA and the 
> exchange of Proving
> > > message during this state.
> > >
> > > Thanks in advance.
> > >
> > > Rohan
> > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > --
> > Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> > [email-masked]    ¦ world; the unreasonable one persists in  ¦
> > http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
> >                         ¦ Therefore  all  progress  depends on the ¦
> >                         ¦ unreasonable man. -- George Bernard Shaw ¦
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran