Re: Proper understanding of

Barry,

The receiver can't use the marker in the 3rd segment - until the second 
segment arrives.

Until this second segment arrives, the 3rd segment is buffered (or 
dropped if the receiver doesn't support out-of-order receipt.)
Once the second segment does arrive, then the FPDU CRC32C can be 
computed. The receiver uses its per-session state  knowledge
of where it left off after the first segment and its per-session 
knowledge of where the markers are to compute where the end of the FPDU
- and the CRC32C field - is.

After validating the CRC32C, it can then trust the contents of any 
embedded markers - including the one in the 3rd segment - to confirm its
determination of where the fpdu header is. Only at this point does the 
receiver have enough confidence in the header's placement information to be
able to dma the fpdu payload into host memory.

I didn't mean to imply that the Rx buffering is limited to 512B. You're 
right that the Rx must be prepared to buffer up segments until it has a 
full FPDU to act on.
This max size is ~64KB since the ULPDU length field is 16b wide. Note 
that the actual buffering amount could be somewhat greater than 64KB 
since the
length field does not account for the MPA overhead itself (length, 
markers, pad, crc).

Lastly, this whole discussion only applies to the (hopefully uncommon!) 
case where the FPDU doesn't fit into a single segment.
The common, high-performance case is one where an entire FPDU arrives in 
a single TCP segment.

Mike Seufert
www.neterion.com

bbr wrote:
> Thanks Mike,
>
> I understand you to be in agreement that the conformant device MUST NOT use
> the marker received in the 3rd segment.
>
> BTW - I am unclear as to why the buffer only has to be 512B, wouldn't it
> need to be large enough to cover whatever size the FPDU might be? What is
> gained by catching the next marker?
>
> -----Original Message-----
> From: Mike Seufert [mailto:[email protected]] 
> Sent: Tuesday, January 02, 2007 10:05 AM
> To: [email protected]
> Cc: RDDP
> Subject: Re: [rddp] Proper understanding of
>
> Barry,
>
> In the situation you described, the receiver could not use the marker 
> information in the 3rd segment until the 2nd segment had also arrived.
> This means the receiver must be prepared to do some amount of 
> (per-session) buffering. Fortunately the amount of this buffering is 
> small since the marker period is only 512B.
>
> Mike Seufert
> www.neterion.com
>
> bbr wrote:
>   
>> Folks,
>>
>> I'm looking at the changes in MPA from draft 02 (against which the 
>> conformance suite was written) to draft 08. I would like to understand 
>> how to take the following text from page 25 (clause 6).
>>
>> "To detect the start of the FPDU unambiguously one of the following
>>
>> MUST be used:
>>
>> 1: In an ordered TCP stream, the ULPDU Length field in the current
>>
>> FPDU when FPDU has a valid CRC, can be used to identify the
>>
>> beginning of the next FPDU.
>>
>> 2: For optimized MPA/TCP receivers that support out of order
>>
>> reception of FPDUs (see section 4.3 MPA Markers on page 15) a
>>
>> Marker can always be used to locate the beginning of an FPDU (in
>>
>> FPDUs with valid CRCs). Since the location of the Marker is
>>
>> known in the octet stream (sequence number space), the Marker can
>>
>> always be found.
>>
>> 3: Having found an FPDU by means of a Marker, an optimized MPA/TCP
>>
>> receiver can find following contiguous FPDUs by using the ULPDU
>>
>> Length fields (from FPDUs with valid CRCs) to establish the next
>>
>> FPDU boundary."
>>
>> Question: Is an implementation allowed to use the marker, as described 
>> below, to "unambiguously" detect the start of a FPDU?
>>
>> Condition under which marker was received:
>>
>> 1. Markers being used (negotiated on)
>>
>> 2. Large FPDU being sent which consumes three TCP segments (not 
>> desired but allowed)
>>
>> 3. Second TCP segment lost
>>
>> 4. Marker located in third TCP segment
>>
>> Issue: In item two above it would appear that the implementation would 
>> have to validate the FPDU in which the marker is received (perform CRC 
>> check) before it can use it. However, since a portion of the FPDU is 
>> missing this would not be possible to do. Therefore a conformant 
>> device MUST NOT use this marker to detect the start of the FPDU.
>>
>> Is this the correct understanding of this requirement?
>>
>> Barry Reinhold
>>
>> (603) 868-8411
>>
>> [email protected] <mailto:[email protected]>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rddp mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rddp
>>   
>>     
>
>
>
>