Re: [bmwg] WGLC: draft-ietf-bmwg-igp-dataplane drafts

[Al Morton <[e-mail]>]

Adding my thoughts to one of the key issues:
Al
(as a participant)

At 10:04 AM 2/4/2010, Kris Michielsen wrote:

Anuj,
 
Comments in green, marked with [Kris1:].
I also added comments in the attached draft and attached another document with accuracy interval calculations (see below).
Please provide your feedback.
 

---

From: Dewangan, Anuj [ mailto:[e-mail]]

Sent: 24 January 2010 02:20

To: Kris Michielsen; Al Morton; [e-mail]; [e-mail]

Subject: RE: [bmwg] WGLC: draft-ietf-bmwg-igp-dataplane drafts

Hi Kris,                                                                                                                                                                               

 

I have commented inline in red and marked as

[Anuj1:]. Also I have added comments/additions to the draft and have attached it. Please look for “[Anuj:]” to find the comments. However, the draft still does not answer some problems/issues seen when such a test is performed practically:

 

1. Due to inherent jitters in the traffic forwarded by the DUT, the graph is never as smooth as in theory. Even without a convergence event, the traffic rate is seen fluctuating due to a combination of jitters in the forwarded traffic and the resolution of sampling interval, which is supposed to be as small as possible (and with the definition of atleast one packet per route) and should usually be in milliseconds for any useful/accurate measurement required. As an example, if there are only a few routes in the test, then even a couple of packets extra seen in a sampling interval (due to forwarding jitters) will cause a major fluctuation in the convergence graph. In such a case, the convergence instants are very difficult (or impossible) to calculate. This is a problem even with a “normal” number of routes but a very small sampling interval – which is possible if the offered rate (=DUT throughput) is high. This is not addressed anywhere in the draft. 

[Kris1:] This is mainly a problem in the cases where variations in rate need to be observed. For cases where there is a transition rcv rate X -> rcv rate 0 or rcv rate 0 -> rcv rate X it is less of a problem, jitter will add to the error interval which is already fairly large.
Assuming jitter is symmetric around an average forwarding delay and this average forwarding delay is constant, and assuming that jitter == n*1/Offered Load, and packet sampling interval is of duration N*#routes/Offered Load, the expected amount of packets under steady state in a packet sampling interval is between N*#routes-2n and N*#routes+2n.
If N>2n and the #received packets is outside of the above #received packets interval under steady state, one can decide a variation in rate has
If convergence has not yet completed for >=1 route during a sampling interval, the #received packets in a sampling interval is <= N*(#routes-1). So, under the above assumptions, and if N>2n one can decide the convergence recovery instant was not reached if #received packets < N*#routes-2n. So the larger the jitter, the larger the packet sampling interval needs to be to derive the convergence recovery instant.
I would propose the following change:
 
"If the Packet Sampling Interval is large
   compared to the time between the convergence time instants, then the
   different time instants may not be easily identifiable from the
   Forwarding Rate observation.  Using a small Packet Sampling Interval in the presence of jitter may cause fluctuations of the Forwarding Rate observation and can prevent accurate measurement of the different time instants. The requirements for the Packet
   Sampling Interval are specified in [Po09t].  The Packet Sampling
   Interval MUST be larger than or equal to the time between two
   consecutive packets to the same route.  For maximum accuracy the
   value for the Packet Sampling Interval SHOULD be as small as
   possible, but the presence of jitter may enforce using a larger Packet Sampling Interval.  The Packet Sampling Interval MUST be reported."
 

[ACM]  The only guidance on jitter I found in the preliminary -20 draft was in Section 5.7:
   ... When packet jitter is much
   less than the convergence time, it is a negligible source of error
   and therefore it will be ignored here.

It seems that a reasonable sanity check on the test configuration might be to measure the packet rate variation during the Packet Sampling Interval  (or jitter, above) and compare the jitter with the value for N (the number of packets sent on each route during a sampling interval). The jitter should be accounted for when determining if the rate in a particular interval is sufficient to declare the convergence recovery instant.

------------------

Speaking as chair, this rate jitter issue appears to affect the
methodologies in a few other bmwg drafts, so folks should take a look
at this and form their own opinions or add their experiences.

Al