Subject: [Ips] Encryption and ISCSI PDUs.

From: "Preetam Verma" <[email-masked]>
Date: Tue, 20 Apr 2004 11:02:19 -0700

Do I need to use on of the reserved bits to compress ISCSI PDUs using some compression algorithm? I quickly went through the draft but could not find any specific bit that you can use for something like this. 

Regards

Preetam

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

---

From: Paul Koning <[email-masked]>
Date: Tue, 20 Apr 2004 14:33:13 -0400

>>>>> "Preetam" == Preetam Verma <[email-masked]> writes:

 Preetam> Do I need to use on of the reserved bits to compress ISCSI
 Preetam> PDUs using some compression algorithm? I quickly went
 Preetam> through the draft but could not find any specific bit that
 Preetam> you can use for something like this. 

Did you mean compression, or encryption?

For compression there is IPcomp, which is loosely tied to encryption.
Loosely, because you can negotiate it with IKE when you negotiate
IPsec.  

	paul

---

From: Julian Satran <[email-masked]>
Date: Tue, 20 Apr 2004 15:58:30 -0400

If you are taling about standard IP compression that is handled by 
different headers than the iSCSI one.
Otherwise if you want compression at the iSCSI level you may want to 
negotiate it with vendor keys and you won't need anything else.

Julo

"Preetam Verma" <[email-masked]> 
Sent by: [email-masked]
20/04/04 14:02

To
<[email-masked]>
cc

Subject
[Ips] Encryption and ISCSI PDUs.

Do I need to use on of the reserved bits to compress ISCSI PDUs using some 
compression algorithm? I quickly went through the draft but could not find 
any specific bit that you can use for something like this. 

Regards

Preetam

---

From: William Studenmund <[email-masked]>
Date: Wed, 21 Apr 2004 10:16:52 -0700

On Apr 20, 2004, at 11:02 AM, Preetam Verma wrote:

> Do I need to use on of the reserved bits to compress ISCSI PDUs using 
> some compression algorithm? I quickly went through the draft but could 
> not find any specific bit that you can use for something like this.

One question which hasn't come up is why do you want to compress PDUs?

Compression makes the most sense for a situation where the connection 
is "slow" and processing power is "cheep". Thus it makes sense to spend 
processing power (CPU cycles) to compress the data for the slow link.

The main motivator behind iSCSI, though, is Gigabit Ethernet. With it, 
the connection is not "slow". In fact, the connection is fast compared 
to a lot of stuff. Line rate for iSCSI is around 112 MiB/sec. Low-end 
PCs have 33 MHz 32-bit busses, which can transfer at 133 MB/sec 
theoretically. You of course aren't going to get that transfer rate, so 
the PCI bus will be as slow or slower than the max iSCSI rate. So all 
compression will do in this case is make things worse. You'll have to 
take processing power to read the raw data, compress it, write it to 
memory, then read that memory for TCP transmission. You're adding two 
extra data copies and eating the CPU. Not a good situation.

On the WAN side of things, the connection will go back to being slow. 
However even here I don't think compression is what you want to do. The 
problem is you probably also have a long link. So to get optimal 
performance, you want to fill the TCP pipe. That means lots of data 
outstanding (specifically bandwidth * delay worth). The way to do that 
is to work with a deep task queue and a storage system that will have 
lots of tasks outstanding. Only when you are filling the TCP pipe full 
will it make sense to look at compression.

Even then I'd suggest something like IPcomp. Otherwise, your initiator 
has to be used with your target (since any solution using reserved bits 
would be proprietary). Do you really want to develop both of them? Will 
your customers really want to be tied into your products? With IPcomp, 
you're playing the standardized-products game. Your product will work 
with other standards-compliant products, and your product will sell 
better.

Take care,

Bill