Re: ISCSI: Urgent Flag requirement violates TCP.

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

I need to be very careful that I don't start a crush of specific vendor
marketing notes on this reflector, however, many vendor statements  sound
similar to what you quote, regarding their HW and the way their NICs works
with standard vendor stacks.  We have performed actual measurements (on
error free links) and found radially different numbers from what you state,
and the numbers the vendors were telling us.

The numbers I quoted are real world actual numbers.  (Investment decision
were based on results of these numbers, so it was important that they were
done correctly.)

We have also had a lot of work with "normal" 100MHz links (& NICs) -- and
have found, that for Desktops and Laptops -- they work extremely well with
iSCSI, in that environment.  So I do not think that you need to worry that
the need for special HW NICs, in servers, will impact the rest of the
world.  The rest of the world, will use standard SW stacks and will work
very well.

You have a valid point, however, and that is -- we should understand  the
impact on SW for the Urgent Pointer. If this impact is high, then we have a
significant problem with the urgent pointer proposal.  The impact maybe
un-measurable, but that is clearly the issue.

I think that Matt has said what he thinks the values are, however, if he
has some quantitative statements on cost reduction, speed improvements,
etc., in local and long distance environments, this would be very useful.

.
.
.
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


"Mark S. Edwards" <marke@muttsnuts.com>@ece.cmu.edu on 11/09/2000 12:09:30
AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  Re: ISCSI: Urgent Flag requirement violates TCP.



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