Re: [PCN] Marking Converter for Excess-Marked Traffic

[<[e-mail]>]

Michael

I found this an interesting idea. Although I couldn't follow the draft
100% (could do with more explanation what the pseudocode is trying to
do! But it seems right to me).

If I get it right, this draft is about edge behaviour (PCN-egress-node)
for termination. It's assuming that an operator has only a single
codepoint and wants to achieve both PCN adm ctrl & termination, so is
using 'single marking' (ie using the Excess traffic meter function of
http://tools.ietf.org/id/draft-eardley-pcn-marking-behaviour-01.txt).
Anna has already described how edges can do admission control. And how
edges can do flow termination, using the approach of the egress
measuring the unmarked rate & the ingress the rate being sent (towards
this egress) & terminating the difference (Method A). 

You say that your idea enables an egress to terminate without rate
measurements, and so is a variant of the "terminate marked flows" idea.


As a WG we have the objective to produce Info RFCs describing edge
behaviour. Of course we have lots of possibilities & could try and
document several of them, but it would seem most realistic to me to try
& do one edge behaviour for admission and one for termination - at least
to start with; tackle more after one is done. 
I think it would be best to choose something that works for 'single
marking', including in the case where there's lots of dropping. At the
moment, to me the most promising choice for termination is therefore
Method A. however, your draft opens up another, interesting,
possibility.

Quick qus
- in your simulations, when you terminate a flow does it instantly cause
a reduction in bit rate on the bottleneck link, or do you simulate a
RTT?
- if there is a RTT, I'd have expected that need to do something similar
to EMFT (to avoid over-terminating, only terminate a flow with some
random probability)
- can you give an intuitive explanation of why there's over-termination
if the load on the bottleneck link comes from many
ingress-egress-aggregates? I didn't follow your explanation.
- when you say "measured rate termination [also] suffers from this", do
you mean Method A, or do you mean where the egress measures the rate of
marked traffic & terminates that. (the two should be equivalent, if
there's no dropping in the domain)
- have you studied the impact of dropping on this? (I assume it'll be
similar to EMFT, where it just slows down the rate at which the
PCN-domain goes from overload to being OK))


thanks
phil

{ -----Original Message-----
{ From: [e-mail] [mailto:[e-mail]] On Behalf Of
{ Michael Menth
{ Sent: 07 July 2008 22:30
{ To: pcn
{ Subject: [PCN] Marking Converter for Excess-Marked Traffic
{ 
{ Hi,
{ 
{ we recently submitted a mechanism that converts PCN markings obtained
{ based on an admissible rate (PCN lower rate) to equivalent PCN
markings
{ based on a supportable rate (PCN upper rate). This mechanism might be
{ useful to implement marked flow termination with single marking, i.e.
{ when only excess marked packets based on the admissible rate are
{ available but excess marked packets based on the supportable rate are
{ required. The mechanism is described in
{ http://www.ietf.org/internet-drafts/draft-menth-pcn-marking-converter-
{ 00.txt
{ 
{ Early simulation results show that the mechanism work somehow, but it
{ has its limitations especially when many small
ingress-egress-aggregates
{ share a single link which is a realistic case. A summary of these
{ results is given in Section 8 of
{ http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-03.txt
{ 
{ Regards,
{ 
{     Michael
{ 
{ --
{ Dr. Michael Menth, Assistant Professor
{ University of Wuerzburg, Institute of Computer Science
{ Am Hubland, D-97074 Wuerzburg, Germany, room B206
{ phone: [phone], fax: [phone]
{ mailto:[e-mail]
{ http://www3.informatik.uni-wuerzburg.de/research/ngn
{ 
{ _______________________________________________
{ PCN mailing list
{ [e-mail]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn