Subject: [Tsvwg] More comments on the pps drafts

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 6 Nov 2003 15:14:09 +0100

Hello Naotaka,

some more thoughts after having read the MF PHB draft (which I felt to be enjoyable reading):

- PPS requires a "customised" output policing 
  rather than a special queuing discipline. It 
  may be useful if the framework could 
  explicitely mention this important fact. 
- The re-routing and mobility cases will require 
  more thought. I doubt that a state free attempt 
  will do. How does a router learn that some MF-H 
  traffic is exceptional?
  Fast thought: something like a path-token 
  transmitted within a domain and tracked by 
  routers? 
- Also suiting variable rate sources may require 
  some state. Here, information about the number 
  of active sources and their peak rate may be 
  useful. This could help to set the MF-M 
  threshold in the dynamic case and also be 
  used for buffer dimensioning.
- Buffer dimensioning needs some more discussion.
- When does an access system decide that a 
  session is terminated? Without a timer, a 
  terminal may continue to send MF-H traffic 
  because it considers the session still to be 
  up. Again, a limited amount of state would be 
  required to handle the issue.

The state maintenance requirements I mentioned still aren't as big as with RSVP and would refer to aggregates in the core. 

Regards, Rüdiger

Rüdiger Geib
T-Systems
Systems Integration
Senior Expert, Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
http://www.t-systems.com

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

---

From: "MORITA, Naotaka" <[email-masked]>
Date: Fri, 07 Nov 2003 13:35:03 +0900

Ruediger,

 >some more thoughts after having read the MF PHB draft (which I felt to be

Thank you again.

 >  explicitely mention this important fact.

Rate limiting is the required function.
Policer or shaper can be used for the rate limiting.
Due to the short-delay characteristics and
being potential to extend to the elastic mode,
the policer is preferable.
But the shaper, for the quick deployment,
can be used.

 >  transmitted within a domain and tracked by

Yes, it is a state free attempt.
But the router does not distingush exceptional MF-H traffic from ordinal one.
For the mobility case, it will work, because the exceptional traffic
may not be so large.
For the re-routing case, if we limit the topology and anticipate the worst
re-routed traffic, it should work.

 >  used for buffer dimensioning.

I am sorry.  I do not catch your point.
As you have pointed out at the previous mail,
the important feature of PPS is stateless inside the nework,
or inside the core at least.
For the ingress edge, per-flow state may be necessary
to avoid unexpected terminal behavior.

Do you mean the state for varible rate source is at the ingress egde,
or all routers?

 >- Buffer dimensioning needs some more discussion.

I fully agree.  I am now investigating in my labs.

 >  required to handle the issue.

Yes, I agree.  For the ingress edge, a limited amout of state
is necessary for unexpected use.
I assume that the terminal send "Bye" message at the SIP level
and the SIP proxy makes the edge router release access control list.

 >
 >The state maintenance requirements I mentioned still aren't as big as with
 >RSVP and would refer to aggregates in the core.

I agree.

I would like to stress the following points.
1. The state per MF-PHB class is mandatory.  It is the rate limit value at 
the policer or the shaper.
The rate limit is per-class basis, at the output port at all routers, or 
even L2 switches.
2. Per-flow states are at terminals.
3. If the operator want to avoid unexpected use such as malicious use or 
failuer condition,
the edge router should keep per-flow states for per-flow policing at the 
input port at the ingress router.

Naotaka

 >Regards, R$B—E(Biger
 >R$B—E(Biger Geib

----------------------------------
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]
MSN messenger: [email-masked]
NTT home page: http://www.ntt.co.jp/about/e/index.html

---

From: "MORITA, Naotaka" <[email-masked]>
Date: Fri, 07 Nov 2003 14:24:41 +0900

You can refer to the following web site for measurement-based admission control.

http://lcn.imit.kth.se/PBAC/