RE: Proper value for embedded marker when FPDU is preceded byamarker

I just want to point out that the processing of FPDUs is always having to know where markers are and skip over them in preparing what it will pass up to DDP. Therefore, the situation we are discussing doesn't require any extra checking. The implementation is just doing the same thing it would do during in order processing where an FPDU ends. 

To ensure that the MPA spec is clear about the value of markers in the case where an FPDU begins with a marker, we should add the following to the end of the paragraph discussing the FPDUPTR value of 0x0000 in 5.1: 
"When a marker contains the FPDUPTR value of 0x0000, the beginning of that marker is  the beginning of the FPDU and its location in the TCP stream is used to determine the FPDUPTR value for any subsequent markers in the FPDU." 

Regards,
Pat

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Carrier, John
Sent: Wednesday, 22 September, 2004 9:32 AM
To: RDDP
Subject: RE: [rddp] Proper value for embedded marker when FPDU is
preceded byamarker



I agree with Pat's explanation. 

I think we should clarify the text in the MPA spec by clearly stating that these markers "are part of the FPDU" not just "viewed as part of the FPDU".  

As a result, since markers point back to the first byte of the FPDU, an MPA receiver that uses a marker with a non-zero FPDUPTR to find the start of the FPDU must check that the start of the FPDU is not another marker before interpreting the FPDU's ULPDU_length field.   

I think, since ULPDU_length=0 isn't ruled out by the spec, the only way to do this is to check that the FPDUPTR is not a multiple of the marker interval.

--jc


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Barry Reinhold
> Sent: Tuesday, September 21, 2004 4:37 PM
> To: RDDP
> Subject: [rddp] Proper value for embedded marker when FPDU is preceded
> by amarker
> 
> 
> Clause 7.1 in MPA states:
> 
>    "An FPDUPTR value of 0x0000 is a special case - it is used when the
>    marker falls exactly between FPDUs.  In this case, the 
> marker MUST be
>    placed in the following FPDU and viewed as being part of that FPDU
>    (e.g. for CRC calculation). Thus an FPDUPTR value of 0x0000 means
>    that immediately following the marker is an FPDU header."
> 
> When a marker falls between FPDUs, and is "viewed as being 
> part of that
> FPDU", is it considered to be part of the FPDU in terms of the values
> placed in other markers? That is, if I have a second marker 
> in the FPDU
> that has a marker right before the start of the FPDU, is the 
> value in my
> second marker point me to the start of the first marker or to 
> the start
> of the "real" FPDU.
> 
> By example:
> 
> |FPDU-start....FPDU-end|MARKER|FPDU-start....MARKER2....FPDU-end|
>                        ^      ^
>                        |      |
>                        |      |
>                        A      B
> 
> Does the back pointer in MARKER2 point to A or to B?
> 
> 
> This issue has already been discussed a bit on another reflector - and
> Pat Thaler has observed the following:
> 
> +++++++++++++++++++++++++++++++++++
> 
> I don't think we thought about this issue. It may be better 
> to have the
> marker point to location A. My rationale: 
> 
> We are always having to keep an eye on which location has a marker and
> skip it so it doesn't save anything to have the markers point at B. 
> 
> On the other hand, if we get data out of sequence and unaligned so we
> are having to use the markers to find the start of data, we 
> will have to
> know where to start the CRC check on the marker we find for 
> that frame.
> If the rule is the marker has to point at B, then we will 
> always have to
> check to see if B is just after a marker location to know 
> where to start
> the CRC calculation.
> 
> Another point: We are using markers to find out where we are right? I
> expect one would look at the earliest marker one has in the stream
> first. Looking at the stream, if what we have received starts here or
> earlier,
>                          |
>                          V
> > |FPDU-start....FPDU-end|MARKER1|FPDU-start....MARKER2....FPDU-end|
> >                        ^      ^
> >                        |      |
> >                        |      |
> >                        A      B
> 
> Then we will have looked at MARKER1 anyway and MARKER2 won't 
> matter and
> we wouldn't do any extra math. Lets say instead that what we 
> got started
> at B. If we get MARKER2 and it points to B, it would be natural to try
> to process the frame because we have the start. But we can't do that
> because we don't have MARKER1 so we can't do the CRC. We would have to
> do the math to check whether there was a marker immediately proceeding
> before we could even decide whether to process the frame.
> 
> If markers always point to the frame start (meaning start 
> including the
> marker position), then we never have to do an extra checking step.
> 
> Regards,
> Pat
> Barry Reinhold
> Lamprey Networks
> [email protected]
> (603) 868-8411
>  
> 
> 
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
> 

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