Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation

From: "Julian Satran" <[email-masked]>
Date: Fri, 22 Feb 2002 11:55:52 +0200

What would the IT and TI add? The information is already available in the 
PDU (IT and IT PDUS are different).

Julo

Martins Krikis <[email-masked]>
Sent by: [email-masked]
20-02-02 00:50

        To:     [email-masked]
        cc: 
        Subject:        FMarker, RFMarkInt and SFMarkInt negotiation

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
  FMarker=receive; RFMarkInt=17,51
the target should answer with something like
  FMarker=send; SFMarkInt=34
(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.

  Martins Krikis

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
http://sports.yahoo.com

---

From: Martins Krikis <[email-masked]>
Date: Fri, 22 Feb 2002 10:12:11 -0800 (PST)

> PDU (IT and IT PDUS are different).

They would add clarity and consistency to text
negotiation. 

The concepts being negotiated are
"fixed interval markers for the initiator to target
direction" and "fixed interval markers for the target
to initiator direction". So why should the keys used
in negotiating these concepts be different depending
on who sent them? If I'm implementing negotiation, I
now have to do an extra mapping from a key (e.g.,
RFMarkInt) to the concept (ITFMarkInt or TIFMarkInt)
and this mapping is different for initiators and
targets (for the same operation, where operations
are send/receive). Plus, if the sequence I mentioned

  (initiator offers) FMarker=receive; RFMarkInt=17,51
  (target responds)  FMarker=send;    SFMarkInt=34

is correct, then it does not fit well in section
2.2.4, where the general format seems to mandate
answering with the same KEY (not the same concept).
A little further down there is also a requirement
to answer numerical negotiations with the "required
key". If the "required key" may or may not be the
same key that was received, this should be mentioned.
(Of course, one could argue that this is not a
numerical negotiation, because ranges are allowed,
not just single numbers, but this, too is not obvious
to the casual reader.)

What I was proposing was simply naming the keys
after the concepts and avoiding the extra mapping
step and seeming conflicts with 2.2.4. I am a pedant.

As to FMarker, its negotiation is very different
from everything else in that it may look like a list
negotiation because of the list of possible values
given, but it isn't. It is yet another special-case
parameter, and one that RFMarkInt and SFMarkInt
depend on. 

I was suggesting getting rid of it altogether by
allowing RFMarkInt/SFMarkInt (or, better yet,
ITFMarkInt, TIFMarkInt) to carry value 0, which
would mean that markers are not in use in the
respective direction.

Just because all the information is there and because
implementation is possible, it doesn't mean that it
cannot be organized more logically and simplify
implementations.

IMO, key names should match concept names regardless
of how and by whom they are being used; and all
parameter dependencies for operational phase should
be eliminated.

  Martins Krikis, Intel Corp.

Disclaimer: these opinions are my own and not
            necessarily those of my employer.

---

From: "Bob Mastors" <[email-masked]>
Date: Fri, 22 Feb 2002 13:12:10 -0700

I agree with the general concern.
FMarker is processed unlike any of the other negotiated keys.
It would be nice if it worked like HeaderDigest or AuthMethod
and presented a <list-of-options>.

R/SFMarkInt also stands out as different (and needing special code) because
it takes a range. But I can see that this would take more effort to fix.

And then there is the requirement in A.3.2 that "Whenever FMarker and RFMarker
are both sent, they MUST appear on the same login request/response."
This seems unnecessary to me and will require special code to handle.
But I imagine that most implementers (myself included) will just ignore
the requirement and hope the pdu doesn't get so full as to cause FMarker
to be in one pdu and RFMarker to be in the next.

And why are the units in 4 byte words instead of bytes with an alignment requirement.
It seems like everything else in the spec is in bytes.

I am not really in favor of FIM but if the hardware folks really want it
I don't mind implementing it. It is not that much work.
It would make my life easier as an implementer if the keys worked like the
other keys in section 12.

Apologies in advance if this has already been hashed out.

Bob