Subject: Re: OAM functionality (Was: RE: can egress know the ingressof a packet?)

From: Florian-Daniel Otel <[email-masked]>
Date: Mon, 12 Jun 2000 23:11:15 +0200 (MEST)

> In message <[email-masked]>, Florian-Daniel O
> tel writes:
>> 
>> 
>> Curtis,
>> 
>> I was pondering a bit about you LQM proposal. AFAIK PPP LQM requires
>> that you have special LQM payload, signaled as such by the LCP
>> Protocol/PayloadID header field  (I don't recall right now the exact
>> name). Bringing this to MPLS, you're proposing:
>> -To signal LQM packet via some reserved (read: OAM) label. E.g. ala
>> 'modes' proposed by Ben.
>> -Payload carrying e.g. LSP counters. Well, how do you propose
>> to have this ? Keeping the same label stack and putting a 'special'
>> payload (oh Lord.....!!) ?  Extending ICMP w/ a special packet type to
>> carry LQM info ? In both these cases don't you need to pop (and save)
>> the _whole_ label stack ?!! How about the reverse (i.e. response)
>> traffic ? 
>> 
>> Best regards,
>> 
>> Florian.
>> 
>> P.S. I took this 'rather'  off-list as both issues might be a question
>> of personal understanding  and sound really scary... :)

> To signal LQM you would use a reserved label and a special payload.
> The payload would identify an LSP and contain the exact count of
> packets and octets sent on that LSP at the time the LQM packet was
> sent and at the time the packet was received.  To be absolutely
> accurate, the counters would have to be sampled by hardware before
> inserting the packet into the data stream and before diverting the
> packet to software on the receiving side.

> This does require hardware change in order to be accurate.  It
> requires that counter be moved into packet payload when a specific
> label is encountered at an ingress and egress.

> An inaccurate measurement can be made by placing the counters into the
> packet in software at the ingress and sampling the counters at the
> egress after the packet was diverted.  LQM works by subtracting the
> results from two samplings.  If the queue lengths differ in the
> samplings, the differences will have some inaccuracy.  If the
> samplings are 1 second apart, and the maximum queue depth is 100ms,
> the error could be at most 10%.  This is not sufficient for loss
> measurement, but fine for connectivity (if hardware had a problem but
> LQM packets arrived intact, the sending counters would advance and the
> receive counters would not.  Loss measurements over the entire LSP
> could be made by subtracting samplings farther apart, for example 600
> seconds (10 minutes) would be expected to be accurate to at least 0.1%
> (sample interval 6,000 times the maximum queue depth).  This would be
> sufficient for most (but not all) SLAs and much more accurate than
> trying to probe the network with pings or lots of OAM packets.

> For PPP LQM there could only be forward traffic, no reverse traffic.
> Only the egress would know what the loss rate was.  I'm assuming that
> the NMS would sample the counters directly or that the egress would
> generate traps if connectivity was lost or loss exceeded threshholds.

> Curtis

> ps- The suggestion that LQM be divorced from PPP and made more
> generally available is not a new one.  It goes back as far as 1995 and
> maybe earlier.  The NSFNET played around with a user land application
> known as PMLQM (poor mans LQM, because it had no support in the
> hardware) for use with non-PPP serial links.  The UDP packet load was
> too high for a host to send probe packets and access to counters was
> slow enough (could be inaccurate by seconds) that the work never
> progress beyond the NSF test network.  In that case the sampling of
> counters by the router's own control software was sufficiently skewed
> in time that it was decided to stick to subtracting counters obtained
> from SNMP.  Some time later there was discussion of putting some form
> of LQM into IP as an IP header option such that loss over ATM VCs
> could be accurately measured (since cell loss rates didn't translate
> into packet loss due to "packet shredding" effects).

Well, I'll put it bluntly (as I almost always tend to do):

IMHO this sounds too complicated, requiring hardw. assistance (as yourself
mentioned) and lot of overhead processing. The claimed payoff ?
Millisecond resolution per LSP (unidirectional) for packet counters. 

What you are proposing reminds me the story behind IP TTL field:
Remember that it was supposed to be decremented both at ingress and
egress and now IPv6 recognized the common practice  and made it a
simple hop count ? Well, you can argue that this  OAM we're talking
about and the overhead for this type of traffic is acceptable. But yet
again, my whole point was that (AFAIG) people tend to cut corners when
it comes to hairy (read: requiring extensive processing) things. So,
as Neil also noted, this seems to be  over-engineering.

With kind regards,

Florian.

P.S. Forgot to mention: Assuming that you get this done and you do get
millisecond (or whatever. Read: _small_) resolution packet counters,
using this information e.g. to compute jitter, packet delay, etc. is
computationally expensive and i cannot tell how relevant it would be
relative to the transmission ambiguities (e.g. relative queuing time)
at each intermediate hop.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 12 Jun 2000 23:41:42 -0400

In message <[email-masked]>, Florian-Daniel O
> Millisecond resolution per LSP (unidirectional) for packet counters. 

The paragraph above explains how to get reasonable measurements
without hardware assist.

The benefit is very accurate loss measurements without adding probe
traffic.

> as Neil also noted, this seems to be  over-engineering.

That leaves us with just a single OAM packet type, a continuity probe.

Curtis