Subject: RE: [bmwg] Some issues in RFC-2544

From: Jim McQuaid <[email-masked]>
Date: Fri, 14 Feb 2003 13:33:06 -0500

A quick thought about item #2 below.

You wrote:

	"in most cases leads to queue buildup in the DUT, resulting in
extemely high latency measurement."

This is true of one class of architectures but is not true of some others.
L2 switches, for example and other hardware level switching tends to
function without much queueing.  So the test and the metric, as currently
described, provides a pretty clear insight into that issue.

Put another way, the high latency is not a "problem" but a characteristic.
The test method is designed to find semi-realistic (but testable) boundary
conditions in performance.  Requiring the latency to be measured at
throughput rate seems to achieve this goal.  And yes, some devices will
reveal their 'worst' behavior under these conditions.  That is, in effect, a
successful test method.

Looking forward to other BMWGers thoughts on this.

Jim McQuaid

NetIQ Raleigh

-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]]
Sent: Friday, February 14, 2003 1:17 PM
To: [email-masked]
Cc: Lane Wigley
Subject: [bmwg] Some issues in RFC-2544

A number of test equipement verndors have implemented RFC2544 benchmarking
suite to their test. Router vendors as well as customers have greately
benefited from this. However, we have seen some issues with these tests with
respect to performance and latency testing. The purpose of this e-mail is to
initiate a discussion on this issues.

1. RFC2544 Throughput Testing

RFC 2544 defines throughput as "the fastest rate at which the count of test
frames transmitted by the DUT is equal to the number of test frames sent to
it by the test equipment." The issue that we have seen is that the no-drop
rate usually overestimates the actuall performance of the DUT. The
measurement error depends on the duration of the test and size of buffering
in the DUT. However, RFC-2544 does not specify nor require the reporting of
test duration and max/min/avg latency measurements during throughput
testing. Note that the test duration T, the minimum latency Dmin, the
maximum latency Dmax and the measurement error due to buffering Eb can be
related as follows:

Eb = (Dmax - Dmin)/T

This is assuming that the latency variation is mostly attributed to
buffering.

There are two possible solutions to this problem:

a. Redefine throughput as "the fastest rate at which count of test frames
transmitted by DUT is qual to the number of test frames sent to it by the
test equipment without exceeding a specified maximum latency. The test
duration should be at least 1000 (or 100) times the specified maximum
latency".

b. Require the vendor to include Test duration and maximum latency in the
test report.

2. RFC2544 Latency Testing

RFC2544 requires that latency be measured while sending traffic at the
no-drop throughput rate. This in most cases leads to queue buildup in the
DUT, resulting in extemely high latency measurement.

One possible solution for this problem is to require that latency be
measured at 90%, 95% and/or 99% of measured throughput.

Thanks,
Dawit Birhanu
[email-masked]

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: Scott Poretsky <[email-masked]>
Date: Fri, 14 Feb 2003 14:32:06 -0500

Right on.  RFC 2481 defines "Incipient Congestion" as the state of queue 
buildup observed by increased latency without packet loss.  The amount of 
this queue buildup, and therefore latency, is dependent upon the DUT 
processing speed.  If packets can be processed at line rate, then there 
will not be queue buildup.  It is possible to build a device with just 
below optimal processing speed and really deep queues so that packet loss 
is not observed.  This is particularly true in today's hardware-based 
routers.  For this reason the duration of test is critical.

Scott

---

From: Scott Poretsky <[email-masked]>
Date: Fri, 14 Feb 2003 14:32:06 -0500

Scott

---

From: "Perser, Jerry" <[email-masked]>
Date: Fri, 14 Feb 2003 12:06:21 -0800

Dawit,

Could you take a look at draft-ietf-bmwg-dsmterm-04.txt definition of Delay
(section 3.2.4) and Peak-to-peak Jitter Vector (section 3.4.4.10).  We are
trying to address these issues as well as some others we have with Latency.

Instead of redefining Latency, the goal of this I-D is to define a new
metric that can:

 - at any OLOAD (below, at, and above the measured throughput).

 - measure more than one packet in a test duration.

 - Look at min versus max.

 - Remove "store and forward" versus "bit forwarding" measurement.

 - Independent of sub-IP technology.

The authors of draft-ietf-bmwg-mcastm-11.txt MAY want to comment/consider
you issues.  Their draft follows RFC2544 and has the same pitfalls.

Jerry.

> Sent: Friday, February 14, 2003 10:17 AM
> To: [email-masked]
> Cc: Lane Wigley

---

From: "Perser, Jerry" <[email-masked]>
Date: Fri, 14 Feb 2003 12:06:21 -0800

Dawit,

Jerry.

---

From: Jim McQuaid <[email-masked]>
Date: Fri, 14 Feb 2003 15:32:46 -0500

I think that #1 and #3 are the normal problems of conducting any test
properly.  #2 is more interesting, but any equipment that truly maintains
"line rate" will have to have the overhead to deal with some of these
conditions, e.g. MTU changes as discussed under Frame sizes.  Again the
build-up of latency is a clue to this function.

Clearly, publishing the duration of the latency test is very important; 2544
says that tests SHOULD be 120 seconds in length with the latency measured
after 60 seconds.  But the reporting format does not specifically include
reporting the duration of the test, which ought to be a requirement.  It
seems to be that what Dawit is really saying is that the test duration is
significant and ought to be a "variable" reported at the very least.

Jim McQuaid

NetIQ Raleigh

-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]]
Sent: Friday, February 14, 2003 2:32 PM
To: Jim McQuaid; [email-masked]
Cc: Lane Wigley
Subject: RE: [bmwg] Some issues in RFC-2544

The high latency could sometimes be a characteristics. But it could as well
be a "problem". We can see queue builup even when a DUT is truely capable of
supporting linerate throughput. Here are some of the reasons why this could
happen:

1. Even if the clock rate used by the DUT and the Test equipment are
nominally identical for similar interface types, in reality there is slight
difference. Therefore, it is possible that the Test equipment may use a
slightly higher clock rate than the DUT. In this case queue buildup is
unavoidable.

2. Some link layer protocols (eg. PPP) use bit/byte stuffing. For such types
of link layer protocols, it is possible that there may not be bit/byte
stuffing sent by Test equipment but the DUT may have to generate bit/byte
stuffing due to changes in TTL, checksum, CRC, etc. The occurance of this is
rare. But when it occurs, queue buildup is be unavoidable.

3. In some cases DUTs may generate L2 keepalives or other control plane
frames. But the Test equipment may not generate this additional frames. This
would also result in queue buildup.

Thanks,
-dawit

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jim
> McQuaid
> Sent: Friday, February 14, 2003 10:33 AM
> To: [email-masked]'; [email-masked]
> Cc: Lane Wigley
> Subject: RE: [bmwg] Some issues in RFC-2544
>
>

---

From: Jim McQuaid <[email-masked]>
Date: Fri, 14 Feb 2003 15:32:46 -0500

Jim McQuaid

NetIQ Raleigh

-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]]
Sent: Friday, February 14, 2003 2:32 PM
To: Jim McQuaid; [email-masked]
Cc: Lane Wigley
Subject: RE: [bmwg] Some issues in RFC-2544

Thanks,
-dawit

---

From: "John Dawson" <[email-masked]>
Date: Fri, 14 Feb 2003 14:11:01 -0800

There are a lot of additional situations in which queue build-up occurs.
Assume for a moment that a DUT can't sustain wire-speed indefinitely (or at
least for the duration of the test).  The throughput rate would therefore be
something less than 100%.  If the DUT employs buffering, then the amount of
data that can be forwarded without loss (throughput) will equal the
state-state forwarding capacity of the system plus the amount of data that
can be held in buffer.  The end result here is that the buffers are always
expected to be full at the end of the throughput test -- if the buffers were
not full, then the DUT would be able to handle more data which would mean
the DUT could support a higher offered load. Taking the latency measurement
half-way through the test just means that we are measuring half of the
buffering depth and not all of the buffering depth.

Now depending upon how the DUT and test equipment is architected, a latency
measurement at the throughput rate can yield vastly different results.
Buffering is not necessarily uniform for all port pairs and some ports may
have slower forwarding rates than others.  Since throughput measurements
force all traffic to slow-down if even one port pair is congested, then we
could have very good latency characteristic on one pair of ports while
another pair of ports could show drastic buffering effects.  This suggests
that reporting latency as a single number isn't always that meaningful -- we
actually need a distribution function to characterize latency properly.

Several years ago, I had presented research on latency measurements that
demonstrated effects caused by clock synchronization between transmit
sources.  Some test systems can have drift between transmitters while others
may not.  This research illustrated the fact that latency can be greatly
affected by the way test systems are internally built -- not a good approach
for providing a reproducible and un-biased measurement.

I would be very against including any latency criteria in the measurement of
Throughput.  You are essentially taking a characteristic (latency) that is
not being measured very well, and mixing it into a measurement that is well
understood (throughput).

I would say go fix latency measurements but leave throughput alone.

John
-----Original Message-----
From: Jim McQuaid [mailto:[email-masked]] 
Sent: Friday, February 14, 2003 12:33 PM
To: [email-masked]'; Jim McQuaid; [email-masked]
Cc: Lane Wigley
Subject: RE: [bmwg] Some issues in RFC-2544

Jim McQuaid

NetIQ Raleigh

-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]]
Sent: Friday, February 14, 2003 2:32 PM
To: Jim McQuaid; [email-masked]
Cc: Lane Wigley
Subject: RE: [bmwg] Some issues in RFC-2544

Thanks,
-dawit

---

From: Jim McQuaid <[email-masked]>
Date: Sat, 15 Feb 2003 09:35:12 -0500

Obviously, your comments about the idiosyncrasies of latency are well
placed.

I don't think that the suggestion in 2544 about when to make the latency
measurement is really = when the buffers are half full.  I think the intent
is to say; let the device run for some reaosnable period of time at the
throughput level and then make the measurement and then watch it for a while
after that to be sure it doesn't do something weird.

If a given device needs to run at throughput load for 2 minutes before
buffers fill, then use that as a guideline. and so on.

As far as the multiple path / distribution issue, of course, you're right
about the complexity and interaction possibilities.  the methodology can't
be complete for every case and I am under the impression that the switch
testing methodology (Bob Mandeville's work among others) dealt with those
issues to a reasonable extent.

Finally, as to the clock drift and test equipment issue, I would distinguish
between "reproducible" and "un-biased."  In a sense, all metrics (at least
all that we can afford in practice) are biased.  However, if they are
repeatable and consistent over some set of conditions, they are still quite
useful.  The BMWG goal has generally been oriented toward understanding
enough about the performance of devices to make a reasonable judgement about
its likely operational performance / behavior in a big network, of course.

Jim

-----Original Message-----
From: John Dawson
To: [email-masked]
Sent: 2/14/2003 2:11 PM
Subject: RE: [bmwg] Some issues in RFC-2544

There are a lot of additional situations in which queue build-up occurs.
Assume for a moment that a DUT can't sustain wire-speed indefinitely (or
at least for the duration of the test).  The throughput rate would
therefore be something less than 100%.  If the DUT employs buffering,
then the amount of data that can be forwarded without loss (throughput)
will equal the state-state forwarding capacity of the system plus the
amount of data that can be held in buffer.  The end result here is that
the buffers are always expected to be full at the end of the throughput
test -- if the buffers were not full, then the DUT would be able to
handle more data which would mean the DUT could support a higher offered
load. Taking the latency measurement half-way through the test just
means that we are measuring half of the buffering depth and not all of
the buffering depth.

Now depending upon how the DUT and test equipment is architected, a
latency measurement at the throughput rate can yield vastly different
results.  Buffering is not necessarily uniform for all port pairs and
some ports may have slower forwarding rates than others.  Since
throughput measurements force all traffic to slow-down if even one port
pair is congested, then we could have very good latency characteristic
on one pair of ports while another pair of ports could show drastic
buffering effects.  This suggests that reporting latency as a single
number isn't always that meaningful -- we actually need a distribution
function to characterize latency properly.

Several years ago, I had presented research on latency measurements that
demonstrated effects caused by clock synchronization between transmit
sources.  Some test systems can have drift between transmitters while
others may not.  This research illustrated the fact that latency can be
greatly affected by the way test systems are internally built -- not a
good approach for providing a reproducible and un-biased measurement.

I would be very against including any latency criteria in the
measurement of Throughput.  You are essentially taking a characteristic
(latency) that is not being measured very well, and mixing it into a
measurement that is well understood (throughput).

John 
-----Original Message----- 
From: Jim McQuaid [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, February 14, 2003 12:33 PM 
To: [email-masked]'; Jim McQuaid; [email-masked] 
Cc: Lane Wigley 
Subject: RE: [bmwg] Some issues in RFC-2544 

properly.  #2 is more interesting, but any equipment that truly
maintains 

Clearly, publishing the duration of the latency test is very important;
2544 
says that tests SHOULD be 120 seconds in length with the latency
measured 
after 60 seconds.  But the reporting format does not specifically
include 
reporting the duration of the test, which ought to be a requirement.  It

seems to be that what Dawit is really saying is that the test duration
is 
significant and ought to be a "variable" reported at the very least. 

Jim McQuaid 

NetIQ Raleigh 

-----Original Message----- 
From: Dawit Birhanu [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, February 14, 2003 2:32 PM 
To: Jim McQuaid; [email-masked] 
Cc: Lane Wigley 
Subject: RE: [bmwg] Some issues in RFC-2544 

The high latency could sometimes be a characteristics. But it could as
well 
be a "problem". We can see queue builup even when a DUT is truely
capable of 
supporting linerate throughput. Here are some of the reasons why this
could 
happen: 

1. Even if the clock rate used by the DUT and the Test equipment are 
nominally identical for similar interface types, in reality there is
slight 
difference. Therefore, it is possible that the Test equipment may use a 
slightly higher clock rate than the DUT. In this case queue buildup is 
unavoidable. 

2. Some link layer protocols (eg. PPP) use bit/byte stuffing. For such
types 
of link layer protocols, it is possible that there may not be bit/byte 
stuffing sent by Test equipment but the DUT may have to generate
bit/byte 
stuffing due to changes in TTL, checksum, CRC, etc. The occurance of
this is 
rare. But when it occurs, queue buildup is be unavoidable. 

3. In some cases DUTs may generate L2 keepalives or other control plane 
frames. But the Test equipment may not generate this additional frames.
This 
would also result in queue buildup. 

Thanks, 
-dawit 

> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of Jim 
> From: Dawit Birhanu [ mailto:[email-masked] <mailto:[email-masked]>
] 

> measured at 90%, 95% and/or 99% of measured throughput. 
<https://www1.ietf.org/mailman/listinfo/bmwg>  
<https://www1.ietf.org/mailman/listinfo/bmwg>  
_______________________________________________ 
bmwg mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/bmwg
<https://www1.ietf.org/mailman/listinfo/bmwg>

---

From: Jim McQuaid <[email-masked]>
Date: Sat, 15 Feb 2003 09:35:12 -0500

Jim

-----Original Message-----
From: John Dawson
To: [email-masked]
Sent: 2/14/2003 2:11 PM
Subject: RE: [bmwg] Some issues in RFC-2544

John 
-----Original Message----- 

Jim McQuaid 

NetIQ Raleigh 

-----Original Message----- 
From: Dawit Birhanu [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, February 14, 2003 2:32 PM 
To: Jim McQuaid; [email-masked] 
Cc: Lane Wigley 
Subject: RE: [bmwg] Some issues in RFC-2544 

Thanks, 
-dawit 

]

---

From: Jim McQuaid <[email-masked]>
Date: Tue, 18 Feb 2003 08:21:11 -0500

First of all, 2544 does deal with the issue of how long a receiver should
wait in section 23; "Wait for two seconds for any residual frames to be
received."

Section 24, titled "Trial Duration" is pretty clear in my opinion.  Most
importantly, it states the GOAL of the test duration, "The aim of these
tests is to determine the rate continuously supportable by the DUT."  That
is a lot better than requiring some specific time, because, obviously, for a
given test time, there is a buffer size large enough to "fool" the test.
This section further states that the duration SHOULD be at least 60 seconds,
which is a pretty large amount of traffic to buffer at any common network
speed today, I think.  (Also a long time to age a frame . . .)  Finally,
there is a reference to "binary search" for throughput, which in practice
means starting with the highest possible value of throughput we can test for
/ expect and observing {typically} some frame loss, than working down using
what I will call a gross interval, until you have  bracketed the frame rate
for throughput, followed by a finer-grained repeat of the same thing.  By
starting at the top, so to speak, we establish that there is a frame loss
condition.  If the device is capable of sustained wire speed, then our only
focus would be the test duration.

I haven't looked closely at 2544 for a while, but it seems to be sufficient
already re: your concerns about duration, waiting, etc.

Jim McQuaid

-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]]
Sent: Tuesday, February 18, 2003 2:35 AM
To: David Newman; John Dawson
Cc: [email-masked]
Subject: RE: [bmwg] Some issues in RFC-2544

> Reinterpreting 2544 also takes us down the path of trying to redefine
> existing terms. it's taken us long enough to make clear that throughput !=
> forwarding rate; let's not go changing those meanings now.
The problem with the current definition "throughput = no drop rate" is that
it
can result in dramatically different measurement values depending on the
duration
of the test. 2544 does not specify the duration of the test. Also it does
NOT specify how long the receiver must wait to receive the last packet after
the transmitter has completed transmitting.

>
> As Jerry noted, the dsterm draft introduces a new term, delay, that
> should help address John's concerns about latency.
>
> dn
>

---

From: Jim McQuaid <[email-masked]>
Date: Tue, 18 Feb 2003 13:05:28 -0500

Right. So the individual tester always has to use their best judgement in
balancing these factors for any particular DUT.  That's why testers get the
big bucks!  ;-)

Jim

-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]]
Sent: Tuesday, February 18, 2003 1:00 PM
To: Jim McQuaid; David Newman; John Dawson
Cc: [email-masked]
Subject: RE: [bmwg] Some issues in RFC-2544

Jim,

I rechecked RFC2544 and it has both 2 second residual time and 60 second
test duration.  (my mistake).

But the main problem that I have is that depending on the size of buffering,
two routers with identical forwarding capability could result in different
performance measurment values. Note that 2 second residual time with 60
second test duration could potentially result in overestimation of the
throughput performance by upto 3.3% (2/60). This suggests that, to decrease
the over-estimation we have to decrease the residual time or increase the
test duration.

-dawit

> Sent: Tuesday, February 18, 2003 5:21 AM
> To: [email-masked]; David Newman; John Dawson
> Cc: [email-masked]

---

From: "John Dawson" <[email-masked]>
Date: Tue, 18 Feb 2003 10:15:37 -0800

There is no over-estimate.  Throughput is a measure of offered load that is
forwarded without loss.  It is not a measure of forwarding rate.

Since the offered load is independent of the residual time, the forwarding
rate may be changing but the throughput measurement is a constant.  This
characteristic has been known for quite some time.

John 

-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]] 
Sent: Tuesday, February 18, 2003 10:00 AM
To: Jim McQuaid; David Newman; Dawson, John [BLVWA:382:EXCH]
Cc: [email-masked]
Subject: RE: [bmwg] Some issues in RFC-2544

Jim,

-dawit

---

From: Jim McQuaid <[email-masked]>
Date: Tue, 18 Feb 2003 13:47:15 -0500

I think 2544 allows different values, no problem.

Also, I think you have too constrained a concept about the relation between
the residual time and the test time.  If I observe that a DUT forwards 60
seconds worth of offered load in 62 seconds, I do not accept that as a
steady state, i.e. throughput rate.  I will begin to adjust the load, timing
and such until I find the actual throughput rate.  2544 is a framework for
thinking about benchmarking, but the thinking is still essential.

Jim McQ

-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]]
Sent: Tuesday, February 18, 2003 1:42 PM
To: Jim McQuaid; David Newman; John Dawson
Cc: [email-masked]
Subject: RE: [bmwg] Some issues in RFC-2544

Allowing different values of and requiring the inclusion of residual time
and test duration in the test report would have the following advantages:

 - Better indication of the test condition (test environment) to the user
 - Controlling the effect of buffering on throughput measurement
 - Increasing testing efficient. For example if we use a residual time of 5
msec, we can decrease the test duration (for example to 5 second).

Thanks,
-dawit

> Sent: Tuesday, February 18, 2003 10:05 AM
> To: [email-masked]'; Jim McQuaid; David Newman; John Dawson
> Cc: [email-masked]

---

From: Jim McQuaid <[email-masked]>
Date: Tue, 18 Feb 2003 13:47:15 -0500

Jim McQ

-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]]
Sent: Tuesday, February 18, 2003 1:42 PM
To: Jim McQuaid; David Newman; John Dawson
Cc: [email-masked]
Subject: RE: [bmwg] Some issues in RFC-2544

Thanks,
-dawit

---

From: "Perser, Jerry" <[email-masked]>
Date: Tue, 18 Feb 2003 10:48:33 -0800

Dawit,

I propose solving the buffer problem by creating a new metric.

More DUT have some sort of input buffer.  By measuring before the buffer,
the actual forwarding process is not measured.  Changing the test duration
can minimize the affects of buffering.  But it will never remove it.

In dsmterm-04, there is a metric called Channel Capacity.  It was inspired
by John Dawson's comments on the reflector a few years ago.  Channel
Capacity is defined as "The maximum forwarding rate [RFC2285] at which none
of the offered packets are dropped by the DUT/SUT."

Channel Capacity is equal or less than Throughput depending upon buffer size
and test duration.  Both are a maximum rate at which none of the offered
packets are dropped.  The Difference is where on the DUT to measure the
rate.  By measuring after the buffer, Channel Capacity reports the actual
forwarding performance.

Jerry.

---

From: "John Dawson" <[email-masked]>
Date: Tue, 18 Feb 2003 11:16:45 -0800

Offered load is independent of the residual time.  Offered load is the
number of frames sent by a port divided by the test duration.  
 
Forwarding rate, however, is highly dependent upon the residual time.  The
forwarding rate is the offered load (total bits or total packets) divided by
the sum of the test duration and the residual time component that actually
carries traffic.
 
If you have lots of buffers on a box then you are more likely to get a
better throughput rate -- no question about it.  Your proposals are trying
to completely eliminate the effect of buffering from the equation.  When I
am trying to compare performance of switches, I care how much buffering is
present.  Throughput helps me evaluate the amount of buffering that exists
on the device.  This is especially true in the half-duplex test cases.
 
Throughput does not measure the forwarding rate -- it never has.  
I see no reason to change the measurement after so many years.
 
John
 
-----Original Message-----
From: Dawit Birhanu [mailto:[email-masked]] 
Sent: Tuesday, February 18, 2003 10:46 AM
To: Dawson, John [BLVWA:382:EXCH]
Cc: [email-masked]
Subject: RE: [bmwg] Some issues in RFC-2544

While the offered load and forwarding rate are independent of the residual
time, throughput is not since for the same offered load there may or may not
be loss depending on the size of the residual time and buffer size.
 
-dawit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of John
Dawson
Sent: Tuesday, February 18, 2003 10:16 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [bmwg] Some issues in RFC-2544

John 

-----Original Message----- 
From: Dawit Birhanu [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, February 18, 2003 10:00 AM 
To: Jim McQuaid; David Newman; Dawson, John [BLVWA:382:EXCH] 
Cc: [email-masked] 
Subject: RE: [bmwg] Some issues in RFC-2544 

Jim, 

-dawit 

> From: Jim McQuaid [mailto:[email-masked]

> From: Dawit Birhanu [mailto:[email-masked] <mailto:[email-masked]> ]