Subject: FW: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 29 Aug 2007 11:23:27 +0200

Bob,

thanks for the explanation. I didn't consider the "race condition" 
resulting from different ingress/egress aggregates competing for 
the same available bandwidth on a link yet. Your point is very good.

I came to conclude that differing link bandwidths wouldn't simplify
measuring QoS resources available or consumed in absolute terms. 
Your last point on dimensionless marking is a good one too.

Regards,

Ruediger 

-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]]
Sent: Wednesday, August 29, 2007 10:55 AM
To: Geib, Rudiger
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PCN] draft-eardley-pcn-architecture-00.txt on-off marking

Ruediger,

I was preparing an answer to both you & Joe yesterday, but the one to
Joe 
needs to be a bit more involved, so below is my response to your point,
and 
I'll get back to Joe next...

Pre-congestion notification is a form of estimating available bandwidth
for 
the Diffserv class - they aren't mutually exclusive. I'll explain using
an 
example of three aggregates crossing a link:

                   a) option | b) option
____________________________|___________________________________________
___
load from         available | percent PCN marking  share of
ingress           capacity  | PCN     threshold    available
                             |         (constant)   capacity
                             |
3.0M __        __ 495k      | 6%      15%          (15%-6%)x3.0M = 270k
        \      /             |
2.0M ---+----+--- 495k      | 6%      15%          (15%-6%)x2.0M = 180k
      __/      \__           |
500k              495k      | 6%      15%          (15%-6%)x500k =  45k
                                                                    ____
                                         Total available capacity = 495k

You get the same answer both ways but neither is meaningful. The
question 
is, which is better:
a) telling all edge nodes 495k is available (even tho no more than one
can 
use any part of it at a time)? or
b) telling all edge nodes they can each send 9% (=15%-6%) more than they

are currently sending (when they are all unlikely to do so at the same
time 
but they might)?

In both cases, no single edge node knows how much extra traffic it can
send 
because it doesn't know how many other nodes might be about to do the
same:
a) each node should not add 495k in case others do too
b) each node will probably think it can add more than its share of 
available capacity, because not all other nodes are likely to in the
next 
round trip time.

In practice there may be anything from 0 to 10,000s of aggregates
crossing 
any specific link, but the aggregation assumption is that a link not 
showing any marking can't be driven into overload by addition of a
single flow.

Imagine now a path between two edge nodes that crosses one link shared
by 2 
aggregates (a possible figure in BT's core) and another shared by 1000 
aggregates (a typical figure across BT's core). How meaningful would it
be 
for the second link to say to 1000 aggregates that 20M is available? Or
for 
the first link to say to both aggregates that 500k is available? How 
meaningful would it be for either link to say there is 1%
pre-congestion? 
In any of these cases, the numbers are fairly meaningless because the
edge 
nodes don't know how many other edge nodes they are up against.

This uncertainty is a design 'feature' of a distributed solution like
PCN - 
because it's hard to know which situation you're in without a
system-wide 
view (and we eventually want system-wide to mean Internet-wide):
- am I the only one asking?
- am I part of a flash crowd?
- am I part of normal flow arrivals and departures?
- what is normal anyway?

So, for admission control, I think the important thing about the marking
is 
its shape wrt load. It should rise gradually then get steeper as the 
reference rate is approached and rapidly saturate at some point (the 
reference rate). Then edge nodes can set their thresholds somewhere
between 
the two, so they trigger admission control close to the reference rate,
but 
sufficiently under the reference rate to give contingency if they happen
to 
be part of a flash crowd.

I also believe it is useful for the marking to be dimensionless (ie a 
fraction rather than meaning a certain rate). Then the system scales
into 
the future as rates increase by orders of magnitude.

Bob

At 08:08 24/08/2007, Geib, Ruediger wrote:
>Lachlan, Bob,
>
>you both seem to agree that ramp marking is the best solution.
>Picking up Lachlan's pretty sound arguments on different thresholds
>for different types of incoming calls - what you describe is
>estimating the available (not consumed) PCN bandwidth rather than
>just a "pre congestion notification", I think.
>If there's a simple solution to realise this idea, PCN should
>investigate it. This could be helpful if there's a new call to be
>admitted and no PCN flow exists between two gateways. The question
>then would be, whether a certain bandwidth is available, rather
>than "any congestion visible".
>
>Regards,
>
>Ruediger
>
>
>|Lachlan wrote:
>|I believe that the marking scheme should carry as much information as
>|possible about the network state, and that thresholding should be done
>|as late as possible (at the decision-making end-points).  The more
>|information the decision-making entity has, better the decisions it
>|can make.
>|
>|If things like thresholding are done where the admission decisions are
>|made, there is also a smoother upgrade path for changes in the
>|admission rules.  For example, an operator may want to apply different
>|thresholds applied to different types of incoming calls.  If routers
>|provide a single threshold, this can't be implemented at a later
>|stage.  Similarly, an operator may want to admit a certain percentage
>|of traffic dependent on the congestion level, rather than admitting
>|all or none.
>
>|Bob wrote:
>|[BB] The problem we were trying to solve with ramp marking was the
>|reverse:
>|we were looking for a marking algo that produced a smooth increase in
>|marking over a wider range of loads. The edge nodes can always turn a
>|smooth rise into a toggle at a specific threshold marking level.

________________________________________________________________________
____
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT
Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
645196 

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