Subject: [PCN] a question on PCN scope

From: "Robert Hancock" <[email-masked]>
Date: Sun, 5 Nov 2006 09:03:14 -0800

Hi,

I've just been reading the problem statement, and there is still one
question about PCN (as a WG) which I am unclear about. I know this has been
discussed on the list but the text which is actually available is still hard
for me to interpret. 

Problem 3 on the charter is

"3. How should these markings (at packet granularity) be converted into 
   admission control and flow pre-emption decisions (at flow granularity)?"

What does 'converted into ... decisions' actually mean? This could
potentially cover a huge range of things to do with network dimensioning and
planning, risk/benefit tradeoffs of admitting when close to capacity,
pre-emption flow selection policies, and so on. To a large extent, these
seem to be orthogonal to the other parts of the PCN story. Indeed, one can
imagine many ways to find out what is going on in the interior of a network
at the aggregate level (tunnel or diffserv aggregation for example), which
are clearly different to points 1 and 2 on the charter, but which would
possibly invoke exactly the same functionality under point 3. It would seem
a bad thing if every aggregation mechanism defined its own algorithms for
CAC/pre-mption of flows within the aggregate.

Does point 3 mean more than "How do we turn individual markings into a CLE
which the egress can then do what it likes with?" If so, what?

cheers,

Robert H.

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

---

From: "Robert Hancock" <[email-masked]>
Date: Sun, 5 Nov 2006 09:04:23 -0800

Hi,

Reading the latest versions of the drafts (especially cl-phb and
cl-architecture) I have a couple of questions about how this all works.
Superficially, I can't tell if these have been discussed on the list up to
now (apologies if they have).

1. So far as I can tell, there are (at least) two smoothing mechanisms in
effect:
- the 1 or 2 marking thresholds in the virtual queue, or (very roughly
equivalently) the bucket size in the token bucket, which apply at the
interior nodes (PINs) and
- the EWMA process which applies at the egress edge node (PEN)

Both these mechanisms have the rough effect that a "short" traffic burst
will have a "small" effect on the CLE. If these mechanisms are parametrised
to operate on different timescales, it would seem that one will have no
effect. If they are parametrised to operate on the same timescale, it would
seem to make the whole system much harder to analyse. (I think I recall
similar questions in the context of RED for TFRC but I can't find the
reference right now.)

Or is the purpose of the EWMA stage purely to turn the sequence of binary
1-0 markings into a real number, over the shortest timescale possible, with
no intention to smooth over time? (In which case, that would be helpful to
clarify in the draft. For example, TEWMA would presumably be no benefit for
this functionality.)

2. My understanding, at least of the virtual queue approach, is that the
overall approach is that for each link there is a regime in which a
proportion 0<p<1 of packets gets marked, where the link is operating near
the CL marking threshold. I don't understand from the description how to
distinguish the following two circumstances:
- one bottleneck link in the network (giving a result of p near 1 from that
link alone)
- a sequence of non-bottleneck links in the network (meaning that eventually
nearly all packets get marked; strictly with the resultant pr given by 1-pr
= (1-p1)(1-p2)...(1-pn).)

There may be some subtlety in the marking algorithm which prevents this
happening, in which case it would be nice to understand it better. Or do the
PINs have to estimate the input CLE and only mark additional packets if
their own congestion level is over that rate? Or am I just totally confused?

cheers,

robert h.