RE: Proper value for embedded marker when FPDU is preceded by amarker

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
>