Re: Markers

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Tue, 6 Aug 2002, Michael J. S. Smith (PacBell) wrote:

> MarkersI helped write our hardware specification on this issue and
> going over the specification again just now, I realized that I
> referenced the Internet draft for the definitive description of marker
> insertion. So, I certainly have an interest in getting this right.
>
> >> From this text, it is not clear whether the two "copies" of the marker are identical copies
>
> Pat, you are right, you need to look beyond the text that you quoted
> to get clarity. Some ambiguity is resolved when you realize that
> markers "don't count".
>
>  [quote]
>
>    The Marker scheme uses payload byte stream counting that includes
>    every byte placed by iSCSI in the TCP stream except for the markers
>    themselves. It also excludes any bytes that TCP counts but are not
>    originated by iSCSI.
>
> [end quote]
>
> Thus,
>
> 1. Since "counting ... includes every byte ... except for the markers
> themselves," I believe the markers are both identical (in particular,
> the count in the two markers is the same, since we don't count the
> marker bytes).
>
> [quote]
>    Marker is eight bytes in length and contains two 32-bit offset fields
>    that indicate how many bytes to skip in the TCP stream in order to
>    find the next iSCSI PDU header.
> [end quote]
>
> [quote]
>
>    The marker interval and the initial marker-less interval are counted
>    in terms of the bytes placed in the TCP stream data by iSCSI.
> [end quote]
>
> >> From this text, it is not clear ... whether each marker specifies
> >> how many bytes to skip from its position in the stream. It also isn't
> >> entirely clear where the count of bytes to skip starts (which is
> >> related to the first).
>
> Again the two markers don't matter. Thus,
>
> 2. The count is how many TCP stream bytes to skip, forget about the
> markers. The definition of "TCP Stream" needs a stretch, but between
> the first and third sections quoted above, I think it is "TCP Stream
> := every byte placed by iSCSI in the TCP stream except for the markers
> themselves and any bytes that TCP counts but are not originated by
> iSCSI".
>
> I had to think a few times about "bytes that TCP counts but are not
> originated by iSCSI", and I can't think of any strange cases that
> leave ambiguity in this definition, but can anyone else?

No, I think that's a good definition.

Though do you have examples of "bytes that TCP counts but are not
originated by iSCSI" that aren't markers?

> On the other hand if we were to add ""The count of bytes begins with
> the first byte after the Marker", I think there is a possibility for
> confusion unless you again declare "count of bytes" means TCP Stream
> (as defined).
>
> I'm probably too close to this now to render an objective opinion on
> whether ambiguity exists, but I think an example will help, and Pat's
> is as good as any to resolve this particular (possible) ambiguity (in
> her example, I believe both marker copies contain zero).

I'd like to suggest another, more complicated example that I think would
remove all ambiguity.

Scenario: We have data digests enabled for CRC32C, and markers every 2k of
data (every 512 int32's of data). We are 4 bytes away from our next
marker, and we send 8k worth of zeros.

We would write (I believe, please help check me on this):

four bytes of zero: 00 00 00 00

Marker (we're 8k away from next pdu): 00 00 20 00 00 00 20 00

2k of data: all zeros  (00 00 00 00 .....)

Marker (we're now 6k away):           00 00 18 00 00 00 18 00

2k of data: all zeros  (00 00 00 00 .....)

Marker (now 4k away):                 00 00 10 00 00 00 10 00

2k of data: all zeros  (00 00 00 00 .....)

Marker (now 2k away):                 00 00 08 00 00 00 08 00

2044 bytes of data, all that's left: (00 00 00 00 .....)

The data digest: (in transmission order) 23 46 44 90

Marker (now 0 away):                  00 00 00 00 00 00 00 00

[Next PDU]

Does that look right?

Also, this example can serve as another CRC example.

Take care,

Bill