Re: Some questions on iSCSI marker

[julian_satran@il.ibm.com]

Answers in text.  Julo

"Sukha Ghosh" <sukghosh@bellsouth.net> on 20/01/2001 20:49:36

Please respond to "Sukha Ghosh" <sukghosh@bellsouth.net>

To:   ips@ece.cmu.edu
cc:
Subject:  Some questions on iSCSI marker




Hi,

    I have some questions on iSCSI Markers which are not clear to me from
the specification. Can one of you please clarify or answer:

1. The marker interval value like RFMarkInt, SFMarkInt, IFMarkInt etc, are
they value in dwords (for example, a value of 1 means interval of 4 bytes)
or are they in bytes but you have to make sure that they are multiple of 4?

<js> 1 is one word </js>

2. Is the position of the first marker in a TCP connection in a direction
(initial sequence value + IFMarkInt value)?

<js>correct</js>

3. Is the relative offset of the next nearest start of the iSCSI message
header that is in the marker is counting the beginning of the marker or is
it relative to the end of the marker?

<js>start-to-start I will clarify the text and add an exemple</js>

4. If there are multiple markers at negotiated marker intervals before the
beginning of next iSCSI message header (in between two iSCSI messages), is
it required to check the content validity of the next marker with respect
to the previous marker or do you take the content of the latest marker
identified as valid value?

<js>that is up to the implemeter; in theory you could ignore them until you
need them but you could as well signal a format error is markers are
incorrect</js>

5. The iSCSI PDUs being always multiple of 4 bytes, does it imply in any
way that the TCP sequence # needs to be also at a 4-byte boundary alignment
before starting placement of markers?

<js> definitely not! TCP asigns a random sequence number to start with and
that is your "virtual-mile-0" </js>

6. As I understood from the specification -01, the idea of using Urgent
pointer to identfy iSCSI message boundary in TCP stream is also to help an
external protocol analyzer to be able to identify and sync correctly from a
iSCSI message boundary at any point of time when it is asked to sample.
With the marker scheme, it seems that the protocol analyzer needs to start
sampling right at the beginning of the iSCSI log-in phase to be able to
identify the markers and hence the iSCSI message boundary etc. Is my
understanding correct?

Thanks

 - att1.htm

<js> a protocol analyzer will either have to find out by itself what marker
interval is being used (trial and error) or ask the operate to key one in
</js>