Re: ISCSI: Urgent Flag requirement violates TCP.

["Mark S. Edwards" <marke@muttsnuts.com>]

I can already buy general purpose TCP hardware accelerated gigabit 
NICs.  OK, these tend to only implement the fast path TCP processing, but 
with today's reasonably reliable links this accounts for over 99% of 
packets and will only consume 5-10% of host CPU.

Can anyone quantify for me the percentage difference that adding the URG 
pointer would make to this sort of throughput ?  I'm not sure, but my 
suspicion about such cards is that URG data does not flow through the fast 
path and would get off-loaded to the software.

My gut feeling is that I am not happy with the mandating of URG pointer as 
a MUST in the spec.  I fully understand the motivation of those seeking to 
implement iSCSI totally in hardware.  But I am concerned that such a 
blinkered approach of who cares about small client systems or we don't care 
about compatibility with legacy o/s implementations will restrict iSCSI to 
a small niche market connecting server farms.

As Glen has pointed out, businesses from the very small to the quite large 
will be connected to a MAN, renting software from the ASP, renting storage 
and backup facilities.  If these people need specialised hardware to use 
iSCSI and can't use their existing hardware/software, then iSCSI is a 
non-starter in what would probably be it's most lucrative and highest 
volume market.

We can go on giving examples and getting all religious, but can we cut this 
argument down to the relevance of the word MUST and at the same time 
consider details outside the technical sphere.  Is mandating this to the 
benefit of a specific set of implementors detrimental to the overall 
acceptance, marketability and sales of the end product ?

As an engineer, I hate to say this, but it is our customers, our sales and 
our profits that we need to consider as the bottom line, not some neat idea 
only relevant to engineers.

regards,

Mark.



At 10:57 PM 11/8/2000 -0800, John Hufferd/San Jose/IBM wrote:
>Glen,
>Along with my previous note about the needs for TCP/IP offload NICs, let me
>tell you how they work with the OSs.
>
>The various vendors that are building these, are letting the iSCSI Device
>Driver directly talk to the NIC, without going through the normal OS
>TCP/IP.  This is very similar to the way a FC adapter are driven.
>
>So  these vendors believe that they can use iSCSI to justify the TCP/IP
>offload NIC, and that once there, the various  host TCP/IP stacks will,
>over time, exploit this capability.  Whether or not, the latter happens
>over time, I do not know, but I like the HW implementations for iSCSI
>direct use.
>
>.
>.
>.
>John L. Hufferd
>Senior Technical Staff Member (STSM)
>IBM/SSG San Jose Ca
>(408) 256-0403, Tie: 276-0403
>Internet address: hufferd@us.ibm.com
>
>
>Glen Turner <glen.turner@aarnet.edu.au>@ece.cmu.edu on 11/08/2000 12:29:53
>AM
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   Matt Wakeley <matt_wakeley@agilent.com>
>cc:   ips@ece.cmu.edu
>Subject:  Re: ISCSI: Urgent Flag requirement violates TCP.
>
>
>
>Matt Wakeley wrote:
> >
> > Nope.  Machines today using "off the shelf" stacks utilizing 1Gbps
>ethernet max out the CPU
> > running the TCP/IP stack, with no processing power left over for doing
>any work.  Machines
> > will not be able to fully utilize the new 10Gbps links if the TCP/IP
>processing is not
> > offloaded out of the main kernel.
>
>But that's an argument for iSCSI *not* using TCP services beyond the
>socket API.  To use such services the general purpose
>computer running TCP/IP offload would then need to change the
>code in the operating system *and* the code in the ethernet adapter.
>
>For commodity hardware you then need support from multiple
>manufacturers to get a computer that will run a complaint
>iSCSI client.  This is inviting maintenance issues (eg:
>need to install Windoze 2002 to fix security issue, but
>the driver for the particular ethernet card doesn't
>work with Win2002, and you can't just use any off-the-shelf
>TCP-offload card becuase you need iSCSI-socket support).
>
>I trying not to harp on about this, but it seems to me that
>people haven't thought out the software options at the client
>end in the same detail that they appear to have put into
>the target end.
>
>My feeling is that if the client can't use off-the-shelf
>gear then iSCSI is only going to displace Fiber Channel
>and will not become a widespread network service.  For
>example, ISPs attempting to add value to their service
>will need to find another mechanism to offer a storage
>and backup service to their customers, whereas iSCSI
>could be an ideal candidate for that application.
>
>Best regards,
>Glen