|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Re: iSCSI Marker questions
Julian,
Thanks for the
response. Some examples would be very helpful.
Your response shows
a parameter negotiation with SFMarkInt=1,512
but Draft 9 doesn't
allow a range for SFMarkInt... only for RFMarkInt.
Is a range also
being allowed for SFMarkInt?
>
> I assume a
normal dialogue may go like: > >
I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 > T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2
>
Section 2.2.4 of
the draft currently requires all integer parameter
negotiations to
have a
response . (Responses are optional only
with
boolean
negotiations where the offered value allows only a
single outcome
-- such as an "OR" boolean function with a "Yes"
offer). Are
responses always required for RFMarkInt and
SFMarkInt,
or is the
following acceptable?
I->
FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T->
FMarker=send,SFMarkInt=4
Would it also
be allowed to respond with the following and, if so,
is one
preferred over the other? (I'm not sure about the
current
state of using
"0" as a "don't care" value, but is that also
permitted in
cases where the response would be irrelevant?)
I->
FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T->
FMarker=send,SFMarkInt=4,RFMarkInt=irrelevant
With the following
exchange, is the target required to respond
with any RFMarkInt
or SFMarkInt values, since there is no
real choice of
values? Agreeing to send markers implies that
the interval is 512,
and not agreeing to receive markers implies
that there is no
receive interval. Is the following allowed, or
should "RFMarkInt=4"
and "SFMarkInt=irrelevant" be returned
by the
target?
I->
FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
T->
FMarker=send
Is the
following acceptable, even though it doesn't reply to
RFMarkInt and SFMarkInt?
I->
FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
T->
FMarker=no
It
would also be helpful to explain what happens if the login
phase
goes beyond the negotiated first marker interval.
Assume, for example, the following:
SYN - at TCP sequence num 1000.
SYN-ACK - at TCP sequence num 2000.
negotiate
to FMarker=send-receive,RFMarkInt=100,
SFMarkInt=100.
If the
1st byte of 1st initiator PDU in full-feature mode has TCP
seqNum=1404,
full-feature phase starts in the middle of what would
have been a marker.
Is a
partial marker inserted? What would be the TCP seqNum of the first
and
second marker?
If the
1st byte of 1st target PDU in full-feature mode has TCP
seqNum=2810,
what would be the TCP seqNum of the first and
second marker?
thanks,
Dean
----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39
-----
| Julian
Satran
11-12-01 14:44
|
To: IPS List cc:
Subject: Re: iSCSI Marker
questionsLink
|
|
Dean,
owner-ips@ece.cmu.edu 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: >
InitiatorName=xxx > TargetName=yyy >
SessionType=normal > ... >
FMarker=send-receive >
RFMarkInt=512,1024 > > T-> Login Response PDU,
T=0,CSG=1,NSG=0: > ... >
FMarker=send-receive > SFMarkInt=1024 >
RFMarkInt=1024 > > I-> Login Request
PDU, T=1,CSG=1,NSG=3: > SFMarkInt=1024 >
(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:
I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T->FMarker=send-receive,RFMarkInt=8,
SFMarkInt=2
Please observe that
target answers with RFMarkInt to the initiators SFMarkInt and
viceversa.
I will attempt an
example in draft 10 (last?).
> Thanks, > Dean Scoville > QLogic
Corp.
Home
Last updated: Fri Dec 14 23:17:47 2001
8081 messages in chronological order
|