Subject: RE: iSCSI-Asynch event code

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Wed, 12 Jun 2002 15:47:20 -0600

Martins,

I think this should be added, but I don't see any need to say that the initiator send an empty Text Request. It is possible (perhaps even likely in the event of a path change) that the initiator will decide to start a negotiation at the same time that the target sends the Asynch Message requesting negotiation. If so, the Initiator could send Text Negotiation before it has received (or processed) the message from  the target. Therefore, the target has to accept the initiator starting the negotiation with its own keys.

Also, all the standard keys currently allowed in FFP are declarations so it doesn't matter who offers keys first. 

An example:
Initiator and target are using a sync steering method where PDUs are aligned to transport segments/packets.
A path change occurs that reduces the path MTU.
Both the initiator and target detect the new MTU.
                       Async message request negotiation <- t
i -> Text negotiation (MaxRecvPDUDataSize)               -> t
i <-   Async message arrives 
but the negotiation has already started so the initiator doesn't need to take action on it. 

Regards,
Pat

-----Original Message-----
From: Martins Krikis [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 1:41 PM
To: [email-masked]
Subject: Re: iSCSI-Asynch event code

I don't mind this code being added for completeness
sake, nor will I be overly disappointed if it isn't.

If it is added, however, perhaps we should go half
a step farther and demand that the Text Request coming
from the initiator MUST be empty? That way the target
is
really "in charge" and may _originate_ any key
negotiable
in FFP. Just my $.02. Comments?

Martins Krikis, Intel Corp.

Disclaimer: These are my opinions and
            may not be my employer's.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

---

From: Martins Krikis <[email-masked]>
Date: Wed, 12 Jun 2002 15:06:40 -0700 (PDT)

I know it doesn't matter for the current standard
keys usable in FFP (it may matter for future keys
or for some vendor keys). I agree that it cannot be
guaranteed that the PDUs don't cross each
other on the wire and that the target gets
a non-empty Text Request. That's life. If it badly
wants to be in "initiator's shoes" and be the
originator, it can always try again. But at least
I'm proposing to give it a chance, and a fairly
decent one (albeit not a 100% guaranteed one) to
be in charge. Alright, so may be the initiator
SHOULD (not MUST) send an empty Text Request?

This new event is about symmetry, right? Well,
that (illusion of) symmetry will be more complete
if the target is given a chance to _originate_
anything it wishes, not just opportunity to
respond.

Anyway, I don't really care. Including whether
the new async event is added or not.

  Martins