Re: FMarker, RFMarkInt and SFMarkInt negotiation

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bob,

Your concerns are important and I will attempt to answer them with a revised negotiation  for markers early tomorrow,
The marker scheme is old (the iSCSI meeting in Haifa) and the parameter negotiation (given the concerns surrounding it) has not been updated.


Julo

"Bob Mastors" <bmastors@aciesnetworks.com> Sent by: owner-ips@ece.cmu.edu 22-02-02 22:12

To:        <ips@ece.cmu.edu>         cc:                 Subject:        Re: FMarker, RFMarkInt and SFMarkInt negotiation

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


----- Original Message ----- 
From: "Martins Krikis" <mkrikis@yahoo.com>
To: <ips@ece.cmu.edu>
Sent: Friday, February 22, 2002 11:12 AM
Subject: Re: FMarker, RFMarkInt and SFMarkInt negotiation


> --- Julian Satran <Julian_Satran@il.ibm.com> wrote:
> > What would the IT and TI add? The information is
> > already available in the 
> > 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.
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com