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

["Georgios Karagiannis" <[e-mail]>]

Hi Ruediger

Please note that what I have described holds also for 
the situation that the routers are well configured, but a catastrophic event
occur 
and at the same time ECMP routing is used.

Best regards,
Georgios


> -----Original Message-----
> From: Geib, Ruediger [mailto:[e-mail]] 
> Sent: maandag 17 maart 2008 17:10
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> 
> Hi Georgios,
> 
> what I say is if PCN decides to deal with catastrophic events 
> in combination with misconfigured routers, then it will end 
> up standardising solutions for academic problems.
> 
> Regards,
> 
> Rudiger
> 
> 
> | -----Original Message-----
> | From: Georgios Karagiannis [mailto:[e-mail]]
> | Sent: Monday, March 17, 2008 4:38 PM
> | To: Geib, Rüdiger
> | Cc: [e-mail]
> | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> | 
> | Hi Ruediger
> | 
> | I do not understand what you try to say. Please note that flow 
> | termination is used for the below explained reason, see below text 
> | taken from the PCN architecture draft:
> | 
> | o  The termination mechanism complements admission control.  It
> |       allows the network to recover from sudden unexpected surges of
> |       PCN-traffic on some links, thus restoring QoS to the remaining
> |       flows.  Such scenarios are expected to be rare but not 
> | impossible.
> |       They can be caused by large network failures that 
> redirect lots 
> | of
> |       admitted PCN-traffic to other links, or by malfunction of the
> |       measurement-based admission control in the presence 
> of admitted
> |       flows that send for a while with an atypically low 
> rate and then
> |       increase their rates in a correlated way.
> | 
> | Best regards,
> | Georgios
> | 
> |  
> | 
> | > -----Original Message-----
> | > From: Geib, Ruediger [mailto:[e-mail]]
> | > Sent: maandag 17 maart 2008 16:32
> | > To: [e-mail]
> | > Cc: [e-mail]
> | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> | > 
> | > Hi Georgios,
> | > 
> | > QoS on redundant links means, that one link is able to
> | carry the QoS
> | > traffic of the other. This may not hold for non QoS
> | traffic. This is,
> | > what typical carrier backbones providing QoS are engineered for 
> | > (commonly known as traffic engineering).
> | > 
> | > Should a misconfiguration occur, things may go wrong. 
> | > Operational staff corrects this a soon as the misconfiguration is 
> | > identified.
> | > 
> | > The engineering of carrier backbones is often done with automated 
> | > tools, leaving little room for human errors.
> | > However maintenance work may result in humanne system
> | interference. I
> | > doubt that Telekom's engineering department is willing to
> | accept extra
> | > protocol and router complexitiy to deal with operator 
> configuration 
> | > errors. While I time and again hear of the worst
> | misconfigs, I can't
> | > recall that my colleagues try to adapt standardisation afterwards.
> | > 
> | > Regards,
> | > 
> | > Rudiger
> | > 
> | > | -----Original Message-----
> | > | From: Georgios Karagiannis [mailto:[e-mail]]
> | > | Sent: Monday, March 17, 2008 3:34 PM
> | > | To: Geib, Rüdiger
> | > | Cc: [e-mail]
> | > | Subject: RE: [PCN] Concensus questions from Thursday's 
> PCN meeting
> | > | 
> | > | Hi Ruediger
> | > | 
> | > | Please note that typical IP networks (thus not MPLS/GMPLS based
> | > | domains) can recover from failures by using rerouting.
> | > | Or do you know another standardized mechanism in typical IP
> | > networks
> | > | (thus not MPLS/GMPLS based) that can provide another kind
> | > of recovery
> | > | from failures.
> | > | 
> | > | Furthermore, I will just explain the example again with maximum 
> | > | capacity of
> | > | pathh2 being equal
> | > | to maximum capacity of path1 = C.
> | > | Please explain what you do not understand in this example!
> | > | 
> | > | 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 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 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 100%.
> | > | Note that the routers in path1 will mark the excess rate
> | > above C, thus
> | > | 1*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 15:26
> | > | > To: [e-mail]
> | > | > Cc: [e-mail]
> | > | > Subject: RE: [PCN] Concensus questions from Thursday's
> | PCN meeting
> | > | > 
> | > | > 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