RE: Last call comments on MPA draft

Hemal Shah wrote:

14.   Section 5.4, page 24: This section seems to suggest that CRC has
to be valid for detecting FPDU start using one of the methods described
in 1, 2, or 3. If the CRC is turned off, then which one of these methods
should be used to detect the start of the FPDUs? Do all of them apply or
a sub-set of them apply? The spec does not specify how to detect start
of
FPDUs when the CRC is turned off. If all the methods apply when the CRC
is turned off, then add a note saying "There is no requirement to have
valid CRCs for detecting the start of FPDUs using the above methods when
the CRC is turned off." 


[caitlin]
CRC is disabled only when equivalent protections are available.
Therefore
in this type of context the CRC *is* valid. In no CRC mode the CRC is
*always*
valid, and the FPDU is always valid. If that were not true then CRC
would
not have been disabled.
[/caitlin]

	
16.   Section 6.1.1: I think we need to add a note here to say
"When markers are not enabled, then the MPA SHOULD NOT enable
DDP to recover out-of-order segments." Currently, the spec does
not say that when the markers are not enabled, then out-of-order
segments are not placed.

[caitlin]
I believe the draft is already clear that out-of-order segments
cannot be delivered to the DDP layer unless there are unambiguous
indicators that it is indeed a valid MPA frame. Merely looking like
one is not enough, because there is nothing to say that the payload
of a DDP Segment could not be a valid MPA frame.

Without markers there is only *one* way to determine that an
out-of-order segment has the starting point of an MPA frame.
You need for CRCs to be disabled *and* to have received the
header of the *prior* MPA frame, but not it's tail. If CRCs
are enabled, then the MPA header is not validated and you
do not know, for certain, how long the MPA frame is. The
discussion on finding iSCSI PDUs is very applicable. Except
that MPA Frames that span multiple TCP segments are very
rare and in fact something that explicitly SHOULD be avoided.
The same tricks for finding iSCSI PDUs without periodic 
marker insertion are *technically* viable for finding
MPA frames with markers disabled. But it is just as
complex with virtually zero chance of producing any
benefit.

I do not believe that an IETF SHOULD is required to guide 
implementers into not wasting code space looking for 
optimizations that have virtually zero benefits.

But  since the burden is entirely on the implementation
there is no real justification for telling them that
they SHOULD NOT do this particular  activity, because
it is only their effort that they are wasting. I don't
see any adverse network impact should someone actually
attempt this extreme example of heroic MPA frame
identification.

[/caitlin]