Subject: AW: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Fri, 9 May 2003 10:10:27 +0200

Tom,

I don't consider it a good idea to leave this value implementation dependent.
That's because the original intention (that's at least my understanding of Q.703) was to generate sufficient traffic to see 1) whether the peer is able to handle the traffic and 
2) the number of transmission errors is sufficiently small.
Now assume the value of "Proving_Interval" set to the value of the T4 timer: only a single message would be sent out invalidating IMHO the whole proving procedure built into M2PA.

My proposal is to state that the traffic load generated with the Link Status Proving messages during the proving period is comparable to the normal traffic load that is expected when the M2PA link is in service. 
Not doing this, but recommending that the size of this messages is similiar to the size of the User Data messages is stopping halfway towards a clean solution.
In my understanding this the only chance to learn about the current QoS of the used IP network. It's of course no garuantee for a long term QoS as in the TDM world.

greetings

HannsJuergen

> -----Ursprüngliche Nachricht-----
> Von: Tom George [mailto:[email-masked]]
> Gesendet: Freitag, 9. Mai 2003 00:14
> Cc: SIGTRAN e-mail list
> Betreff: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call
> 
> 
> Hanns,
> 
> I should be able to improve the wording. I want the messages 
> to be sent
> periodically, but I do not want to specify the interval. 
> Maybe I should
> add this: 
> 
> During the proving period (i.e., after M2PA starts the proving period
> timer T4), M2PA SHALL send Link Status Proving messages to its peer at
> an interval defined by the protocol parameter Proving_Interval. ***The
> value of Proving_Interval is implementation dependent.***
> 
> tomG.
> 
> 
> 
> 
> Schwarzbauer Hanns Juergen wrote:
> > 
> > Dear all,
> > 
> > another finding in the draft 8:
> > 
> > Section 4.1.3 last but one para refers to a protocol 
> parameter called "Proving_Interval".
> > 
> > But no value is assigned to it throughout the document.
> > 
> > greetings
> > 
> > HannsJuergen
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> * Tom George       PB7-24001 (near B-21)      
> [email-masked]  *
> * 972-519-3168   Intranet:  
http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tom George <[email-masked]>
Date: Fri, 09 May 2003 16:00:32 -0500

Hanns,

That makes sense. Let me try again, using your phraseology: 

During the proving period (i.e., after M2PA starts the proving period
timer T4), M2PA SHALL send Link Status Proving messages to its peer at
an interval defined by the protocol parameter Proving_Interval. ***It is
RECOMMENDED that Proving_Interval be set so that the traffic load
generated with the Link Status Proving messages during the proving
period is comparable to the normal traffic load expected when the link
is in service.***

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 9 May 2003 15:19:06 -0600

Tom,

Q.2210 permits proving to be skipped altogether under maintenance
directive.

Where the grade of service of the underlying transport is known
to be sufficient, proving can be foregone.

M2PA should also permit proving to be skipped altogether.

--brian

-- 
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

---

From: Tom George <[email-masked]>
Date: Fri, 09 May 2003 16:24:58 -0500

IMHO "RECOMMENDED" allows for that. 

tomG.

---

From: "Umesh Vats" <[email-masked]>
Date: Fri, 9 May 2003 14:43:24 -0700

Proving should be an option. M2PA should specifically allow for skipping
proving where underlying transport is sufficiently reliable.

IMHO, in MTP2 proving was necessary because of the state of technology at
that time.

Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Tom George
Sent: Friday, May 09, 2003 2:25 PM
To: SIGTRAN e-mail list
Subject: Re: [Sigtran] (M2PA) Comments on M2PA v8 - Last Call

tomG.

"Brian F. G. Bidulock" wrote:
> > > That's because the original intention (that's at least my
understanding of Q.703) was to generate sufficient traffic to see 1) whether
the peer is able to handle the traffic and
> > > Now assume the value of "Proving_Interval" set to the value of the T4
timer: only a single message would be sent out invalidating IMHO the whole
proving procedure built into M2PA.
> > >
> > > My proposal is to state that the traffic load generated with the Link
Status Proving messages during the proving period is comparable to the
normal traffic load that is expected when the M2PA link is in service.
> > > Not doing this, but recommending that the size of this messages is
similiar to the size of the User Data messages is stopping halfway towards a
clean solution.
> > > In my understanding this the only chance to learn about the current
QoS of the used IP network. It's of course no garuantee for a long term QoS
as in the TDM world.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 9 May 2003 15:51:07 -0600

Tom,

It might be better to say that "proving MAY be foregone".  The opposite
of RECOMMENDED is not really MAY.

--brian

---

From: Tom George <[email-masked]>
Date: Fri, 09 May 2003 17:05:09 -0500

Here is the definition from RFC 2119

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

That sounds exactly like this case. 

tomG.

---

From: Tom George <[email-masked]>
Date: Fri, 16 May 2003 16:16:07 -0500

Brian et. al.,

One more try:

**The proving period MAY be omitted if this is allowed by the applicable
MTP2 standard (e. g., [Q.2210]). **

**If proving is performed,** then during the proving period (i.e., after
M2PA starts the proving period timer T4), M2PA SHALL send Link Status
Proving messages to its peer at
an interval defined by the protocol parameter Proving_Interval. **It is
RECOMMENDED that Proving_Interval be set so that the traffic load
generated with the Link Status Proving messages during the proving
period is comparable to the normal traffic load expected when the link
is in service.**

tomG.