Proper understanding of

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

RE: Proper understanding of

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:mike.seufert <at> neterion.com] 
Sent: Tuesday, January 02, 2007 10:05 AM
To: bbr <at> lampreynetworks.com
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
>
> bbr <at> lampreynetworks.com <mailto:bbr <at> lampreynetworks.com>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rddp mailing list
> rddp <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rddp
>   

RE: Proper understanding of

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?
> 
> 

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.

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:mike.seufert <at> neterion.com] 
> Sent: Tuesday, January 02, 2007 10:05 AM
> To: bbr <at> lampreynetworks.com
> 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
>>
>> bbr <at> lampreynetworks.com <mailto:bbr <at> lampreynetworks.com>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rddp mailing list
>> rddp <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/rddp
>>   
>>     
>
>
>
>   

Re: 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
>
> bbr <at> lampreynetworks.com <mailto:bbr <at> lampreynetworks.com>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rddp mailing list
> rddp <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rddp
>   

Messages from Mike Seufert

These were delayed in the IETF's spam trap, due to the
fact that I was on vacation.  I apologize for the delay
in forwarding the messages out of the spam trap to the
RDDP mailing list.

Just a reminder - if you are not a subscriber to this
mailing list, you should expect any messages sent to
the list to be held by the spam trap for at least a day
or over the weekend.  Actual traffic on this list is
fairly light (especially compared to the volume of spam
that the spam trap catches), and a digest option is
available to avoid being inundated by a burst of activity,
so the best bet for anyone interested to the list is to
subscribe.

Thanks,
--David (rddp WG chair and mailing list admin)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

No RDDP meeting in Prague

The RDDP working group will not meet in Prague.  Since
all of the WG's drafts have been approved by the IESG
for RFC publication, the WG is unlikely to meet again.
If additional issues arise in the documents, they will
be resolved on the mailing list.

Thanks,
--David (rddp WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

Re: No RDDP meeting in Prague

On 2007-1-30, at 3:13, ext rddp-bounces <at> ietf.org wrote:
> The RDDP working group will not meet in Prague.  Since
> all of the WG's drafts have been approved by the IESG
> for RFC publication, the WG is unlikely to meet again.
> If additional issues arise in the documents, they will
> be resolved on the mailing list.

FYI, the current plan is to close the WG and declare victory after  
the documents have been published, to safeguard against the  
(unlikely) event that any changes will need to be made during the  
publication process that would require WG consensus.

Lars

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp