Subject: Re: DRAFT Nashua interim meeting minutes

From: [email-masked]
Date: Tue, 15 May 2001 23:30:02 +0300

David,

> (2) ESP with null authentication is mandatory to implement

Should be ESP with null encryption
(and Ofer Birman should probably be Ofer Biran...)

    Regards,
         Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

---

From: [email-masked]
Date: Wed, 16 May 2001 02:47:26 -0400

2 for 2 - both changes have been made to the
working version of the minutes.  Thanks, --David

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, May 15, 2001 4:30 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: DRAFT Nashua interim meeting minutes
> 
> 
> 
> David,
>

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 18 May 2001 18:13:47 -0700

A few items from my notes that I couldn't find in your draft minutes:

Strong consensus that header formats and opcodes should not be changed in
further revisions of the draft except when there is rough concensus from the
group for such changes.  There are changes expected in rev. 07 to correct
some things pointed out on the list.

There was discussion in the security portion of the agenda to the effect
that "if we mandate IPSec with it's data integrity check capabilities, is
there further need to specify error recovery"?

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]

---

From: [email-masked]
Date: Mon, 21 May 2001 19:07:34 -0400

> some things pointed out on the list.

Added the following under iSCSI Requirements Last Call Issues:

	The general sense of the room was that data formats and the like
ought
	not to be changed - at this point in the process, stability matters,
	and further changes of this sort need to be discussed on the list
prior
	to being made.

While I don't believe consensus was called on this, I do remember it as the
"general
sense of the room".

> there further need to specify error recovery"?

That topic was picked up again in the error recovery session.  In essence,
if ESP is in
use, CRC failures at the iSCSI level will essentially never happen, allowing
at least
within-session and within-connection (and presumably) within-command
recovery
to be dropped, but the HMAC in ESP is computationally expensive leading to
the
interest in a CRC shim.  I've added explanation of this to the point in the
error
recovery session where the CRC shim was discussed.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 21 May 2001 19:17:33 PDT

David,

I just have two comments on this note.

>Within-connection recovery reissues command on same connection to fill
>	CmdSN holes.  Has to be on same connection due to connection
>	allegiance.  

If there is a CmdSN hole, the command should be unacknowledged causing
the initiator to re-use the same CmdSN on retry.  I don't see connection
allegiance here since the CmdSN was never ack'ed.  IMHO, technically 
it should be able to be re-issued on any connection in the session
(though don't know why an initiator would do that).  

>These errors require framing support over TCP -
>	in the absence of framing, the connection has to
>	be terminated.

This is generally true, since most likely it would be a header 
digest error.  If the CmdSN hole was due to a data digest error on
immediate data, original framing is still intact.
--
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 21 May 2001 19:00:06 PDT

David,

>to be dropped, 

I want to add one comment here, though the right context to discuss
this would be while making a case for "CRC shim"/ESP-with-CRC.

Within-session recovery should continue to live on even with perfect
TCP, to transparently effect connection recovery on NIC failures.  The
Nashua error recovery slides explicitly make this point.  It however
may not have to be mandatory with a perfect/shored-up TCP.
--
Mallikarjun 

Mallikarjun Chadalapaka

>but the HMAC in ESP is computationally expensive leading to
>the