Subject: RE: [bmwg] Terminology Question: Throughput

From: Jim McQuaid <[email-masked]>
Date: Thu, 13 Nov 2003 13:51:50 -0000

I think the concept that throughput can be measured at the ingress of
anything is incorrect.  Throughput is the ability of a DUT to forward 100%
of the offered load.  The definition more or less requires measurement on
both the ingress and egress and a comparison.  This is just 1242 stuff.

Jim McQuaid
NetIQ Raleigh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Perser, Jerry
Sent: Wednesday, November 12, 2003 6:45 PM
To: [email-masked]'
Subject: RE: [bmwg] IPSec Terminology Question: Encryption/Decryption
Thr oughput

Tim,

Before we can agree, I like to get some basic terminology correct:

- Throughput is measured at the ingress of the DUT/SUT
- Forwarding Rate is measured at the egress of the DUT/SUT
- Layer 2 measurements are in frames
- Layer 3 measurements are in packets

If anyone disagrees with these definitions, please point to the correct
definition document.  I bring this up because I don't think we are talking
apples to apples here.

Jerry.

> -----Original Message-----
> From: Tim Van Herck [mailto:[email-masked]]
> Sent: Wednesday, November 12, 2003 3:17 PM
> To: Perser, Jerry
> Cc: [email-masked]'
> Subject: Re: [bmwg] IPSec Terminology Question: Encryption/Decryption
> Throughput
> 
> 
> 	Jerry,
> 
> Let me restate that. We will define a tput test with two 
> ipsec devices 
> in a back to back setup on which we only measure at ingress ports and 
> may report the projected egress rate/Mbps.
> 
> In other scenario's we can use the defined framesizes to 
> measure rates. 
> In all cases the definition of a rate doesn't change, just 
> the framesize 
>   used to calculate the throughput changes. Agree ?
> 
> See section 9.1
> 
> 	Tim-
> 
> > If you are going to measure at the ingress AND egress, then 
> you will need
> > two different definitions for the two metrics.
> > 
> > Jerry.
> > 
> > 
> >>-----Original Message-----
> >>From: Tim Van Herck [mailto:[email-masked]]
> >>Sent: Wednesday, November 12, 2003 10:46 AM
> >>To: Player, Timmons
> >>Cc: [email-masked]'
> >>Subject: Re: [bmwg] IPSec Terminology Question: 
> Encryption/Decryption
> >>Throughput
> >>
> >>
> >>	Timmons,
> >>
> >>Like Michele already mentioned this will be addresses in 
> the meth I-D 
> >>but to answer the question, we will indeed document that you can 
> >>represent throughput in four ways :
> >>
> >>- measured at ingress in pps (clear traffic)
> >>- measured at ingress in Mbps (clear traffic)
> >>- measured at egress in pps (crypto traffic)
> >>- measured at egress in Mbps (crypto traffic & using crypto 
> pkt size)
> >>
> >>	Tim-
> >>
> >>
> >>>When performing an IPSec Encryption/Decryption Throughput 
> >>
> >>the draft isn't
> >>
> >>>clear as to which side of the DUT pps or Mbps should be 
> >>
> >>measured.  I'm
> >>
> >>>pretty sure that Mbps will be different for ingress and 
> >>
> >>egress.  And pps
> >>
> >>>could be different for ingress and egress depending on the 
> >>
> >>size of the input
> >>
> >>>packet, at least for the encryption throughput case.
> >>
> >>
> >>
> >>_______________________________________________
> >>bmwg mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/bmwg
> >>
> > 
> > 
> > _______________________________________________
> > bmwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/bmwg
> 

_______________________________________________
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: Jim McQuaid <[email-masked]>
Date: Thu, 13 Nov 2003 13:51:50 -0000

Jim McQuaid
NetIQ Raleigh

-----Original Message-----

Tim,

Jerry.

---

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 13 Nov 2003 09:37:46 -0800

Jim,

The definition leads one to believe that it is an ingress method.  "The
maximum rate at which none of the offered frames are dropped by the device"
[RFC1242] mentions offered frames, not forwarded frames.  Also the
measurement units are in N-octet input frames per second.  IMHO, ingress and
input are the same.

My issue is that throughput can not both be an ingress metric AND an egress
metric.  In any DUT/SUT that buffers (store and forward devices) the maximum
zero loss rate at the ingress will be higher than the egress.  Vendors will
use this ambiguity to engage in "specsmanship".

Jerry.

> From: Jim McQuaid [mailto:[email-masked]]
> Sent: Thursday, November 13, 2003 5:52 AM
> To: 'Perser, Jerry'; [email-masked]'
> Subject: RE: [bmwg] Terminology Question: Throughput
> 
>

---

From: Jim McQuaid <[email-masked]>
Date: Thu, 13 Nov 2003 19:52:36 -0000

Yes, correct.  And you state it better than I did.  You have to *measure* on
both ingress and egress, but the metric is the ingress rate at which the
throughput condition is satisfied.
 
There was a discussion years back about "goodput" (and other suggested
nomenclature) which was kind of throughput with some amount of dropped
frames allowed or ignored or deducted in some fashion.  But that discussion
never yielded any consensus about what is acceptable or useful in practice
when it comes to dropping frames.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of John
Dawson
Sent: Thursday, November 13, 2003 2:46 PM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

I agree with Jerry on this one.  The throughput measurement as not as clear
as you think (Jim). 

Yes, you do look at the number of packets/frames sent (ingress) and compare
it to the number received (egress), and you try to find a maximum rate that
can be offered on the ingress without loss.

However, when it comes time to report the final "rate", you must report the
offered load -- which is purely an ingress calculation.  The reported
Throughput rate has nothing to due with the received (egress) rate, so long
as all packets are received.

John D. 

-----Original Message----- 
From: Jim McQuaid [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, November 13, 2003 11:26 AM 
To: 'Perser, Jerry'; [email-masked]' 
Subject: RE: [bmwg] Terminology Question: Throughput 

No.  You cannot measure throughput without measuring ingress and egress. 
The definition of throughput perhaps allows some ambiguity.  However, how 
would one detect "dropped" if only looking at ingress?  Likewise, the 
definition of frame loss rate clearly talks about forwarded (egress) frames;

the 'percentage' can only be calculated if you have both ingress and egress.

Finally, the definition of the throughput procedure is extremely clear about

HOW to measure throughput: by counting ingress and egress and comparing it. 
Test equipment implementing this test did exactly that.  It is necessary to 
achieve a sufficently long test duration to overcome buffering effects, 
hence the reference in 'frame loss rate' to "steady state." 

You said that your issue is that 'throughput' cannot be both an ingress and 
egress metric.  In one sense, that's true.  It's a metric about throughput, 
namely the relationship of inputs to outputs and it requires two 
simultaneous measurements to be computed. 

cheers, 

Jim McQuaid 
NetIQ Raleigh 

------------------------------------------ 
1242 definition of throughput: 
"The maximum rate at which none of the offered frames are dropped by the 
device." 

1242 definition of frame loss rate: 
"Percentage of frames that should have been forwarded by a network device 
under steady state (constant)load that were not forwarded due to lack of 
resources." 

1944/2544 definition of throughput benchmark procedure: 
 'Procedure:  Send a specific number of frames at a specific rate through 
the DUT and then count the frames that are transmitted by the DUT. ' 

-----Original Message----- 
From: Perser, Jerry [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, November 13, 2003 12:38 PM 
To: Jim McQuaid; [email-masked]' 
Subject: RE: [bmwg] Terminology Question: Throughput 

Jim, 

input are the same. 

Jerry. 

> From: Jim McQuaid [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of 
> > From: Tim Van Herck [ mailto:[email-masked] <mailto:[email-masked]>
] 
> > >>From: Tim Van Herck [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > >>>packet, at least for the encryption throughput case. 
<https://www1.ietf.org/mailman/listinfo/bmwg>  
<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: Thu, 13 Nov 2003 19:25:58 -0000

cheers,

Jim McQuaid
NetIQ Raleigh

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Thursday, November 13, 2003 12:38 PM
To: Jim McQuaid; [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Jim,

Jerry.

---

From: "John Dawson" <[email-masked]>
Date: Thu, 13 Nov 2003 11:46:29 -0800

John D.

-----Original Message-----
From: Jim McQuaid [mailto:[email-masked]] 
Sent: Thursday, November 13, 2003 11:26 AM
To: 'Perser, Jerry'; [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

cheers,

Jim McQuaid
NetIQ Raleigh

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Thursday, November 13, 2003 12:38 PM
To: Jim McQuaid; [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Jim,

Jerry.

---

From: "Perser, Jerry" <[email-masked]>
Date: Thu, 13 Nov 2003 12:24:39 -0800

Okay,

Let me restate the problem assuming the loss detection happens at both the
ingress and egress:

Throughput is a measured RATE at the ingress of the DUT/SUT [RFC1242]
Forwarding Rate is a measured RATE at the egress of the DUT/SUT [RFC1242]

As I understand Timmons question on ipsec I-D:

9.3.1 IPsec Tunnel Throughput
   Definition:
      The forwarding rate through an IKE/IPsec tunnel at which none of
      the offered frames are dropped by the device under test.

Does the measurement Units follow RFC1242 or RFC2285?

Jerry.

-----Original Message----- 
From: Perser, Jerry [mailto:[email-masked]] 
Sent: Thursday, November 13, 2003 12:38 PM 
To: Jim McQuaid; [email-masked]' 
Subject: RE: [bmwg] Terminology Question: Throughput 

Jim, 

input are the same.

---

From: Jim McQuaid <[email-masked]>
Date: Fri, 14 Nov 2003 13:05:59 -0000

This is definitely an "interesting" problem.  We had the same issue with
simple compression and with LAN - WAN MTU changes.

I think that throughput requires a metric for ingress RATE and a way to
measure the egress in terms that make sense for the DUT/SUT.  Of course,
enclosing the encryption inside an A:B:B:A system is one simple way.  Having
test equipment that is capable of determining that 100% of the input IS
actually being emitted by the device is the requirement / challenge here.
Given a piece of test equipment that can do that, you can measure
throughput, even if the physical rate of bytes or packets is different on
the egress.

Philosophically BMWG wants to be useful but it is acceptable to define
metrics for which no current test equipment exists [I think this was in the
original charter].  (not procedures perhaps, but metrics)  Then compromises
with actual equipment (today) can be mapped onto the "ideal" metric.
Obviously, I am no longer in touch with the details of the test equipment
marketplace, but I think the concept is clear.

-----Original Message-----
From: Tim Van Herck [mailto:[email-masked]]
Sent: Friday, November 14, 2003 3:47 AM
To: Perser, Jerry
Cc: 'Jim McQuaid'; [email-masked]'
Subject: Re: [bmwg] Terminology Question: Throughput

	Jerry, Jim,

I believe IPSEC is a special case where it is not so clear cut in terms 
of ingress and egress but rather in the sense of clear and crypto 
traffic applied to throughput or forwarding rates.

The whole idea of a throughput measurement is to do check at which point 
  no frames are lost anymore vs the offered load. This check is mostly 
done by comparing ingress and egress frames (i.e. verifying painted 
packets). This is slightly more difficult in the ipsec case since you 
cannot get access to the signatures in the packets unless you decrypt first.

So knowing this it depends on your topology what you define as 
throughput and forwarding rate. We will suggest 2 scenario's: one where 
we use a regular packet generator on a pair of ipsec devices that are 
connected in a back to back scenario. Throughput is then defined as the 
throughput of the SUT. In the second case we will put an ipsec enabled 
traffic generator at the lan and secure links and the testinterface 
connected to the secure interface will first decrypt all packets and 
perform a throughput measurement based on that data.

Does that make sense ? I rather avoid using ingress and egress 
terminology in a ipsec context since they may be confused with inbound 
and outbound traffic.

	Tim-

>>>in a back to back setup on which we only measure at ingress 
>>
>>ports and 
>>

---

From: "Player, Timmons" <[email-masked]>
Date: Fri, 14 Nov 2003 05:44:27 -1000

So, just to clarify the point...  Following the conventions of 1242 would
mean rewording the throughput defintions to use input frames per second or
input bits per second as the measurement units, right?

This was the main point of the original question.  Supposing a device has a
(as currently defined) {en,de}cryption throughput of x input Mbps and y
output Mbps, then the vendor will report the max(x,y) as the throughput.
Specifying where the measurement is made removes any, err, opportunity for
specmanship. :)

Timmons

> Sent: Friday, November 14, 2003 9:05 AM
> To: Perser, Jerry
> Cc: [email-masked]'
> Loss detection happens on the egress side but throughput as 
> not a metric 
> that is specific to ingress or egress, I would say.
> 
> I would say we stick to the definition of throughput as stated in 
> RFC1242 but remember that this can happen in two distinct topologies 
> which will be described in detail in the methodology draft.
> 
> For IPSec Tunnel Throughput this would be the throughput of an SUT 
> consisting of two identical back-to-back connected IPSec devices.
> 
> 	Tim-
>

---

From: "Perser, Jerry" <[email-masked]>
Date: Mon, 17 Nov 2003 10:13:01 -0800

> traffic applied to throughput or forwarding rates.

Where do I connect my RATE probe to make the throughput measurement?

RFC1242 was very clear on stating "input frames per second".  "Terminology
for Benchmarking IPSec Devices" MUST be equal clear cut in terms of ingress
and egress as RFC1242 was.

Throughput does not equal Forwarding rate.  The RATE probe is connected in
different places.  You have used the term correctly here.  I would suggest
that your I-D reflects this.  I disagree with the concept that Throughput is
defined as a Forwarding rate.

Jerry.

___________________________________________________________ 
Jerry Perser                         Spirent Communications
Director of Test Methodology         SmartBits Division 
Phone: 818.676.2320                  26750 Agoura Road 
Lab:   818.676.2337                  Calabasas, CA, 91302 
Cell:  818.292.6457                  Corp:  818.676.2300

---

From: Michele Bustos <[email-masked]>
Date: Mon, 17 Nov 2003 11:34:06 -0800

Hi Jerry, Hope this finds you well...

The verbage in the discussion section for IPsec en/de crption throughput
will be reworded for clarity.  
Though stating that they must be equal in terms of ingress and egress as
1242 is not entirely correct, 
per your intended comment(s), if I understand you correctly (I could be
wrong, just tell me why).

Ingress and Egress are not defined terms.  Inferred terms lead to ambiguity
and "specmanship", IMO.
Can you find a ref for them?  

I *could* agree that 1242 infers ingress (throughput) and 2889 infers egress
(forwarding rate).  The term 
*forwarding rate*, however, will be removed from the sections titled
*throughput* for clarity.  

All references to the word *frame* will also be replaced with the L3
alternative *packet*, per our mcast discussions.  

Probe is an undefined word in benchmarking, last time I checked, though I
hear it's a fairly decent for a Ford. :)

Thank you and Aloha,
/m

Michele Bustos
Ixia
818-444-3244
[email-masked]

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Monday, November 17, 2003 10:13 AM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Jerry.

---

From: Michele Bustos <[email-masked]>
Date: Mon, 17 Nov 2003 11:34:06 -0800

Thank you and Aloha,
/m

Michele Bustos
Ixia
818-444-3244
[email-masked]

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Monday, November 17, 2003 10:13 AM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Jerry.

---

From: "Perser, Jerry" <[email-masked]>
Date: Mon, 17 Nov 2003 12:24:46 -0800

> Ingress and Egress are not defined terms.  Inferred terms 
> lead to ambiguity and "specmanship", IMO.

I find that Merriam-Webster definition is sufficient. See
http://www.m-w.com/.

Main Entry: ingress 
Etymology: Middle English, from Latin ingressus, from ingredi
Date: 15th century
1 : the act of entering : ENTRANCE
2 : the power or liberty of entrance or access

Main Entry: egress 
Function: noun
Etymology: Latin egressus, from egressus, past participle of egredi to go
out, from e- + gradi to go -- more at GRADE
Date: 1538
1 : the action or right of going or coming out
2 : a place or means of going out : EXIT 

> Probe is an undefined word in benchmarking, last time I 
> checked, though I hear it's a fairly decent for a Ford. :)

Sorry, I forget that we are not all Electrical Engineers using Test
Equipment.  I use 'probe' in the same context as an oscilloscope probe, a
voltage probe, a logic analyzer probe. See
http://www.tek.com/cgi-bin/si.pl?term=probe.

Instead of a philosophical Rate probe, lets say I got a real-world Frequency
counter
(http://we.home.agilent.com/cgi-bin/bvpub/agilent/Product/cp_Product.jsp?NAV
_ID=-11154.0.00).  Where do I connect the frequency counter's input to the
DUT/SUT?  Do I connect the counter where the packets go into the DUT/SUT, or
where the packets come out of the DUT/SUT?

Jerry.

---

From: [email-masked]
Date: Mon, 17 Nov 2003 16:59:29 -0500

Besides Jerry's excellent citations from a well-respected dictionary, we
cannot dismiss the fact that "ingress" and "egress" are commonly used terms
in the IETF's MPLS RFCs.

Scott

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Monday, November 17, 2003 3:25 PM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Main Entry: ingress 

Main Entry: egress 
Function: noun

Jerry.

---

From: Michele Bustos <[email-masked]>
Date: Mon, 17 Nov 2003 14:12:24 -0800

Hi Scott,

Are you volunteering to define them in your paper?  :)

Besides, if we can cite the dictionary, then why use rfc's?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 17, 2003 1:59 PM
To: [email-masked]; [email-masked]
Subject: RE: [bmwg] Terminology Question: Throughput

Scott

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Monday, November 17, 2003 3:25 PM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Main Entry: ingress 

Main Entry: egress 
Function: noun

Jerry.

---

From: Michele Bustos <[email-masked]>
Date: Mon, 17 Nov 2003 14:12:24 -0800

Hi Scott,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 17, 2003 1:59 PM
To: [email-masked]; [email-masked]
Subject: RE: [bmwg] Terminology Question: Throughput

Scott

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Monday, November 17, 2003 3:25 PM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Main Entry: ingress 

Main Entry: egress 
Function: noun

Jerry.

---

From: [email-masked]
Date: Mon, 17 Nov 2003 19:30:02 -0500

Michelle,

In the MPLS Protection Methodology draft we actually make reference to
existing IETF terminology including Ingress and Egress.  You do not need to
re-define what is already defined.  It seems that you agree.  

This does raise one issue I have with the IPsec Terminology draft - Many of
the terms in section 7, Term Definitions, are IPsec terms defined in IETF
RFCs.  Such terms are as follow:

IPsec
Client
Server
ISAKMP
IKE
SA
AH
ESP
many others

I recommend that these be moved to Section 6, Existing Definitions, with
reference to the appropriate RFC.

Scott

-----Original Message-----
From: Michele Bustos [mailto:[email-masked]]
Sent: Monday, November 17, 2003 5:12 PM
To: [email-masked]'; [email-masked];
[email-masked]

Hi Scott,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 17, 2003 1:59 PM
To: [email-masked]; [email-masked]
Subject: RE: [bmwg] Terminology Question: Throughput

Scott

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Monday, November 17, 2003 3:25 PM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Main Entry: ingress 

Main Entry: egress 
Function: noun

Jerry.

---

From: [email-masked]
Date: Mon, 17 Nov 2003 19:36:55 -0500

Agree

-----Original Message-----
From: Tim Van Herck [mailto:[email-masked]]
Sent: Monday, November 17, 2003 5:22 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [bmwg] Terminology Question: Throughput

	Scott,

> cannot dismiss the fact that "ingress" and "egress" are commonly used
terms

Dismiss, no ! But I would not use those terms. Maybe inbound 
clear|crypto and outbound clear|crypto is more appropriate since it 
lines up with the IPSEC framework terminology.

But when you look at MPLS label switching capacity then an ingress 
packet is still identical to an egress packet i.e. none of the payload 
has been changed. Even in the case of an LER you can still track the 
signature by setting a different offset on the egress port. In the case 
of IPSEC there is nothing that you can do to match a signature against. 
That is just it's purpose ! Hence you will need to decrypt somewhere, so 
rather in terms of ingress and egress it may be easier to talk in terms 
of clear and crypto links since that is what is of interest. And yes, 
some of those links can be labeled as ingress and some of them as egress 
but that is already implied in the original throughput definition. No 
need for us to re-invent the wheel, right ?

	Tim-

>>>I believe IPSEC is a special case where it is not so clear 
>>
>>cut in terms 
>>

---

From: [email-masked]
Date: Mon, 17 Nov 2003 19:36:55 -0500

Agree

-----Original Message-----
From: Tim Van Herck [mailto:[email-masked]]
Sent: Monday, November 17, 2003 5:22 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [bmwg] Terminology Question: Throughput

	Scott,

	Tim-

---

From: [email-masked]
Date: Mon, 17 Nov 2003 19:30:02 -0500

Michelle,

IPsec
Client
Server
ISAKMP
IKE
SA
AH
ESP
many others

Scott

-----Original Message-----
From: Michele Bustos [mailto:[email-masked]]
Sent: Monday, November 17, 2003 5:12 PM
To: [email-masked]'; [email-masked];
[email-masked]

Hi Scott,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 17, 2003 1:59 PM
To: [email-masked]; [email-masked]
Subject: RE: [bmwg] Terminology Question: Throughput

Scott

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Monday, November 17, 2003 3:25 PM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Main Entry: ingress 

Main Entry: egress 
Function: noun

Jerry.

---

From: "Perser, Jerry" <[email-masked]>
Date: Mon, 17 Nov 2003 16:51:44 -0800

> Forget about frequencies, rates, ... all throughput measurements are 
> still done by looking at packet counters !

Not as long as the definition of throughput uses rate (or frequencies).
Please read section 9.3 of the draft-ietf-bmwg-ipsec-term-02 I-D.  The
authors insist that throughput is a rate, not a count.

> I suggest you re-read the Spirent Test Methodology paper, case TM-0100. 
> You will find nothing in there that even indicates that rates are compared
!

Does it say which rate should be reported as the throughput?  The problem
with rates (plural) is that not all of them can be the throughput.  Weather
it is inbound, outbound, clear, or crypto, the terminology needs to be clear
on which rate is the throughput.

My question still is which one of the rates is reported as the throughput?
Using terms from RFC2285, is it the ILOAD, OLOAD or FR ?  Or are there
better terms to describe where?

Jerry.

PS. as much as you and I like Spirent, it may not be a good thing to name
vendors.  The IETF is suppose to be neutral ground.

---

From: Michele Bustos <[email-masked]>
Date: Mon, 17 Nov 2003 17:47:37 -0800

Hi Scott,

As we stated 2 meetings ago, the reason we included the definitions in the
draft was for *ease of testing*; to eliminate the need to reference several
rfc's while trying to run a test.

We don't have a problem with moving the already defined terms for clarity.  
Though we hesitate to add them to the Existing Definition section (section
6), for that section includes no definitions, only ref's.  These terms are
apparently fairly well known to the test community.
So we'll change the name of section 6 to Existing Benchmark Definitions. 

Next we will rename and separate the Term Definition section to into: 
Referenced Term Definitions and Term Defintions.   This will meet the *ease
of testing* goal, while retaining the appropriate rfc references. 

Thanks so much for reading the paper :)

Michele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 17, 2003 4:30 PM
To: [email-masked]; [email-masked]
Subject: RE: [bmwg] Terminology Question: Throughput

Michelle,

IPsec
Client
Server
ISAKMP
IKE
SA
AH
ESP
many others

Scott

-----Original Message-----
From: Michele Bustos [mailto:[email-masked]]
Sent: Monday, November 17, 2003 5:12 PM
To: [email-masked]'; [email-masked];
[email-masked]

Hi Scott,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 17, 2003 1:59 PM
To: [email-masked]; [email-masked]
Subject: RE: [bmwg] Terminology Question: Throughput

Scott

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Monday, November 17, 2003 3:25 PM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Main Entry: ingress 

Main Entry: egress 
Function: noun

Jerry.

---

From: Michele Bustos <[email-masked]>
Date: Mon, 17 Nov 2003 17:47:37 -0800

Hi Scott,

Michele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 17, 2003 4:30 PM
To: [email-masked]; [email-masked]
Subject: RE: [bmwg] Terminology Question: Throughput

Michelle,

IPsec
Client
Server
ISAKMP
IKE
SA
AH
ESP
many others

Scott

-----Original Message-----
From: Michele Bustos [mailto:[email-masked]]
Sent: Monday, November 17, 2003 5:12 PM
To: [email-masked]'; [email-masked];
[email-masked]

Hi Scott,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 17, 2003 1:59 PM
To: [email-masked]; [email-masked]
Subject: RE: [bmwg] Terminology Question: Throughput

Scott

-----Original Message-----
From: Perser, Jerry [mailto:[email-masked]]
Sent: Monday, November 17, 2003 3:25 PM
To: [email-masked]'
Subject: RE: [bmwg] Terminology Question: Throughput

Main Entry: ingress 

Main Entry: egress 
Function: noun

Jerry.