Re: iSCSI framing Meeting Wednesday

[Daniel Smith <dfsmith@almaden.ibm.com>]

"HAAGENS,RANDY (HP-Roseville,ex1)" wrote:
> 
> that a group of us are meeting Wednesday to discuss this issue offline.
> John Hufferd plans to attend.  The rules of engagement are up to three
> attendees per company.  Please coordinate with John if you wish to attend
> also.
> 
> Randy Haagens

I don't believe we have anything to discuss.  B-)

My contribution to the debate can be summed up as follows.

1. The iSCSI draft should not discuss specific accelerator additions to
TCP.

2. The iSCSI draft should recommend that accelerator mechanisms be
considered.

3. The accelerator additions would be covered in other RFCs.

Hence, an implementation would describe itself as being iSCSI/RFC12345
compliant, or iSCSI/RFC12345/RFC12346 etc.  (RFC12345=urgent pointer,
RFC12346=RDMA, for example.)

When the market has worked out which accelerator actually works, and which
is just hassle, then we can work that mechanism into the standard if
warranted.  I have very deep reservations about advocating/mandating
something untested!  (I look at the VGA card market.  In the beginning there
was plain VGA, then 2D accelerated, then 3D acellerated.  Each card is
capable of working in plain VGA mode, but companies can differentiate
themselves with accelerator mechanisms.  While iSCSI is more complex,
because of the multi-vendor interoperability facet, it is basically the same
situation: mandate basic functionality, advise acceleration.)

Just one comment on the UP mechanism.  If a company really has a desperate
need for the benefits of not slowing down on dropped packets, then they will
make sure that their implementation runs on a network that does /not/ drop
packets.

Daniel Smith
-- 
IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA
K65B/C2 Phone: +1(408)927-2072 Fax: +1(408)927-3010