Subject: [rddp] RE: Data Digests (was RE: One vs Two CRCs)

From: "Mukund, Shridhar" <[email-masked]>
Date: Fri, 13 Dec 2002 14:16:34 -0800

> A. Use CRC-Chaining (for lack of another known term)
>    * Assume you split header and data CRC.
>    * Say the *data* (ABC) is split into three segments A,B,C
>    * CRC(ABC) = CRC(CRC(CRC(A),B),C). Check it out. If you
>      are not convinced, I will give you a mathematical proof.

A word of caution:
In case someone tries the above, pl. be careful how you 
interpret the "," in CRC(X,Y). I will be glad to help off-line.

-Shridhar Mukund
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Mukund, Shridhar" <[email-masked]>
Date: Mon, 16 Dec 2002 12:21:26 -0800

Caitlin,

On one hand, I am in total fear, uncertainity and doubt:-)
and on the other we are digressing.

If a tagged message was segmented by the DDP layer than 
the DDP reciever *by definition* knows the relationship
between it's constituent tagged DDP segments, irrespective 
of the order in which they arrive. If it used CRC-chaining 
than it would in a *state-less* fashion be able to deliver 
the CRC(digest) of the entire DDP message(not just segment) 
when the last DDP segment is determined to be in-order. 
Keep in mind that the CRC of the last DDP segment is same 
as the CRC of the entire DDP message, under CRC-chaining.

On the other hand, if a tagged ULP message(transaction) was
segmented by the ULP before being handed over to the DDP 
layer, it is up to the ULP to maintain(if needed) the digest 
relationship between tagged ULP-segments. a) The ULP 
interested in mainting the digest-atomicity may not perform
ULP-segmentation b) The ULP may not be interested in ULP
level digest or c) The ULP may choose to perform CRC-chaining
at it's level as well.

In any case, in the debate for 1 CRC vs 2 CRC, this is 
a peripheral issue. I am not suggesting that CRC-chaining 
be used in the context of RDDP mapping over TCP. 
When mapping over TCP, there is no need whatsoever to 
perform DDP segmentation in the first place. Built-in SAR
is intrinsic to TCP. To TCP every byte is an information 
segment!

-Shridhar Mukund

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Friday, December 13, 2002 4:28 PM
> To: [email-masked]
> Cc: 'Michael Krause'; Mukund, Shridhar
> Subject: Re: [rddp] RE: Data Digests (was RE: One vs Two CRCs)
> 
> 
> On 12/13/02, Mukund, Shridhar wrote:
> 
> >
> >Caitlin,
> >
> >
> >> There is a problem with providing ULP level data digests
> >> on Tagged messages -- the receiving side cannot
> >> distinquish between A 2K tagged message that was
> >> segmented into two 1K segments, and two 1K tagged
> >> messages that happen to be adjacent.
> >
> >Yes, I can see that. But then, it is just an artifact of
> >*a* design choice. For instance consider the following two
> >arguments:
> >
> >   * The ULP is only interested in CRC(ABC) which is 
> >     the same as the CRC of the last segment, as long as
> >     you chain them.
> >   * This is fairly simple to incorporate.
> >
> >B. On the other hand, my take is that DDP-SAR is a mistake.
> >   * DDP-SAR is nice and natural for SCTP.
> >   * What is natural to TCP is periodic synchronization. 
> >     There is no need to SAR.
> >   * See David Black's email where he saves the
> >     damsel(iSCSI like markers) from distress(MPA):-)
> >   * ...
> >
> 
> That still assumes that the receiver knows what set of
> receives to compare the digest against. That would involve
> some sort of state tracking. The wonderful thing about
> tagged segments currently is that they can be placed and
> simply forgotten.
> 
> You cannot assume that the tagged messages received between
> two untagged messages constitute a whole. Consider the
> following totally legitimate sequence:
> 
>     Client                      Server
>     ------                      ------
>     Untagged Request A----->
>         <----- Tagged Put in response to A - 1
>     Untagged Request B ----->
>         <----- Tagged Put in response to A - 2
>         <----- Tagged Put in response to B - 1
>         <----- Tagged Put in response to A -3
>         <----- Untagged Response to A
>         <----- Tagged Put in response to B - 2
>         <----- Untagged Response to B
>         
> Unless the Tagged Puts are somehow labeled as being a group
> there is no way for the receiver to know what set of data to
> apply the data digest against.
> 
> The fundamental problem is that the DDP layer simply does
> not know which Tagged messages are correlated with each
> other or with which untagged messages.
> 
> 
> Caitlin Bestler
> http://asomi.com/CaitlinBestler/
>

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 18 Dec 2002 12:01:22 -0600

> as the CRC of the entire DDP message, under CRC-chaining.
At the DDP layer, the Data Sink does not know DDP segments formed
a single message to the ULP at the Data Source. There is no
marking of 'first' or 'last'. Or even with are part of the
same message (and they can be interleaved).

> level digest or c) The ULP may choose to perform CRC-chaining
If only the ULP knows when to test the digest, then why define it
at the DDP layer at all?

The bottom line is that having DDP layer CRCs on the entire payload
from host to host requires additional information in the DDP header
(which makes it bigger), and a standard completion handler on the
host processor (which might not have otherwise been required).

Not providing an optional standard DDP layer host-processor to host-
processor digest simplifies the DDP layer, and does absolutely nothing
to interfere or prevent ULP-to-ULP digests.

> is intrinsic to TCP. To TCP every byte is an information 
When segmentation is maintained, which will be most cases, there can be a
substantial optimization in the receivers memory utilization. Just because it is
not available in *all* cases is no reason to not take advantage of a major
optimization when possible -- especially if "when" is most of the time.

 -- 
Caitlin Bestler <[email-masked]>
Bestlerk±î¨›‡ë€Ñÿ7Em/ k±î¨c¤ë€Ñÿ57m/0k±î¨Ããë¶cT.Ek±îk±î|¸ë€Ñÿ.5m/@k±î‚S…@ë€Ñÿ7Em/Pk±î‚@;@ë€Ñÿ57m/`k±î‚Lá@ë¶cT.Ek±îk±î¸ë€Ñÿ3>m/Ýk±î‚1ðë¶cT1?k±îk±îýë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±êë¶cTk±êk±ê•Ä
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp