RE: Proper value for embedded marker when FPDU is preceded 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