Subject: RE: [bmwg] Terminology Question: Throughput

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.

> -----Original Message-----
> 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
> 
> 
> 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: Tim Van Herck <[email-masked]>
Date: Fri, 14 Nov 2003 00:46:53 -0800

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-

---

From: Tim Van Herck <[email-masked]>
Date: Fri, 14 Nov 2003 00:46:53 -0800

Jerry, Jim,

	Tim-