[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Re: iSCSI Marker questions
Marker interval is from the end-of-marker to the beginning-of-next marker.
The pointers to the next header do not include markers either.
Calculating the marker position is trivial anyway.
Pointers are not dependent on the marker interval and can be computed without knowing the TCP sequence numbers (makes layering cleaner).
Should the marker interval be counted from the begining of 1 marker to the
begining of the next, or from the end of one marker to the begining of the next.
Having the marker interval counted from the begining of 1 marker to the begining
of the next makes it easier for the receiver to determine where the next marker
From: email@example.com [mailto:firstname.lastname@example.org]On Behalf Of Julian Satran
Sent: Tuesday, December 11, 2001 4:54 PM
Subject: Fw: Re: iSCSI Marker questions
----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 -----
email@example.com wrote on 11-12-2001 03:09:11:
> The iSCSI Draft 9 Appendix C makes the following statements about
> Markers and the Initial Marker-less Interval:
> "The offset to the next iSCSI PDU header is counted in terms
> of the TCP stream data. Anything counted in the TCP
> sequence-number is counted for the offset. Specifically this
> includes any bytes "inserted" in the TCP stream by an UFL and
> it excludes any other markers inserted between the one we are
> examining and the next PDU header."...
> "To enable the connection setup including the login phase
> negotiation, marking (if any) is started only at the first
> marker interval after the end of the login phase."
> I understand that markers are not inserted until after login phase.
> Am I correct to assume that the placement of the first marker
> determined by the TCP sequence numbers on the final Login Request/
> Response PDUs, or is initial marker position determined by the
> TCP sequence numbers at connection establishment?
> Assume the following interaction:
> I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion?
> T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion?
> I-> Login Request PDU, T=0,CSG=1,NSG=0:
> T-> Login Response PDU, T=0,CSG=1,NSG=0:
> I-> Login Request PDU, T=1,CSG=1,NSG=3:
> (64-byte PDU... TCP sequenceNum=1301-1364)
> T-> Login Response PDU, T=1,CSG=1,NSG=3:
> (48-byte PDU... TCP sequenceNum=2201-2248)
> The above interaction designates a 1024 x 4 = 4096-byte marker
> interval in both directions. The first PDU byte sent by the
> intitiator in full-feature mode will have sequenceNum=1365, and
> the first byte sent by the target will have sequenceNum=2249.
> Assuming the markerless interval starts at the end of login
> phase, the first two markers in each direction will have the
> following TCP sequence numbers:
> TCP SeqNum of TCP SeqNum of
> First Marker Second Marker
> ------------ -------------
> Initiator: 5461-5468 9565-9572
> Target: 6345-6352 10449-10456
No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are:
Initiator 5096-5103 9200-9201
Target 6096-6103 10200-10201
> Is this the correct interpretation of marker usage in iSCSI
> Draft 9, or does marker placement depend on the connection's
> initial sequence numbers?
> Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt="
> considered a reply to that offer? If an offer is sent with "FMarker=..."
> and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or
> BOTH "FMarker=yes" and "SFMarkInt=..."?
Fmarker is not boolean - legal values are no, send, receive, send-receive
The sender and receiver must set the interval it wants/is ready to use
otherwise the responder can't answer.
I assume a normal dialogue may go like:
Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa.
I will attempt an example in draft 10 (last?).
> Dean Scoville
> QLogic Corp.
Last updated: Mon Dec 17 14:17:51 2001
8099 messages in chronological order