Subject: RE: is 1 Gbps a MUST?

From: [email-masked]
Date: Fri, 22 Feb 2002 11:54:15 -0700

Hi Fred,

|
|I won't respond to the wording of the draft, but to the sense 
|that it must 
|be intended to convey. If the wording doesn't convey this, it is the 
|wording which must change.
|
|It seems to me that if the transfer of encrypted data at 
|nominal link rates 
|is expected, then encryption and decryption must be achieved 
|at link rates. 
|If 1 GBPS link rates are in view, guess what rates are 
|important. If 10 GBPS...

Unfortunately some believe that they can be iSCSI compliant by having a slow
implementation of IPSec and claiming that most traffic will not require
security processing. I am not one of those persons. I think that at least
the policy check must occur at link speed regardless of what proportion of
traffic requires security processing.

|
|It seems to me that the question is not whether or not you are 
|mandated to 
|implement IPSEC in software, but what you need to do to 
|accomplish link 
|speed encryption and decryption. Hardware and software are 
|duals; you can 
|implement the algorithm either way, and the trade-off is money 
|vs speed.

I agree, and I did not mean to imply otherwise. I am trying to gather
opinions from this group on whether link speed encryption/decryption is
necessary, especially now that Bernad Aboba has clarified that the spec does
not mandate it.

Vince

---

From: Paul Koning <[email-masked]>
Date: Fri, 22 Feb 2002 16:12:51 -0500 (EST)

>>>>> "vince" == vince cavanna <[email-masked]> writes:

 vince> Unfortunately some believe that they can be iSCSI compliant by
 vince> having a slow implementation of IPSec and claiming that most
 vince> traffic will not require security processing. I am not one of
 vince> those persons. I think that at least the policy check must
 vince> occur at link speed regardless of what proportion of traffic
 vince> requires security processing.

I can't think of any RFC that contains a performance mandate.  For
example, the TCP standard does not mandate doing TCP at wire rate or
any other rate.  The iSCSI spec does not mandate doing iSCSI at any
particular rate.  Why, then, should the security spec mandate doing
something at some particular rate?

 vince> Jonathan pointed out the need for bandwidth*RoundTripDelay
 vince> worth of buffering per TCP connection to avoid a cliff-effect
 vince> drop in performance; and I extrapolated the need to have no
 vince> bottlenecks (such as IPSec) anywhere in the path to those
 vince> buffers. From my perspective IPSec, or at least the part of
 vince> IPSec that discriminates between secured and unsecured
 vince> traffic, had better not be a bottleneck or IPSec will not be
 vince> turned on at all.

More generally, the throughput you get is that of the lowest
throughput component, and the buffering you ideally want is that times
the round-trip delay including any internal delays cause by high
latency processing steps.  That will drive your design decisions given
a particular performance requirement.

So if your example, if the requirement is X Mb/s total and Y Mb/s of
that protected by IPsec, the sorting of protocol 50 from protocol 6,
and the checking of protocol 6 traffic against the SPD to verify that
it's allowed to travel in the clear, have to run at rate X (not Y)
since they are a common bottleneck.  What X is depends on what you're
building.  If you need X to be gigabit wire rate, you have some work
to do, but nothing fundamental in IP or IPsec stands in the way.

     paul