[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FMarker, RFMarkInt and SFMarkInt negotiation
What would the IT and TI add? The information is already available in the PDU (IT and IT PDUS are different).
Dear list members,
I seem to be having problems (or at least mild
surprises) reading A.3.1 to A.3.3 of draft 10.
Would you mind answering a few questions and hearing
out some beginner's ideas? Many thanks in advance.
Is it true that RFMarkInt when used by initiator
means the intervals for the T->I direction, while
this same key used by target refers to the I->T
direction? Similarly (well, dually) for SFMarkInt?
That is, if initiator starts the negotiation and sends
the target should answer with something like
(the numbers used are just examples).
I'm not sure that RFMarker is properly negotiated
if the answer for it comes with the key "SFMarker"...
The fact that FMarker=receive by originator
is the same as FMarker=send by responder isn't
pretty either, but at least the given example
leaves no doubt. Or does it? What if send/receive
is always with respect to the target? It would
contradict the general principle that most everything
in iSCSI is named with respect to initiator, but
no example eliminates this possibility...
May I suggest that we use something like ITFMarkInt
and TIFMarkInt to unambiguously show which
direction is being talked about?
I would also love to tinker with FMarker values
a bit, ideally get rid of it (thus getting rid of
a clear parameter dependency), and use ITFMarkInt=0
and TIFMarker=0 to denote that markers are not in
use in the respective direction.
Any comments will be greatly appreciated.
P.S. I am not really a fan of features that are
useless for software implementations and that
break protocol layering, but would like to at
least understand how they are to be negotiated...
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
Last updated: Fri Feb 22 13:18:03 2002
8848 messages in chronological order