Re: [PCN] Consensus questions: Q4, Q5, and Q6

[Michael Menth <[e-mail]>]

Hi Phil,

as your analysis showed, CL/SM require preferential dropping of marked 
packets. Other termination methods required preferential marking of 
unmarked packets. If PCN marking should be optimized for CL/SM at the 
expense of other solutions, preferential dropping of marked packets it 
the way to go. But this kind of marking is hardly of any use for other 
termination methods in challenging situations.

So, if other solutions should not be excluded, preferential dropping of 
unmarked packets is also required as an option. Then it is probably also 
wise to have another option that does not do any preferential drop. The 
decision on preferential dropping limits the potential use of PCN 
marking or the number of architectural options.

Regards,

    Michael

[e-mail] wrote:
> On the subject of Qu 4:
> Don't want to re-open this question, but I thought a bit more at the
> preferential dropping issue, ie if a PCN-node is overloaded and has to
> drop PCN-packets, should it preferentially drop any that are already
> PCN-marked (PCN-excess-rate-marked) - or preferentially drop ones that
> are not marked - or just randomly drop. (The first of these is where the
> WG consensus lies, and is also where this email ends up.)
>
> The preferential dropping behaviour matters when there's at least one
> pre-congested node 'before' the overloaded node ("two bottlenecks")
>  
> The ideal answer depends on what the edge behaviour is:
> *	the CL/SM edge mechanism measures the sustainable rate (the rate
> of unmarked pkts), and terminates rate above this. So ideally PCN-nodes
> should preferentially drop pkts that already PCN-(termination-)marked,
> otherwise too much PCN-traffic will be terminated if there are two
> bottlenecks.
> *	The excess rate & EMFT mechanisms measure (react to) PCN-marked
> pkts. So ideally PCN-nodes should preferentially drop pkts that not
> PCN-(termination-)marked, otherwise PCN-traffic will be terminated
> slower if there are two bottlenecks.
>  
> However, it would be good if the PCN-node behaviour allowed some
> flexibility in terms of the edge behaviour (at least we seem to have
> been implicitly assuming this). Their pros/cons are:
> *	CL/SM edge behaviour: can terminate the right amount in a single
> shot (but can also terminate slower, if that's preferred); requires one
> msg from egress to ingress to indicate termination; but has to measure
> rates at both egress and ingress
> *	Excess rate: in general terminates slower & so requires several
> msgs; requires rate measurement at the egress but not ingress
> *	EMFT: doesn't need to measure any rate, but terminates slower
> and needs a msg for each flow that's terminated
>  
> Consider two cases in more detail. [1] the operator sets the
> PCN-upper-rate at 95% of PCN-max-rate; [2] the operator sets the
> PCN-upper-rate at 50% of PCN-max-rate There's the PCN-upper-rate above
> which pkts are PCN-excess-rate-marked and the PCN-max-rate above which
> PCN-pkts are dropped.
>  
> For case [1], with a single bottleneck that's overloaded (say at 5*
> PCN-max-rate), ie dropping pkts as well as marking pkts:
> *	the CL/SM edge mechanism can terminate the right amount in one
> go. Termination is just as fast as when the bottleneck is pre-congested
> but not overloaded. 
> *	the excess rate mechanism measures the 5% of marked pkts. It
> terminates this amount - the link is now overloaded at 4.95*
> PCN-max-rate. This makes termination about 100* slower.
> *	With EMFT, if the edge sees a marked pkt then it terminates this
> flow with some probability. This is similar to the previous case, so
> again termination is much much slower. However, it should be possible to
> speed up termination a bit by terminating a marked flow with a greater
> probability; the caution is that this increases the chances of
> over-terminating, because of the time lag after a termination decision
> before the rate reduces.)
>  
> For case [2], the difference is not quite as great - termination is
> about 10* slower. 
> Conclusion: an operator who wants to use its capacity "aggressively" by
> setting the PCN-upper-rate at 95% of PCN-max-rate must use the CL/SM
> edge mechanism. 
>  
> Now let's consider the two bottleneck case, with the first marking and
> the second dropping pkts. We only need to compare edge behaviours in
> case [2].
> *	if the overloaded node preferentially drop pkts that are already
> marked, then the result is (max) 50% are unmarked, 50% marked and the
> rest are dropped (0.5* PCN-max-rate unmarked = PCN-upper-rate; 0.5*
> PCN-max-rate marked; 4* PCN-max-rate dropped). This is exactly the same
> as in the single bottleneck case. Hence:
> o	again, the CL/SM edge mechanism can terminate the right amount
> in one go.
> o	Again, Excess rate /EMFT terminates at the same slow speed as in
> the single bottleneck case
> *	if the overloaded node preferentially drop pkts that are
> unmarked, then the result is all pkts are marked and the rest are
> dropped (1* PCN-max-rate marked; 4* PCN-max-rate dropped)
> o	the CL/SM edge mechanism no longer works. All pkts are marked,
> so the sustainable rate is 0 & so it terminates all flows.
> o	Excess rate /EMFT terminates about twice as fast as in the
> single bottleneck case (but still about 5* slower than the CL/SM
> mechanism achieves above)
> *	if the overloaded node randomly drops pkts that are already
> marked, then the result is roughly 10% are unmarked, 90% marked and the
> rest are dropped (0.1* PCN-max-rate unmarked; 0.9* PCN-max-rate marked;
> 4* PCN-max-rate dropped)
> o	the CL/SM edge mechanism terminates 5* too much (sustainable
> rate is only 20% of what it really is)
> o	Excess rate /EMFT terminates towards twice as fast as in the
> single bottleneck case (but still over 5* slower than the CL/SM
> mechanism achieves above)
>  
> Conclusion:
> *	if the overloaded node preferentially drop pkts that are
> unmarked, then the CL/SM edge behaviour is not possible - so this option
> can be excluded.
> *	if the overloaded node randomly drops pkts that are already
> marked, then the CL/SM edge mechanism terminates far too much. The CL/SM
> mechanism could be deliberately slowed down in order to reduce the risk
> of over-termination. However, this creates a penalty of slower
> termination in the single bottleneck case. The operator also needs to
> guess what the highest level of overload is/ 
>  
> The above is intended to be purely descriptive. Now to give my opinion.
> I believe it means that the standard should specify that an overloaded
> node SHOULD preferentially drop pkts that are already excess-rate
> marked:
> *	it gives the operator as much freedom as possible on setting the
> PCN-upper-rate in relation to the PCN-max-rate. Otherwise it cannot set
> PCN-upper-rate close to PCN-max-rate.
> *	It allows an operator to achieve termination to the correct rate
> in a single shot (providing they're prepared to do the work of measuring
> rates at egress & ingress). Otherwise they must *always* slow down
> termination, in case there are two bottlenecks when there could be far
> too much termination. 
> *	It allows an operator to achieve termination with a simpler
> mechanism like EMFT, albeit somewhat slower than would be achieved by
> different preferential dropping behaviour. However, such an operator has
> already accepted that, in the case where even one node is overloaded,
> termination will be much slower than with a CL/SM edge behaviour. In
> other words, such an operator has made the decision that the simpler
> edge mechanism (in terms of not having to measure rates) is important
> enough that they don't mind termination being slower than ideal if
> there's an overloaded node.
>
>
> Comments?
> Phil/
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Steven Blake
>> Sent: 20 April 2008 18:41
>> To: pcn
>> Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6
>>
>> On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote:
>>     
>>> Here are the remaining three questions that were taken during the
>>>       
> IETF
>   
>>> 71 meeting:
>>>
>>> Q4: Should the standards-track PCN scheme require (as a MUST
>>>       
> implement
>   
>>>     feature) that interior PCN routers support Excess-Rate marking,
>>>     according to the particular method of handling already marked
>>>     packets and drops described in Anna Charny's presentation?
>>>     http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf
>>>
>>> Q5: Should the standards-track PCN scheme require (as a MUST
>>>       
> implement
>   
>>>     feature) that interior PCN routers support Threshold marking (in
>>>     addition to Excess-Rate marking), according to the particular
>>>       
> method
>   
>>>     described in Philip Eardley's presentation on Tuesday?
>>>     http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf
>>>
>>> Q6: If presented with sufficient evidence in a timely fashion, would
>>>     the PCN wg entertain the option of modifying the interior router
>>>     Excess-Rate marking behavior for the standards-track PCN scheme
>>>       
> (as
>   
>>>     described in question 4)?
>>>
>>> According to the draft meeting minutes, Q4 was accepted 8-0 (my
>>>       
> notes
>   
>>> have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0.
>>>       
>> The feedback from the list for Q4 and Q5 seems to match up closely
>>     
> with
>   
>> the results in the meeting (not surprising, as it was mostly the same
>> individuals commenting).  I counted one dissent for Q4 and one for Q5.
>>
>> The feedback for Q6 was a mixture of abstain and Yes with caveats.  If
>> and when someone wants to propose modifications to the Excess-Rate
>> marking behavior, we can see if there is interest to discuss it on the
>> list, but I *strongly encourage* that any such discussion needs to
>> happen before the Dublin meeting.
>>
>> We seem to have consensus to go forward with a standards-track
>>     
> proposal
>   
>> supporting two encoding states, with Excess-Rate and Threshold marking
>> as MUST implement features.  In addition, we are open to work on one
>>     
> or
>   
>> more experimental-track proposals (as a lower priority acitivity) that
>> are extensions of the standards-track proposal, using an additional
>> encoding state.
>>
>> This is a call for volunteers to start working on drafts for the
>> standards-track interior node detection, (in-band) PCN encoding,
>> egress-ingress feedback protocol, and boundary node mechanisms, as
>> spelled out in the PCN charter.
>>
>> Note: I will be (mostly) off line for the rest of the week.
>>
>>
>> Regards,
>>
>> // Steve
>>
>> _______________________________________________
>> PCN mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcn
>>     
> _______________________________________________
> 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