RE: bridging issues -- Converging FCP-2 and iSCSI control struct ures

[Charles Monia <cmonia@NishanSystems.com>]

Hi Julo:

> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Sunday, September 10, 2000 7:44 AM
> To: ips@ece.cmu.edu
> Subject: RE: bridging issues -- Converging FCP-2 and iSCSI control
> struct ures
> 
> 
> 
> 
> Charles,
> 
> We (the iSCSI design team) had some guidelines that we 
> followed (to the
> best
> of our knowledge) when deciding on formats.
> 
> Here are some of those:
> 
>    constant header length
>    no redundant information (as far as possible) to avoid the need for
>    validity checks
>    compact coding while keeping implementations efficient
>    close resemblance to FCP to simplify bridging
> 
> We also considered that requiring a bridge to do stateless 
> transliteration
> is acceptable.
> Your proposal has many elements towards which we are neutral. 
> We might be
> wiling to change some coding elements to better fit bridges 
> as long as they
> don't affect iSCSI efficiency but we would like to keep the 
> header length
> constant.
> 

I agree with that goal. However, as you state below, the issue of how best
to distribute I/O traffic across multiple TCP/IP connections effects header
design and was still in flux.  Like you, I felt it was premature to address
concerns in this area.

> There is some misunderstanding about the CDB length - the 
> iSCSI is pretty
> liberal only that it use a tricky coding of the length field 
> (not something
> we would necessarily want to keep in).
> 

I may well have misunderstood something here.  After reading the iSCSI spec,
I was not clear as to what the extra data field in the iSCSI command PDU was
to be used for.  It was my surmise that you may have intended this for CDBs
in excess of 16 bytes -- although, I didn't glean that from the wording in
the spec.

> The FCP task management encoding is strange - if any task 
> management flag
> is set
> the CDB is unused; we might go for it if it where not for 
> that the task
> abort command requires us to specify which task we are taking 
> about and we
> don't want to expand every header. The net result is a header 
> that exceeds
> our constant length.
> 

I suspect that the rational for the encapsulation was based on the desire to
simplify implementations by having all control blocks be the same size.
After all, task mangement requests are very infrequent, so there's not much
point in optimizing them. 

> 
> 
> Responses - are simpler. There is an almost 1-to-1 match and the total
> length is within bounds.
> 
> For R2T - we can rearange the fields.
> 
> For Data - if we are moving to an asymmetric model with 2 
> connections we
> may want
> to have a streamlined header on the data stream(as in the 
> 00-draft - no use
> for the current clutter).
> 
> THE QUESTION of TAG MAPPING is still open.
> 
> In summary I think that we can converge but we have some more 
> work to do
> to on the commands and I think that before we settle the
> asymmetric/symmetric and
> related it will be hard to see all the details.
> 
> But let us keep talking and agree to attempt a format 
> convergence before
> the next version of the draft is due (before San Diego).
> 
> Keep in mind that if we go for asymmetric we would like to 
> get the header
> back to the original
> 40 bytes (?) if possible.
> 
<material deleted>

Regards,
Charles