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

Hi John

Only reference to this special case of zero marker inclusion is the
parenthetical reference to CRC, nothing else. I guess the spec can enjoy
use of better wording, sigh. 

I think we all agree the receiver has to run same arithmetic and same
complexity whether Marker2 points to A or B. Hence, we differ on
transmitter complexity.

However, it also means that all the other markers if present in the FPDU
have values computed as usual i.e. pointing to ULPDU_Length. 

One way to get to this, is by refreshing our memories on the algorithm
and how we got to the zero marker. In general we wanted a back pointing
marker to point to the first byte of the FPDU i.e. ULPDU_Length field,
such that the receiver can identify the first byte of the FPDU i.e.
ULPDU_Length, when receiving out of order frames. Then we noticed that
in the case a marker falls right after CRC, we can't guarantee it can be
part of the previous FPDU. so to create a deterministic receiver
algorithm (i.e. receiver can always tell what TCP bytes are included in
CRC compute..), we decided to ALWAYS have that marker in front of next
FPDU and assign a special value of zero to it. We did not decide,
however to change the computation of all other markers...they still
point to the ULPDU_Length field
 


Uri  ("Oo-ree") 

W: (949)-926-6432 
C:  (949)-292-6098 


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Carrier, John
Sent: Wednesday, September 22, 2004 2:08 PM
To: RDDP
Subject: RE: [rddp] 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
> 

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