Subject: [Tsvwg] Re: PPS: influence of route changes

From: "MORITA, Naotaka" <[email-masked]>
Date: Thu, 22 Jan 2004 19:32:46 +0900

Ruediger,

Thank you for your interesting question.
I thought I have missed to join the discussion,
when you raised such issue.

At 09:57 04/01/22 +0100, Geib, Ruediger wrote:
 >Dear Naotaka,
 >
 >accounting for the influence of route changes to me is an
 >open issue with respect to PPS. What happens after a route
 >change is that some routers recognise a sudden increase in
 >High Subclass traffic without prior Middle Subclass traffic
 >(others notice a sudden decrease).

I had already considered the situation, and my current idea is,
if the router operates as a static mode, which has the common
bandwidth threshold for both High and Middle, it must be a problem.
If it operates as a elastic mode, it is not a problem,
because it exceptionally passes High class.
As you know, in the elastic mode, the router has two threshold,
one is BWm, e.g. 40Mbps, and anther is BWh, e.g. 80Mbps.
When the sum is more than BWm, and if Middle packets are there,
they are discarded, but all High packets can pass upto BWh.
This is what I want to write in section 3.2.2 in the definition of MF-PHB.

 >
 >If service quality should not suffer from this effect,
 >resources must be overprovisioned prior to its occurence.
 >If resources are to be re-provisioned as a consequence of a
 >route change, a rather fast signaling protocol is required.
 >This protocol must further accurately determine the
 >resources required. That sounds complex and it may
 >spoil the "state free" benefits of pps.

Yes, it is a kind of overprovisioning.
But, no, it is still state free.
In the above example, the link would be 100Mbps and
up to 40Mbps can be used in normal operation.
In the case of route change,
the link can tolerate upto 80Mbps with High class.
The values of 40Mbps and 80Mbps are configured and no signalling is necessary.
Off course, it can not tolerate more than double traffic,
but it is a matter of network engineering.
If I carefully design the network, it is not a problem I believe.

This concept can easilly be exteded when MF-PHB is applied to MPLS network.

The issue of my proposed approach is how to avoid
the accumulation of the exceptional traffic.
For the sake of simplicity, let's assume 1 to 1 protection.

Phase (link A, link B)
#1 (  0,  0)
#2 ( 30, 20)
#3 ( 40, 40) further session attempt fails
Link A is broken
#4 ( x  , 80)
Link A is recovered instantaneously.
#5 ( 10, 75)
Link A is broken again.
#6 ( x , 85) **** now 5 Mbps high packets will be discarded.

I am now investigating such scenario and
examine it by the real router in February.

 >
 >Assuming overprovisioned High Subclass resources as a solution,
 >which value is added by an information on route change
 >occurences? It doesn't decrease the load, it only helps to
 >distinguish the effect of a route change from a DoS attack or
 >other kinds of misuse. I'm not sure whether PPS is a reasonable
 >architecture if it allows for DoS attacks and other kinds of
*************
 >misuse. So excluding this cause for a spontaneous load increase,
 >the load increase itself indicates a route change. A
************
 >node will discard Middle Subclass traffic for a while. What it
 >further may do is marking High Subclass Traffic by something
 >as ECN. Many voice and video codecs are able to decrease
 >sending rate. After a while, "normal" operation is resumed and
 >these ECN marks dissapear.
 >
 >What are your thoughts about how to deal with route changes in
 >a PPS network?
 >
 >Regards, Rudiger

I sorry but I do not understand the two lines between *****.

Yes, DoS is an issue of PPS, but as is described in the framework draft,
I assume two protecting point: edge router and media monitor server.

Initially, I do not think path coupled signaling for PPS.
But it is another intersting topic how to apply NSIS
to measurement based admission control.

----------------------------------
Naotaka MORITA, NTT 

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

---

From: "Geib, Ruediger" <[email-masked]> (by way of "MORITA, Naotaka" <[email-masked]>)
Date: Thu, 22 Jan 2004 21:15:03 +0900

Naotaka,

thanks for your fast reply. I think we agree on the best way
to deal with route changes in a pps architecture. Some
comments and a clarification in line.

Regards, Rudiger

----snip----

|In the above example, the link would be 100Mbps and
|up to 40Mbps can be used in normal operation.
|In the case of route change,
|the link can tolerate upto 80Mbps with High class.
|The values of 40Mbps and 80Mbps are configured and no
|signalling is necessary.
|Off course, it can not tolerate more than double traffic,
|but it is a matter of network engineering.
|If I carefully design the network, it is not a problem I believe.

I fully agree.

|This concept can easilly be exteded when MF-PHB is applied to
|MPLS network.

Yes. Another benefit of pps.

------snip--------------

The following section just should say that DoS attacks and
other misuse aren't expected to be an issue for PPS. To
clarify this, I've argued from an opposite viewpoint: if
attacks and misuse were an issue for pps, nobody would
deploy it.

| >. I'm not sure whether PPS is a reasonable
| >architecture if it allows for DoS attacks and other kinds of
|*************
| >misuse. So excluding this cause for a spontaneous load increase,
| >the load increase itself indicates a route change. A
|************
| >node will discard Middle Subclass traffic for a while. What it
| >further may do is marking High Subclass Traffic by something
| >as ECN. Many voice and video codecs are able to decrease
| >sending rate. After a while, "normal" operation is resumed and
| >these ECN marks dissapear.
|I sorry but I do not understand the two lines between *****.
|
|Yes, DoS is an issue of PPS, but as is described in the
|framework draft, I assume two protecting point: edge router and
|media monitor server.

---snip-------

----------------------------------
Naotaka MORITA, Senior Research Engineer, Supervisor
Network Service Systems Laboratories
Information Sharing Laboratory Group
NTT
3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN
Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012
E-mail: [email-masked]