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

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

Hi Ruediger

The problem that I have explained it does not have to do with slow reaction
time 
but it has to do with complete collapse of the PCN domain operation. 
This occurs when the admission control/flow termination triggers at the 
egress are not activated when they should be activated.


Here is a more concrete example:

When ECMP routing is used, it means that flows that are associated with the
same 
ingress-egress-aggregate can follow different paths. 
Assume that there are 5 such paths that are carrying flows 
associated with the same ingress-egress-aggregate.

Consider now that one of the 5 paths fails and it is rerouted to one of the
other paths.
Assume that path1 is becoming congested and the other 3 remaining paths are
not congested.
I am also assuming in this case that the thresholds are well configured.

The egress will calculate CLE in the following way:
CLE = marked_1 /(unmarked_1 + unmarked_2 + unmarked_3 + unmarked_4 +
marked_1)

I think that typcially the above calculated CLE will not reach 1% when
marked 
packets are preferentially dropped.
This problem is due to the fact that ECMP routing is used and 
flows that are not participating at the congestion are contributing 
to the calculation of the CLE. The flows that are not 
passing through congested nodes will actually forward unmarked 
packets to the egress node.

When marked packets are preferentially dropped than marked_1 can easily be 
smaller than 1% * (unmarked_1 + unmarked_2 + unmarked_3 + unmarled_4 +
marked_1). 
In this case the admission control situation is not triggered and a 
complete collapse of the PCN domain operation can occur!

Thus:
If no ECMP routing would have been used than for the same situation 
CLE = marked_1/unmarked_1 + marked_1), which can go easily to 1%, if the
C-A-R is well configured.

But when ECMP routing is used and the above scenario is applied 
then CLE = marked_1 /(unmarked_1 + unmarked_2 + unmarked_3 + unmarled_4 +
marked_1), 
which probaly will not reach 1% when marked packets are preferentially
dropped, 
since marked_1 can be 
smaller than 1% * (unmarked_1 + unmarked_2 + unmarked_3 + unmarled_4 +
marked_1)

I hope that you now understand the problem!

Best regards,
Georgios 

> -----Original Message-----
> From: Geib, Ruediger [mailto:[e-mail]] 
> Sent: dinsdag 18 maart 2008 8:30
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> 
> Hi Georgios,
> 
> in the situation you describe, packet losses occur. This will 
> result in bad press, as the customers using PCN based 
> services were promised another type of service.
> 
> In this situation it doesn't matter whether or not ECMP is 
> deployed and it also doesn't matter whether termination is 
> fair or not. The important event is: packet losses occur (in 
> one of your examples several routers drop packets). The drops 
> are the only relevant issue. 
> Whether service resumes after 5 seconds due to extremly well 
> engineered termination or after 10 seconds after a sufficient 
> number of customers hang up is not important. 
> I can't recall having read anytime in the news "Major network 
> outage - but termination was fair." I can only recall having 
> seen the first part.
> 
> I'm sure you're happy in adapting your example, as you do all 
> the time. I'm having work to do, but maybe someone else is 
> interested in continuing discusion. I think, I've made my point.
> 
> Regards,
> 
> Rudiger
> 
> | -----Original Message-----
> | From: Georgios Karagiannis [mailto:[e-mail]]
> | Sent: Monday, March 17, 2008 5:36 PM
> | To: Geib, Rüdiger
> | Cc: [e-mail]
> | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> | 
> | 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