Subject: RE: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Tue, 19 Sep 2006 11:23:34 -0400

Hi Michael,

Thanks for the feedback.    Please see a couple of comments below
(marked [Anna]).

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 6:21 AM
To: [email-masked]
Subject: [PCN] Feedback to draft-briscoe-tsvwg-cl-architecture-03.txt

Hi all,

I've read the draft
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-
03.txt

I find the proposed concept pretty good as I consider it a simple and
technically feasible solution. Here are my comments regarding the draft.

1) Abstract: Although I am working on this field for years, I haven't
understood what the draft is about upon the first reading. Here is how
I'd summarize the presented mechanism.

This document describes a distributed, measurement-based, and resilient
admission control for application in large DiffServ-based networks.
All routers have a configured admission and pre-emption rate for their
adjacent links.
They measure the admitted traffic they forward on each outgoing link and
use a so-called pre-congestion notification (PCN) mechanism to mark
packets that exceed the configured rates. The egress router measures the
rates of non-labelled, admission-marked, and preemption-marked packets
from each ingress, 

	[Anna] just a clarification here: in fact the mechanisms for
admission and preemption that were currently discussed in
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-
architecture-03.txt  differ in what they look at at the egress - for
cac it is the admission-marked packets that are being measured,
while for preemption those that are not preempton marked. 

and notifies the respective ingress if it must not admit any further
packets or that it must even pre-empt a certain rate of admitted flows.
Per-flow admission states are kept at the edge routers only, while the
PCN markers that are required for all routers focus on the aggregate
traffic. The admission control is resilient with regard to the following
two aspects:
(1) the configured admission and preemption rates can be chosen in such
a way that the reservations for admitted flows are not pre-empted if a
foreseeable failure occurs and (2) that reservations can be torn down
explicitly if a large failure occurs to preserve the quality of service
of the remaining flows.

2) The summary is very long. As the terminology is explained only in
1.2, it is sometime hard to follow Section 1.1. It is sometimes
unnecessarily unprecise and, therefore, hard to follow. I think this
could be rewritten without increasing the length of Sections 1.1 and 1.2
such that they it provide more clarity even at the first reading.

    [Anna] Will try to clean up/shorten the summary. 

3) Terminology for "sustainable-aggregate-rate" is not clear.
Suggestion:
rate of non-preemption marked packets measured by an egress gateway for
a specific ingress gateway; this is the supportable traffic rate between
these gateways if the corresponding path is congested.

    [Anna] Thanks - will consider making it clearer

4) Section 2.2: o Routing: a study regarding the accuracy of load
balancing schemes can be found in

[LoadBalancing-a] Ruediger Martin, Michael Menth, and Michael
Hemmkeppler:
"Accuracy and Dynamics of Hash-Based Load Balancing Algorithms for
Multipath Internet Routing", IEEE Broadnets, San Jose, CA, USA, October
2006
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth06p.pdf

[LoadBalancing-b] Ruediger Martin, Michael Menth, and Michael
Hemmkeppler:
"Accuracy and Dynamics of Multi-Stage Load Balancing for Multipath
Internet Routing", currently under submission
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub-
6.pdf

    	[Anna] In general load-balancing/ECMP issues are on our open
issues 	list.  Understanding accuracy of load-balancing is clearly of
issues and approaches to deal with these issues tha have been
discussed but on which consensus is yet to be reached. Seems like a
good thing for the BoF/WG to address?

Section 3 and 4: no comments, they look good and are well
understandable.

5) Section 5.1:

o tunnel: what kind of tunnel? IP-in-IP tunneling from ingress gateway
to egress gateway with the effect that all flows are forced by ECMP on
the paths that is determined by the IPs of these tunnel endpoints? This
is how understood tunneling later in 5.7.1.

o probes: probe packets have the same address as the corresponding flow.
Do they finally leave the CL-domain and reach the destination?
This is unwanted extra traffic for this machine.

	[Anna]these are but some possibilities.  Again these are issue
left open and are subject to further work/discussion

6) Section 5.2:

Another potential solution: smart marking

The meaning of preemption marked packets is: this is an excess packet
and the rate of the corresponding CL-region-aggregate will be reduced in
the future. Therefore, packets that are already preemption marked should
not be counted at another router for the metering process which is done
for preemption marking. This does not solve the problem in Figure 4, but
it alleviates the problem in other constellations:

                        IAR-b=1
                           @
             +-----+ L1 +-----+ L2
             |CPR=1|    |CPR=2|@@@@ SAR-b=2/3
IAR-a=2 >####| R1  |####| R2  |#### SAR-a=1/2*2/3=1/3
             +-----+    +-----+

These SARs lead in the end to a rate of 1 on link L2 although the
configured-admission-rate (CAR) is 2.
If already marked packets are not respected at R2 for the metering
process for preemption marking, we get SAR-b=1 and SAR-a=1/2 which leads
in the end to the fully used CAR on link L2.

After I wrote this, I read the draft about the markers:
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-phb-02.txt
The suggested algorithm implements the preemption marker in fact in such
a way that it respects only non-preemption-marked packets for the
measurement process. This is a requirement which should also be
mentioned in this draft.

	[Anna] I believe that it is understood in the approaches that
were 	considered for preemption that router meters the packet
aggregates 	which have not already been preemption-marked.  Need to
go through 	various drafts to make sure this is clear.  But again,
one of the 	issues her is whether in fact there is consensus that
this is a 	behaviour that is a MUST (and hence needs to be
standardized) or 	whether this is just a good thing to have (my
personal view here is 	that it does need to be standardized, but this
is again an issue to 	reach consensus on).

7) Section 5.5

Another potential solution: add the declared rate to the SAR at the
ingress gateway as long as new flows send hardly any traffic. This
information must be obtained from the corresponding policers which are
also under the control of the ingress gateway. Or add it for an initial
period of e.g. 10 s?

       [Anna]Just to understand what you mean: this is a proposal to
solve 	 which aspect of the problem?

8) Section 5.7.2
What does over-congested mean?

        [Anna] Need to clarify.  Means "very congested" :-) that is
being 	  above the chosen theshold, but need to look in detail and make
the 	  wording clear.

9) Section 5.7.4
Reminds me of RFC4127: Russian Dolls Bandwidth Constraints Model for
Diffserv-aware MPLS Traffic Engineering (and other models for that
objective)
         [Anna] Not sure what point you are trying to make?

10) Section 5.7.5
I haven't understood the last sentence of this section.
Can it be rephrased?
         [Anna] - thanks - will look into that and make sure it is clear

11) Section 6.8 *NEW*
Other Network Admission Control Approaches Link admission control (LAC)
describes how admission control (AC) can be done on a single link and
comprises, e.g., the calculation of effective bandwidths which may be
the base for a parameter-based AC.
In contrast, network AC (NAC) describes how AC can be done for a network
and focuses on the locations from which data is gathered for the
admission decision. Most approaches implement a link budget based NAC
(LB NAC) where each link has a certain AC-budget. RSVP works according
to that principle,
 but also the new concept admits additional flows as long as each link
on
 the new flow's path still has resources available. The border-to-border

budget based NAC (BBB NAC) pre-configures an AC budget for all
border-to-
border relationships (=CL-region-aggregates) and if this capacity budget
 is exhausted, new flows are rejected. The TCA-based admission control 
which is associated with the DiffServ architecture implements an ingress

budget based NAC (IB NAC). These basically different concepts have 
different flexibility and efficiency with regard to the use of link 
bandwidths [NAC-a,NAC-b]. They can be made resilient by choosing the
 budgets in such a way that the network will not be congested after 
rerouting due to a failure. The efficiency of the approaches is
different
 with and without such resilient requirements.

[NAC-a] Michael Menth: "Efficient Admission Control and Routing in
Resilient Communication Networks", PhD thesis, July 2004,
http://opus.bibliothek.uni-wuerzburg.de/opus/volltexte/2004/994/pdf/Ment
h04.pdf

[NAC-b] Michael Menth, Stefan Kopf, Joachim Charzinski, and Karl
Schrodi: "Resilient Network Admission Control", currently under
submission.
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-Sub-
3.pdf

    	[Anna] Thanks for pointing out this work. We have had some 
	experience 	in estimating bandwidth requirements of
mechanisms 
	similar to the ones you propose in the above paper, and found
that 
	the bandwidth requirements needed for resiliency depend quite 
	dramatically on the assumption on which failures one protects 
	against (just link or node, or shared risk link groups (SRLGs),
and 
	are also rather topology dependent.  We found that for some real

	networks capacity requirements nneeded to provide resiliency to 
	local failures in the manner you disuss in the above paper is
quite 
	high.  Some of the refereces in various pcn drafts also point to

	similar conclusions albeit the circumstances are slighly
different 
	that those you consider.  This sometimes 	extensive
capacity needed 	
	for resiliency seems in fact to motivate 	a lot of the pcn
work, 	
	which tries to address the "normal"  operating conditions and 	
	protect against unexpected (and/or expensive to protect
otherwise)
	failures in a graceful manner. 

12) Section 11.1
Paragraph "The ECN-Capable ... codepoint set." is hard to understand.
Two sentences more explanation could maybe help.
        
      [Anna] thanks, will do.

13) Section 11.3
By running the EWMA whenever a new packet for a specific
CL-region-aggregate arrives makes the aging process depending on the
arrival rate of the traffic. As a consequence, there is the problem with
the stale information. This can be done in a better way, e.g.
by using the time-exponentially weighted moving average (TEWMA) [TEWMA].

[TEWMA] Ruediger Martin and Michael Menth: "Improving the Timeliness of
Rate Measurements", in proceedings of GI/ITG Conference on Measuring,
Modelling and Evaluation of Computer and Communication Systems (MMB),
Dresden, Germany, September 2004
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04h.pdf

If the TEWMA seems too complex (it requires the calculation of an
exponential function), a rate of the admission- or preemption-marked
packets can be calculated based on a, e.g., 20 ms interval and used as
input for a conventional EWMA.

      [Anna] Thanks - will look into the reference.  Again, from the
 	standartisation point one needs to decide how much detail does
one 
	have to standardize and in fact at the moment the question of 
	whether anything that the edges do must be standardized at all
is an
 	open question.  This would be something the BoF/WG would adress
I 
	presume (assuming of course the WG is created)

14) Some places in the document say that admission and preemption
marking is done based on the rates of the packet AND some virtual queue
size. This is misleading from my perspective. The objective is
a) to admission-mark all packets of an CL-region-aggregate if the
configured admission rate ist exceeded and
b) to preemption-mark only those packets exceeding the configured
preemption rate.
The virtual queue is just a means to allow a tolerance against
short-time rate fluctuations like the "cell delay variation tolerance"
or the "burst tolerance" in ATM. More on this topic in an extra mail
regarding draft-briscoe-tsvwg-cl-phb-02.txt

          [Anna] Thanks - will clean up to make sure it is clearer. 

	Best regards,
	Anna

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

---

From: Michael Menth <[email-masked]>
Date: Wed, 20 Sep 2006 08:44:09 +0200

Dear Anna,
> solve 	 which aspect of the problem?
This proposal tries to cope with flash crowds, i.e. with many almost 
simultaneous admission requests. The problem is that the AC can respect 
the impact of  newly admitted flows only after some time when their 
typical sent rate influences the admission marking in the routers. I 
think that there should be a mechanism to find out the minimum rate 
between two border routers that is still admissible. The sum of the 
overall declared rates of new flows should not consume more than this 
rate. A flow is new as long as its typical rate has not yet hat an 
impact on the packet marking, and to keep things simple, for an initial 
time of maybe 10 s.
>          [Anna] Not sure what point you are trying to make?
I'd like to say that some of the nomenclature in this context can maybe 
be reused.
> 	that those you consider.  
This is right. The required (backup) capacity depends on many aspects: 
the routing, the traffic matrix, the topology, and probably many others. 
However, it also depends on the network admission control (NAC) approach 
that is used and the PCN concept implements a specific NAC approach. 
Therefore, it is of interest how its efficiency relates, e.g., to the 
one of the TCA approach. And this is done in my PhD thesis and the cited 
paper. Apart from the TCA approach, there are several other basic NAC 
approaches that are compared.
> This sometimes 	extensive
Hm? - Anyway. I think [IyBh03] provides the best motivation for 
resilient admission control as it points out that "link overload is 
rare, and when it occurs, 80% of the time it is caused due to link 
failures" (see abstract). Conventional AC does not consider a safety 
margin to accommodate redirected traffic. Therefore, failures will still 
lead to overload and therefore conventional AC mostly doesn't work when 
it is needed.  This concludes that AC must be resilient to failures, 
anything else does not make sense.

[IyBh03] S. Iyer, S. Bhattacharyya, N. Taft, and C. Diot: "An Approach 
to Alleviate Link Overload as Observed on an IP Backbone", in 
proceedings of IEEE Infocom, San Francisco, CA, USA, April 2003
http://klamath.stanford.edu/~sundaes/Papers/infocom2003.pdf

> 	presume (assuming of course the WG is created)
Any moving average mechanism has some "memory". For example, if new 
samples get a high weight relative to the existing average, the memory 
is short. Both the averaging algorithm and the length of the 
corresponding memory at the egress routers may be chosen differently in 
different networks. They have both an impact on the reaction speed of 
the AC which should carefully be investigated. The same holds for the 
measurement algorithms and their parameters for the markers.

Best wishes,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 20 Sep 2006 09:30:10 +0200

Hallo Michael,

You are right, dealing with re-route events and other 
sudden changes in traffic load is a very important 
issue for any provider trying to produce "Quality of 
Service". Solving the related planning aspects may be 
out of scope for a PCN WG. But the PCN design should 
allow for solutions allowing a once admitted flow 
to get the promised QoS, regardless of events in the 
backbone (at least for foreseeable conditions).

I'd strongly favour a simple operational scheme in the backbone. 
Both of your proposals, measuring available bandwidth to then 
applying reservation based admission control (that's what I'd 
understand to be meant by using "declared rates" for AC) doesn't
seem to be favourable in the backbone. 

A flash crowd may cause a short term congestion on a link. If 
you just look at the resulting traffic (not at the cause for 
it), a re-route event may have to some extent similar 
consequences. I personally favour to spare some QoS capacity 
on a link and to stop admitting new sessions for a while to 
cope with both of them. 

A smart mechanism to detect whether the bandwidth required by 
an application is still available within the backbone is the 
Priority Promotion Scheme (PPS). It is another measurement 
based admission control method, where end-systems create 
short bursts of application traffic prior to being admitted. 
A hyrachical token bucket avoids flows from being admitted 
once a settable load level has been reached on a link. 
To me, changes required in end-systems, a hyrachical 
policer and the consumption of DSCPs make PPS less 
favourable than PCN. I would however prefer PPS over 
any "available" capacity measurements in combination 
with reservation based admission control in the backbone. 
For PPS see: http://www.ee.kth.se/~nacho/PBAC/ . The PPS 
ceators work with losses to indicate congestion. I think 
re-marking is smarter (as applied by ECN/PCN)

Regards,

Rüdiger

[Michael]
|> 7) Section 5.5
|>
|> Another potential solution: add the declared rate to the SAR at the
|> ingress gateway as long as new flows send hardly any traffic. This
|> information must be obtained from the corresponding policers 
|> which are also under the control of the ingress gateway. Or add 
|> it for an initial period of e.g. 10 s?

        [Anna]Just to understand what you mean: this is a proposal 
         to solve which aspect of the problem?
   
[Michael]
|This proposal tries to cope with flash crowds, i.e. with many almost 
|simultaneous admission requests. The problem is that the AC 
|can respect the impact of  newly admitted flows only after some 
|time when their typical sent rate influences the admission marking 
|in the routers. I think that there should be a mechanism to find 
|out the minimum rate between two border routers that is still 
|admissible. The sum of the overall declared rates of new flows 
|should not consume more than this rate. A flow is new as long as 
|its typical rate has not yet hat an impact on the packet marking, 
|and to keep things simple, for an initial time of maybe 10 s.

---

From: Michael Menth <[email-masked]>
Date: Wed, 20 Sep 2006 11:33:49 +0200

Hi Ruediger,

> backbone (at least for foreseeable conditions).
Yes, that's right. We already did that in a former project for a 
different network admission control approach:
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04d.pdf
Capacity budgets (aka configured-admission-rates) are set in such a way 
that the capacity in the network suffices to carry all admissible 
traffic patterns in all single failure scenarios. This is a 
configuration problem and is subject to further research for a PCN-based 
NAC.

> on a link and to stop admitting new sessions for a while to 
That is true. But when I talk about flash crowds, I do not think of 
uncorrelated users entering the network independently of each other. 
When a soccer game starts at 3:30 pm and many users simultaneously try 
to access the network, then the load can increase significantly. And 
this will possibly lead to a long-term congestion. Hoping that the 
impact of the flash crowd is not so strong that it does not lead to real 
congestion since there is extra capacity is one option and is certainly 
a viable option in core networks with very large link capacities and a 
small likelihood for uncorrelated flows. Going further to regional 
networks, it might be good to do something against flash crowds that 
could lead to physical link congestion. In such a case I see two 
alternative options:
a) Do nothing and preempt flows when the configured-preemption-rate is 
exceeded.
b) Try to avoid overload due to flash crowds and this is what the 
mechanism I mentioned aims at.
> re-marking is smarter (as applied by ECN/PCN)
I've looked at the draft 
http://www.ee.kth.se/~nacho/PBAC/draft-morita-tsvwg-pps-01.txt where PPS 
is described. This admission control works as follows. The origin end 
system [in our context the ingress router] sends a packet burst of the 
declared rate of the flow into the network and the destination end 
system [in our context the egress router] signals back how many of these 
packets have arrived. The packet burst needs to be sufficiently long, 
otherwise only large packet loss probabilities can be detected. This 
mechanism does not support any admission threshold at e.g. 30% link load 
which is the enormous benefit of the PCN-based NAC as this is a 
prerequisite for resilient NAC as discussed above.

Obviously, I haven't explained the mechanism I had in mind not well 
enough as "reservations and available bandwidth measurements" sound 
difficult to you and probably to others. What's behind?

The ingress router asks the egress router for the bandwidth that is 
still available for a specific border-to-border (b2b) 
CL-region-aggregate: s simple round-trip signaling evaluates the minimum 
difference between the configured-admission-rate and the currently used 
rate by CL traffic on each link on the b2b path. The current CL rate on 
the link should not be too difficult to obtain because the admission and 
preemption marking have similar complexity.
Furthermore, the ingress router holds a table of recently admitted flows 
for each b2b CL-region aggregate. It adds them after admission and 
removes them when they terminate or when they are older than 10 s. The 
latter action can be done whenever the aggregate rate of the recently 
admitted flows is needed. Such a table is feasible as long as flows 
declare a rate which is used for the policers. Therefore, it does not 
significantly increase the complexity of the AC as the ingress routers 
is an end point for end-to-end signalling (RSVP) anyway. When a new flow 
requests admission, its declared rate is compared to the available b2b 
bandwidth minus the aggregate rate of the recently admitted flows. This 
bandwidth reduction can be further decreased by mechanisms borrowed from 
experience-based admission control (EBAC), however, I don't like to 
further explain this at this point to avoid confusion.

Best wishes,

    Michael

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 20 Sep 2006 15:48:51 +0200

Hallo Michael,

my comments are in line.

Regards,

Rüdiger

|> You are right, dealing with re-route events and other 
|> sudden changes in traffic load is a very important 
|> issue for any provider trying to produce "Quality of 
|> Service". Solving the related planning aspects may be 
|> out of scope for a PCN WG. But the PCN design should 
|> allow for solutions allowing a once admitted flow 
|> to get the promised QoS, regardless of events in the 
|> backbone (at least for foreseeable conditions).
|>   
| Yes, that's right. We already did that in a former project for a 
| different network admission control approach:
| http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth04d.pdf
| Capacity budgets (aka configured-admission-rates) are set in 
| such a way that the capacity in the network suffices to carry all 
| admissible traffic patterns in all single failure scenarios. This is a 
| configuration problem and is subject to further research for a 
| PCN-based NAC.

Well, I'd regard the planning issues to be out of scope of PCN. The 
kind of network planning you describe is in priciple operational 
in at least one commercial backbone network I'm aware of.

|> I'd strongly favour a simple operational scheme in the backbone. 
|> Both of your proposals, measuring available bandwidth to then 
|> applying reservation based admission control (that's what I'd 
|> understand to be meant by using "declared rates" for AC) doesn't
|> seem to be favourable in the backbone. 
|>
|> A flash crowd may cause a short term congestion on a link. If 
|> you just look at the resulting traffic (not at the cause for 
|> it), a re-route event may have to some extent similar 
|> consequences. I personally favour to spare some QoS capacity 
|> on a link and to stop admitting new sessions for a while to 
|> cope with both of them.

| That is true. But when I talk about flash crowds, I do not think of 
| uncorrelated users entering the network independently of each other. 
| When a soccer game starts at 3:30 pm and many users simultaneously try 
| to access the network, then the load can increase significantly. And 
| this will possibly lead to a long-term congestion. Hoping that the 
| impact of the flash crowd is not so strong that it does not 
| lead to real congestion since there is extra capacity is one option 
| and is certainly a viable option in core networks with very large 
| link capacities and a small likelihood for uncorrelated flows. 
| Going further to regional networks, it might be good to do 
| something against flash crowds that could lead to physical link 
| congestion. In such a case I see two alternative options:
| a) Do nothing and preempt flows when the configured-preemption-rate is 
| exceeded.
| b) Try to avoid overload due to flash crowds and this is what the 
| mechanism I mentioned aims at.

IPTV gains a lot of attention these days. I'd expect multicast 
distribution within a single domain. The Flash crowd should use a 
communication service rather than a distribution service. Events 
like catastrophes lend to that, but the demand may not grow as 
fast as in your example.

|> A smart mechanism to detect whether the bandwidth required by 
|> an application is still available within the backbone is the 
|> Priority Promotion Scheme (PPS). It is another measurement 
|> based admission control method, where end-systems create 
|> short bursts of application traffic prior to being admitted. 
|> A hyrachical token bucket avoids flows from being admitted 
|> once a settable load level has been reached on a link. 
|> To me, changes required in end-systems, a hyrachical 
|> policer and the consumption of DSCPs make PPS less 
|> favourable than PCN. I would however prefer PPS over 
|> any "available" capacity measurements in combination 
|> with reservation based admission control in the backbone. 
|> For PPS see: http://www.ee.kth.se/~nacho/PBAC/ . The PPS 
|> ceators work with losses to indicate congestion. I think 
|> re-marking is smarter (as applied by ECN/PCN)
|>   
| I've looked at the draft 
| http://www.ee.kth.se/~nacho/PBAC/draft-morita-tsvwg-pps-01.txt 
| where PPS 
| is described. This admission control works as follows. The origin end 
| system [in our context the ingress router] sends a packet burst of the 
| declared rate of the flow into the network and the destination end 
| system [in our context the egress router] signals back how 
| many of these 
| packets have arrived. The packet burst needs to be sufficiently long, 
| otherwise only large packet loss probabilities can be detected. This 
| mechanism does not support any admission threshold at e.g. 30% 
| link load 
| which is the enormous benefit of the PCN-based NAC as this is a 
| prerequisite for resilient NAC as discussed above.

If PPS works with a hyrachical token bucket policer instead of a 
queuing mechnism, setting link load levels is quite easy. The 
problem with nthat is, that no commercial router supports this 
kind of policing. Further, marking of measurement packets 
should be applied instead of dropping.

| Obviously, I haven't explained the mechanism I had in mind not well 
| enough as "reservations and available bandwidth measurements" sound 
| difficult to you and probably to others. What's behind?
|
| The ingress router asks the egress router for the bandwidth that is 
| still available for a specific border-to-border (b2b) 
| CL-region-aggregate: s simple round-trip signaling evaluates 
| the minimum difference between the configured-admission-rate and the 
| currently used rate by CL traffic on each link on the b2b path. 

How do you get information on configured or actual used rates on 
b2b paths? Do you assume RSVP-TE or the like to be applied? 

| The current CL rate on 
| the link should not be too difficult to obtain because the 
| admission and preemption marking have similar complexity.
| Furthermore, the ingress router holds a table of recently 
| admitted flows 
| for each b2b CL-region aggregate. It adds them after admission and 
| removes them when they terminate or when they are older than 10 s. The 
| latter action can be done whenever the aggregate rate of the recently 
| admitted flows is needed. Such a table is feasible as long as flows 
| declare a rate which is used for the policers. Therefore, it does not 
| significantly increase the complexity of the AC as the ingress routers 
| is an end point for end-to-end signalling (RSVP) anyway. When 
| a new flow 
| requests admission, its declared rate is compared to the available b2b 
| bandwidth minus the aggregate rate of the recently admitted 
| flows. This 
| bandwidth reduction can be further decreased by mechanisms 
| borrowed from 
| experience-based admission control (EBAC), however, I don't like to 
| further explain this at this point to avoid confusion.
|
|Best wishes,
|
|    Michael
|
|-- 
|Dr. Michael Menth, Assistant Professor
|University of Wuerzburg, Institute of Computer Science
|Am Hubland, D-97074 Wuerzburg, Germany, room B206
|phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
|mailto:[email-masked]
|http://www3.informatik.uni-wuerzburg.de/research/ngn
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: Michael Menth <[email-masked]>
Date: Wed, 20 Sep 2006 16:36:31 +0200

Hi Ruediger,

> in at least one commercial backbone network I'm aware of.
Sure, that is no protocol stuff which requires standardization.

> b2b paths? Do you assume RSVP-TE or the like to be applied? 
Well, that's probably a protocol issue that needs to be standardized if 
this mechanism is of interest.
Regards,

    Michael

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 20 Sep 2006 17:12:55 +0200

Hallo Michael,

|> | Obviously, I haven't explained the mechanism I had in mind not well 
|> | enough as "reservations and available bandwidth measurements" sound 
|> | difficult to you and probably to others. What's behind?
|> |
|> | The ingress router asks the egress router for the bandwidth that is 
|> | still available for a specific border-to-border (b2b) 
|> | CL-region-aggregate: s simple round-trip signaling evaluates 
|> | the minimum difference between the configured-admission-rate and the 
|> | currently used rate by CL traffic on each link on the b2b path. 

|> How do you get information on configured or actual used rates on 
|> b2b paths? Do you assume RSVP-TE or the like to be applied? 
|>   

| Well, that's probably a protocol issue that needs to be 
| standardized if this mechanism is of interest.

To me that sounds like tradeoff of between efficiency and complexity.
I prefer a stateless backbone network, just DiffServ. It may not 
provide the most efficient service. But this solution may 
be deployable within a few years and still perform pretty good.

Further improvements should be specified later. So there could 
be a PCN based AC version 1 and later PCN version 2.

Regards,

Rüdiger

---

From: Michael Menth <[email-masked]>
Date: Wed, 20 Sep 2006 17:29:44 +0200

Hi Ruediger,

> be a PCN based AC version 1 and later PCN version 2.
As this mechanism against flash crowd is just an add-on to the rest of 
the architecture and probably with any incompatibilities, this feature 
can be well separated from the main core and postponed to the future if 
it is of interest at all. I fully agree. I just want to suggest it as a 
potential countermeasure against flash crowds in Section 5.5 of the draft
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt

Kind regards,

    Michael