Some thoughts about draft 05 of iSCSI

["Jeroen Ruigrok van der Werven" <JeroenR@InterXion.com>]

Hi all,

first, I am (not yet) subscribed to the list, so if you people
could keep me in the CC:-loop for this thread I would very much
appreciate it.

Second, I have some remarks I want to make and some questions to
ask.  Please bear with me that storage solutions aren't exactly
my forte aside from a consumer/customer point of view, I am more
of a networking/programmer type, so I might be asking things which
might be normal stuff for you.
I've read some large parts of the archives already, but I might
have missed my answers.

1) Why was it decided to use a 16 number dotted decimal specifier
   for IPv6 addresses?  As far as I know, and reading RFC 2373
   again, it is not mentioned anywhere, and it is so different from
   what is currently standard practice in notation.  Sure, it's
   simply basic convert-the-number-from-base-x-to-base-y type of
   stuff, but the current practice always settles on colon-delimited
   hexadecimal.

2) From reading the draft it seems logical to implement iSCSI in
   Operatnig System in a NFS like form, in which certain disk access
   gets exported and the kernel/low-level stuff/daemon(s) handle the
   actual requests/responses.
   What scares me though is that with NFS one knows he is accessing
   filesystems over a network, with iSCSI we want to make it as
   transparent as possible [at least that's how it struck me], but
   how is the blocking issue looked upon then?  It seems hard to
   guarantee the same reponse over a network as with directly coupled
   cables.  I am very much interested in this, since if we want to
   deploy this as a product our customers will have at least the
   following demands/questions:

	- data integrity
	- speed/latency

3) Julian, on page 80 of draft 05, section 6.2, last sentence:
   "it receives the a Data PDU with" should probably be:
   "it receives a DATA PDU with".

4) Am I correct in assuming, based 'pon my readnig of the draft, that
   bursting is limited to what FirstBurstSize is set to?  So there is
   little/no chance of having the iSCSI protocol saturate the available
   networkbandwidth all of a sudden by bursting to the max.

5) The draft specifies that both data PDU and commands are being sent
   over the same TCP connection.  This got me curious about the fact
   if iSCSI commands would get delayed if sufficiently large amounts of
   data are being sent over the TCP connection.
   For example, with some protocols they have a seperate control and
data
   connection.  IIRC, NNTP-streaming has it, ISDN is another prime
   example of this.

Thanks in advance for any trouble and time taken to answer
my questions,

-- 
Jeroen Ruigrok van der Werven <jeroenr@interxion.com>
Systems Software Engineer  /  Connectivity Services Development
InterXion, where the Internet lives <http://www.interxion.com/>