Subject: RE: iSCSI: draft 7: remove S bit and Status field from the Data-i n PD U?

From: [email-masked]
Date: Mon, 13 Aug 2001 20:57:56 -0400

John,

I think you've taken a wrong turn.  
 
> First, immediate and unsolicited separate Data PDUs are very valuable for
> situations where the Target is at distance from the Initiator.

Ok, that's fine.

> Second, thoughts of removing the immediate data seem not to be
> simplification, since all the information to tie the data to the command
is
> right there with the command.  That has got to be easier than matching up
> separate PDUs of data with the appropriate commands.

Actually, that was the point, since the logic for "matching up separate
PDUs of data with the appropriate commands" has to exist for inbound
Data PDUs already.  The slide I presented in London was about replacing
immediate data with an unsolicited data PDU immediately following the
command, thus removing the immediate data case in favor of reusing the
logic for dealing with separate Data PDUs.  Remember that this was presented
as a simplification possibility.

Comments?
--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: Dave Sheehy <[email-masked]>
Date: Tue, 14 Aug 2001 21:35:56 PDT

David,

> I think you've taken a wrong turn.  

I think John hit the nail on the head.

> Data PDUs already.  

Except that there is a target context present in the solicited case to route 
the data. That doesn't exist in the unsolicited case.

> The slide I presented in London was about replacing

This does help some. It eliminates the situation where a target can receive
an essentially unlimited number of immediate data commands prior to receiving
*any* data PDUs.

But, do you mean to say that *one* unsolicited data PDU would follow the
command? Wouldn't that be unnecessarily restrictive if the PDU size is small?
Simply guaranteeing that the data PDUs will immediately follow the command
seems like an adequate improvement.

Dave Sheehy

---

From: Sandeep Joshi <[email-masked]>
Date: Sat, 25 Aug 2001 17:11:39 -0400

Julian,

I wonder if Dave's last paragraph in this email has been considered.
Here it is again..

> an essentially unlimited number of immediate data commands prior to receiving

in reference to Section 1.2.5
> Unsolicited data MUST be sent on 
> every connection in the same order in which commands were sent.

The draft currently allows 
   c-1,c-2,c-3, (SEP-1-1),(SEP-1-2),(SEP-2-1,SEP-2-2),..
where c-N = command {N}
and   SEP-N-M = unsolicited (non-immediate) PDU number {M} for command
{N}

It would be simplify target login (ITT lookup) if we only permitted
this sequence. 
   c-1, SEP-1-1, SEP-1-2, c-2, SEP-2-1, SEP-2-2,..

-Sandeep