Subject: re: [PCN] thoughts for draft-charny-pcn-single-marking

From: Anna Charny <[email-masked]>
Date: Mon, 23 Jul 2007 08:51:34 -0700 (PDT)

Hello Tina,
   
  Here are some answers to your questions, below.
   
  >Hi all,
  >Some thoughts came to my mind for draft-charny-pcn-single-marking-02.txt as below.
  >1)      If the single marking scheme could solve all the problems that the dual marking
  >  scheme could, only with very little tradeoffs? What are the biggest tradeoffs?
  >
   
  Well, I first want to emphasize that there is no clear view at the moment of which dual-marking approach to choose. Since  there are three substantially different proposals with substantially different properties, it is hard to answer your questions in a way that would apply to all dual-marking proposals.  In draft-charny-pcn-single-marking  we attempt to quantify performance tradeoffs with respect to the specific dual marking approach that was proposed in various draft-briscoe drafts prior to the PCN BOF.  Here are some (although not all) points from the single marking draft:
   
  * single marking saves a codepoint and  allows core equipment to do only one metering/marking instead of two (important since it is done in the forwarding path). This point provides the key motivation.  A secondary motivation is that it can be implemented with a (single) token bucket which most of the equipment can support today.
  * with single marking,  there is some degree of accuracy lost in the ability to deal with multi-path routing (the extent of comparative loss of accuracy differs for different dual-marking approaches)
  * there are some tradeoffs in the flexibility of traffic engineering (see appropriate section in the draft-charny-single-marking) - this tradeoff will be the same in comparison with other dual-marking approaches
  * there are some performance tradeoffs (discussed in the draft in comparison with *specific* dual marking approach).  Note that performance tradeoffs will be different for *different* dual-marking schemes currently on the table.
  * it is unclear how to deal with anti-cheating end-to-end (something virtual-queue based approach previously discussed in several draft-briscoe drafts dealt with).  Note here that it is equally unclear how to deal with the anti-cheating issue with other dual marking approaches proposed in draft-babiarz and draft-westberg.
   
  >2)      If single marking can solve all the problems, why not consider give up dual marking 
  >   approach?
   
  see above tradeoffs.  One can be prepared to live with those tradeoffs in some environments but not in others.
   
  >3)      Per draft-charny-pcn-single-marking-02, single marking approach can transit to
  >   dual marking approach, why not directly design the dual marking directly, is there 
  >    reason to keep the single marking approach?
   
  the key reasons to allow single marking would be to avoid requiring the complexity of two metering/marking in the forwarding path, saving codepoints where necessary, and to allow quick implementations 
   
  the key reason to eventually get to dual marking would be to allow eventually remove the restrictions/tradeoffs and get a more flexible scheme.    
   
  >4)      A) How to mark the interim node? Single marking approach requires marking
  >    Excess Traffic; dual marking approach does not require this, so they are impossible
  > to be compatible with each other at this point. 
   
  I think this may be some misconception here.  First I note that dual marking as described in various draft-briscoe drafts requires both excess rate and virtual queue marking, so both require excess rate marking.  Other dual marking drafts require yet different versions of marking.   
  Single marking draft argues that if a device implements only excess rate marking, then single marking approach can be used. If a device implements both excess rate marking and virtual-queue marking, then the specific version of dual marking (that of draft-briscoe...) can be used.   
   
  single-marking draft does not address at the moment whether and how single marking can live with other dual-marking approaches.  
   
  >May dual marking approach adopt only mark Excess Traffic method, whatever for
  > Admission Rate or Termination Rate?
   
  see above
   
  >B) Egress and Ingress measurement basis and decision basis are different for single
  > marking and dual marking approaches. 
   
  I note here that these decisions are also different for the multiple dual-marking approaches proposed :-).
   
  >Via the configuration to let both working modes work together, both modes can co
  >exist, but in fact they don’t have compatibility. Then why do we do it?
   
  It is probably useful to note that the measurement functions and decisions are exactly the same for single-marking and the specific dual-marking draft proposed in the briscoe drafts.   So the implementation differences at the edge nodes are almost negligible.   As to why do it - this question seems to be equivalent to why single-marking is needed which has been addressed above
   
  > C) Since single marking and dual marking don’t have compatibility, and solve the
  >  almost the same problem, do we need to select and only keep one approach?
   
  We were trying to argue both at the last IETF and in draft-charny that it may be beneficial to allow both single and dual marking approaches.  We were also arguing that the single-marking can be viewed as an intermediate step, leading to faster implementation and deployments.  We argued that in environments where the tradeoffs associated with single marking are undesirable or  unacceptable, the additional complexity of the dual marking may be necessary.  We argued that with minor changes to the architecture it is possible to allow both, and argued how transitions from one to another can be achieved.
   
  Hope this is helpful,
   
  Anna  
   
  >B. R.
  >Tina

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 24 Jul 2007 08:35:25 +0200

Hello Anna,

I like your argumentation and I subscribe to your conclusion. Start with a 
simple, easy implement solution which may not be perfect and then go on 
with more complex schemes.

A crucial point is the tradeoff of the simple solution. If that simple 
solution gets complex in standardisation or if there is a "killing 
criterium", we'd have to drop it.

Regards,

Ruediger

[snipped all but Tina's final question and your response]

> C) Since single marking and dual marking don't have compatibility, and solve the
 
Anna: We were trying to argue both at the last IETF and in draft-charny that it 
may be beneficial to allow both single and dual marking approaches.  We were 
also arguing that the single-marking can be viewed as an intermediate step, 
leading to faster implementation and deployments.  We argued that in 
environments where the tradeoffs associated with single marking are undesirable 
or  unacceptable, the additional complexity of the dual marking may be necessary.  
We argued that with minor changes to the architecture it is possible to allow 
both, and argued how transitions from one to another can be achieved.
 
Hope this is helpful,
 
Anna