Subject: [rddp] I-D ACTION:draft-williams-iwarp-ift-00.txt

From: "Williams, Jim" <[email-masked]>
Date: Fri, 18 Oct 2002 16:13:18 -0400

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: iWARP Framing for TCP
	Author(s)	: J. Williams
	Filename	: draft-williams-iwarp-ift-00.txt
	Pages		: 10
	Date		: 2002-10-10
	
A framing protocol is defined for DDP over TCP that is fully
compliant with applicable TCP RFCs and fully interoperable with
existing TCP implementations.  This protocol is being offered 
for discussion and consideration as an alternative to the
proposal offered in "draft-culley-iwarp-mpa-00.txt".

The protocol offers to two things, definition of the DDP record
boundaries within the TCP stream, and added data integrity 
by means of added CRC protection.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-williams-iwarp-ift-00.txt
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Sat, 19 Oct 2002 16:37:25 -0500

On 10/18/02, Williams, Jim wrote:

>A framing protocol is defined for DDP over TCP that is
>fully compliant with applicable TCP RFCs and fully
>interoperable with existing TCP implementations.  This
>protocol is being offered for discussion and consideration
>as an alternative to the proposal offered in
>"draft-culley-iwarp-mpa-00.txt".
>
>The protocol offers to two things, definition of the DDP
>record boundaries within the TCP stream, and added data
>integrity by means of added CRC protection.
>

The arguments for a seperate CRC on the DDP header are
strong, however I do not believe they belong here.

The destination address in the DDP header must be validated
before any data placement can occur. Without a CRC header
the DDP layer must buffer the data for at least the size of
an entire DDP segment. It cannot do immediate 'cut through'
placement of the data.

However, when DDP is carried over SCTP there will be no such
facility available. If "cut-through" data placement is
indeed desirable enough to add the complexity of an
additional CRC, then it should be defined at the DDP layer.
The functionality that would justify it is independent of
the LLP used to deliver the DDP message. CRCs are only part
of the LLP-adaptation when the LLP fails to provide the
complete message CRC that SCTP does.

Curiously, the benefit of DDP header CRC (enabling
cut-through placement of the DDP payload) seems to run to
the opposite direction of the rest of the proposal. If it is
tolerable to defer placement until TCP segments can be
processed in order, why is it not tolerable to defer
placement until the entire DDP segment has been scanned?

The argument against alignment markers and header CRCs is
ultimately the same: they represent extra bytes in the
messages and extra complexity in the implementations and it
can be argued that they do not provide sufficient benefit to
justify themselves.

The IFT approach is optimized for a LLP layer that already
uses sufficient buffering to deliver the TCP payload to the
next layer in order. The RMA approach is optimized for a LLP
layer that attempts to  place each TCP segment as it
arrives, and then track acking/delivery seperately. Both are
valid, cleanly layered, implementation strategies.

However I believe that the IFT approach would force the LLP
layer to have more buffering capacity than would MPA. This
could be incompatible with an "on chip" buffering strategy.
By contrast MPA is compatible with either NIC design, it
merely "wastes" bytes on alignment markers that a
traditionally layered TCP optimizing chip would have little
use for.

I recognize that one benefit of such a NIC design is that
large NIC buffers allow it to optimize *all* TCP traffic,
not merely RDMAP/DDP. That is a valuable plus to such a
design, which buyers should consider when selecting NICs.
However, the IETF should accomodate both design strategies.

Have you analyzed the worst case impact on required
buffering that removing the alignment markers will have? If
it could be shown to be slight enough the advantages of a
simpler protocol could still be compelling.

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