Subject: RE: [rddp] One vs Two CRCs

From: "Shah, Hemal" <[email-masked]>
Date: Fri, 22 Nov 2002 08:46:37 -0800

I would like to add one more point to the debate between two CRCs vs. one
CRC. In the DDP draft, one of the LLP requirement is LLP MUST provide strong
digest to cover at least the DDP Segment. The goal is to have the same DDP
Segment format for different LLPs.

IFT has two CRCs based proposal for DDP over TCP. SCTP already has a strong
digest covering the payload. In this case, are we going to have a different
DDP Segment format for DDP over SCTP mapping or are we going to have two
CRCs on top of SCTP digest for the DDP over SCTP mapping to maintain the
same DDP Segment format? I would like to hear more thoughts on this one.

I think with IFT we are roto-tilling DDP and framing layer with digests. I
would like to have DDP functionality cleanly layered above underlying LLP
that provides strong digest covering the DDP Segment. 

Hemal

-----Original Message-----
From: Williams, Jim [mailto:[email-masked]] 
Sent: Thursday, November 21, 2002 7:31 PM
To: [email-masked]
Subject: RE: [rddp] One vs Two CRCs

> -----Original Message-----
> From: Uri Elzur [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 6:51 PM
> To: Somesh Gupta; [email-masked]
> Subject: RE: [rddp] One vs Two CRCs
> 
> 
> There has not been any argument as for the benefit of the 
> additional CRC.

I believe there is an argument both in my draft and my
presentation.  If there is a flaw in this argument,
it would be preferable for you to point out what
aspect of the argument is flawed, rather than
claim the argument doesn't exist.

> The only argument I hear is implementation. 

That is true for may of the features defined in 
the protocols under discussion in this WG.
Implementation issues are valid considerations
as long as they are generic to the protocol
and not a narrow implication of one possible
implementation.

> "After listening to many NIC vendors" in the same meeting, 
> one must reach the conclusion that many other vendors feel it 
> is easier to implement one CRC.

I don't think this should degenerate into a vote, but so
far the NIC vendor representatives I am aware of
are Uri, Pat, Somesh, and myself.  And that looks
like an even split.

------

Having said that, though, I think the source of the
disagreement is a different model of how an RNIC is 
implemented.  It is probably worth drilling into that
a little, and I will attempt to do that at some point
in the near future.  It may boil down to an assessment
of which model is more generic, and which is more
of a point solution. 

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 22 Nov 2002 13:07:10 -0600

On 11/22/02, Shah, Hemal wrote:

>
>IFT has two CRCs based proposal for DDP over TCP. SCTP
>already has a strong digest covering the payload. In this
>case, are we going to have a different DDP Segment format
>for DDP over SCTP mapping or are we going to have two CRCs
>on top of SCTP digest for the DDP over SCTP mapping to
>maintain the same DDP Segment format? I would like to hear
>more thoughts on this one.
>
SCTP middle-boxes do not have the same latitude to massage
the stream as TCP middle-boxes do. Basically a TCP
connection is a stream of bytes (actually two streams, if
you count out-of-band), while SCTP is a stream of chunks.
The original user message (a DDP segment) boundaries are
preserved by SCTP, even if SCTP fragementation is allowed.

If fragmentation is allowed, then each fragment is fully
validated by the SCTP CRC32. The DDP Header would always be
in the first segment, so the problem would not exist.

In the current SCTP draft fragmentation is disallowed. Which
ultimately means that IP fragmentation must be used instead
if it is the only way to reach the destination. The
advantage of doing so is that it keeps the CRC as an
end-to-end protection.

IP fragmentation should not be a persistent problem, as both
SCTP and DDP are supposed to adjust to the PMTU. This
contrasts with TCP scenarios where a middle-box could break
alignment on a connection, and keep it broken for the
duration of the connection.

In addition to to above factors, SCTP middle-boxes are less
likely to be a problem for the simple reason that they are
not as needed as TCP middleboxes.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 22 Nov 2002 19:35:06 -0500

> Basically a TCP connection is a stream of bytes (actually two
> streams, if you count out-of-band),

[nit]

No, TCP has a single stream of bytes, plus an "urgent pointer".

Traditionally, tcp's urgent pointer appears through the sockets API as
"out of band data", but that's really not what's happening on the
wire, and this is generally regarded as a botch.  best not to think
too hard about this since existing protocols which use the urgent
pointer will likely not have much need for rddp, and new protocols
just shouldn't use it.

					- Bill