Subject: LQM over SONET

From: "Kim Edwards" <[email-masked]>
Date: Fri, 16 Mar 2001 10:07:09 -0500

I was wondering if anyone was using LQM over packet over SONET (POS)
interfaces because I cannot see how it can provide accurate performance
measurements.

Let's assume we are receiving 8000000 packets/sec (OC-192, 10 GBits/s
with 1500 byte packets).

When I receive an LQR packet, it is excepted up to software. While the
LQR packet is being processed by software, the hardware datapath can be
simultaneously receiving more data traffic. Therefore, the
ifInUinPackets and ifInNUniPackets counters will be increasing. By the
time software retrieves the ifIn counters, they have already increased.
Hence, when we attempt to perform quality measurements over the incoming
link, the delta  for SaveInPackets will be inaccurate as it contains
packets after the LQR packet was received and before the ifIn counters
could be retrieved.

If we assume a 10 msec delay to process the LQR packet and retrieve the
ifIn counters, we would have received 8000 packets before being able to
retrieve the ifIn counters.

Secondly, at OC-192 rates, the 32 bit octet counters will wrap every 3
seconds; suggesting that we would have to send LQR packets at least
every 3 secs which will add a lot of congestion in your network.

Kim

---

From: James Carlson <[email-masked]>
Date: Fri, 16 Mar 2001 17:08:16 -0500 (EST)

> Let's assume we are receiving 8000000 packets/sec (OC-192, 10 GBits/s

Those numbers look strange to me; the packets per second is off by a
factor of 10.  Subtracting out the SONET overhead, I see 9.58464Gbps
on OC-192c.  That's 9.58464E9/1500/8 = 798720 packets per second.
(Ignoring the RFC 1662 overhead, which is statistical and normally
about 1%.)

> retrieve the ifIn counters.

True; but you should always be off by about this amount.  All that
matters here are the approximate packet counts that are seen in a
given interval and the number of link errors relative to that.  These
are very rough numbers, and adding 1% error isn't going to affect
them.

(I would think that the section and path error monitoring in SONET
would be more interesting than LQR ...)

> seconds;

Right.

> suggesting that we would have to send LQR packets at least

Really?  One extra 48 octet (+8 nominal PPP overhead) packet out of
2.4 million 1500 octet packets causes noticable congestion on that
link?  How is that possible?

I think you should be able to send tens of thousands of LQR packets
per second without causing noticable link congestion.  (The software
might have trouble, but the link should not.)

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

---

From: "Kim Edwards" <[email-masked]>
Date: Mon, 19 Mar 2001 08:19:10 -0500

James,

> (Ignoring the RFC 1662 overhead, which is statistical and normally

... thanks for pointing that out, I should have cut and paste the 800k
number from my calc (typo)

> are very rough numbers, and adding 1% error isn't going to affect

... sure, I'll buy that

> would be more interesting than LQR ...)

... my intention was to use the SONET PMs for link quality, but I have also
been requested to support LQM. I cannot find anyone POS interfaces in the
market that support LQM.

Do you know of any POS devices using LQM?

> might have trouble, but the link should not.)

... I am not affraid of congestion on the link; our box has such a rich
feature set, that I am affraid software will not be able to keep up with all
of the processing (stats collection, SONET APS processing, SONET PMs, MPLS,
IP, PPP, LQM, MLT ...)

... your congestion assumption is absolutely correct and I should have
worded my statement more accurately

Many thanks,

Kim

---

From: James Carlson <[email-masked]>
Date: Mon, 19 Mar 2001 11:36:46 -0500 (EST)

> Do you know of any POS devices using LQM?

Don't Cisco GSR-12000 routers do this?

I worked on LQM support at Ironbridge, but that product never saw
daylight.

> of the processing (stats collection, SONET APS processing, SONET PMs, MPLS,

Except for extreme circumstances -- if, for example, nobody could
implement the protocol -- the standards process really doesn't address
such issues.  The standard IETF response is that you need to solve
that problem yourself.  Buy a faster CPU, distribute the load among
multiple processors, design hardware assistance, et cetera.

It's a system design issue, not a protocol issue.