Subject: RE: QoS for the CE "heartbeat" frames in HDLC and PPP PWs

From: "Santiago Alvarez" <[email-masked]>
Date: Tue, 9 Sep 2003 10:47:28 -0700

I think the current wording allows for keepalives to have the same or a
different marking (exp/dscp).  It also allows for keepalives to be carried
by a different tunnel. The benefit of providing a much higher delivery
guarantee for keepalives through the PSN may be questionable, but I don't
think it should be necessarily precluded.  I guess one could think of some
special treatment for these packets on the ACs (e.g. bypass packet metering,
special queuing/dropping treatment) but that doesn't involve the PSN or the
PW.
Cheers.

SA
--

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luca Martini
> Sent: Tuesday, September 09, 2003 8:12 AM
> To: Sasha Vainshtein
> Cc: Fred Baker (E-mail); PWE3 WG (E-mail); Alik Shimelmits
> Subject: Re: [PWE3] QoS for the CE "heartbeat" frames in HDLC 
> and PPP PWs
> 
> 
> Sasha,
> 
> this a very good point. I think that any such service will 
> most likely require 
> priority over "best effort" PSN traffic. So none the PPP/HDLC 
> frames will be 
> dropped during PSN congestion.
> 
> Pulling the LCP keepalive , or "heartbeat" frames out of the 
> PW is not easy.
> The draft design is very simple , and does not require a 
> lookup to be performed 
> on the payload.
> 
> I would like to hear from other people if this is perceived 
> to be a problem , 
> or we can simply mark all PW frames as high priority to avoid 
>  this issue.
> 
> Thanks.
> Luca
> 
> 
> Sasha Vainshtein wrote:
> > Luca, Fred and all,
> > I would like to raise the following potential issue 
> > with HDLC and/or PPP PWs as specified in 
> > draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt 
> > and in conjunction with application of principles 
> > stated in draft-baker-diffserv-basic-classes-00.txt.
> > 
> > Let's consider an HDLC or PPP PW as shown below:
> > 
> >                                                               
> >                            {-------}                          
> >             |------\      {DiffServ-}     /-------|           
> > |-----|     |       \    {  enabled }    /        |     |-----|
> > | CE-1|<--->|  PE-1 |==={ IP or MPLS }===|  PE-2  |<--->| CE-2|
> > |-----|     |       /    { network  }    \        |     |-----|
> >       |     |------/      {--------}      \-------|     |     
> >       |            |                       |            |     
> >       |            |<=== A PPP or HDLC ===>|            |     
> >       |                        PW                       |
> >       |                                                 |
> >       |<------ Emulated service (application) --------->     
> >          across a 'link' containing an HDLC or PPP PW
> > 
> > I consider the following cases of emulated services:
> > - Cisco HDLC with its keep-alive messages
> > - A FR service using some kind of LMI
> > - A PPP service using LCP.
> > 
> > In all these cases some  "heartbeat" frames are exchanged 
> between the CEs
> > in addition to the CE user traffic. If these frames are 
> treated exactly
> > as the CE user traffic by the PEs and the PSN experiences a 
> congestion,
> > they frames may be dropped and, as a consequence, the CEs will
> > recognize a false "link failure" condition. From my experience,
> > it is worth preventing such situations.
> > 
> > Please note that, at least in the case of a PPP PW, the PEs 
> can identify
> > the CE "heartbeat" frames. In case of an HDLC PW such a 
> capability could
> > be also provided.
> > 
> > If the "CE heartbeat" frames can be identified by the PEs, 
> and if the
> > PSN supports multiple DiffServ classes , it is possible
> > to improve availability of the emulated service by assigning a 
> > DiffServ class with higher reliability properties to the PW
> > packets encapsulating the "CE heartbeat" frames. However, it is not
> > clear to me if such a behavior is consistent with the basic PWE3 
> > principles. (To the best of my knowledge, nothing like this 
> have ever 
> > been mentioned in any of the PWE3 encapsulation drafts).
> > 
> > 
> > I would highly appreciate your opinion on the following questions:
> > 
> > 1. Is it acceptable to assign the HDLC or PPP PW packets 
> encapsulating
> >    the CE "heartbeat" frames to a DiffServ class that is 
> different from
> >    the class(es) to which the PW packets encapsulating the 
> CE user frames
> >    are assigned?
> > 
> > 2. If the answer to the 1st question is positive, then:
> >    a) Which DiffServ class (among the classes specified in 
> draft-baker) 
> >       seems the most appropriate, and what kind of 
> admission rule(s) 
> >       should be applied to these frames?
> >     b) What kind of a transport LSP should be used to carry an 
> >        HDLC or PPP PW across a DiffServ-enabled MPLS network?
> > 
> > With best regards,
> >                                    Sasha Vainshtein
> > email:     [email-masked]
> > tel:       +972-3-7659993 (office)
> >            +972-8-9254948 (res.)
> >            +972-58-674833 (cell.)
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Luca Martini <[email-masked]>
Date: Tue, 09 Sep 2003 09:11:34 -0600

Sasha,

this a very good point. I think that any such service will most likely require 
priority over "best effort" PSN traffic. So none the PPP/HDLC frames will be 
dropped during PSN congestion.

Pulling the LCP keepalive , or "heartbeat" frames out of the PW is not easy.
The draft design is very simple , and does not require a lookup to be performed 
on the payload.

I would like to hear from other people if this is perceived to be a problem , 
or we can simply mark all PW frames as high priority to avoid  this issue.

Thanks.
Luca

Sasha Vainshtein wrote:
> In all these cases some  "heartbeat" frames are exchanged between the CEs
> in addition to the CE user traffic. If these frames are treated exactly
> as the CE user traffic by the PEs and the PSN experiences a congestion,
> Please note that, at least in the case of a PPP PW, the PEs can identify
> the CE "heartbeat" frames. In case of an HDLC PW such a capability could
> be also provided.
> 
> If the "CE heartbeat" frames can be identified by the PEs, and if the
> principles. (To the best of my knowledge, nothing like this have ever 
> 1. Is it acceptable to assign the HDLC or PPP PW packets encapsulating
>    the CE "heartbeat" frames to a DiffServ class that is different from
>    the class(es) to which the PW packets encapsulating the CE user frames
>    are assigned?
> 
>    a) Which DiffServ class (among the classes specified in draft-baker) 
>       seems the most appropriate, and what kind of admission rule(s)

---

From: Ali Sajassi <[email-masked]>
Date: Tue, 09 Sep 2003 18:08:41 -0700

At 09:11 AM 9/9/2003 -0600, Luca Martini wrote:
>Sasha,
>
>this a very good point. I think that any such service will most likely 
>require priority over "best effort" PSN traffic. So none the PPP/HDLC 
>frames will be dropped during PSN congestion.
>
>The draft design is very simple , and does not require a lookup to be 
>performed on the payload.
>
>I would like to hear from other people if this is perceived to be a 
>problem , or we can simply mark all PW frames as high priority to 
>avoid  this issue.

There should be multiple failure of heartbeat messages before a link 
failure is recognized. So if the network congestion is bad enough that 
causes multiple heartbeat messages to be dropped, then maybe the link 
should be failed and the end user get noticed via this failure. If we treat 
these heartbeat messages with higher priority, then I am afraid this may 
give a false impression to the end user even when the PW quality is really bad.

-Ali

>Thanks.
>Luca
>
>
>Sasha Vainshtein wrote:
>>Luca, Fred and all,
>>I would like to raise the following potential issue with HDLC and/or PPP 
>>PWs as specified in draft-ietf-pwe3-hdlc-ppp-encap-mpls-00.txt and in 
>>conjunction with application of principles stated in 
>>draft-baker-diffserv-basic-classes-00.txt.
>>to improve availability of the emulated service by assigning a DiffServ 
>>class with higher reliability properties to the PW
>> draft-baker)       seems the most appropriate, and what kind of 
>> admission rule(s)       should be applied to these frames?
>>     b) What kind of a transport LSP should be used to carry 
>> an        HDLC or PPP PW across a DiffServ-enabled MPLS network?
>>With best regards,
>>                                    Sasha Vainshtein
>>email:     [email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 11 Sep 2003 20:51:31 -0400

I agree with Ali's point, and was going to post a similar answer myself 
after reading Sasha's initial email (and before reading Ali's).  The LCP 
keepalive and the FR LMI polls should have similar error characteristics as 
the PW itself - that's part of their job.  If it's important to keep the PW 
alive over a highly utilized (like that euphemism? :-) diffserv-aware 
network, then (as Luca suggested in his reply) the entire PW should receive 
an appropriate diffserv marking.

Cheers,
Andy

---------

At 9/9/2003 06:08 PM -0700, Ali Sajassi wrote:
>should be failed and the end user get noticed via this failure. If we 
>treat these heartbeat messages with higher priority, then I am afraid this 
>may give a false impression to the end user even when the PW quality is 
>really bad.
>
>-Ali

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 17 Sep 2003 09:53:50 +0200

Andrew G. Malis wrote:
> keepalive and the FR LMI polls should have similar error characteristics 
> as the PW itself - that's part of their job.  If it's important to keep 
> the PW alive over a highly utilized (like that euphemism? :-) 
> diffserv-aware network, then (as Luca suggested in his reply) the entire 
> PW should receive an appropriate diffserv marking.

Keepalives have more than one purpose. One may be to infer link quality (which 
for PPP should not be done with LCP Echos, but with PPP LQM messages). Another 
is to simply know if your peer is still alive and aware of negotiated state. For 
the latter function, assigning a higher priority to the keepalive packets makes 
sense.

- Mark

>>> this a very good point. I think that any such service will most 
>>> likely require priority over "best effort" PSN traffic. So none the 
>>> PPP/HDLC frames will be dropped during PSN congestion.
>>>
>> treat these heartbeat messages with higher priority, then I am afraid 
>> this may give a false impression to the end user even when the PW 
>> quality is really bad.
>>
>> -Ali
> 
> 
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 17 Sep 2003 19:39:05 +0200

Lloyd Wood wrote:
> On Wed, 17 Sep 2003, W. Mark Townsley wrote:
> 
> 
>>Andrew G. Malis wrote:
>>
>>Keepalives have more than one purpose. One may be to infer link
>>quality (which for PPP should not be done with LCP Echos, but with
>>PPP LQM messages).
> 
> 
> ...which aren't keepalives. Notice how RFC1989 doesn't say
> 'keepalive', though, as is traditional, it does leave heuristics and
> implementation sufficiently open to allow people to shoot themselves
> in the foot and use things not intended to be keepalives as
> keepalives.

RFC 1661 doesn't call LCP Echos keepalives either, but they tend to be called 
that in practice. I agree that the term "keepalive" is a misnomer in general, 
but this is all just so much semantic pontification.

> 
> 
>>Another is to simply know if your peer is still alive and aware of
>>negotiated state. For the latter function, assigning a higher
>>priority to the keepalive packets makes sense.
> 
> 
> I disagree. Those different-priority keepalive packets can be handled
> differently from other packets in the stream they're keeping alive in
> a number of different ways, both by intermediate boxes and by the end
> box. For example, by applying some sort of QoS filter rule or ACL on
> the priority that nixes the keepalive packets, but not the datastream,
> or vice versa. 

You're not suggesting that P routers dig into each packet to determine whether 
it is a tunneled keepalive and apply QoS accordingly at each hop?

 > And troubleshooting such behaviour is cumbersome, not
> least because the keepalive mechanism is now effectively lying to you,
> and everything depending on that mechanism gets broken. Castles built
> on sand.
> 
> Your peer is the tunnel endpoint, not the box. And you want to know if
> your datastream is being handled by that endpoint.
> 
> This is a subject that comes up every time someone decides it's a good
> idea and expedient to hardcode a different QoS/ToC value for keepalive
> packets. 

Who said anything about hardcoding? Recognizing keepalives and setting them to 
*something* is the (or at least my) central point. Whether that something is 
configurable or not is somewhat tangential to the discussion (FWIW, I think 
packet markings should always be configurable, with perhaps a well-defined or 
canonical default if one happens to exist).

 > Fix someone's short-term configuration problem, give yourself
> and your users long-term headaches. (Odd that people who think that
> magic numbers in C code are a bad idea have a different idea about
> magic numbers in protocols.)

(whatever...)

Attempting to get back to the point here, PW traffic may be treated in a number 
of ways one might not expect as it traverses its path between PEs. A common 
feature, for example, is to reflect the DSCP of inner tunneled and framed IP 
packets to the outer IP or MPLS header. Point is, the assumptions by which 
traditional LQM mechanisms may be built upon, such as a packet being used as a 
link probe being just as statistically likely to be dropped as a packet carrying 
user data due to some noise on a line, can go completely out the door on a PW.

> 
> You want to know what state has been negotiated? There are MIBs for
> that, and exposing MIBs as LQM does is neither a keepalive function
> nor of different priority.

By negotiated state, I was referring to, say, PPP state reached after the 
exchange of a number of control messages (and perhaps a few off-box server hits) 
to complete LCP, Authentication, IPCP, etc. This is a shared view of the world 
by the peers involved in the exchange, which is continually verified as current 
(or "kept alive") by LCP Echos which indicate that the peer is still there, 
still knows who you are, hasn't rebooted, etc. This particular feature of LCP 
Echos has absolutely nothing to do with the intervening nodes or even the 
quality of the line between the CEs. Thus, getting the echos between the CEs, 
even in periods of congestion on the PSN which the PW traverses, is vital so 
that you don't go around flapping the CE interfaces for the wrong reason.

- Mark

> 
> L.
> 
> rant, rant, rant; rant rant rant, grumble rant rant.
> 
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>