Subject: [rddp] Proper understanding of

From: "bbr" <[email-masked]>
Date: Mon, 1 Jan 2007 12:54:00 -0500

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-masked]

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "bbr" <[email-masked]>
Date: Tue, 2 Jan 2007 10:24:53 -0500

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-masked]] 
Sent: Tuesday, January 02, 2007 10:05 AM
To: [email-masked]
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:
> conformance suite was written) to draft 08. I would like to understand 
> how to take the following text from page 25 (clause 6).
>
> 2. Large FPDU being sent which consumes three TCP segments (not 
> desired but allowed)
>
> 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.
>
> [email-masked] <mailto:[email-masked]>
>
> ------------------------------------------------------------------------
>

---

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 2 Jan 2007 08:45:55 -0800

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). 
> 
> 
> 
> Question: Is an implementation allowed to use the marker, as
> described below, to "unambiguously" detect the start of a FPDU?
> 
> 
> 
> 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.
> 
> 
> 

The probable FPDU is not complete, therefore a conformant
receiver MUST NOT provide the DDP Segment to the DDP layer.

Whether the MPA receiver "used" the marker in the third segment
in an attempt to validate the FPDU is irrelevant, since no action
would result from merely testing the hypothesis. It would still
conclude that the FPDU was no ready for delivery to the DDP layer.

---

From: Mike Seufert <[email-masked]>
Date: Tue, 02 Jan 2007 11:56:01 -0500

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

---

From: Mike Seufert <[email-masked]>
Date: Tue, 02 Jan 2007 10:05:02 -0500

Barry,

Mike Seufert
www.neterion.com

bbr wrote:
>
> Folks,
>
> I’m looking at the changes in MPA from draft 02 (against which the 
> “To detect the start of the FPDU unambiguously one of the following
>
> MUST be used:
>
> FPDU boundary.”
> below, to “unambiguously” detect the start of a FPDU?
>