Subject: [PCN] Architecture draft - probing section & general updates.

From: <[email-masked]>
Date: Tue, 16 Oct 2007 18:00:55 +0100

Hi,

There was quite a discussion about the probing section of the
Architecture draft recently, draft-ietf-pcn-architecture-00. This showed
to me that it needed a re-write, which I've attempted. 

One thing that struck me reading the discussion was that there really
seem to be 2 uses of probing. The current draft tries to talk about them
as though they're two aspects of the same thing; in the text below I've
tried instead to talk about them separately - because I think they're
really quite different.

The first uses probing to test the ingress-egress-aggregate, the second
uses probing is to test a particular ECMP path.

The first uses probe pkts addressed to the PCN-egress-node, the second
uses probe pkts addressed to the destination end node [so they follow
the same ECMp path as the data pkts would do]

The first has no problem stopping probe pkts leaking out of the
PCN-domain [because they're addressed to the PCN-egress-node] whilst the
second has to think carefully about this [how the PCN-egress-node can
easily identify pkts, but the ECMP algos are unaffected by the "flag =
probe pkt"]

The first would probably be used by people who envisage probing rarely
being used (most ingress-egress-aggregates always have traffic), the
second is probably favoured by people who would actually probe on every
call admission attempt [esp people who have it in mind to have PCN
operating in parts of network with lower capacity links ie the multiple
flows (aggregation) assumption doesn't hold]. (There are plenty of other
scenarios which I'm not commenting on!)

The first has a less clear benefit to me (it doesn't seem that much
better than the easy alternative - just admit the 'first' flow into an
'empty' ingress-egress-aggregate, and take the chance it causes flows to
be terminated or pkts to be dropped). The second has a clearer benefit
to me, in some scenarios (you test the actual ECMP path the flow would
take.) 

The first probing approach (ie tests the ingress-egress-aggregate) seems
to me quite simple to define, but the second much harder [need to work
out how to stop probes leaking out of PCN-domain and how to flag a probe
to minimise interactions with ECMP]. 

Personally I think that in the short term (say until Christmas) our
objective is to start converging on the router's PCN-marking behaviour
(algorithm & encoding) - so it isn't necessary to talk about the details
of probing at the moment. However, as part of the algorithm discussion
it is relevant to note (as Michael has already pointed out) that
excess-rate-marking algorithm is less suitable than a threshold-marking
algo from a probing perspective (at least you have to send a lot more
probe pkts to get an accurate picture of the pre-congestion level). (of
course it's only one factor when we choose the algo.)

Anyway, here's the proposed revised sub-section 5.5 about probing -
please comment /shout if you don't like it:-

****

Probing functions are optional, and can be used for admission control.  

PCN's admission control, as described so far, is essentially a reactive
mechanism where the PCN-egress-node monitors the pre-congestion level
for traffic from each PCN-ingress-node; if the level rises then it
blocks new flows on that ingress-egress-aggregate. However, it's
possible that an ingress-egress-aggregate carries no traffic, and so the
PCN-egress-node can't make an admission decision using the usual method
described earlier. 

One approach is to be "optimistic" and simply admit the new flow.
However it's possible to envisage a scenario where the traffic levels on
other ingress-egress-aggregates are already so high that they're
blocking new PCN-flows and admitting a new flow onto this 'empty'
ingress-egress-aggregate would add extra traffic onto the link that's
already pre-congested - which may 'tip the balance' so that PCN's flow
termination mechanism is activated or some packets are dropped. This
risk could be lessened by configuring on each link sufficient 'safety
margin' above the PCN-lower-rate.   

An alternative approach is to make PCN a more proactive mechanism. The
PCN-ingress-node explicitly determines, before admitting the prospective
new flow, whether the ingress-egress-aggregate can support it. This can
be seen as a "pessimistic" approach, in contrast to the "optimism" of
the approach above. It involves probing: a PCN-ingress-node generates
and sends probe packets in order to test the pre-congestion level that
the flow would experience. A probe packet is just a dummy data packet,
generated by the PCN-ingress-node and addressed to the PCN-egress-node.
A downside of probing is that it adds delay to the admission control
process. Also note that in the scenario described in the previous
paragraph (where traffic levels on other ingress-egress-aggregates is
already very high), the probe packets may also 'tip the balance'.
However, the risk should be reduced because it should be possible to
send probe packets for a shorter time and at a lower rate than a typical
data flow. 

The situation is more complicated if there is multipath routing (ECMP)
in the PCN-domain. It is then possible for some paths to be
pre-congested whilst other paths within the same
ingress-egress-aggregate aren't pre-congested.

One approach essentially ignores ECMP: as usual, admit or block a new
flow depending on the "measurements of PCN-traffic" on the
ingress-egress-aggregate. This is rather similar to the "optimistic"
approach above. 

An alternative ("pessimistic" or "proactive") approach is to probe the
ECMP path. The PCN-ingress-node generates and sends probe packets (dummy
data) that follow the specific ECMP path that the new flow would do, in
order to test the pre-congestion level along it. An ECMP algorithm
typically examines: the source and destination IP addresses and port
numbers, the protocol ID and the DSCP. Hence these fields must have the
same values in the probe packets as the future data packets would have.
On the other hand, the PCN-egress-node needs to consume the probe
packets to ensure that they don't travel beyond the PCN-domain (eg they
might confuse the destination end node). Hence somehow the
PCN-egress-node has to be able to disambiguate a probe packet from a
data packet, via the characteristic setting of particular bit(s) in the
packet's header or body - but these bit(s) mustn't be used by the
PCN-node's ECMP algorithm. 

The probing functions are:

   o  Make decision that probing is needed. As described above, this is
when the ingress-egress-aggregate or the ECMP path carries no
PCN-traffic. An alternative is always to probe, ie probe before
admitting every PCN-flow.

   o  (if required) Communicate the request that probing is needed - the
PCN-egress-node signals to the PCN-ingress-node that probing is needed

   o  Generate probe traffic - the PCN-ingress-node generates the probe
traffic.  The appropriate number (or rate) of probe packets will depend
on the PCN-marking algorithm; for example an excess-rate-marking
algorithm generates fewer PCN-marks than a threshold-marking algorithm,
and so will need more probe packets.

   o  Forward probe packets - as far as PCN-interior-nodes are
concerned, probe packets must be handled the same as (ordinary data)
PCN-packets, in terms of routing, scheduling and PCN-marking.

   o  Consume probe packets - the PCN-egress-node consumes probe packets
to ensure that they don't travel beyond the PCN-domain.

****

Incidentally, I have edited the draft to include all the comments
/discussion that there's been on the list since Vancouver. I'll add the
above probing section [unless there are cries of unhappiness]. I also
have some comments on paper from bob [will summarise to list where >
typos etc]. So will send revised version out next week or end of this
week.

Best wishes

phil

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 16 Oct 2007 18:48:49 +0100

phil,
 
your text
"Hence somehow the PCN-egress-node has to be able to disambiguate a
probe packet from a data packet, via the characteristic setting of
particular bit(s) in the packet's header or body - but these bit(s)
mustn't be used by the PCN-node's ECMP algorithm."
is nicely written (especially the "somehow"). 
 
Presumably the last phrase should read "but these bit(s) mustn't be used
by any interior PCN-node's ECMP algorithm." And there lies the rub: I
can't see any robust technique that the ingress can use to decide what
bits to set and how to set them, without the specification making
explicit assumptions that go beyond what the ECMP "specifications" say,
and which may not be compatible with filtering capabilities on the
interior and egress nodes. 
 
robert h.

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 16 October 2007 18:01
	To: [email-masked]
	Subject: [PCN] Architecture draft - probing section & general
updates.

	Hi,

	One thing that struck me reading the discussion was that there
really seem to be 2 uses of probing. The current draft tries to talk
about them as though they're two aspects of the same thing; in the text
below I've tried instead to talk about them separately - because I think
they're really quite different.

	The first uses probing to test the ingress-egress-aggregate, the
second uses probing is to test a particular ECMP path.

	The first uses probe pkts addressed to the PCN-egress-node, the
second uses probe pkts addressed to the destination end node [so they
follow the same ECMp path as the data pkts would do]

	The first would probably be used by people who envisage probing
rarely being used (most ingress-egress-aggregates always have traffic),
the second is probably favoured by people who would actually probe on
every call admission attempt [esp people who have it in mind to have PCN
operating in parts of network with lower capacity links ie the multiple
flows (aggregation) assumption doesn't hold]. (There are plenty of other
scenarios which I'm not commenting on!)

	The first has a less clear benefit to me (it doesn't seem that
much better than the easy alternative - just admit the 'first' flow into
an 'empty' ingress-egress-aggregate, and take the chance it causes flows
to be terminated or pkts to be dropped). The second has a clearer
benefit to me, in some scenarios (you test the actual ECMP path the flow
would take.) 

	The first probing approach (ie tests the
ingress-egress-aggregate) seems to me quite simple to define, but the
second much harder [need to work out how to stop probes leaking out of
PCN-domain and how to flag a probe to minimise interactions with ECMP]. 

	Personally I think that in the short term (say until Christmas)
our objective is to start converging on the router's PCN-marking
behaviour (algorithm & encoding) - so it isn't necessary to talk about
the details of probing at the moment. However, as part of the algorithm
discussion it is relevant to note (as Michael has already pointed out)
that excess-rate-marking algorithm is less suitable than a
threshold-marking algo from a probing perspective (at least you have to
send a lot more probe pkts to get an accurate picture of the
pre-congestion level). (of course it's only one factor when we choose
the algo.)

	Anyway, here's the proposed revised sub-section 5.5 about
probing - please comment /shout if you don't like it:-

	****

	Probing functions are optional, and can be used for admission
control.  

	PCN's admission control, as described so far, is essentially a
reactive mechanism where the PCN-egress-node monitors the pre-congestion
level for traffic from each PCN-ingress-node; if the level rises then it
blocks new flows on that ingress-egress-aggregate. However, it's
possible that an ingress-egress-aggregate carries no traffic, and so the
PCN-egress-node can't make an admission decision using the usual method
described earlier. 

	One approach is to be "optimistic" and simply admit the new
flow. However it's possible to envisage a scenario where the traffic
levels on other ingress-egress-aggregates are already so high that
they're blocking new PCN-flows and admitting a new flow onto this
'empty' ingress-egress-aggregate would add extra traffic onto the link
that's already pre-congested - which may 'tip the balance' so that PCN's
flow termination mechanism is activated or some packets are dropped.
This risk could be lessened by configuring on each link sufficient
'safety margin' above the PCN-lower-rate.   

	An alternative approach is to make PCN a more proactive
mechanism. The PCN-ingress-node explicitly determines, before admitting
the prospective new flow, whether the ingress-egress-aggregate can
support it. This can be seen as a "pessimistic" approach, in contrast to
the "optimism" of the approach above. It involves probing: a
PCN-ingress-node generates and sends probe packets in order to test the
pre-congestion level that the flow would experience. A probe packet is
just a dummy data packet, generated by the PCN-ingress-node and
addressed to the PCN-egress-node. A downside of probing is that it adds
delay to the admission control process. Also note that in the scenario
described in the previous paragraph (where traffic levels on other
ingress-egress-aggregates is already very high), the probe packets may
also 'tip the balance'. However, the risk should be reduced because it
should be possible to send probe packets for a shorter time and at a
lower rate than a typical data flow. 

	The situation is more complicated if there is multipath routing
(ECMP) in the PCN-domain. It is then possible for some paths to be
pre-congested whilst other paths within the same
ingress-egress-aggregate aren't pre-congested.

	One approach essentially ignores ECMP: as usual, admit or block
a new flow depending on the "measurements of PCN-traffic" on the
ingress-egress-aggregate. This is rather similar to the "optimistic"
approach above. 

	An alternative ("pessimistic" or "proactive") approach is to
probe the ECMP path. The PCN-ingress-node generates and sends probe
packets (dummy data) that follow the specific ECMP path that the new
flow would do, in order to test the pre-congestion level along it. An
ECMP algorithm typically examines: the source and destination IP
addresses and port numbers, the protocol ID and the DSCP. Hence these
fields must have the same values in the probe packets as the future data
packets would have. On the other hand, the PCN-egress-node needs to
consume the probe packets to ensure that they don't travel beyond the
PCN-domain (eg they might confuse the destination end node). Hence
somehow the PCN-egress-node has to be able to disambiguate a probe
packet from a data packet, via the characteristic setting of particular
bit(s) in the packet's header or body - but these bit(s) mustn't be used
by the PCN-node's ECMP algorithm. 

	   o  Make decision that probing is needed. As described above,
this is when the ingress-egress-aggregate or the ECMP path carries no
PCN-traffic. An alternative is always to probe, ie probe before
admitting every PCN-flow.

	   o  (if required) Communicate the request that probing is
needed - the PCN-egress-node signals to the PCN-ingress-node that
probing is needed

	   o  Generate probe traffic - the PCN-ingress-node generates
the probe traffic.  The appropriate number (or rate) of probe packets
will depend on the PCN-marking algorithm; for example an
excess-rate-marking algorithm generates fewer PCN-marks than a
threshold-marking algorithm, and so will need more probe packets.

	   o  Consume probe packets - the PCN-egress-node consumes probe
packets to ensure that they don't travel beyond the PCN-domain.

	****

	Incidentally, I have edited the draft to include all the
comments /discussion that there's been on the list since Vancouver. I'll
add the above probing section [unless there are cries of unhappiness]. I
also have some comments on paper from bob [will summarise to list where
week.

	Best wishes

	phil

---

From: Michael Menth <[email-masked]>
Date: Tue, 16 Oct 2007 20:52:53 +0200

Hi Phil,

I like your text as it reflects the current ideas about probing. It 
nicely identifies the benefits and also the difficulties (that we were 
always aware of!) of the two different types of probing. My view is to 
first solve the easy tasks and then see whether there is a solution to 
the more challenging objectives. It is good to have this section in the 
architecture draft that the benefits of probing do not get lost on the 
way to a first simple system.

Regards,

Michael

[email-masked] wrote:
> Architecture draft recently, draft-ietf-pcn-architecture-00. This 
> showed to me that it needed a re-write, which I’ve attempted.
>
> seem to be 2 uses of probing. The current draft tries to talk about 
> them as though they’re two aspects of the same thing; in the text 
> below I’ve tried instead to talk about them separately – because I 
> think they’re really quite different.
>
> PCN-domain [because they’re addressed to the PCN-egress-node] whilst 
> the second has to think carefully about this [how the PCN-egress-node 
> can easily identify pkts, but the ECMP algos are unaffected by the 
> “flag = probe pkt”]
>
> second is probably favoured by people who would actually probe on 
> every call admission attempt [esp people who have it in mind to have 
> PCN operating in parts of network with lower capacity links ie the 
> multiple flows (aggregation) assumption doesn’t hold]. (There are 
> plenty of other scenarios which I’m not commenting on!)
>
> The first has a less clear benefit to me (it doesn’t seem that much 
> better than the easy alternative - just admit the ‘first’ flow into an 
> ‘empty’ ingress-egress-aggregate, and take the chance it causes flows 
> benefit to me, in some scenarios (you test the actual ECMP path the 
> flow would take.)
>
> The first probing approach (ie tests the ingress-egress-aggregate) 
> seems to me quite simple to define, but the second much harder [need 
> to work out how to stop probes leaking out of PCN-domain and how to 
> flag a probe to minimise interactions with ECMP].
>
> objective is to start converging on the router’s PCN-marking behaviour 
> (algorithm & encoding) – so it isn’t necessary to talk about the 
> details of probing at the moment. However, as part of the algorithm 
> threshold-marking algo from a probing perspective (at least you have 
> to send a lot more probe pkts to get an accurate picture of the 
> pre-congestion level). (of course it’s only one factor when we choose 
> the algo.)
>
> Anyway, here’s the proposed revised sub-section 5.5 about probing – 
> please comment /shout if you don’t like it:-
>
> ****
>
> PCN’s admission control, as described so far, is essentially a 
> reactive mechanism where the PCN-egress-node monitors the 
> pre-congestion level for traffic from each PCN-ingress-node; if the 
> level rises then it blocks new flows on that ingress-egress-aggregate. 
> However, it’s possible that an ingress-egress-aggregate carries no 
> traffic, and so the PCN-egress-node can’t make an admission decision 
> using the usual method described earlier.
>
> One approach is to be “optimistic” and simply admit the new flow. 
> However it’s possible to envisage a scenario where the traffic levels 
> on other ingress-egress-aggregates are already so high that they’re 
> ingress-egress-aggregate would add extra traffic onto the link that’s 
> already pre-congested – which may ‘tip the balance’ so that PCN’s flow 
> risk could be lessened by configuring on each link sufficient ‘safety 
> margin’ above the PCN-lower-rate.
>
> PCN-ingress-node explicitly determines, before admitting the 
> prospective new flow, whether the ingress-egress-aggregate can support 
> it. This can be seen as a “pessimistic” approach, in contrast to the 
> “optimism” of the approach above. It involves probing: a 
> PCN-ingress-node generates and sends probe packets in order to test 
> the pre-congestion level that the flow would experience. A probe 
> packet is just a dummy data packet, generated by the PCN-ingress-node 
> and addressed to the PCN-egress-node. A downside of probing is that it 
> adds delay to the admission control process. Also note that in the 
> scenario described in the previous paragraph (where traffic levels on 
> other ingress-egress-aggregates is already very high), the probe 
> packets may also ‘tip the balance’. However, the risk should be 
> reduced because it should be possible to send probe packets for a 
> shorter time and at a lower rate than a typical data flow.
>
> ingress-egress-aggregate. This is rather similar to the “optimistic” 
> approach above.
>
> An alternative (“pessimistic” or “proactive”) approach is to probe the 
> ECMP path. The PCN-ingress-node generates and sends probe packets 
> (dummy data) that follow the specific ECMP path that the new flow 
> would do, in order to test the pre-congestion level along it. An ECMP 
> algorithm typically examines: the source and destination IP addresses 
> and port numbers, the protocol ID and the DSCP. Hence these fields 
> must have the same values in the probe packets as the future data 
> consume the probe packets to ensure that they don’t travel beyond the 
> packet from a data packet, via the characteristic setting of 
> particular bit(s) in the packet’s header or body – but these bit(s) 
> mustn’t be used by the PCN-node’s ECMP algorithm.
>
> o (if required) Communicate the request that probing is needed – the 
> algorithm generates fewer PCN-marks than a threshold-marking 
> algorithm, and so will need more probe packets.
>
> o Forward probe packets - as far as PCN-interior-nodes are concerned, 
> probe packets must be handled the same as (ordinary data) PCN-packets, 
> in terms of routing, scheduling and PCN-marking.
>
> /discussion that there’s been on the list since Vancouver. I’ll add 
> the above probing section [unless there are cries of unhappiness]. I 
> also have some comments on paper from bob [will summarise to list 
> where > typos etc]. So will send revised version out next week or end 
> of this week.
>
> Best wishes
>
> phil
>
> ------------------------------------------------------------------------
>

-- 
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: "Anna Charny (acharny)" <[email-masked]>
Date: Tue, 16 Oct 2007 14:55:27 -0400

Hi Robert, Phil,
 
Yes, Robert's is a fair concern to which no obvious solution is in
sight. Different equipment might use different algorithms and might use
different fields for ECMP load-balancing under different circumstances.
IMHO this is a killer argument of why the use of probing for discovering
the state of ECMP paths should not be considered within the scope of PCN
WG.  
 
There remains a question of whether probing can/should be considerd to
probe the path regardless of the ECMP issue.  I see most of its value in
flash crowd situations in combination with low ingress-egress
agregation.  
 
Anna 

From: Hancock, Robert [mailto:[email-masked]] 
Sent: Tuesday, October 16, 2007 1:49 PM
To: [email-masked]; [email-masked]
Subject: RE: [PCN] Architecture draft - probing section & general
updates.

	phil,
	 
	your text
	"Hence somehow the PCN-egress-node has to be able to
disambiguate a probe packet from a data packet, via the characteristic
setting of particular bit(s) in the packet's header or body - but these
bit(s) mustn't be used by the PCN-node's ECMP algorithm."
	is nicely written (especially the "somehow"). 
	 
	Presumably the last phrase should read "but these bit(s) mustn't
be used by any interior PCN-node's ECMP algorithm." And there lies the
rub: I can't see any robust technique that the ingress can use to decide
what bits to set and how to set them, without the specification making
explicit assumptions that go beyond what the ECMP "specifications" say,
and which may not be compatible with filtering capabilities on the
interior and egress nodes. 
	 
	robert h.

		From: [email-masked]
[mailto:[email-masked]] 
		Sent: 16 October 2007 18:01
		To: [email-masked]
		Subject: [PCN] Architecture draft - probing section &
general updates.

		Hi,

		There was quite a discussion about the probing section
of the Architecture draft recently, draft-ietf-pcn-architecture-00. This
showed to me that it needed a re-write, which I've attempted. 

		One thing that struck me reading the discussion was that
there really seem to be 2 uses of probing. The current draft tries to
talk about them as though they're two aspects of the same thing; in the
text below I've tried instead to talk about them separately - because I
think they're really quite different.

		The first uses probing to test the
ingress-egress-aggregate, the second uses probing is to test a
particular ECMP path.

		The first uses probe pkts addressed to the
PCN-egress-node, the second uses probe pkts addressed to the destination
end node [so they follow the same ECMp path as the data pkts would do]

		The first has no problem stopping probe pkts leaking out
of the PCN-domain [because they're addressed to the PCN-egress-node]
whilst the second has to think carefully about this [how the
PCN-egress-node can easily identify pkts, but the ECMP algos are
unaffected by the "flag = probe pkt"]

		The first would probably be used by people who envisage
probing rarely being used (most ingress-egress-aggregates always have
traffic), the second is probably favoured by people who would actually
probe on every call admission attempt [esp people who have it in mind to
have PCN operating in parts of network with lower capacity links ie the
multiple flows (aggregation) assumption doesn't hold]. (There are plenty
of other scenarios which I'm not commenting on!)

		The first has a less clear benefit to me (it doesn't
seem that much better than the easy alternative - just admit the 'first'
flow into an 'empty' ingress-egress-aggregate, and take the chance it
causes flows to be terminated or pkts to be dropped). The second has a
clearer benefit to me, in some scenarios (you test the actual ECMP path
the flow would take.) 

		Personally I think that in the short term (say until
Christmas) our objective is to start converging on the router's
PCN-marking behaviour (algorithm & encoding) - so it isn't necessary to
talk about the details of probing at the moment. However, as part of the
algorithm discussion it is relevant to note (as Michael has already
pointed out) that excess-rate-marking algorithm is less suitable than a
threshold-marking algo from a probing perspective (at least you have to
send a lot more probe pkts to get an accurate picture of the
pre-congestion level). (of course it's only one factor when we choose
the algo.)

		Anyway, here's the proposed revised sub-section 5.5
about probing - please comment /shout if you don't like it:-

		****

		Probing functions are optional, and can be used for
admission control.  

		PCN's admission control, as described so far, is
essentially a reactive mechanism where the PCN-egress-node monitors the
pre-congestion level for traffic from each PCN-ingress-node; if the
level rises then it blocks new flows on that ingress-egress-aggregate.
However, it's possible that an ingress-egress-aggregate carries no
traffic, and so the PCN-egress-node can't make an admission decision
using the usual method described earlier. 

		One approach is to be "optimistic" and simply admit the
new flow. However it's possible to envisage a scenario where the traffic
levels on other ingress-egress-aggregates are already so high that
they're blocking new PCN-flows and admitting a new flow onto this
'empty' ingress-egress-aggregate would add extra traffic onto the link
that's already pre-congested - which may 'tip the balance' so that PCN's
flow termination mechanism is activated or some packets are dropped.
This risk could be lessened by configuring on each link sufficient
'safety margin' above the PCN-lower-rate.   

		The situation is more complicated if there is multipath
routing (ECMP) in the PCN-domain. It is then possible for some paths to
be pre-congested whilst other paths within the same
ingress-egress-aggregate aren't pre-congested.

		One approach essentially ignores ECMP: as usual, admit
or block a new flow depending on the "measurements of PCN-traffic" on
the ingress-egress-aggregate. This is rather similar to the "optimistic"
approach above. 

		An alternative ("pessimistic" or "proactive") approach
is to probe the ECMP path. The PCN-ingress-node generates and sends
probe packets (dummy data) that follow the specific ECMP path that the
new flow would do, in order to test the pre-congestion level along it.
An ECMP algorithm typically examines: the source and destination IP
addresses and port numbers, the protocol ID and the DSCP. Hence these
fields must have the same values in the probe packets as the future data
packets would have. On the other hand, the PCN-egress-node needs to
consume the probe packets to ensure that they don't travel beyond the
PCN-domain (eg they might confuse the destination end node). Hence
somehow the PCN-egress-node has to be able to disambiguate a probe
packet from a data packet, via the characteristic setting of particular
bit(s) in the packet's header or body - but these bit(s) mustn't be used
by the PCN-node's ECMP algorithm. 

		   o  Make decision that probing is needed. As described
above, this is when the ingress-egress-aggregate or the ECMP path
carries no PCN-traffic. An alternative is always to probe, ie probe
before admitting every PCN-flow.

		   o  (if required) Communicate the request that probing
is needed - the PCN-egress-node signals to the PCN-ingress-node that
probing is needed

		   o  Generate probe traffic - the PCN-ingress-node
generates the probe traffic.  The appropriate number (or rate) of probe
packets will depend on the PCN-marking algorithm; for example an
excess-rate-marking algorithm generates fewer PCN-marks than a
threshold-marking algorithm, and so will need more probe packets.

		   o  Forward probe packets - as far as
PCN-interior-nodes are concerned, probe packets must be handled the same
as (ordinary data) PCN-packets, in terms of routing, scheduling and
PCN-marking.

		   o  Consume probe packets - the PCN-egress-node
consumes probe packets to ensure that they don't travel beyond the
PCN-domain.

		****

week.

		Best wishes

		phil

---

From: Lars Eggert <[email-masked]>
Date: Fri, 19 Oct 2007 15:58:26 +0300

> the state of ECMP paths should not be considered within the scope  

Agreed.

> flash crowd situations in combination with low ingress-egress

I note that scenarios with low aggregation aren't in scope of the  
charter:

   The initial scope of the PCN WG is restricted by the following
   assumptions:
...
   (C) the number of flows across any potential aggregation bottleneck
   is sufficiently large for stateless, statistical mechanisms
   to be effective

Lars

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 19 Oct 2007 09:23:02 -0400

Hi Lars,

On the low agfgregation point, please see below: 

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Friday, October 19, 2007 8:58 AM
> To: Anna Charny (acharny)
> Cc: Hancock, Robert; [email-masked]; [email-masked]
> Subject: Re: [PCN] Architecture draft - probing section & 
> general updates.
> 
> > sight. Different equipment might use different algorithms and might 
> > use different fields for ECMP load-balancing under different 
> > circumstances.
> > IMHO this is a killer argument of why the use of probing for 
> > discovering the state of ECMP paths should not be considered within 
> > the scope of PCN WG.
> 
> Agreed.
> 
> > probe the path regardless of the ECMP issue.  I see most of 
> its value 
> > in flash crowd situations in combination with low ingress-egress 
> > agregation.
> 

Actually,  I did not mean low aggregation *at the bottleneck*, which is
what the charter seems to restrict.  Rather I meant the case when the
bottleneck has high aggregation, but traffic on that bottleneck comes
from a large number of ingress-egress pairs, each having very low
aggregation levels.  I believe technically the charter does put any
explicit restrictions on the scope for ingress-egress aggregation. 

Perhaps the WG should consider whether it is reasonable to impose
restrictions on the *ingress-egress* aggregation levels as well.  An
argument can be made that in practice a large number of ingress-egress
pairs may only have a few flows, even when the bottleneck aggregations
are large. 

The decision on whether low ingress-egress aggregation level is in scope
seems to be important for choosing among the various approaches proposed
to the WG, as some of them are substantially more sensitive to the low
ingress-egress aggregations than others (e.g. single marking does not
perform well at very low levels of aggregation, as we showed at the last
meeting).  

Perhaps an explicit discussion on the assumptions regarding the expected
levels of ingress-egress aggregations is needed on the list? 

Towards that discussion, my personal view is that in the long range
ignoring low levels of ingress-egress aggregation levels will severely
limit the viability/usefulness of the technology.  However, perhaps as
an initial step it would be OK to assume moderate to high aggregation
levels, as long as a clear path is visible on how to address low
aggregations in the future within the scope of defined behaviors.  But I
think it is important to have a clear consensus on this point. 

Anna

---

From: Lars Eggert <[email-masked]>
Date: Fri, 19 Oct 2007 17:18:30 +0300

Hi,

> explicit restrictions on the scope for ingress-egress aggregation.

thanks for teasing these two issues apart. I had been under the  
assumption that one would come with the other, but you're correct  
that they can be unrelated.

It was the intent of the charter to initially restrict PCN to  
scenarios with significant levels of multiplexing, so that simple,  
statistical measures are effective. So I'd argue that although the  
current charter text isn't explicit about ingress-egress-pair  
aggregation levels, it was written under the assumption that they'd  
be significant.

That said, I do agree with you that it would be good to come to an  
explicit agreement on this within the WG.

Agreed.

I've stated my reasons for wanting PCN to focus on high-aggregation  
scenarios in previous emails. Let me add one additional argument:

I see PCN as being complementary to traditional, hop-by-hop signaled  
QoS reservation mechanisms. These mechanisms already cover scenarios  
with low-aggregation levels well. They tend to break down for high  
traffic volumes, which is exactly where I'd expect PCN to be the most  
attractive. In other words, because using PCN in low-aggregation  
scenarios means that probing is required, with the already-discussed  
complexities, delays and overheads, traditional QoS mechanisms become  
attractive. Yes, signaled QoS mechanisms are more complex than PCN,  
but not much more complex than PCN with a fully-worked out probing  
mechanism. Additionally, signaled QoS setup results in a guarantee  
that a flow can be sustained, while even with probing, PCN will only  
results in an estimate on whether a flow can be sustained.

Lars

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 19 Oct 2007 10:49:22 -0400

Hi Lars,

I have a question and a point:

1) Question:  

You say:

> I see PCN as being complementary to traditional, hop-by-hop 
> signaled QoS reservation mechanisms. These mechanisms already 
> cover scenarios with low-aggregation levels well. They tend 
> to break down for high traffic volumes, which is exactly 
> where I'd expect PCN to be the most attractive. 
 
Why do you say that aggregate hop-by-hop reservation mechanisms tend to
break at high traffic volumes? 

2) Point:

You say: 

>In other 
> words, because using PCN in low-aggregation scenarios means 
> that probing is required, with the already-discussed 
> complexities, 

I would ask the question in two parts:

   - is it important for a mechanism to work well when there is a small
number (but greater than 1) of ingress-egress flows for a large number
of ingress-egress pairs.  Note that this is not necessarily a question
about probing, but that of performance of an algorithm on low
ingress-egress aggregation levels (this is because once the first flow
is accepted, it provides the necessary state for admission of future
flows, and does it reasonably well at least for some of the proposed
algorithms).

   - should the WG consider the case when expected number of flows on
very large number of ingress-egress aggregates sharing a bottleneck has
on the order of *one* flow.  Note that this is the case when probing
might be needed.

Anna  

> Sent: Friday, October 19, 2007 10:19 AM
> > Actually,  I did not mean low aggregation *at the 
> bottleneck*, which 
> > is what the charter seems to restrict.  Rather I meant the 
> case when 
> > the bottleneck has high aggregation, but traffic on that bottleneck 
> > comes from a large number of ingress-egress pairs, each having very 
> > low aggregation levels.  I believe technically the charter does put 
> > any explicit restrictions on the scope for ingress-egress 
> aggregation.
> 
> thanks for teasing these two issues apart. I had been under 
> the assumption that one would come with the other, but you're 
> correct that they can be unrelated.
> 
> scenarios with significant levels of multiplexing, so that 
> simple, statistical measures are effective. So I'd argue that 
> although the current charter text isn't explicit about 
> ingress-egress-pair aggregation levels, it was written under 
> the assumption that they'd be significant.
> 
> That said, I do agree with you that it would be good to come 
> to an explicit agreement on this within the WG.
> 
> > The decision on whether low ingress-egress aggregation level is in 
> > scope seems to be important for choosing among the various 
> approaches 
> > proposed to the WG, as some of them are substantially more 
> sensitive 
> > to the low ingress-egress aggregations than others (e.g. single 
> > marking does not perform well at very low levels of 
> aggregation, as we 
> > showed at the last meeting).
> >
> > Perhaps an explicit discussion on the assumptions regarding the 
> > expected levels of ingress-egress aggregations is needed on 
> the list?
> >
> I've stated my reasons for wanting PCN to focus on 
> high-aggregation scenarios in previous emails. Let me add one 
> additional argument:
> 
> I see PCN as being complementary to traditional, hop-by-hop 
> signaled QoS reservation mechanisms. These mechanisms already 
> cover scenarios with low-aggregation levels well. They tend 
> to break down for high traffic volumes, which is exactly 
> where I'd expect PCN to be the most attractive. In other 
> words, because using PCN in low-aggregation scenarios means 
> that probing is required, with the already-discussed 
> complexities, delays and overheads, traditional QoS 
> mechanisms become attractive. Yes, signaled QoS mechanisms 
> are more complex than PCN, but not much more complex than PCN 
> with a fully-worked out probing mechanism. Additionally, 
> signaled QoS setup results in a guarantee that a flow can be 
> sustained, while even with probing, PCN will only results in 
> an estimate on whether a flow can be sustained.
> 
> Lars

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 23 Oct 2007 10:19:05 +0200

Phil,

I appreciate that probing is optional. I understand that to mean that
standardisation allows to operate PCN within a domain without having to
support any probing functionality.

There may be operational conditions, when probing makes sense. This may
be the case, if the number of multiplexed flows is at the lower bound of
the range where statistical multiplexing can be applied on any link and
the number of possible ingress to egress relations passing this link is
big enough to lead to (pre-)congestion by admission of a single flow
with a reasonable probability. I don't want to stop people from working
on this issue, but I'd favour PCN to finish standards for an operational
environment where the probability of a single admitted flow causing
congestion on a link is extremly low. 

Regards,

Rudiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 23 Oct 2007 10:26:08 +0200

Anna,

could you re-write your point? I don't get the sense completely.

Thanks,

Rudiger

|   - should the WG consider the case when expected number of flows on
|very large number of ingress-egress aggregates sharing a bottleneck has
|on the order of *one* flow.  Note that this is the case when probing
|might be needed.

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Tue, 23 Oct 2007 09:38:15 -0400

Hi Ruediger,

I meant roughly the following. Suppose many ingress-egress aggregates
have on the average 1 flow.  If you have just one flow per
ingress-egress aggregate, when this flow arrives and is the only one
active in its ingress-egress pair, and if no 
probing of any kind is used, then effectively there is no admission
control for this aggregate.  If many such aggregates share a bottleneck,
then effectively all these ingress-egress aggregates have to be admitted
regardless of the state of the bottleneck.  In the extreme, if all
ingress-egress aggregates sharing a bottleneck consist of one flow, then
this bottleneck effectively does not have any admission control.  In
such situations probing might be quite useful, as it will enable
admission control. 

Of course one does not have to require that *all* ingress-egress
aggregates sharing a bottleneck have just one flow to have a similar
problem - just enough of them on the average to take a substantial share
of the bottleneck bandwidth.

Does it make sense?
Anna 

> From: Geib, Ruediger [mailto:[email-masked]] 
> Sent: Tuesday, October 23, 2007 4:26 AM
> Cc: [email-masked]
> Subject: RE: [PCN] Architecture draft - probing section & 
> general updates.
> 
> Anna,
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 23 Oct 2007 16:18:52 +0200

Hi Anna,

thanks, I understand your explanation. 

Regards,

Rudiger

|-----Original Message-----
|From: Anna Charny (acharny) [mailto:[email-masked]]
|Sent: Tuesday, October 23, 2007 3:38 PM
|To: Geib, Rudiger
|Cc: [email-masked]
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|
|Hi Ruediger,
|
|I meant roughly the following. Suppose many ingress-egress aggregates
|have on the average 1 flow.  If you have just one flow per
|ingress-egress aggregate, when this flow arrives and is the only one
|active in its ingress-egress pair, and if no probing of any kind is 
|used, then effectively there is no admission control for this 
|aggregate.  If many such aggregates share a bottleneck, then 
|effectively all these ingress-egress aggregates have to be admitted
|regardless of the state of the bottleneck.  In the extreme, if all
|ingress-egress aggregates sharing a bottleneck consist of one flow, 
|then this bottleneck effectively does not have any admission control.
|In such situations probing might be quite useful, as it will enable
|admission control. 
|
|Of course one does not have to require that *all* ingress-egress
|aggregates sharing a bottleneck have just one flow to have a similar
|problem - just enough of them on the average to take a substantial 
|share of the bottleneck bandwidth.
|
|Does it make sense?
|Anna 
|
|> -----Original Message-----
|> From: Geib, Ruediger [mailto:[email-masked]] 
|> Sent: Tuesday, October 23, 2007 4:26 AM
|> To: Anna Charny (acharny)
|> Cc: [email-masked]
|> Subject: RE: [PCN] Architecture draft - probing section & 
|> general updates.
|> 
|> Anna,
|> 
|> could you re-write your point? I don't get the sense completely.
|> 
|> Thanks,
|> 
|> Rudiger
|> 
|> 
|> |   - should the WG consider the case when expected number of 
|> flows on 
|> |very large number of ingress-egress aggregates sharing a 
|> bottleneck has 
|> |on the order of *one* flow.  Note that this is the case 
|when probing 
|> |might be needed.
|> 
|

---

From: Lars Eggert <[email-masked]>
Date: Tue, 23 Oct 2007 17:17:19 +0300

> such situations probing might be quite useful, as it will enable

To me, this looks like an awfully unlikely corner case. Do we really  
need to spend effort to make sure admission control can happen in  
this case? Can't we simply leave it to the flow termination procedure  
to kick in and remove the excess load, if such a case should really  
occur?

Lars

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 23 Oct 2007 12:21:43 -0400

Ruediger, the issue is not addition of one more flow into the link that
is experiencing (pre-)congestion level for admission but potentially
hundreds of new ingress-egress aggregates that have not been established
passing through the link. 

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: October 23, 2007 4:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [PCN] Architecture draft - probing section & general
updates.

Phil,

Regards,

Rudiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 24 Oct 2007 09:03:35 +0200

Joe,

my perception is, that probing may be useful, once there is 
pre-congestion. In a situation without a single admitted 
flow between an ingress and an egress, if neither ingress 
node nor egress node have any indication of pre-congestion 
on any of the links crossed by the PCN flows passing through 
them, there's with high probability no need to probe, 
I'd assume. I don't do simulations and would like to invite
those simulating to come up with cases where this assumption 
is wrong.

I'd further propose to collect information from providers 
on the probability of the event you describe. 

Regards, 

Rudiger

|-----Original Message-----
|From: Jozef Babiarz [mailto:[email-masked]]
|Sent: Tuesday, October 23, 2007 6:22 PM
|To: Geib, Rudiger; [email-masked]
|Cc: [email-masked]
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|
|Ruediger, the issue is not addition of one more flow into the link that
|is experiencing (pre-)congestion level for admission but potentially
|hundreds of new ingress-egress aggregates that have not been 
|established
|passing through the link. 
|
|Regards, Joe
|email:[email-masked]
|Telephone:613-763-6098
|
|-----Original Message-----
|From: Geib, Ruediger [mailto:[email-masked]] 
|Sent: October 23, 2007 4:19 AM
|To: [email-masked]
|Cc: [email-masked]
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|Phil,
|
|I appreciate that probing is optional. I understand that to mean that
|standardisation allows to operate PCN within a domain without having to
|support any probing functionality.
|
|There may be operational conditions, when probing makes sense. This may
|be the case, if the number of multiplexed flows is at the 
|lower bound of
|the range where statistical multiplexing can be applied on any link and
|the number of possible ingress to egress relations passing this link is
|big enough to lead to (pre-)congestion by admission of a single flow
|with a reasonable probability. I don't want to stop people from working
|on this issue, but I'd favour PCN to finish standards for an 
|operational
|environment where the probability of a single admitted flow causing
|congestion on a link is extremly low. 
|
|Regards,
|
|Rudiger
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Wed, 24 Oct 2007 09:54:05 -0400

Hi all,

I think it boils down to a set of questions below.  If anyone has any
direct data regarding real-time traffic from today's Diffserv networks
(or any futuire projections) that can help answer those questions, itr
would help resolve the probing discussion.

1) is it a common occurrence in todays Diffserv networks (say using EF
to support real-time traffic) that a large number of ingress-egress EF
aggregates have just 1-2 flows?  [I do not have direct data but from
many incidental pieces of information I think the answer may be yes]

2) Is it reasonable to assume that when video becomes widespread, many
ingress-egress aggregates might have just 1 video flow?  [I do not see
why this cannot be the case]

3) Even if many ingress-egress aggregates are small, is it a common
occurrence that on a bottleneck link inside the network a large portion
of the bottleneck bandwidth is taken by those small ingress-egress
aggregates? 
[It seems a more expected case is when the bottleneck is shared by large
and small aggregates, and the large aggregates take a fair amount of
bandwidth. It this case, under "normal circumstances" when the demand on
the bottleneck does not drastically exceed the configured admission
rate, admission control will likely resolve the pre-congestion at the
expence of the large aggregates.]

4) Are there realistic circumstances (flash crowds or massive failures
lasting for some time?) when the load on the bottleneck of small
aggregates alone might cause substantial overload?  (and if so, should
we attempt to address these cases for admission or just rely on
termination?

Anna 

> Sent: Wednesday, October 24, 2007 3:04 AM
> To: [email-masked]
> Cc: [email-masked]
> pre-congestion. In a situation without a single admitted flow 
> between an ingress and an egress, if neither ingress node nor 
> egress node have any indication of pre-congestion on any of 
> the links crossed by the PCN flows passing through them, 
> there's with high probability no need to probe, I'd assume. I 
> don't do simulations and would like to invite those 
> simulating to come up with cases where this assumption is wrong.
> 
> I'd further propose to collect information from providers on 
> the probability of the event you describe. 
> 
> Regards, 
> 
> Rudiger
> 
> |established passing through the link.
> |
> |Regards, Joe
> lower bound 
> |of the range where statistical multiplexing can be applied 
> on any link 
> |and the number of possible ingress to egress relations passing this 
> |link is big enough to lead to (pre-)congestion by admission 
> of a single 
> |flow with a reasonable probability. I don't want to stop people from 
> |working on this issue, but I'd favour PCN to finish standards for an 
> |operational environment where the probability of a single 
> admitted flow 
> |causing congestion on a link is extremly low.
> |
> |Regards,
> |
> |Rudiger
> |
> |

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 24 Oct 2007 16:41:20 +0200

Hi Anna,

one more remark on your question 4) would be, that Deutsche Telekom 
- to the extent I'm aware of it - does not plan her network 
to provide QoS also during massive failures or flash crowds. To 
the best of my knowledge, also consumer organisations rank our 
IP network as the best or at least one of the best in Germany. 
It is dimensioned to cope with probable failures and forseeable 
traffic developments. I doubt that any carrier acting in a highly 
competitive market, possibly regulated in some parts, intends to 
invest heavily into his network to provide QoS also under very 
exceptional operational conditions. Especially, if a solution 
working under normal operational conditions was significantly 
cheaper or faster and easier to deploy.

Regards,

Rudiger

|-----Original Message-----
|From: Anna Charny (acharny) [mailto:[email-masked]]
|Sent: Wednesday, October 24, 2007 3:54 PM
|To: Geib, Rudiger; [email-masked]
|Cc: [email-masked]
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|
|Hi all,
|
|I think it boils down to a set of questions below.  If anyone has any
|direct data regarding real-time traffic from today's Diffserv networks
|(or any futuire projections) that can help answer those questions, itr
|would help resolve the probing discussion.
|
|1) is it a common occurrence in todays Diffserv networks (say using EF
|to support real-time traffic) that a large number of ingress-egress EF
|aggregates have just 1-2 flows?  [I do not have direct data but from
|many incidental pieces of information I think the answer may be yes]
|
|2) Is it reasonable to assume that when video becomes widespread, many
|ingress-egress aggregates might have just 1 video flow?  [I do not see
|why this cannot be the case]
|
|3) Even if many ingress-egress aggregates are small, is it a common
|occurrence that on a bottleneck link inside the network a large portion
|of the bottleneck bandwidth is taken by those small ingress-egress
|aggregates? 
|[It seems a more expected case is when the bottleneck is 
|shared by large
|and small aggregates, and the large aggregates take a fair amount of
|bandwidth. It this case, under "normal circumstances" when the 
|demand on
|the bottleneck does not drastically exceed the configured admission
|rate, admission control will likely resolve the pre-congestion at the
|expence of the large aggregates.]
|
|4) Are there realistic circumstances (flash crowds or massive failures
|lasting for some time?) when the load on the bottleneck of small
|aggregates alone might cause substantial overload?  (and if so, should
|we attempt to address these cases for admission or just rely on
|termination?
|
|Anna 
|
| 
|
|> -----Original Message-----
|> From: Geib, Ruediger [mailto:[email-masked]] 
|> Sent: Wednesday, October 24, 2007 3:04 AM
|> To: [email-masked]
|> Cc: [email-masked]
|> Subject: RE: [PCN] Architecture draft - probing section & 
|> general updates.
|> 
|> Joe,
|> 
|> my perception is, that probing may be useful, once there is 
|> pre-congestion. In a situation without a single admitted flow 
|> between an ingress and an egress, if neither ingress node nor 
|> egress node have any indication of pre-congestion on any of 
|> the links crossed by the PCN flows passing through them, 
|> there's with high probability no need to probe, I'd assume. I 
|> don't do simulations and would like to invite those 
|> simulating to come up with cases where this assumption is wrong.
|> 
|> I'd further propose to collect information from providers on 
|> the probability of the event you describe. 
|> 
|> Regards, 
|> 
|> Rudiger
|> 
|> |-----Original Message-----
|> |From: Jozef Babiarz [mailto:[email-masked]]
|> |Sent: Tuesday, October 23, 2007 6:22 PM
|> |To: Geib, Rudiger; [email-masked]
|> |Cc: [email-masked]
|> |Subject: RE: [PCN] Architecture draft - probing section & general 
|> |updates.
|> |
|> |
|> |Ruediger, the issue is not addition of one more flow into 
|> the link that 
|> |is experiencing (pre-)congestion level for admission but 
|potentially 
|> |hundreds of new ingress-egress aggregates that have not been 
|> |established passing through the link.
|> |
|> |Regards, Joe
|> |email:[email-masked]
|> |Telephone:613-763-6098
|> |
|> |-----Original Message-----
|> |From: Geib, Ruediger [mailto:[email-masked]]
|> |Sent: October 23, 2007 4:19 AM
|> |To: [email-masked]
|> |Cc: [email-masked]
|> |Subject: RE: [PCN] Architecture draft - probing section & general 
|> |updates.
|> |
|> |Phil,
|> |
|> |I appreciate that probing is optional. I understand that to 
|> mean that 
|> |standardisation allows to operate PCN within a domain 
|> without having to 
|> |support any probing functionality.
|> |
|> |There may be operational conditions, when probing makes 
|> sense. This may 
|> |be the case, if the number of multiplexed flows is at the 
|> lower bound 
|> |of the range where statistical multiplexing can be applied 
|> on any link 
|> |and the number of possible ingress to egress relations passing this 
|> |link is big enough to lead to (pre-)congestion by admission 
|> of a single 
|> |flow with a reasonable probability. I don't want to stop 
|people from 
|> |working on this issue, but I'd favour PCN to finish 
|standards for an 
|> |operational environment where the probability of a single 
|> admitted flow 
|> |causing congestion on a link is extremly low.
|> |
|> |Regards,
|> |
|> |Rudiger
|> |
|> |
|> |_______________________________________________
|> |PCN mailing list
|> [email-masked]
|> |https://www1.ietf.org/mailman/listinfo/pcn
|> |
|> 
|> 
|> _______________________________________________
|> PCN mailing list
|> [email-masked]
|> https://www1.ietf.org/mailman/listinfo/pcn
|> 
|

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Wed, 24 Oct 2007 11:38:57 -0400

Hi Ruediger,

Thank you - that is very important information.  But may I ask why,
under these circumstances, one would want to use PCN at all?  PCN seems
to have the benefit of working in cases when the network is NOT well
provisioned for any reason (e.g. under the set of failures that are not
provisioned, or when traffic martix differs from the one "predicted" for
dimentioning?  So what is the motivation to go beyond the current
(PCN-free) environment, if we define away those
"not-so-well-dimentioned" circumstances as  being of no interest?

Thank you,
Anna 

> Sent: Wednesday, October 24, 2007 10:41 AM
> to provide QoS also during massive failures or flash crowds. 
> To the best of my knowledge, also consumer organisations rank 
> our IP network as the best or at least one of the best in Germany. 
> It is dimensioned to cope with probable failures and 
> forseeable traffic developments. I doubt that any carrier 
> acting in a highly competitive market, possibly regulated in 
> some parts, intends to invest heavily into his network to 
> provide QoS also under very exceptional operational 
> conditions. Especially, if a solution working under normal 
> operational conditions was significantly cheaper or faster 
> and easier to deploy.
> 
> Regards,
> 
> Rudiger
> 
> |[It seems a more expected case is when the bottleneck is shared by 
> |large and small aggregates, and the large aggregates take a 
> fair amount 
> |of bandwidth. It this case, under "normal circumstances" when the 
> |demand on the bottleneck does not drastically exceed the configured 
> |admission rate, admission control will likely resolve the 
> |pre-congestion at the expence of the large aggregates.]
> |
> |> Subject: RE: [PCN] Architecture draft - probing section & general 
> |> updates.
> |> 
> |> Joe,
> |> 
> |> pre-congestion. In a situation without a single admitted 
> flow between 
> |> an ingress and an egress, if neither ingress node nor egress node 
> |> have any indication of pre-congestion on any of the links 
> crossed by 
> |> the PCN flows passing through them, there's with high 
> probability no 
> |> need to probe, I'd assume. I don't do simulations and 
> would like to 
> |> invite those simulating to come up with cases where this 
> assumption 
> |> is wrong.
> |> 
> |> I'd further propose to collect information from providers on the 
> |> probability of the event you describe.
> |> 
> |> Regards,
> |> 
> |> Rudiger
> |>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 24 Oct 2007 12:14:21 -0400

Ruediger, 
I'm thinking of a scenario that many enterprises face today. Large multi
location enterprises use multiple WAN links or VPS to interconnect their
locations. PCN is run inside the enterprise network including WAN links
which maybe tunneled across the carrier network. Network Access Control
with PCN admission control is done at the enterprise access edge nodes.
New flows can be routed to any egress access edge node and some flows
will (between different locations) be routed over one of the WAN links
which are normally bandwidth constrained. There is a high probability
that many access nodes will only have one flow between each other as
there are a large number of them.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: October 24, 2007 3:04 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: RE: [PCN] Architecture draft - probing section & general
updates.

Joe,

Regards, 

Rudiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 25 Oct 2007 10:57:35 +0200

Hi Anna,

using PCN (hopefully) allows to engineer a network to stay below a 
certain "PCN flow block ratio" and make sure by stopping 
admission, that even during times of likely network distortions 
(like single link/router failures) the QoS of admitted PCN 
flows remains as guaranteed by an SLA.

Briefly, it is trading flow blocking for a better performance 
of admitted flows under most common operational conditions.

Please note that Telekom's backbone network is dimensionsed 
with redundant capacity. It further fully supports DiffServ.

Regards,

Rudiger

|-----Original Message-----
|From: Anna Charny (acharny) [mailto:[email-masked]]
|Sent: Wednesday, October 24, 2007 5:39 PM
|To: Geib, Rudiger
|Cc: [email-masked]
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|
|Hi Ruediger,
|
|Thank you - that is very important information.  But may I ask why,
|under these circumstances, one would want to use PCN at all?  PCN seems
|to have the benefit of working in cases when the network is NOT well
|provisioned for any reason (e.g. under the set of failures that are not
|provisioned, or when traffic martix differs from the one 
|"predicted" for
|dimentioning?  So what is the motivation to go beyond the current
|(PCN-free) environment, if we define away those
|"not-so-well-dimentioned" circumstances as  being of no interest?
|
|Thank you,
|Anna 
|
|> -----Original Message-----
|> From: Geib, Ruediger [mailto:[email-masked]] 
|> Sent: Wednesday, October 24, 2007 10:41 AM
|> To: Anna Charny (acharny)
|> Cc: [email-masked]
|> Subject: RE: [PCN] Architecture draft - probing section & 
|> general updates.
|> 
|> Hi Anna,
|> 
|> one more remark on your question 4) would be, that Deutsche Telekom
|> - to the extent I'm aware of it - does not plan her network 
|> to provide QoS also during massive failures or flash crowds. 
|> To the best of my knowledge, also consumer organisations rank 
|> our IP network as the best or at least one of the best in Germany. 
|> It is dimensioned to cope with probable failures and 
|> forseeable traffic developments. I doubt that any carrier 
|> acting in a highly competitive market, possibly regulated in 
|> some parts, intends to invest heavily into his network to 
|> provide QoS also under very exceptional operational 
|> conditions. Especially, if a solution working under normal 
|> operational conditions was significantly cheaper or faster 
|> and easier to deploy.
|> 
|> Regards,
|> 
|> Rudiger
|> 
|> |-----Original Message-----
|> |From: Anna Charny (acharny) [mailto:[email-masked]]
|> |Sent: Wednesday, October 24, 2007 3:54 PM
|> |To: Geib, Rudiger; [email-masked]
|> |Cc: [email-masked]
|> |Subject: RE: [PCN] Architecture draft - probing section & general 
|> |updates.
|> |
|> |
|> |Hi all,
|> |
|> |I think it boils down to a set of questions below.  If 
|> anyone has any 
|> |direct data regarding real-time traffic from today's 
|> Diffserv networks 
|> |(or any futuire projections) that can help answer those 
|> questions, itr 
|> |would help resolve the probing discussion.
|> |
|> |1) is it a common occurrence in todays Diffserv networks 
|> (say using EF 
|> |to support real-time traffic) that a large number of 
|> ingress-egress EF 
|> |aggregates have just 1-2 flows?  [I do not have direct data 
|but from 
|> |many incidental pieces of information I think the answer may be yes]
|> |
|> |2) Is it reasonable to assume that when video becomes 
|> widespread, many 
|> |ingress-egress aggregates might have just 1 video flow?  [I 
|> do not see 
|> |why this cannot be the case]
|> |
|> |3) Even if many ingress-egress aggregates are small, is it a common 
|> |occurrence that on a bottleneck link inside the network a 
|> large portion 
|> |of the bottleneck bandwidth is taken by those small ingress-egress 
|> |aggregates?
|> |[It seems a more expected case is when the bottleneck is shared by 
|> |large and small aggregates, and the large aggregates take a 
|> fair amount 
|> |of bandwidth. It this case, under "normal circumstances" when the 
|> |demand on the bottleneck does not drastically exceed the configured 
|> |admission rate, admission control will likely resolve the 
|> |pre-congestion at the expence of the large aggregates.]
|> |
|> |4) Are there realistic circumstances (flash crowds or 
|> massive failures 
|> |lasting for some time?) when the load on the bottleneck of small 
|> |aggregates alone might cause substantial overload?  (and if 
|> so, should 
|> |we attempt to address these cases for admission or just rely on 
|> |termination?
|> |
|> |Anna
|> |
|> | 
|> |
|> |> -----Original Message-----
|> |> From: Geib, Ruediger [mailto:[email-masked]]
|> |> Sent: Wednesday, October 24, 2007 3:04 AM
|> |> To: [email-masked]
|> |> Cc: [email-masked]
|> |> Subject: RE: [PCN] Architecture draft - probing section & general 
|> |> updates.
|> |> 
|> |> Joe,
|> |> 
|> |> my perception is, that probing may be useful, once there is 
|> |> pre-congestion. In a situation without a single admitted 
|> flow between 
|> |> an ingress and an egress, if neither ingress node nor egress node 
|> |> have any indication of pre-congestion on any of the links 
|> crossed by 
|> |> the PCN flows passing through them, there's with high 
|> probability no 
|> |> need to probe, I'd assume. I don't do simulations and 
|> would like to 
|> |> invite those simulating to come up with cases where this 
|> assumption 
|> |> is wrong.
|> |> 
|> |> I'd further propose to collect information from providers on the 
|> |> probability of the event you describe.
|> |> 
|> |> Regards,
|> |> 
|> |> Rudiger
|> |> 
|> |> |-----Original Message-----
|> |> |From: Jozef Babiarz [mailto:[email-masked]]
|> |> |Sent: Tuesday, October 23, 2007 6:22 PM
|> |> |To: Geib, Rudiger; [email-masked]
|> |> |Cc: [email-masked]
|> |> |Subject: RE: [PCN] Architecture draft - probing section 
|& general 
|> |> |updates.
|> |> |
|> |> |
|> |> |Ruediger, the issue is not addition of one more flow into
|> |> the link that
|> |> |is experiencing (pre-)congestion level for admission but
|> |potentially
|> |> |hundreds of new ingress-egress aggregates that have not been 
|> |> |established passing through the link.
|> |> |
|> |> |Regards, Joe
|> |> |email:[email-masked]
|> |> |Telephone:613-763-6098
|> |> |
|> |> |-----Original Message-----
|> |> |From: Geib, Ruediger [mailto:[email-masked]]
|> |> |Sent: October 23, 2007 4:19 AM
|> |> |To: [email-masked]
|> |> |Cc: [email-masked]
|> |> |Subject: RE: [PCN] Architecture draft - probing section 
|& general 
|> |> |updates.
|> |> |
|> |> |Phil,
|> |> |
|> |> |I appreciate that probing is optional. I understand that to
|> |> mean that
|> |> |standardisation allows to operate PCN within a domain
|> |> without having to
|> |> |support any probing functionality.
|> |> |
|> |> |There may be operational conditions, when probing makes
|> |> sense. This may
|> |> |be the case, if the number of multiplexed flows is at the
|> |> lower bound
|> |> |of the range where statistical multiplexing can be applied
|> |> on any link
|> |> |and the number of possible ingress to egress relations 
|> passing this 
|> |> |link is big enough to lead to (pre-)congestion by admission
|> |> of a single
|> |> |flow with a reasonable probability. I don't want to stop
|> |people from
|> |> |working on this issue, but I'd favour PCN to finish
|> |standards for an
|> |> |operational environment where the probability of a single
|> |> admitted flow
|> |> |causing congestion on a link is extremly low.
|> |> |
|> |> |Regards,
|> |> |
|> |> |Rudiger
|> |> |
|> |> |
|> |> |_______________________________________________
|> |> |PCN mailing list
|> |> [email-masked]
|> |> |https://www1.ietf.org/mailman/listinfo/pcn
|> |> |
|> |> 
|> |> 
|> |> _______________________________________________
|> |> PCN mailing list
|> |> [email-masked]
|> |> https://www1.ietf.org/mailman/listinfo/pcn
|> |> 
|> |
|> 
|

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 25 Oct 2007 11:30:05 +0200

Joe,

if I understand you right, the PCN ingress/egress nodes are CPEs 
(or the like) connected to a single carriers network and this 
carrier supports PCN. Is that correct?

While there are many different accesses and a high number 
access to access communications, each single access carries 
aggregated traffic from some origins only (but not from all).

The accesses probably capture congestion information from WAN 
links close to them - the number of those usually is 
restricted and some of the already admitted flows pass them.
Without any congestion feedback/indication on ingress or egress
- admit the next flow. Otherwise, probing may be useful.

My own perception of PCN would be more carrier centric, assuming 
the PCN edge nodes to be part of the carrier network and not 
of the customers. But this doesn't necessary invalidate your 
example.

Regards,

Rudiger

|-----Original Message-----
|From: Jozef Babiarz [mailto:[email-masked]]
|Sent: Wednesday, October 24, 2007 6:14 PM
|To: Geib, Rudiger
|Cc: [email-masked]
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|
|Ruediger, 
|I'm thinking of a scenario that many enterprises face today. 
|Large multi
|location enterprises use multiple WAN links or VPS to 
|interconnect their
|locations. PCN is run inside the enterprise network including WAN links
|which maybe tunneled across the carrier network. Network Access Control
|with PCN admission control is done at the enterprise access edge nodes.
|New flows can be routed to any egress access edge node and some flows
|will (between different locations) be routed over one of the WAN links
|which are normally bandwidth constrained. There is a high probability
|that many access nodes will only have one flow between each other as
|there are a large number of them.
|
|Regards, Joe
|email:[email-masked]
|Telephone:613-763-6098
|
|-----Original Message-----
|From: Geib, Ruediger [mailto:[email-masked]] 
|Sent: October 24, 2007 3:04 AM
|To: Babiarz, Jozef (CAR:0S03)
|Cc: [email-masked]
|Subject: RE: [PCN] Architecture draft - probing section & general
|updates.
|
|Joe,
|
|my perception is, that probing may be useful, once there is 
|pre-congestion. In a situation without a single admitted 
|flow between an ingress and an egress, if neither ingress 
|node nor egress node have any indication of pre-congestion 
|on any of the links crossed by the PCN flows passing through 
|them, there's with high probability no need to probe, 
|I'd assume. I don't do simulations and would like to invite
|those simulating to come up with cases where this assumption 
|is wrong.
|
|I'd further propose to collect information from providers 
|on the probability of the event you describe. 
|
|Regards, 
|
|Rudiger
|
||-----Original Message-----
||From: Jozef Babiarz [mailto:[email-masked]]
||Sent: Tuesday, October 23, 2007 6:22 PM
||To: Geib, Rudiger; [email-masked]
||Cc: [email-masked]
||Subject: RE: [PCN] Architecture draft - probing section & general
||updates.
||
||
||Ruediger, the issue is not addition of one more flow into the 
|link that
||is experiencing (pre-)congestion level for admission but potentially
||hundreds of new ingress-egress aggregates that have not been 
||established
||passing through the link. 
||
||Regards, Joe
||email:[email-masked]
||Telephone:613-763-6098
||
||-----Original Message-----
||From: Geib, Ruediger [mailto:[email-masked]] 
||Sent: October 23, 2007 4:19 AM
||To: [email-masked]
||Cc: [email-masked]
||Subject: RE: [PCN] Architecture draft - probing section & general
||updates.
||
||Phil,
||
||I appreciate that probing is optional. I understand that to mean that
||standardisation allows to operate PCN within a domain without 
|having to
||support any probing functionality.
||
||There may be operational conditions, when probing makes 
|sense. This may
||be the case, if the number of multiplexed flows is at the 
||lower bound of
||the range where statistical multiplexing can be applied on 
|any link and
||the number of possible ingress to egress relations passing 
|this link is
||big enough to lead to (pre-)congestion by admission of a single flow
||with a reasonable probability. I don't want to stop people 
|from working
||on this issue, but I'd favour PCN to finish standards for an 
||operational
||environment where the probability of a single admitted flow causing
||congestion on a link is extremly low. 
||
||Regards,
||
||Rudiger
||
||
||_______________________________________________
||PCN mailing list
[email-masked]
||https://www1.ietf.org/mailman/listinfo/pcn
||
|

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 25 Oct 2007 11:36:28 +0200

Joe,

as an add on: if these are all CPEs and probing is 
restricted to CPEs, it doesn't matter much to me. 
I'm having more of a problem, if a backbone edge 
router or any other backbone edge system 
(like carrier VoIP gateways) are expected to probe.

If it is the CPE which is probing, this traffic is 
standard PCN traffic to the carrier. It is forwarded 
and accounted like standard PCN traffic by the carrier.

Regards,

Rudiger

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Oct 2007 12:54:29 +0300

On 2007-10-24, at 19:14, ext Jozef Babiarz wrote:
> which are normally bandwidth constrained.

I understand your scenario so far.

> There is a high probability

I don't see how this follows, however. It seems that if the sites  
that are being interconnected aren't tiny, there should very likely  
be multiple flows per ingress/egress pair, no?

Lars

---

From: <[email-masked]>
Date: Thu, 25 Oct 2007 11:56:38 +0100

Lars, I believe the guess is that there'll be many ingress-egress pairs
with none or very few flows at a particular moment. Not a random
distribution of calls onto all possible pairs. Basically there are many
calls between London & Manchester and very few between truro and
Shetland. I & Ben will try and extract some numbers from the [bt]
predicted future traffic matrix.

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: 25 October 2007 10:54
To: ext Jozef Babiarz
Cc: [email-masked]; Geib, Ruediger
Subject: Re: [PCN] Architecture draft - probing section & general
updates.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Oct 2007 15:25:07 +0300

On 2007-10-25, at 13:56, ext [email-masked] wrote:
> Shetland.

I can agree with that. But note that that alone is not a problem yet.

The problem occurs only when several of these "empty" ingress pairs  
share a bottleneck *and* when single flows start simultaneously  
sending across them at a combined rate that will push the bottleneck  
directly into overload.

I don't believe this can be very common. Wouldn't you provision your  
network such that interior routers could handle at least one flow per  
ingress/egress pair? In which case there is no issue unless there's a  
failure. And why not let flow termination handle these rare cases?

> I & Ben will try and extract some numbers from the [bt]

That'd be *very* useful! We're all guessing probabilities here, and  
data would help.

Lars

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 29 Oct 2007 16:18:12 -0400

Sorry Ruediger for the delayed response. See below for additional
clarifications. 

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: October 25, 2007 5:30 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: RE: [PCN] Architecture draft - probing section & general
updates.

Joe,

if I understand you right, the PCN ingress/egress nodes are CPEs 
(or the like) connected to a single carriers network and this 
carrier supports PCN. Is that correct?
[Joe] What you defined is slightly different but also valid scenario.
Sorry if I confused you with "access edge node" I mean edge
router/switch within enterprise LAN that hosts, IP phones, etc. connect.

My own perception of PCN would be more carrier centric, assuming 
the PCN edge nodes to be part of the carrier network and not 
of the customers. But this doesn't necessary invalidate your 
example.
[Joe] My view is that PCN is needed in enterprise and carrier networks
and will be deployed by enterprise using tunneling (VPNs) across carrier
networks.

Regards,

Rudiger

---

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 29 Oct 2007 17:05:36 -0400

Hi Lars, 
I did not explain my scenario that clearly, I confused people the word
"access node". So here goes a second try.

I'm thinking of a scenario that many enterprises face today. Large multi
location enterprises use multiple WAN links or VPS to interconnect their
locations (branch offices). PCN is run inside the enterprise network
including WAN links which may be tunneled across the carrier network.
Carrier network is not required to support PCN as the enterprise traffic
including PCN marking is tunneled, however it could.  Network Access
Control with PCN admission control is done at the *enterprise* LAN edge
switch/router. New flows can be routed to any egress LAN edge
switch/router and some flows will (between different locations) be
routed over one of the WAN links which are normally bandwidth
constrained. There is a high probability that many of the edge LAN
switches/routers will have no flows setup between each other (no
ingress-egress aggregate) as there are a large number of edge LAN
switches/routers in the enterprise network and people calling patterns
change. They normal expect that they should be able to call anyone.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: October 25, 2007 5:54 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: Geib, Ruediger; [email-masked]
Subject: Re: [PCN] Architecture draft - probing section & general
updates.

Lars

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 30 Oct 2007 10:17:37 +0100

Hello Joe,

Thanks for your clarification.

|locations (branch offices). PCN is run inside the enterprise network
|including WAN links which may be tunneled across the carrier network.
|Carrier network is not required to support PCN as the enterprise
traffic
|including PCN marking is tunneled, however it could.  

I'm more interested in a PCN scenario interconnecting carrier
application 
servers or edge nodes. That way, sufficiently high numbers of flows may 
result to have a relatively good perception of the congestion status 
of the network.

Corporate networks allow for any to any communication, but the question
is, 
whether all are used for it. Within my own corporation, I largely 
communicate with 4 centers and randomly call say 6 other destinations,
one 
of which is outside of my home country. My company is active worldwide
and 
has a huge number of PoPs. Most of my colleagues have similar
communication 
patterns.

Regards,

Rudiger