Re: iSCSI: No Framing

["Mallikarjun C." <cbm@rose.hp.com>]

I share the concern about iSCSI embracing a framing mechanism that is
not a MUST implement.  For all the reasons that Jim pointed out, OTOH,
I am not recommending a MUST framing either.  I suspect not many will
implement framing if it's a MAY, so it appears that we're talking about
a potential SHOULD.

Given that SHOULD is a fairly strong requirement, one "significant justification"
for not doing framing could be (even while the NIC *may be* on the expensive side) -
 - has less design complexity since no OOO placement.
 - can have quicker TTM since less design, testing, debugging etc.

I think ultimately it boils down to: how many vendors would use a "significant
justfication" to not implement a SHOULD-requirement?

If that's a majority: let's say vendor X is implementing (whatever) framing for
optimizing the memory requirements, it essentially means that X's product will
perform poorly with (the majority) no-framing senders.  I don't think X would
like that, nor the customer.  IOW, this situation doesn't seem to be long-lasting.
OTOH, the situation of an almost equal number of  "framing" and "no-framing"
products in the market (perhaps at different price points) could be unfortunately
long-lasting....

To summarize, it is a troubling prospect that a framing technique (if adopted as
SHOULD) has the potential to somewhat fracture the market and in effect
create "interoperability problems" (of performance sort) similar to that affect
FC....
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747

>
> -----Original Message-----
> From: WENDT,JIM (HP-Roseville,ex1) [mailto:jim_wendt@hp.com]
> Sent: Tuesday, January 29, 2002 10:47 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: No Framing
>
>
>
> So, it would be good to hear from several iSCSI
> NIC/chip implementors who:
> - have or plan to implement FIM or COWS (or some
> other framing mechanism) and take advantage of it to
> minimize demands on on-NIC buffer memory
> bandwidth/quantity.
> - believe that all-buffers-on-chip solutions are
> feasible and valid (wrt the points above, including
> #2)
> - can quantify the memory/pin/power/space cost
> savings for all-buffers-on-chip solutions
>
> Jim
>