Re: Some thoughts about draft 05 of iSCSI

[julian_satran@il.ibm.com]

Responses in text. Julo

"Jeroen Ruigrok van der Werven" <JeroenR@InterXion.com> on 15/03/2001
14:20:34

Please respond to "Jeroen Ruigrok van der Werven" <JeroenR@InterXion.com>

To:   ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Some thoughts about draft 05 of iSCSI




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.

+++ No reason other than convenience. At first I did not know and when I
learned about I did not know how popular it is and then I forgot completely
-:) If it is very popular we can change  +++

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

+++ both should be better than NFS -:). For data integrity we have
end-to-end digests - (does NFS?) for latency we have no wonders but we did
our best to allow hiding it and not let it affect throughput +++

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".
+++ will fix case +++
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.
+++ bursting limit (unsolicited data) is meant mainly to help targets but
network could also benefit +++
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.
+++ don't get back into this - many of us have open wounds here -:)
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/>