Re: [PCN] Concensus questions from Thursday's PCN meeting

["Geib, Ruediger" <[e-mail]>]

Hi Georgios,

Unfortunately you missed my point.

No such thing as you describe has been, is or will for 
the foreseeable future be engineered in the IP backbone 
of the company I'm working for. 

My expectation on the backbone of any carrier offering 
transport QoS is, that it is engineered to survive probable
failures (like single link losses) without impact on the 
performance of QoS traffic. This is where we should start 
from, if we discuss PCN. From there on, PCN is able to 
add value. 

Links without traffic engineering followed by misconfigured 
routers aren't the arguments which will convince 
either product management or backbone engineering of the 
company I work for to deploy PCN. 

As a general comment: I don't regard PCN as a plug and 
play toy for the operational equivalent of a 'script 
kiddie'. If others share that view and our documents 
don't state that, we should add text.

Regards,

Rudiger

| -----Original Message-----
| From: Georgios Karagiannis [mailto:[e-mail]] 
| Sent: Monday, March 17, 2008 2:49 PM
| To: Geib, Rüdiger
| Cc: [e-mail]
| Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| 
| Hi Ruediger
| 
| You missed my point!
| The explanation applies to all types of IP networks.
| Please note that the problem occurs also when path2 and path1 
| use exactly the same maximum capacity, say C!
| 
| In this case, if pathh2 fails then path1 will see an excess 
| rate equal to at least C.
| The rest of the explanation is identical to the one used 
| during my previous example!
| 
| 
| 
| Best regards,
| Georgios
| 
| 
| 
|  
| 
| > -----Original Message-----
| > From: Geib, Ruediger [mailto:[e-mail]]
| > Sent: maandag 17 maart 2008 14:34
| > To: [e-mail]
| > Cc: [e-mail]
| > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > 
| > Hi Georgios,
| > 
| > What you describe isn't backbone traffic engineering. What you 
| > describe may happen in corporate VPNs, where a DSL access 
| is used to 
| > back up a WAN Fast Ethernet access or the like. I don't 
| object to have 
| > standards on PCN for VPNs, but I'm not interested in this issue for 
| > now.
| > 
| > If you know any carrier who's operating his network with a
| > 16:1 load balancing for QoS traffic on any particular link 
| set, please 
| > publish the name, we are all interested in hearing it.
| > 
| > Regards,
| > 
| > Rudiger
| > 
| >  
| > 
| > | -----Original Message-----
| > | From: Georgios Karagiannis [mailto:[e-mail]]
| > | Sent: Monday, March 17, 2008 11:03 AM
| > | To: Geib, Rüdiger
| > | Cc: [e-mail]
| > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
| > | 
| > | Hi Ruediger
| > | 
| > | I will try to explain this more clearly.
| > | Here are the assumptions:
| > | * In the PCN domain we assume that ECMP routing is possible!
| > | * ingress-eggress-aggregate can contain flows that are
| > passing through
| > | one path or more paths (when ECMP routing is used).
| > | 
| > | * routers are currently dropping packets randomly. Thus 
| marked and 
| > | unmarked packets will be
| > |   dropped randomly
| > | 
| > | * When excess rate measurements are used, the triggering of
| > admission
| > | control and flow
| > |   termination are done at the egress by using the CLE. One
| > example of
| > | this trigger is:
| > |   CLE > 1%. Note that CLE = marked/(unmarked + marked). 
| This means 
| > | that if this trigger is not activated while a severe
| > |   congestion occurs in the PCN domain, then the operation
| > of the PCN
| > | domain will completely collapse.
| > | 
| > | 
| > | My statement is:
| > | If the routers do not preferentially drop marked packets
| > then the PCN
| > | domain operation, even in corner case and misconfiguration
| > situations,
| > | is more robust and more stable than in the situation that
| > the router
| > | is preferentially dropping marked packets.
| > | 
| > | The below example show such a corner case!
| > | 
| > | 
| > | I will describe two situations:
| > | 
| > | Situation 1:
| > | Consider that an ingress-egress-aggregate due to ECMP routing it 
| > | includes flows that are passing from at least two paths.
| > | Assume that path1 supports a maximum bandwidth capacity of C. 
| > | Now consider
| > | that the maximum bandwdith capacity of path2 is 15*C.
| > | Consider also that both paths are fully utilized.
| > | 
| > | Consider that preferentially marked packets are dropped and
| > that path2
| > | fails.
| > | Now assume that all (maximum) traffic passing through 
| path2 will be 
| > | rerouted through path1.
| > | If a bottleneck router located in path1, say Rbott, is
| > misconfigured
| > | (i.e., from the point of view of having wrongly too high 
| > | configured-admissible-rate value), or even if it is well
| > configured,
| > | then it can be possible that CLE measured at the egress
| > cannot reach
| > | 1%.
| > | Note that
| > | CLE = marked packets/ (marked packets + unmarked packets).
| > | This is because Rbott will just allow an excess rate to
| > pass through
| > | that is
| > | 
| > | equal to: C - configured-admissible-rate. The rest of the marked 
| > | packets, so the rest of the excess rate, will be dropped 
| by Rbott, 
| > | since this router is preferentially dropping marked packets.
| > | Furthermore, note that due to the ECMP routing flows that are 
| > | belonging to the same ingress-egress-aggregate and that 
| are passing 
| > | through another path,
| > | 
| > | than path1, which is not congested, will forward traffic
| > towards the
| > | egress node that will be unmarked.
| > | This will mean that the CLE > 1% will not be triggered,
| > this will mean
| > | that the flow termination will not be triggered and that
| > the operation
| > | of the PCN domain will collapse completely.
| > | 
| > | 
| > | Situation 2:
| > | Now consider that the router just operates as currently, i.e., no 
| > | preferential drop, randomly dropping marked and unmarked packets.
| > | Consider also that the two paths described in Situation 1 
| above are 
| > | used, ECMP routing is used, and that they are fully utilized.
| > | Assume also that path2 fails and that the path2 traffic is
| > rerouted on
| > | path1.
| > | Now the CLE value will have a higher probability of reaching the 
| > | triggering value of 1%.
| > | 
| > | This is because the routers in path1 will drop randomly 
| marked and 
| > | unmarked packets.
| > | It is more certain that in this case the CLE will reach 1%
| > due to the
| > | following reason.
| > | In this example it is assumed that the maximum bandwidth capacity 
| > | supported by path2 is 15*C.
| > | This means that after rerouting the traffic from path2 into
| > path1, the
| > | ratio between marked packets and unmarked packets that 
| are passing 
| > | thorugh path1 can be equal or higher than 16.
| > | Note that the routers in path1 will mark the excess rate
| > above C, thus
| > | 16 * C (i.e., the rerouted traffic from path2) as marked.
| > | The above observation holds also for the situation that 
| the routers 
| > | are preferentially dropping unmarked packets.
| > | 
| > | Thus when routers are preferentially dropping marked packets the 
| > | robustness of the PCN domain operation is decreasing and in
| > some cases
| > | it severely decreases, which could cause the complete
| > collapse of the
| > | PCN domain operation.
| > | 
| > | Best regards,
| > | Georgios
| > | 
| > | 
| > | 
| > | 
| > | 
| > | > -----Original Message-----
| > | > From: Geib, Ruediger [mailto:[e-mail]]
| > | > Sent: maandag 17 maart 2008 9:42
| > | > To: [e-mail]
| > | > Cc: [e-mail]
| > | > Subject: RE: [PCN] Concensus questions from Thursday's 
| PCN meeting
| > | > 
| > | > Hi Georgios,
| > | > 
| > | > PCN is designed for deployment in traffic engineered networks. 
| > | > Please decribe, how to engineer a high performance
| > carrier backbone
| > | > and then review the assumptions your discussion is based on.
| > | > 
| > | > Regards,
| > | > 
| > | > Rudiger
| > | > 
| > | > | -----Original Message-----
| > | > | From: Georgios Karagiannis [mailto:[e-mail]]
| > | > | Sent: Monday, March 17, 2008 9:34 AM
| > | > | To: Geib, Rüdiger
| > | > | Cc: [e-mail]
| > | > | Subject: RE: [PCN] Concensus questions from Thursday's
| > PCN meeting
| > | > | 
| > | > | Hi Ruediger
| > | > | 
| > | > | What do you mean?
| > | > | Do you mean that you do not want to discuss corner cases
| > | > (ECMP related
| > | > | cases) that could
| > | > | collapse the PCN domain operation?
| > | > | What I am saying is that if the routers do not
| > | preferentially drop
| > | > | marked packets then the PCN domain operation is more robust
| > | > and more
| > | > | stable than in the situation that the router is 
| preferentially 
| > | > | dropping marked packets.
| > | > | 
| > | > | Are you saying that this statement is not right?
| > | > | 
| > | > | 
| > | > | Best regards,
| > | > | Georgios
| > | > |  
| > | >
| > | 
| > | 
| > | 
| > 
| 
| 
| 
_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn