Subject: iSCSI: Renegotiation and Non Spanning key

From: [email-masked]
Date: Fri, 24 May 2002 21:14:52 -0400

Ok, let me step in and observe a bit of rough consensus.

Martins' first issue was a request for clarifying text to
make it clear that keys cannot be renegotiated even if
the first negotiation ended with Reject, Irrelevant, or
NotUnderstood.  That clarifying text needs to go into the
draft, as I believe I've seen more than one request for it.

For the PDU spanning issue, I believe the rough consensus
is that the key plus the following "=" character MUST NOT
span a PDU boundary.

Thanks,
--David

> -----Original Message-----
> From: John Hufferd [mailto:[email-masked]]
> Sent: Friday, May 24, 2002 9:01 PM
> To: Martins Krikis
> Cc: Mallikarjun C.; Julian Satran; [email-masked]
> Subject: Re: iSCSI: Non Spanning key
> 
> 
> 
> OK, (note the change of subject.  So we can focus on one 
> thing at a time.)
> 
> I am fine with what Mallikarjun said, and do not fine it a 
> problem to do.
> 
> I propose that Mallikarjun's approach be our closure.  That 
> is, Keywords
> (including the =) do not span PDUs.
> 
> Can I get agreement.
> 
> If so we can then move to the next issue.
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136, Cell: (408) 499-9702
> Internet address: [email-masked]
> 
> 
> Martins Krikis <[email-masked]>@ece.cmu.edu on 05/24/2002 
> 05:45:09 PM
> 
> Sent by:    [email-masked]
> 
> 
> To:    "Mallikarjun C." <[email-masked]>, Julian 
> Satran/Haifa/IBM@IBMIL
> cc:    [email-masked]
> Subject:    Re: iSCSI: Negotiation clarifications still needed
> 
> 
> 
> Mallikarjun wrote:
> 
> > 2. Seems to me that we need to stipulate that only
> > key values
> >     may straddle PDU boundaries - key names (ideally
> > inclusive
> >     of "=") shall not.  That should avoid requiring
> > blank PDUs.
> 
> Definitely inclusive of "=". Otherwise there are
> no strict guarantees that the whole key has been
> received (we may have keys that are prefixes to
> other keys in future, and vendor keys may be like
> that).
> 
> I can implement it and live with it if that's what
> people decide on. I just want people to understand
> that it is conceptually a more complex aproach than
> requiring strictly blank PDUs and having a data-end
> flag. (Even if we don't add a new flag and decide
> data-end by looking for NUL-s at the end, we get
> a cleaner scheme.) Allowing non-blank PDUs  gives
> better bandwith utilization under
> presumably rare circumstances (all pairs not fitting),
> but introduces more complexity for your everyday case.
> 
> If we only stipulate that no key ever gets broken,
> then there is the following "clumsiness" required.
> When "originating" a key=value pair, it has to be
> checked whether the key will fit fully in the PDU
> or not, and if not, then "originating" must be
> postponed. We also need either a more elaborate
> state for the key (to mark key as received but
> value as not; so it is not processable yet, nor
> originatable anymore), or for each key=value pair
> being originated, key has to be checked against
> the buffer that would hold the "leftover stuff"
> from the just received PDU, otherwise we may
> illegally originate it. Doable, but not clean.
> 
> I still think that letting the whole set-of-pairs
> go through (no matter over how many PDUs spread)
> before the other side is allowed to process them
> is cleanest.
> 
> Martins Krikis, Intel Corp.
> 
> Disclaimer: these opinions are my own and may
>             not be those of my employer
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
> 
> 
>

---

From: Martins Krikis <[email-masked]>
Date: Fri, 24 May 2002 18:56:10 -0700 (PDT)

> is that the key plus the following "=" character

It might be fairer to wait till Tuesday for a
real consensus (it's a long weekend here and
it's Friday 9:50pm on the east coast, USA). 

If this is the way we go (and not what I proposed),
then there also needs to be text along these lines:
"A node MUST NOT send any key that has been received
with incomplete (including empty) value". In other
words, you cannot just leave the incomplete leftover
junk laying around in buffers, you must check against
it your outgoing keys. It all could have been avoided.
Even checking for whether a key and '=' fully fits
could have been avoided. Your call.

Disclaimer: these opinions are mine and may not
            be those of my employer