re: mpa-00 draft - 8.1 Connection Setup

 >       Note: The requirement to wait on a Request Frame before sending 
a
 >         Reply frame is a design choice, it makes for well ordered
 >         sequence of events at each end, and avoids having to specify
 >         how to deal with situations where both ends start at the same
 >         time.

	As covered in the SCTP draft, supporting Active/Active startup
	is not that difficult. Admittedly, it is not that useful, either. All
	that is required is to define a third value for "instant start",
	which each side sends *and* expects to receive.

	For the goal of LLP neutrality, I believe that this should
	be added to the MPA draft, or removed from the SCTP mapping.
	I'm neutral on the topic, and would love to hear other opinions.

	The strongest argument for inclusion is that it is simple.
	The strongest argument for exclusion is that even simple
	things must go through QA.

 >  Note: Since the receiver's ability to deal with markers is
 > unknown until the Request and Reply frames have been
 > received, sending FPDUs before this occurs is not possible.

If a mismatch in capabilities will result in terminating the
connection, then there is nothing wrong with sending FPDUs
before this is confirmed. If there is a mismatch, the FPDUs
will be flushed anyway. Obviously traffic should not be placed
on the network that has any substantial chance of being
thrown away. But if the sender has reason to believe that
it already knows its peers mode (perhaps based on directory
information or prior connections) then it should not be required
to stall waiting for dynamic confirmation.

 >   4.  MPA "Responder" mode implementations MUST receive and validate 
at
 >     least one FPDU before sending any FPDUs or markers.
 >
 >
 >     Note: this requirement is present to allow the Initiator time to
 >         get its receiver into full operation before an FPDU arrives,
 >         avoiding potentially difficult requirements on the receiver.

As previously covered, I believe this rule is overly broad. The only
requirement is that neither side send their MPA Start Frame before
they are ready to process DDP Segments.


 >   6.  The received "Private Data" fields may be used by consumers at
 >     either end to further validate the connection, and set up DDP or
 >     other ULP parameters.  The ULP MAY close the TCP/MPA/DDP
 >     connection as a result of validating the "Private Data" fields.

If the ULP "may" use the Private Data, then the stack MUST pass the
Private Data to the ULP. I believe that this would be better stated
explicitly.

 >   8.  MPA implementations MUST use the difference between the MPA
 >     Request Frame and the MPA Reply Frame to check for incorrect
 >     "Initiator/Initiator" startups.  Implementations SHOULD put a
 >     timeout on waiting for the MPA Reply Frame when started in
 >     "Responder" mode, to detect incorrect "Responder/Responder"
 >     startups.

Which might imply that the Hamming Distance between the two
frames perhaps should be a bit larger than a few bits, especially
since the field only has TCP protection.




 > (Dual-Stack)   Note: Regardless of the "stack" architecture used, 
TCP's
 >  rules must  be followed.  For example, if network data is lost, 
re-segmented
 >     or re-ordered, TCP must recover appropriately even when this
 >     occurs while switching stacks.

It should be noted that the same remote host may be serviced
by *both* of these stacks. Therefore L2/L3 messages that relate
to a remote IP address may have to be processed by *both* stacks.



-----------------------------------------------
Caitlin Bestler - http://asomi.com/