Re: ISCSI: Urgent Flag requirement violates TCP.

[Glen Turner <glen.turner@aarnet.edu.au>]

Matt Wakeley wrote:
> 
> > But when I look at the socket API for UNIX I can't see how
> > a receiver can use Urgent data create a synchronisation point
> > within a TCP stream.
> 
> For a strictly software implementation, the urgent pointer provides no benefit at all.
> This framing mechanism is to help special TCP/iSCSI accelerated implementations, not
> iSCSI implemented using generic off the self TCP stacks.
> 
> Sorry I forgot to mention that...

Hi Matt,

Actually, now I'm feeling even more confused.  I am assuming
my cold is making me slow, so I apologise for that.

Won't the client (the machine using the disk) almost always
be a general purpose computer, and thus using an "off the shelf"
TCP stack?

The clients that spring to my mind are web servers,
desktop machines doing backups, corporate mainframes
and the like.  The only accelerated-accelerated
applications I can think of are dumping iSCSI drives
to tape and creating a mirrored disk.

I think that most clients are unlikely to use special
network interfaces for iSCSI, as happens for Fiber Channel
now.  They'll just use their generic GbE interface,
route the traffic to a subnet that is a 802.1Q VLAN reserved
for storage devices and allow the DSCP to set the 802.1Q
Priority above that of other switched traffic.

I'm sorry to keep asking these questions, but I'd really
like iSCSI to work in the wide area as well as within a
SAN, as this leads to some simple answers for remote access
to national assets such as the tape silos at supercomputer
sites -- at the moment there's a lot of "staging disk"
nonsense and FTPing of files.

We're also building a 10Gbps nationwide network with QoS
support, so I fully expect that university A may join with
univerisity B to pool their nearline and offline storage.

As far as I see it, there is already a SAN technology --
fiber channel -- so the whole rationale for doing iSCSI is
an ability to run SCSI over wide area Internet infrastructure
(and if that infrastructure needs to support QoS, then that's
OK).

Best wishes,
Glen

-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised