RE: Proper value for embedded marker when FPDU ispreceded by a marker

Uri,

The spec does not say that the Marker of zero is included only for CRC calculation.  It says that the marker of zero is part of the FPDU and only mentions the CRC calculation parenthetically:

 "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)."

I think it's easier to say that the CRC calculation always starts from the beginning of the FPDU.  The only question for the MPA receiver is whether the FPDU starts with a marker or the ULPDU_Length field.  But as Pat pointed out, the receiver already knows where the markers will be since it has to strip them out before passing to the ULPDU to DDP. 

This shouldn't complicate a transmitter sending aligned FPDUs because the marker of zero is part of the FPDU being sent.  Hence, the FPDUPTR in all markers in the aligned FPDU will point to the first byte of the segment MPA passes to TCP.  

--jc

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Uri Elzur
> Sent: Wednesday, September 22, 2004 10:28 AM
> To: Barry Reinhold; RDDP
> Subject: RE: [rddp] Proper value for embedded marker when FPDU
> ispreceded by a marker
> 
> 
> Having MARKER2 (below) point to FPDU-start (B), rather than to
> Zero-Marker (A), provides for a consistent computation of the marker
> value on transmit (backwards delta to FPDU-start or zero, no 
> corner case
> of check for Marker-Zero preceding FPDU-Start) and makes the algorithm
> for finding the FPDU-start in a received frame, invariant of frame
> format and of this corner case in particular. (note, in any case
> Zero-Marker is part of the FPDU for CRC calc purposes, as correctly
> stated in the draft and also that there is no saving of 
> arithmetic steps
> for both approaches)
>  
> Receiver algorithm: 
> 
> 1. When aligned, receiver gets both markers as part of the 
> FPDU and can
> ignore them. 
> 
> 2. It becomes more interesting when FPDU is not aligned or 
> out of order.
> Receiver has to first find a marker. For the general case, the marker
> arithmetic is:
>  
> 	X. if non zero then subtract marker value from TCP seq to get
> FPDU-Start
> 		X.1 If FPDU-Start is 4 bytes after a marker location,
> include marker-			zero in CRC calc. 
> 			Arithmetic is if (seq - marker_offset)mod 512 =
> 4, then include 			prev 4 bytes in CRC calc
> 	Y. if zero, FPDU-Start follows immediately.
> 
>  Now in the corner case, where the receiver has received the FPDU from
> point B, it   
> 
> 
> |FPDU-start....FPDU-end|Zero-MARKER|FPDU-start....MARKER2....FPDU-end|
>                        ^           ^
>                        |           |
>                        |           |
>                        A           B
> still has to find the PDU boundaries first. Even if MARKER2 
> points to A,
> receiver can tell it misses the beginning of the FPDU but it still has
> to compute X.1 above, as it will have to find out it needs to skip 4
> bytes to get to FPDU-Start. But now the XMT algorithm is more
> complicated see above.    
> 
> As for the draft, I'm not sure if we have the X.1 arithmetic described
> any where.
>  
> 
> 
> Uri  ("Oo-ree") 
> 
> W: (949)-926-6432 
> C:  (949)-292-6098 
> 
> 
> -----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 a marker
> 
> 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
>