Subject: [Sigtran] Re: Suggested New Test Cases for draft-bidulock-sigtran-m2pa-test-02.ps

From: [email-masked]
Date: Thu, 19 Sep 2002 08:47:34 -0400

Hello Brian,

>My preference is that they are struck.  The reason for striking
>is that sending these at an interval serves no purpose whatsoever
>that I can think of.  Can you think of a reason to send any of
>these periodically?  This is SCTP after all and not a lossy link.

I can think of no reason to periodically send these messages.
My preference for keeping them has to with the fact that I've
implemented them. (Yes, I know, not a good reason.... I'm human).

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]> on 09/19/2002 08:32:24 AM

Please respond to [email-masked]

To:    [email-masked]
cc:    [email-masked]
Subject:    Re: Suggested New Test Cases for
       draft-bidulock-sigtran-m2pa-test-02.ps

Jeffrey,

I'm glad the test spec can flush out these issues.

Comments below...

[email-masked] wrote:           (Thu, 19 Sep 2002 08:13:12)
>
> Hello Brian,
>
> >> 1. Receive message having invalid SCTP payload (e.g. not 5).
> > Kind of a useless test if you ask me, but I can add it.
>
> I'm okay either way. I was merely trying to cover the various
> M2PA-specific message content faults.
>
> >> 2. Receive message having unsupported M2PA version.
> >> 3. Receive message having unsupported M2PA class.
> >> 4. Receive message having unsupported M2PA type.
> >> 5. Receive message having M2PA and SCTP length mismatch.
> >> 7. Receive link status message having invalid length.
>
> >These could be added to the unexpected message sequences in the
> >existing tests.
>
> Sounds good to me.
>
> >> 6. Receive user data message of greater than (273+1+16=) 290 bytes.
> >M2PA does not restrict user data messages to these limits.  M2PA
> >permits the MTP3b 3094 or even higher lengths.
>
> You're right. Scratch this one.
>
> >> 8. Verify LSR is sent periodically until LSR is received or OOS.
> >LSR is not sent periodically in M2PA.
>
> M2PA v6, page 29, second paragraph, first sentence:
> "...and send Link Status Ready messages to its peer at interval
> Status_Interval."

Hmmm.  And Page 30....

"Status_Interval - implementation dependent."

>
>
> > 9. Verify LSB is sent periodically until busy clears.
> > 10.Verify LSPO is sent periodically until PO clears.
> >It is not a requirement to send LSB, LSPO periodically (only a
> >recommendation).  Anyway, there is no period specified in the M2PA
> >draft upon which to establish a test.  Perhasps these lines from the
> >draft should be struck.  Either the recommendation should be struck
> >from M2PA, or M2PA must provide a period.
>
> I agree. That's why I was harping about the M2PA 'rate' timers
> some time ago. My preference is that M2PA keep the recommendation,
> and also provide periods. Note that MTP2 T5 is the Busy interval.

My preference is that they are struck.  The reason for striking
is that sending these at an interval serves no purpose whatsoever
that I can think of.  Can you think of a reason to send any of
these periodically?  This is SCTP after all and not a lossy link.

--brian

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

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 19 Sep 2002 09:33:45 -0400

Brian/Jeff,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Thursday, September 19, 2002 8:48 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sigtran] Re: Suggested New Test Cases for
[TOLGA] Maybe to prevent SCTP cwnd to shrink? And because the rate will
dependent on the desired cwnd, it wouldn't be nice if the draft specified a
value.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Sep 2002 07:24:04 -0600

Jeffrey,

I don't enjoy burning timers for nothing.  It is easy enough
(even trivial) for an implementation to ignore the repetition,
but generating and interval requires a timer and introduces
additional fodder for race conditions and barriers to scale.
Unless someone can come up with a good reason, the intervals
should be struck.

Can you remember why they were added, Tom?

--brian

[email-masked] wrote:               (Thu, 19 Sep 2002 08:47:34)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Sep 2002 07:30:13 -0600

Tolga,

Do you have any idea how many LSR messages (of about 8 bytes) have to
be sent to keep any reasonable cwnd open?  Quite a few, I would imagine.
In that case, the interval should be measured in microseconds.

Sorry, but your explanation doesn't sound practical.  If the objective
were to keep cwnd open, send some larger fill-in messages, particularly
some kind of heartbeat message with an adjustable fill (similar to
proving messages) so that the objective can be more easily met.

Even then, an interval is the wrong way to go about it.  One could
jam a large amount of hearbeat into SCTP's send buffer and just
wait for it to play out.

Also, what happens when SCTP looses packets?  Does one keep sending
these things to the point of SCTP congestion?  Beyond?

The more I think about it, the more apparent it becomes that these
intervals need to be struck.

--brian

Tolga Asveren wrote:                                                                 (Thu, 19 Sep 2002 09:33:45)

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 19 Sep 2002 10:10:11 -0400

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, September 19, 2002 9:30 AM
> To: Tolga Asveren
> Cc: [email-masked]; Tom George
> Subject: Re: [Sigtran] Re: Suggested New Test Cases for
[TOLGA] Yes, it is not practical.
> proving messages) so that the objective can be more easily met.
[TOLGA] It was more a question than an explanation. Do those heartbeat
messages currently exist in M2PA? M2PAv06 4.3.1 gives as an example sending
Link Status Proving messages for proving period. But what about other cases?
What about the secondary path?
> these things to the point of SCTP congestion?  Beyond?
[TOLGA] IMO, the correct place for taking some action to keep cwnd around a
predefined value is SCTP. Because it is SCTP which does the calculation and
has the necessary information to do those calculations. But I don't think
any change in SCTP is possible. I am really wondering, how this problem
might be solved in M2PA?
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Sep 2002 08:10:38 -0600

Tolga,

Tolga Asveren wrote:                                 (Thu, 19 Sep 2002 10:10:11)

> any change in SCTP is possible. I am really wondering, how this problem

T7.

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 19 Sep 2002 10:35:13 -0400

Brian,

> Sent: Thursday, September 19, 2002 10:11 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] But isn't T7 restarted with any acknowledgement received? IMO, it is
not very related with the bandwith, i.e. with keeping cwnd around a
predefined value.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Sep 2002 08:48:11 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 19 Sep 2002 10:35:13)
> not very related with the bandwith, i.e. with keeping cwnd around a

Hogging bandwidth is not necessary if the latency is being met.

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 19 Sep 2002 11:23:07 -0400

Brian,

> Sent: Thursday, September 19, 2002 10:48 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] Which value is to be taken as the latency value to be meet? From
Q.706?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Sep 2002 09:27:48 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 19 Sep 2002 11:23:07)
> [TOLGA] Which value is to be taken as the latency value to be meet? From

Q.709 or, simpler, T7.

--brian

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 19 Sep 2002 15:55:49 -0400

Brian,
> > [TOLGA] Which value is to be taken as the latency value to be meet? From
[TOLGA] IMO, T7 is not very related with this issue. Q.709 5.1.3 refers to
T_cs as defined in Q.706 for cross-office transmit time for an STP. So, is
T_cs value also applicable when M2PA is used?
M2PA draft acknowledges the problem, which might arise because of SCTP
congestiona avoidance mechanisms in 4.3 SCTP Considerations, and tells how
to solve it for link proving case. But what can be done for other cases? Or
is this in fact not a problem?