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

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

Hi Phil

Actually the problem is that when ECMP routing is used, then 
the stability/robustness during a catastrophic event (thus flow termination)
of the PCN domain operation is decreased.  Therefore, we should not mandate 
to preferentially drop marked packets.

Please note that I have identified this problem after the 
IETF meeting.

Best regards,
Georgios


 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: woensdag 19 maart 2008 15:50
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> 
> Georgios
> 
> - it would have been very useful to have raised this last 
> week at IETF. Progress is so much easier face to face.
> - are you talking about admission or termination? I got 
> confused; your emails didn't seem consistent.
> - I haven't read all the emails in detail, but I don't 
> understand what are you saying that's different from 
> http://www.ietf.org/internet-drafts/draft-charny-pcn-compariso
n-00.txt ?  eg Table 8.1 extract:
>     
> -------------------------------------------------------------------|
>    |Comparison    |      SM       |       3SM        |      
> CL         |
>    |criteria      |               |                  |        
>          |
>    
> |--------------------------------------------------------------------
>    
> |-------------------------------------------------------------------|
>    |ECMP support  |no;   only     |     yes          | no;  
> but full   |
>    |for           |partial support|                  | 
> support with    |
>    |Termination   |with additional|                  | 
> additional      |
>    |              | complexity at |                  | 
> complexity at   |
>    |              | the edge +    |                  | the 
> edge +      |
>    |              | signaling flow|                  | plus 
> signalling |
>    |              | flow IDs from |                  | flow 
> IDs from   |
>    |              | egress to     |                  | egress 
> to       |
>    |              | ingress       |                  | 
> ingress         |
>    
> |-------------------------------------------------------------------|
>    |ECMP support  |no w/out probes| no w/out probing | no 
> w/out probing|
>    |for Admission |yes with probes| yes with probing | yes 
> with probing|
>    |              |but needs many |(needs one probe, |(needs 
> one probe,|
>    |              |probes; use of |can use RSVP as   | can 
> use RSVP    |
>    |              |RSVP as probes |probe)            | as 
> probe)       |
>    |              |not understood |                  |        
>          |
>    
> |-------------------------------------------------------------------|
> 
> - you seem to be saying that preferential dropping of 
> excess-rate-marking pkts in your view can lead to problems - 
> and proposing instead random dropping, but saying this can 
> also lead to the same problem (but maybe not as often). Is that right?
> 
> best wishes,
> phil
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of 
> > Geib, Ruediger
> > Sent: 19 March 2008 13:42
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
> > 
> > Hi Georgios,
> > 
> > I assume the costs to marginal as compared to the 
> expenditure required 
> > to avoid these losses. We face tough regulation and can't stay in 
> > business if we engineer networks for resilience during catastrophic 
> > outages. These times are gone.
> > 
> > During catastrophic outages, my operational staff will require good 
> > OAM tools to enable return to bearable operation as soon as 
> possible. 
> > To me, OAM is the only section in PCN drafts I'd like to be 
> addressed 
> > to deal with catastrophic outages.
> > 
> > Regards
> > 
> > Rudiger
> > 
> > | -----Original Message-----
> > | From: Georgios Karagiannis [mailto:[e-mail]]
> > | Sent: Wednesday, March 19, 2008 2:21 PM
> > | To: Geib, Rüdiger
> > | Cc: [e-mail]
> > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> > |
> > | Hi Ruediger
> > |
> > | I do not know, but when such an event occurs, what are then the 
> > | costs involved associated with the financial losses and customer 
> > | losses for an operator of a large network with a huge number of 
> > | subscribers?
> > |
> > | Best regards,
> > | Georgios
> > |
> > |
> > |
> > | > -----Original Message-----
> > | > From: Geib, Ruediger [mailto:[e-mail]]
> > | > Sent: woensdag 19 maart 2008 14:17
> > | > To: [e-mail]
> > | > Cc: [e-mail]
> > | > Subject: RE: [PCN] Concensus questions from Thursday's 
> PCN meeting
> > | >
> > | > Hi Georgios,
> > | >
> > | > could you give us an estimate of the propability that 
> this problem 
> > | > occurs? How often within a year?
> > | >
> > | > Regards,
> > | >
> > | > Rudiger
> > | >
> > | >
> > | > | -----Original Message-----
> > | > | From: Georgios Karagiannis [mailto:[e-mail]]
> > | > | Sent: Wednesday, March 19, 2008 1:35 PM
> > | > | To: Geib, Rüdiger
> > | > | Cc: [e-mail]
> > | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN 
> > | > | meeting
> > | > |
> > | > |
> > | > |  Hi Ruediger
> > | > |
> > | > | It is not a new solution! What I describe are problems that
> > | > are in my
> > | > | opinion occuring when the PCN domain uses ECMP routing,
> > | AND when a
> > | > | catastrophic event occurs AND when marked packets are
> > | > preferentially
> > | > | dropped.
> > | > | The only thing that I am trying to say, is PLEASE DO NOT
> > | > mandate the
> > | > | preferentially dropping of  marked packets, such that we
> > | can avoid
> > | > | such difficult and nasty problems.
> > | > |
> > | > | I am not proposing here another solution.
> > | > |
> > | > |
> > | > | Best regards,
> > | > | Georgios
> > | > |
> > | > | > -----Original Message-----
> > | > | > From: Geib, Ruediger [mailto:[e-mail]]
> > | > | > Sent: woensdag 19 maart 2008 13:06
> > | > | > To: [e-mail]
> > | > | > Cc: [e-mail]
> > | > | > Subject: RE: [PCN] Concensus questions from Thursday's
> > | PCN meeting
> > | > | >
> > | > | > Hi Georgios,
> > | > | >
> > | > | > with how many operator representatives involved into
> > | > | backbone traffic
> > | > | > engineering including activation of ECMP did you 
> talk prior to 
> > | > | > proposing your solution on this mailing list?
> > | > | >
> > | > | > Regards,
> > | > | >
> > | > | > Rudiger
> > | > | >
> > | > | >
> > | > | > | -----Original Message-----
> > | > | > | From: Georgios Karagiannis [mailto:[e-mail]]
> > | > | > | Sent: Wednesday, March 19, 2008 12:38 PM
> > | > | > | To: Geib, Rüdiger; [e-mail]
> > | > | > | Cc: [e-mail]
> > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's
> > | > PCN meeting
> > | > | > |
> > | > | > | Hi Rudeiger
> > | > | > |
> > | > | > | What I am proposing is how to achieve a robust/stable PCN
> > | > | operation
> > | > | > | when the PCN domain uses ECMP routing and when a
> > | > | catastrophic event
> > | > | > | occurs.
> > | > | > |
> > | > | > | Best regards,
> > | > | > | Georgios
> > | > | > |
> > | > | > |
> > | > | > |
> > | > | > |
> > | > | > |
> > | > | > | > -----Original Message-----
> > | > | > | > From: [e-mail] 
> [mailto:[e-mail]] 
> > | > | > | > On
> > | > | > | Behalf Of
> > | > | > | > Geib, Ruediger
> > | > | > | > Sent: woensdag 19 maart 2008 11:37
> > | > | > | > To: [e-mail]
> > | > | > | > Cc: [e-mail]
> > | > | > | > Subject: Re: [PCN] Concensus questions from Thursday's
> > | > | PCN meeting
> > | > | > | >
> > | > | > | > Steven,
> > | > | > | >
> > | > | > | > what Georgios is proposing is to optimise PCN so that
> > | > it works
> > | > | > | > properly if a catastrophic event coincides with a
> > | > misconfigured
> > | > | > | > router.
> > | > | > | >
> > | > | > | > If this is the main or even an important task 
> of PCN, then
> > | > | > | I waste my
> > | > | > | > time here.
> > | > | > | >
> > | > | > | > The salary I obtain monthly depends on my companies
> > | > | > | backbone network
> > | > | > | > providing good service to customers under regular
> > | operational
> > | > | > | > conditions (which cover planned outages and expectable
> > | > | > | failures). The
> > | > | > | > telephony or streaming services offered to our
> > | > customers should
> > | > | > | > experience a minimised network impact on the Quality of
> > | > | > Experience
> > | > | > | > perceived by the consumers under regular operational
> > | > | > | conditions. This
> > | > | > | > includes the creation of a "Network Busy Indication", 
> > | > | > | > which
> > | > | > | however is
> > | > | > | > a rare event. So my position on what PCN should be
> > | > | > | optimised for is to
> > | > | > | > create this "network busy indication" for regular
> > | operational
> > | > | > | > conditions, reliably and only if it is required.
> > | > | > | > This should be done with the least possible complexity
> > | > | > | (like the least
> > | > | > | > possible flow awareness, the least codepoint
> > | > | consumption, simple
> > | > | > | > queuing/policing and measurement functions, 
> utmost re-use
> > | > | > | of allready
> > | > | > | > implemented features).
> > | > | > | >
> > | > | > | > To clarify what I mean by a rare event: a well 
> engineered
> > | > | > backbone
> > | > | > | > creating a PCN network busy indication either during a
> > | > | > main traffic
> > | > | > | > hour or after a re-routing event. During ISDN times,
> > | > | engineering
> > | > | > | > resulted in what Americans called 5ESS 
> switches, aiming on
> > | > | > | a network
> > | > | > | > busy indication probability of (100 - 99,999%, the 5
> > | > | > nines). We may
> > | > | > | > see that a bit more relaxed for IP networks, but I don't
> > | > | > think the
> > | > | > | > customers of my company should experience the
> > | > | consequences of PCN
> > | > | > | > behaviour more often than in (100 - 99,x)%.
> > | > | > | >
> > | > | > | > I don't look at PCN as a replacement of network
> > | > | > engineering, it is
> > | > | > | > rather an add on to guarantee service quality 
> of admitted
> > | > | > users by
> > | > | > | > stopping admission of new traffic once 
> engineering reaches
> > | > | > | its limits.
> > | > | > | > Under regular operational conditions.
> > | > | > | >
> > | > | > | > If someone now answers to this mail: uhh, just 
> that - easy!
> > | > | > | > Then lets move this easy thing to WGLC. Now. I
> > | can't see that.
> > | > | > | >
> > | > | > | > If the PCN WG indeed has completely different aims, then
> > | > | > | I'm sorry for
> > | > | > | > bothering you with my mails (but I wonder 
> whether I'm the
> > | > | > | one having
> > | > | > | > gotten things wrong).
> > | > | > | >
> > | > | > | > By the way, I'm happy with the progress visible in the
> > | > | > | questions you /
> > | > | > | > the WG has formulated. That looks like a constructive
> > | > approach.
> > | > | > | >
> > | > | > | > Regards,
> > | > | > | >
> > | > | > | > Rudiger
> > | > | > | >
> > | > | > | >
> > | > | > | >
> > | > | > | > | -----Original Message-----
> > | > | > | > | From: Steven Blake [mailto:[e-mail]]
> > | > | > | > | Sent: Tuesday, March 18, 2008 3:19 PM
> > | > | > | > | To: Geib, Rüdiger
> > | > | > | > | Cc: [e-mail]
> > | > | > | > | Subject: Re: [PCN] Concensus questions from Thursday's
> > | > | > PCN meeting
> > | > | > | > |
> > | > | > | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, 
> Ruediger wrote:
> > | > | > | > |
> > | > | > | > | > 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.
> > | > | > | > |
> > | > | > | > | Ruediger,
> > | > | > | > |
> > | > | > | > | If I follow this comment to its logical conclusion,
> > | > | then PCN is
> > | > | > | > | superfluous in this network.  Is that what you are
> > | > | > trying to say?
> > | > | > | > |
> > | > | > | > |
> > | > | > | > | Regards,
> > | > | > | > |
> > | > | > | > | 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > | > | > | > | Steven Blake                
> <[e-mail]>
> > | > | > | > | Ericsson/Redback Networks               +1 
> 919-472-9913
> > | > | > | > |
> > | > | > | > |
> > | > | > | > _______________________________________________
> > | > | > | > PCN mailing list
> > | > | > | > [e-mail]
> > | > | > | > https://www.ietf.org/mailman/listinfo/pcn
> > | > | > | >
> > | > | > |
> > | > | > |
> > | > | > |
> > | > | >
> > | > |
> > | > |
> > | > |
> > | >
> > |
> > |
> > |
> > _______________________________________________
> > PCN mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pcn
> 


_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn