Subject: [PCN] Dropping preference as a configuration option

From: <[email-masked]>
Date: Wed, 19 Nov 2008 02:21:56 -0000

Michael and Georgios have raised this issue recently, and we've discussed it here in Minneapolis - both in a 'corridor' meeting and in the WG meeting.
so i wanted to summarised the issue and the discussions so far. 
 
The issue is about if there are 2 bottlenecks on the path, the first one is pre-congested & excess-traffic-marking pkts and the second one is even more overloaded and is actually dropping pkts. the question is whether the second node should preferentially drop pkts that have already been marked or do something else instead.
 
History of issue:
In 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 19 Nov 2008 03:27:07 -0000

Michael and Georgios have raised this issue recently, and we've discussed it here in Minneapolis - both in a 'corridor' meeting and in the WG meeting.
so i wanted to summarised the issue and the discussions so far. Especially as neither of you could make it here. clearly this means we need to discuss and reach consensus on this on the mailing list. i'd really like to do this as quickly as poss, since i believe it's the only current discussion issue for the marking behaviour draft (plus perhaps the satoh draft).

History of issue:
==================
In Philadelphia we discussed the choice between:
* MUST preferentially drop pkts that are already excess-traffic-marked OR 
* MUST drop independent of marking
* a logical thid option that we didn't discuss: preferentially drop pkts that are not excess-traffic-marked)
There was a consensus for option 1, as a SHOULD
There was also a discussion afterwards on the mailing list (one of Steve's "Questions") which confirmed this consensus.
 
I believe a fair summary of the thinking was as follows:
(CL/SM = edge behaviour where egress measures rate of pkts that are not ExM (from an ingress), ingress measures rate of pkts (sent to that egress)
(MFT = edge behaviour where egress terminates a flow (with some probability) when it sees a marked pkt on that flow
 
* Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for MFT
* 'random' drop: breaks completely in some scenarios (terminates far too much) for CL/SM ; works OK (slightly slower than above) for MFT
* Preferentially drop pkts not ExM: breaks completely in some scenarios (terminates all flows) for CL/SM ; best for MFT  (much faster than above)
 
Michael, i beleive this is what's shown by the paper of yours you pointed me at in your email http://www.ietf.org/mail-archive/web/pcn/current/msg01841.html
ie Fig 9 in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf
 
we should also bear in mind the pros and cons of CL/SM & MFT:
* CL/SM: Can terminate fast ('1 shot') 
* MFT: Simpler (don't measure rates), but accept trade-off that won't terminate so fast
See also more details in http://www.ietf.org/mail-archive/web/pcn/current/msg01449.html
 
so the result of all the discussions at/after Philadelphia was the consensus decision to go for preferentially drop pkts that are already excess-traffic-marked, but as a SHOULD (rather than as a MUST)
 
The latest proposal
===================
The proposal from Michael & Georgios is that the preferential dropping behaviour is an Option. 

Summary of discussion in Minneapolis about proposal
=======================================
Pros: All edge behaviours can choose their optimal preferential dropping behaviour
Cons: Extra complexity to standardise, implement & operate (configure, manage etc)

Quite a few people made comments at the mike. my impression was that the general feeling is that we should think very hard before having an Option - "have one choice"
 
Another question is what a Std with such options would actually say. 
eg is one of them the default (MUST) and the other(s) a MAY? 
- making pref. drop the default MUST and 'random' dropping the MAY would be rather empty, since existing routers do tail drop, so you would be saying you MAY do something that the router does anyway!
- marking 'random' dropping the default would therefore seem more likely But this then means that the default is something that we know is broken for CL/SM in scenarios that are easy to devise (basically if the link is greatly overloaded, say 5*, then you might over-terminate by 4*). which seems quite scay. 
- making them both MUSTs to implement (option which is used). this is actually tougher on vendors than what the current draft says (SHOULD for pref. drop - since the 'random dropping' is what the router does today, so it's trivial to offer it if that's demanded.
 
So the conclusion of this discussion was that a SHOULD actually captures quite well what we want to say, ie this is the new behaviour, and this is the thing that means CL/SM can work, whilst MFT can also work OK. 
We also thought it would be worth adding a brief explanation why it's not a MUST (the Informative Appendix B would be the right place). so we could say something like:
- you might instead want to do tail drop, as this is what today's routers do, so lowers the implementation step for PCN. But beware it has these trade-offs for CL/SM Edge behaviour
- you might instead want to preferentially drop pkts that arent excess traffic marked, becuase this gives the best overall behaviour for MFT (ie if you know that this is your edge behaviour)
 
Minneappers - Hopefully this captures OK our disussion, please add/correct if it doesnt.
 
Michael, Gegorios, what do you think? 
 
thanks,
phil

---

From: <[email-masked]>
Date: Wed, 19 Nov 2008 09:50:16 -0000

So outcome of discussion is that we stick with a SHOULD for preferential
drop, but include some proper explanation of the trade-offs that a
vendor might consider when deciding if they can ignore it?

This seems to be a very good compromise. Perhaps it could be phrased
something like:

"nodes SHOULD preferentially drop excess-traffic-marked packets.
Alternatively they MAY choose to drop randomly but for many deployment
scenarios this is NOT RECOMMENDED (see appendix n for explanation)."

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 19 November 2008 03:27
> To: [email-masked]
> Subject: [PCN] Dropping preference as a configuration option
> 
> Michael and Georgios have raised this issue recently, and we've
> discussed it here in Minneapolis - both in a 'corridor' meeting and in
> the WG meeting.
> Especially as neither of you could make it here. clearly this means we
> need to discuss and reach consensus on this on the mailing list. i'd
> really like to do this as quickly as poss, since i believe it's the
> only current discussion issue for the marking behaviour draft (plus
> perhaps the satoh draft).
> 
> The issue is about if there are 2 bottlenecks on the path, the first
> one is pre-congested & excess-traffic-marking pkts and the second one
> is even more overloaded and is actually dropping pkts. the question is
> whether the second node should preferentially drop pkts that have
> already been marked or do something else instead.
> 
> History of issue:
> ==================
> There was also a discussion afterwards on the mailing list (one of
> Steve's "Questions") which confirmed this consensus.
> 
> (CL/SM = edge behaviour where egress measures rate of pkts that are
not
> ExM (from an ingress), ingress measures rate of pkts (sent to that
> egress)
> (MFT = edge behaviour where egress terminates a flow (with some
> probability) when it sees a marked pkt on that flow
> 
> * 'random' drop: breaks completely in some scenarios (terminates far
> too much) for CL/SM ; works OK (slightly slower than above) for MFT
> * Preferentially drop pkts not ExM: breaks completely in some
scenarios
> (terminates all flows) for CL/SM ; best for MFT  (much faster than
> above)
> 
> Michael, i beleive this is what's shown by the paper of yours you
> pointed me at in your email http://www.ietf.org/mail-
> archive/web/pcn/current/msg01841.html
> ie Fig 9 in http://www3.informatik.uni-
> wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf
> 
> so the result of all the discussions at/after Philadelphia was the
> consensus decision to go for preferentially drop pkts that are already
> excess-traffic-marked, but as a SHOULD (rather than as a MUST)
> 
> The latest proposal
> ===================
> Quite a few people made comments at the mike. my impression was that
> the general feeling is that we should think very hard before having an
> Option - "have one choice"
> 
> - making pref. drop the default MUST and 'random' dropping the MAY
> would be rather empty, since existing routers do tail drop, so you
> would be saying you MAY do something that the router does anyway!
> - marking 'random' dropping the default would therefore seem more
> likely But this then means that the default is something that we know
> is broken for CL/SM in scenarios that are easy to devise (basically if
> the link is greatly overloaded, say 5*, then you might over-terminate
> by 4*). which seems quite scay.
> - making them both MUSTs to implement (option which is used). this is
> actually tougher on vendors than what the current draft says (SHOULD
> for pref. drop - since the 'random dropping' is what the router does
> today, so it's trivial to offer it if that's demanded.
> 
> So the conclusion of this discussion was that a SHOULD actually
> captures quite well what we want to say, ie this is the new behaviour,
> and this is the thing that means CL/SM can work, whilst MFT can also
> work OK.
> We also thought it would be worth adding a brief explanation why it's
> not a MUST (the Informative Appendix B would be the right place). so
we
> could say something like:
> - you might instead want to do tail drop, as this is what today's
> routers do, so lowers the implementation step for PCN. But beware it
> has these trade-offs for CL/SM Edge behaviour
> - you might instead want to preferentially drop pkts that arent excess
> traffic marked, becuase this gives the best overall behaviour for MFT
> (ie if you know that this is your edge behaviour)
>

---

From: Michael Menth <[email-masked]>
Date: Wed, 19 Nov 2008 11:01:44 +0100

Hi Toby and all,

the issue of drop preferences highly depends on the edge behavior. E.g. 
direct measured rate termination or marked flow termination benefit from 
preferentially dropping unmarked packets while indirect measured rate 
termination requires preferential dropping of marked packets. Therefore, 
it makes most sense to demand a certain drop preference when defining 
the edge behavior (aka deployment model).  Defining drop preferences 
independently of the deployment models is like erasing some of them. 
This could be done more directly just by saying, we want only this or 
that deployment model and others not (and not even for later in case the 
chosen one turns out to be too complex!). If this is not the strategy, 
the deployment model is the right place for the definition of drop 
preferences.

Fact is that we discovered that drop preferences are an important issue. 
Therefore, it makes sense to require in general two options in the 
marking or architecture draft: dropping marked or unmarked packets. The 
deployment model indicates what's needed.

Regards,

    Michael

[email-masked] schrieb:
>> * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for
>>     
> MFT
>   

-- 
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: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 19 Nov 2008 11:18:10 +0100

Hi Phil

I think that the conclusions, of the discussions, regarding SHOULD for
dropping, see below,
are reasonable to me.  However, regarding the text that will be 
given in Appendix A should be carefully written!

>  
> So the conclusion of this discussion was that a SHOULD 
> actually captures quite well what we want to say, ie this is 
> the new behaviour, and this is the thing that means CL/SM can 
> work, whilst MFT can also work OK. 
> We also thought it would be worth adding a brief explanation 
> why it's not a MUST (the Informative Appendix B would be the 
> right place). so we could say something like:
> - you might instead want to do tail drop, as this is what 
> today's routers do, so lowers the implementation step for 
> PCN. But beware it has these trade-offs for CL/SM Edge behaviour
> - you might instead want to preferentially drop pkts that 
> arent excess traffic marked, becuase this gives the best 
> overall behaviour for MFT (ie if you know that this is your 
> edge behaviour)

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: woensdag 19 november 2008 4:27
> To: [email-masked]
> Michael and Georgios have raised this issue recently, and 
> we've discussed it here in Minneapolis - both in a 'corridor' 
> meeting and in the WG meeting.
> so i wanted to summarised the issue and the discussions so 
> far. Especially as neither of you could make it here. clearly 
> this means we need to discuss and reach consensus on this on 
> the mailing list. i'd really like to do this as quickly as 
> poss, since i believe it's the only current discussion issue 
> for the marking behaviour draft (plus perhaps the satoh draft).
>  
> The issue is about if there are 2 bottlenecks on the path, 
> the first one is pre-congested & excess-traffic-marking pkts 
> and the second one is even more overloaded and is actually 
> dropping pkts. the question is whether the second node should 
> preferentially drop pkts that have already been marked or do 
> something else instead.
>  
> History of issue:
> ==================
> * a logical thid option that we didn't discuss: 
> preferentially drop pkts that are not excess-traffic-marked) 
> There was a consensus for option 1, as a SHOULD There was 
> also a discussion afterwards on the mailing list (one of 
> (CL/SM = edge behaviour where egress measures rate of pkts 
> that are not ExM (from an ingress), ingress measures rate of 
> pkts (sent to that egress) (MFT = edge behaviour where egress 
> terminates a flow (with some probability) when it sees a 
> marked pkt on that flow
>  
> * 'random' drop: breaks completely in some scenarios 
> (terminates far too much) for CL/SM ; works OK (slightly 
> slower than above) for MFT
> scenarios (terminates all flows) for CL/SM ; best for MFT  
> (much faster than above)
>  
> Michael, i beleive this is what's shown by the paper of yours 
> you pointed me at in your email 
> http://www.ietf.org/mail-archive/web/pcn/current/msg01841.html
> ie Fig 9 in 
> http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio
ns/papers/Menth08-PCN-MFT.pdf
> * MFT: Simpler (don't measure rates), but accept trade-off 
> that won't terminate so fast See also more details in 
> http://www.ietf.org/mail-archive/web/pcn/current/msg01449.html
>  
> so the result of all the discussions at/after Philadelphia 
> was the consensus decision to go for preferentially drop pkts 
> that are already excess-traffic-marked, but as a SHOULD 
> (rather than as a MUST)
>  
> The latest proposal
> ===================
> Quite a few people made comments at the mike. my impression 
> was that the general feeling is that we should think very 
> hard before having an Option - "have one choice"
>  
> - making pref. drop the default MUST and 'random' dropping 
> the MAY would be rather empty, since existing routers do tail 
> drop, so you would be saying you MAY do something that the 
> router does anyway!
> - marking 'random' dropping the default would therefore seem 
> more likely But this then means that the default is something 
> that we know is broken for CL/SM in scenarios that are easy 
> to devise (basically if the link is greatly overloaded, say 
> 5*, then you might over-terminate by 4*). which seems quite scay. 
> - making them both MUSTs to implement (option which is used). 
> this is actually tougher on vendors than what the current 
> draft says (SHOULD for pref. drop - since the 'random 
> dropping' is what the router does today, so it's trivial to 
> offer it if that's demanded.
>  
> So the conclusion of this discussion was that a SHOULD 
> actually captures quite well what we want to say, ie this is 
> the new behaviour, and this is the thing that means CL/SM can 
> work, whilst MFT can also work OK. 
> We also thought it would be worth adding a brief explanation 
> why it's not a MUST (the Informative Appendix B would be the 
> right place). so we could say something like:
> - you might instead want to do tail drop, as this is what 
> today's routers do, so lowers the implementation step for 
> PCN. But beware it has these trade-offs for CL/SM Edge behaviour
> - you might instead want to preferentially drop pkts that 
> arent excess traffic marked, becuase this gives the best 
> overall behaviour for MFT (ie if you know that this is your 
> edge behaviour)
>

---

From: <[email-masked]>
Date: Wed, 19 Nov 2008 21:57:57 -0000

>> So outcome of discussion is that we stick with a SHOULD for preferential drop, but include some proper explanation of the trade-offs that a vendor might consider when deciding if they can ignore it?

[phil] yes, that's right

________________________________

From: Moncaster,T,Toby,CXR9 R
Sent: Wed 19/11/2008 09:50
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Dropping preference as a configuration option

So outcome of discussion is that we stick with a SHOULD for preferential drop, but include some proper explanation of the trade-offs that a vendor might consider when deciding if they can ignore it?

This seems to be a very good compromise. Perhaps it could be phrased something like: 

"nodes SHOULD preferentially drop excess-traffic-marked packets. Alternatively they MAY choose to drop randomly but for many deployment scenarios this is NOT RECOMMENDED (see appendix n for explanation)."

Toby 

> (CL/SM = edge behaviour where egress measures rate of pkts that are not 
> * Preferentially drop pkts not ExM: breaks completely in some scenarios 
> ie Fig 9 in http://www3.informatik.uni- <http://www3.informatik.uni-/>  
> not a MUST (the Informative Appendix B would be the right place). so we

---

From: <[email-masked]>
Date: Wed, 19 Nov 2008 22:07:03 -0000

Michael
 
firstly, i don't beleive it "highly" depends. marked flow termination still works with preferential dropping of exces-traffic-marked pkts, eg your paper showed that this was nearly as good as 'random' dropping for MFT (i remember 3.5secs vs 3secs). please see discussion below and pointers to other emails.
 
secondly, independently of the above, any proposal needs to be phrased in standards language, since the Marking behaviour is a Stds doc. please see the paragrpah below that starts "Another question is what a Std with such options would actually say."
 
thanks
phil

From: Michael Menth [mailto:[email-masked]]
Sent: Wed 19/11/2008 10:01
To: Moncaster,T,Toby,CXR9 R
Cc: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: Re: [PCN] Dropping preference as a configuration option

Hi Toby and all,

Regards,

    Michael

---

From: <[email-masked]>
Date: Wed, 19 Nov 2008 22:07:32 -0000

Georgios
excellent, thanks. i'll try and work a proposal for some text for the Appendix (probably next week). i agree it needs careful writing and that this may take some bashing to get right.
 
phil

From: Georgios Karagiannis [mailto:[email-masked]]
Sent: Wed 19/11/2008 10:18
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] Dropping preference as a configuration option

Hi Phil

Best regards,
Georgios

---

From: Michael Menth <[email-masked]>
Date: Wed, 19 Nov 2008 23:41:23 +0100

Hi Phil,

> firstly, i don't beleive it "highly" depends. marked flow termination still works with preferential dropping of exces-traffic-marked pkts, eg your paper showed that this was nearly as good as 'rand…
Yes MFT is rather robust. I'm not so much talking about MFT but about 
direct measured rate termination. Just see next email!

> secondly, independently of the above, any proposal needs to be phrased in standards language, since the Marking behaviour is a Stds doc. please see the paragrpah below that starts "Another question…
Yes, see next email, too.

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 19 Nov 2008 23:42:16 +0100

Hi Phil,

thanks for this very good summary!

> The issue is about if there are 2 bottlenecks on the path, the first one is pre-congested & excess-traffic-marking pkts and the second one is even more overloaded and is actually dropping pkts. the…
Yes.

> See also more details in http://www.ietf.org/mail-archive/web/pcn/current/msg01449.html
The issue is not only between CL/SM (indirect measured rate termination, 
IMRT) and marked flow termination (MFT). For me it is not clear whether 
indirect measured rate termination is better than direct measured rate 
termination (DMRT) which are very similar and could be used as an 
alternative in CL/SM. DMRT also requires dropping of unmarked packets. 
We studied this in
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9.pdf
We showed in IV.C that IMRT can suffer from biased measurement intervals 
and lead to overtermination.
IMRT: reduce SR-overload always within two measurement intervals (one at 
the egress and another at the ingress plus anoter MI at the ingress for 
another termination step), but is prone to overtermination in case of 
biased measurement intervals.
DMRT: reduce SR-overload also within a very few measurement intervals 
(one measurement interval at the egress + RTT for signalling to ingress 
+ one inter-termination time (=2 measurement intervals+2RTT) for two 
termination steps). It terminates slower than IMRT only if there is a 
significant amount of PCN packet loss. However, DMRT is not prone to 
overtermination.

I believe that this issue was not discussed and understood enough, yet.

> so the result of all the discussions at/after Philadelphia was the consensus decision to go for preferentially drop pkts that are already excess-traffic-marked, but as a SHOULD (rather than as a MU…
I believe that make one option a MUST and another as SHOULD is not 
helpful as one cannot rely on the implementation. If there is evidence 
that IMRT is fine forever, we can live with dropping marked packets as 
the only option. But keeping the door open for DMRT means making 
preferential dropping of unmarked packets a MUST.

BTW, I do not understand why preferential dropping must be fixed in the 
marking draft, deployment models seem a better place to me.

Regards,

    Michael

---

From: <[email-masked]>
Date: Wed, 19 Nov 2008 23:49:54 -0000

ah, right - direct measured rate termination had slipped to back of mind. i think i'd not be too worried about this type of edge behaviour being compromised - if you're prepared to measure rates at egress (needed by direct measured rate termination) then seems ok to measure rate at ingress as well (ie CL/SM edge behaviour)
phil

From: Michael Menth [mailto:[email-masked]]
Sent: Wed 19/11/2008 22:41
To: Eardley,PL,Philip,CXR9 R
Cc: Moncaster,T,Toby,CXR9 R; [email-masked]
Subject: Re: [PCN] Dropping preference as a configuration option

Hi Phil,

Regards,

    Michael
>>> ie Fig 9 in http://www3.informatik.uni- <http://www3.informatik.uni-/>  <http://www3.informatik.uni-/>

---

From: Michael Menth <[email-masked]>
Date: Thu, 20 Nov 2008 09:18:58 +0100

Hi Phil,

> ah, right - direct measured rate termination had slipped to back of mind. i think i'd not be too worried about this type of edge behaviour being compromised - if you're prepared to measure rates at…
This is not the point. I'm not talking about overhead or the feasibility 
of measurements. I'm talking about problems that may occur when 
measurement intervals at ingress and egress are not synchronized. This 
issue has always been ignored. We explained it in IV.C of
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9.pdf

Regards,

    Michael

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Fri, 21 Nov 2008 21:33:56 -0500

Hi Michael,  

Just a quick note below:

> Behalf Of Michael Menth
> Sent: Thursday, November 20, 2008 2:19 AM
> To: [email-masked]
> Cc: [email-masked]
> > ah, right - direct measured rate termination had slipped to back of 
> > mind. i think i'd not be too worried about this type of 
> edge behaviour 
> > being compromised - if you're prepared to measure rates at egress 
> > (needed by direct measured rate termination) then seems ok 
> to measure 
> > rate at ingress as well (ie CL/SM edge behaviour) phil
> >   
> This is not the point. I'm not talking about overhead or the 
> feasibility of measurements. I'm talking about problems that 
> may occur when measurement intervals at ingress and egress 
> are not synchronized. This issue has always been ignored. We 
> explained it in IV.C of 

I just wanted to point out that we did not really see any evidence of
issues related to desynchronized measurement intervals neither for CL
nor for SM in any of the CL or SM simulations we ran and reported (which
did not rely on synchronized intervals at all). 

Best,
Anna 

> >> firstly, i don't beleive it "highly" depends. marked flow 
> termination still works with preferential dropping of 
> exces-traffic-marked pkts, eg your paper showed that this was 
> nearly as good as 'random' dropping for MFT (i remember 
> 3.5secs vs 3secs). please see discussion below and pointers 
> to other emails.
> >>  
> >>     
> >> secondly, independently of the above, any proposal needs 
> to be phrased in standards language, since the Marking 
> behaviour is a Stds doc. please see the paragrpah below that 
> starts "Another question is what a Std with such options 
> would actually say."
> >>  
> >>     
> >> direct measured rate termination or marked flow 
> termination benefit 
> >> from preferentially dropping unmarked packets while 
> indirect measured 
> >> rate termination requires preferential dropping of marked packets. 
> >> Therefore, it makes most sense to demand a certain drop preference 
> >> when defining the edge behavior (aka deployment model).  Defining 
> >> drop preferences independently of the deployment models is 
> like erasing some of them.
> >> that deployment model and others not (and not even for 
> later in case 
> >> the chosen one turns out to be too complex!). If this is not the 
> >> strategy, the deployment model is the right place for the 
> definition 
> >> of drop preferences.
> >>
> >> marking or architecture draft: dropping marked or unmarked 
> packets. 
> >> The deployment model indicates what's needed.
> >>
> >> Regards,
> >>
> >>     Michael
> >>
> >>> So outcome of discussion is that we stick with a SHOULD for 
> >>> preferential drop, but include some proper explanation of the 
> >>> trade-offs that a vendor might consider when deciding if 
> they can ignore it?
> >>>
> >>> Alternatively they MAY choose to drop randomly but for many 
> >>> deployment scenarios this is NOT RECOMMENDED (see 
> appendix n for explanation)."
> >>>
> >>> Toby
> >>>
> >>>
> >>>    
> >>>       
> >>>> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >>>> Of [email-masked]
> >>>> discussed it here in Minneapolis - both in a 'corridor' 
> meeting and 
> >>>> in the WG meeting.
> >>>> Especially as neither of you could make it here. clearly 
> this means 
> >>>> we need to discuss and reach consensus on this on the 
> mailing list. 
> >>>> i'd really like to do this as quickly as poss, since i 
> believe it's 
> >>>> the only current discussion issue for the marking 
> behaviour draft 
> >>>> (plus perhaps the satoh draft).
> >>>>
> >>>> The issue is about if there are 2 bottlenecks on the path, the 
> >>>> first one is pre-congested & excess-traffic-marking pkts and the 
> >>>> second one is even more overloaded and is actually 
> dropping pkts. 
> >>>> the question is whether the second node should 
> preferentially drop 
> >>>> pkts that have already been marked or do something else instead.
> >>>>
> >>>> History of issue:
> >>>> ==================
> preferentially drop 
> >>>> pkts that are not excess-traffic-marked) There was a 
> consensus for 
> >>>> option 1, as a SHOULD There was also a discussion 
> afterwards on the 
> >>>> mailing list (one of Steve's "Questions") which confirmed this 
> >>>> consensus.
> >>>>
> >>>> * 'random' drop: breaks completely in some scenarios (terminates 
> >>>> far too much) for CL/SM ; works OK (slightly slower than 
> above) for 
> >>>> MFT
> >>>> <http://www3.informatik.uni-/>  <http://www3.informatik.uni-/> 
> >>>> * MFT: Simpler (don't measure rates), but accept trade-off that 
> >>>> won't terminate so fast See also more details in 
> >>>> http://www.ietf.org/mail- archive/web/pcn/current/msg01449.html
> >>>>
> >>>> consensus decision to go for preferentially drop pkts that are 
> >>>> already excess-traffic-marked, but as a SHOULD (rather than as a 
> >>>> MUST)
> >>>>
> >>>> The latest proposal
> >>>> ===================
> >>>> Quite a few people made comments at the mike. my impression was 
> >>>> that the general feeling is that we should think very 
> hard before 
> >>>> likely But this then means that the default is something that we 
> >>>> know is broken for CL/SM in scenarios that are easy to devise 
> >>>> (basically if the link is greatly overloaded, say 5*, then you 
> >>>> might over-terminate by 4*). which seems quite scay.
> >>>> - making them both MUSTs to implement (option which is 
> used). this 
> >>>> is actually tougher on vendors than what the current draft says 
> >>>> (SHOULD for pref. drop - since the 'random dropping' is what the 
> >>>> router does today, so it's trivial to offer it if that's 
> demanded.
> >>>>
> >>>> captures quite well what we want to say, ie this is the new 
> >>>> behaviour, and this is the thing that means CL/SM can 
> work, whilst 
> >>>> MFT can also work OK.
> >>>> We also thought it would be worth adding a brief explanation why 
> >>>> it's not a MUST (the Informative Appendix B would be the right 
> >>>> place). so
> >>>>   
> >>>>      
> >>>>         
> >>> we
> >>>
> >>>    
> >>>       
> >>>> routers do, so lowers the implementation step for PCN. 
> But beware 
> >>>> it has these trade-offs for CL/SM Edge behaviour
> >>>> - you might instead want to preferentially drop pkts that arent 
> >>>> excess traffic marked, becuase this gives the best overall 
> >>>> behaviour for MFT (ie if you know that this is your edge 
> behaviour)
> >>>>
> >> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> >> Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> >> room B206
> > Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> > Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> > room B206
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: Michael Menth <[email-masked]>
Date: Sat, 22 Nov 2008 10:10:15 +0100

Hi Anna,

Anna Charny (acharny) schrieb:
>> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/pa
>>     
> pers/Menth08-Sub-9.pdf
>
In simulations you can easily have synchronization effects that can have 
positive or negative impact on the results. Our example shows that 
overtermination through desynchronized measurement intervals is 
possible. So this problem does exist. The question is how big is its 
probability and impact in real systems. To that end, it's important to 
use explicitly desynchronized measurement intervals in simulations and 
changing traffic. You can see this phenomenon in simulations only if you 
make sure that the settings allow the problem I've described.

Regards,

    Michael

>>> Yes MFT is rather robust. I'm not so much talking about MFT 
>>>       
>> but about 
>>     
>>>> the issue of drop preferences highly depends on the edge 
>>>>         
>> behavior. E.g.
>>     
>>>> This could be done more directly just by saying, we want 
>>>>         
>> only this or 
>>     
>>>> Fact is that we discovered that drop preferences are an 
>>>>         
>> important issue.
>>     
>>>>> This seems to be a very good compromise. Perhaps it could 
>>>>>           
>> be phrased 
>>     
>>>>> something like:
>>>>>
>> meeting and 
>>>>>> in the WG meeting.
>>>>>> (CL/SM = edge behaviour where egress measures rate of 
>>>>>>             
>> pkts that are
>>     
>>>>>>   
>>>>>>      
>>>>>>         
>>>>>>             
>>>>> not
>>>>>
>>>>>    
>>>>>       
>>>>>           
>>>>>> ExM (from an ingress), ingress measures rate of pkts 
>>>>>>             
>> (sent to that
>>     
>>>>>> egress)
>>>>>> * Preferentially drop ExM pkts: works Best for CL/SM ; 
>>>>>>             
>> Works ok for
>>     
>>>>>>   
>>>>>>      
>>>>>>         
>>>>>>             
>>>>> MFT
>>>>>
>>>>>    
>>>>>       
>>>>>           
>>>>>> (terminates all flows) for CL/SM ; best for MFT  (much 
>>>>>>             
>> faster than
>>     
>>>>>> above)
>>>>>>
>>>>>> Michael, i beleive this is what's shown by the paper of 
>>>>>>             
>> yours you 
>>     
>>>>>> so the result of all the discussions at/after 
>>>>>>             
>> Philadelphia was the 
>>     
>> hard before 
>>>>>> having an Option - "have one choice"
>>>>>>
>>>>>> Another question is what a Std with such options would 
>>>>>>             
>> actually say.
>>     
>>>>>> - making pref. drop the default MUST and 'random' 
>>>>>>             
>> dropping the MAY 
>>     
>>>>>> would be rather empty, since existing routers do tail 
>>>>>>             
>> drop, so you 
>>     
>>>>>> - marking 'random' dropping the default would therefore 
>>>>>>             
>> seem more 
>>     
>> work, whilst 
>>>>>> MFT can also work OK.
>>>>>> - you might instead want to do tail drop, as this is 
>>>>>>             
>> what today's 
>>