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

[Michael Menth <[e-mail]>]

Hi Phil,

[e-mail] wrote:
> 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).
>   
The limitation "only a single DSCP is available for PCN marking" does 
not mean that only one marking scheme can be applied. The encoding 
scheme in 
http://www.ietf.org/internet-drafts/draft-menth-pcn-psdm-encoding-00.txt 
uses only one DSCP for PCN marking and supports concurrent excess and 
exhaustive marking such that probe-based admission control can be based 
on exhaustive marking  (with admissible rate as reference rate) and flow 
termination can be based on excess marking (with supportable rate as 
reference rate).

> 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?
>   
We assume that a flow stops sending packets D_T time after the egress 
node decides that it should be terminated. We set D_T=200 ms, so it's in 
the order of an 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)
>   
Yes. EMFT is used for termination.

> - 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.
>   
Assume  that there is no supportable rate (SR) pre-congestion, but (AR) 
pre-congestion. Then a certain amount of traffic is excess-marked. If 
the fraction of marked traffic is larger for a first aggregate and 
smaller for a second aggregate, the first aggregate will see marked  
packets even after conversion  and hence flows will be terminated.  This 
is why overtermination occurs. This happens more easily if the number of 
aggregates on a link is large because then packet markings within a 
aggregates become more random, i.e. they are not spaced in more or less 
regular intervals.

> - 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)
>   
I mean method A.

> - 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))
>   
No, we have not looked at it.

Some additional comments. From our simulations we have seen that marked 
flow termination based on converted markings has limitations such that I 
don't see it as a significant improvement compared to Single Marking. It 
might work better with multipath routing, but also not 100% correctly.

Regards,

    Michael

>
> 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
>   

-- 
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