RE: Proper value for embedded marker when FPDUispreceded by a marker

Pat

I think it is fair to say that the text is not clear, as I mentioned,
the text that talks about the content of the marker doesn't support the
claim that a marker can point to another marker instead of pointing to
the ULPDU_length. 

Implementation is a different space and people tend to have different
opinions for obvious reasons. I contend that marker that is always
pointing to ULPDU_Length is simpler. 

A receive implementation that is using the marker to find beginning of
the FPDU, first have to locate the marker itself. I.e. it needs to find
the offset of the first byte of TCP payload which for instance is X and
then performs X(mod 512). Using add/subtract it will get to the marker
in this TCP segment if it exists there (always in locations Y where
Y(mod 512) = 0).

Now consider the two cases: 
1) if the zero marker is used to find the beginning of the FPDU, the
receiver doesn't care what the value of Marker2 is. 
2) If Marker2 is used to find the FPDU start e.g. when the receiver has
received a partial FPDU (starting from ULPDU_Length but without the
immediately preceding zero-marker), the receiver has a simpler
algorithm. The previous X(Mod 512) has already yielded 4, so the
receiver knows a marker with zero value must have preceded this
location, no further computation is required. 
 When the missing zero-marker is received and the FPDU is ready for
processing, the receiver needs a pointer to the FPDU_Length in order to
continue in the FPDU processing, Marker2 conveniently does that (as long
as it doesn't point to another marker all of the sudden...). 
 


Uri  (pronunciation exempli gratia "Oo-ree", id est "U" followed by
"ri") 


-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Thursday, September 23, 2004 5:17 PM
To: Uri Elzur; [email protected]; [email protected]
Subject: RE: [rddp] Proper value for embedded marker when FPDUispreceded
by a marker

Uri, 

It says "viewed as being part of that FPDU (e.g. for CRC calculation)"

"E.g." means for example (abbreviation for the Latin exempli gratia). So
"viewed as being part of the FPDU" is a blanket statement and "for the
CRC calculation" is just an example of what the effect of that view is.

"I.e." means "that is" (abbreviation for the Latin id est). If the
statement before only applied to CRC calculation, it would have  said
"i.e. for the CRC calculation" though in that case the former statement
should have also made the limitation clear.

As far as implementation, it is always simpler to have the other markers
in a FPDU that begins with a marker point to the beginning of the
initial marker. Rationale:

	You can't process the FPDU until you have the marker that leads
it.
	Presumably most implementations using markers to find the front
of an FPDU (to do out of order processing or whatever) will look at the
first marker they have available so they can find and process the first
FPDU they have.
	Therefore, normally when an implementation is trying to find its
place and the first FPDU it has starts with a marker, they will look at
the 0x0000 marker and the values in the later markers won't be
important.
	The case may occur an implementation when the missing part of
the stream ends at the boundary between a 0x0000 marker and an FPDU
header. 
	In that case, the FPDU cannot be processed because the CRC check
cannot be performed with a missing marker. So it is okay or even
desireable for the other markers to point to the beginning of the marker
- the implementation will see that it doesn't yet have the head of the
PDU and will look for a later marker to find the first PDU it does have.
	When the gap gets filled, then the FPDU can be processed either
because the marker that was missing arrives and is examined or because
the implementation remembered the FPDU start location and skipped over
the marker to find the header as it would do during in order processing.

Regards,
Pat

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Uri Elzur
Sent: Thursday, 23 September, 2004 11:40 AM
To: Carrier, John; RDDP
Subject: RE: [rddp] Proper value for embedded marker when FPDUispreceded
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



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