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

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

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