Subject: [rddp] Framing and TCP changes

From: [email-masked]
Date: Wed, 4 Dec 2002 02:28:26 -0500

Jim,

> It seems there are two groups with fiercely
> held convictions.  One that MPA should not 
> be modified, and the other that TCP should
> not be modified.  Clearly both groups would
> oppose such a proposal.  So not modifying
> TCP seems like the preferable of the
> alternatives that actually stands a chance.
> 
> Is my assessment of the situation correct?
> Some guidance with your WG chair hat back
> on might be helpful here.

As I recall saying in Atlanta, the MPA and IFT
drafts strike me as lying roughly at the
endpoints of a design spectrum, and I suspect
the proverbial "right answer" (technically
best solution) lies somewhere in between.  If
progress in this TCP mapping area is not visible
by March, that will be a consideration in the
charter revision of the WG scheduled to occur
then (e.g., if there are no signs that useful
work will occur, TCP mapping can be removed
from the charter).

The WG is going to be held to a high standard
in this area, independent of whether it proposes
changing TCP or not, as whatever is proposed for
framing will have to satisfy the WG chair, the ADs and
in all likelihood the tsvwg WG.  There are aspects
of MPA that are far from that standard, as should
be clear from other emails on both this list and
the tsvwg list.  OTOH, our AD declined to completely
rule out modifications to TCP, and I concur -
consideration of limited TCP changes is ok, but strong
design requirements and rationale will be necessary.

To put this somewhat more informally - TCP is demonstrably
"not broke" and hence very strong design rationales will be
necessary for any proposal to "fix it".

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 4 Dec 2002 14:26:39 -0600

This post represents my understanding of the benefits of
markers.

Arguments for markers:

- It is the only mechanism that allows frames to be found
- even when TCP segments are received out of order, and the
- TCP segment boundaries have been altered by middleboxes.

- DDP/whatever/TCP must work even when there are middleboxes
- that destroy alignment.

- It works even when the Data Source is a software stack
- that cannot enforce outbound alignment.

Arguments against markers:

- They are complex.

- They waste bandwidth.

It is important to remember that even when alignment is
preserved, without markers no TCP segment can be processed.
There is no way to distinquish valid DDP segments from
potential payload. There could be payload that looks like a
header, and of course a header could be valid payload.
Once markers have been eliminated, TCP segments can *only*
be processed in order.

It is possible to build a very low cost RNIC that optimizes
for the receipt of aligned TCP segments with markers even
out of order.

Without markers, an RNIC would have to have extensive
buffering to deal with dropped segments. Dropped segments,
unlike alignment-destroying middleboxes are next to
impossible to avoid. (Unless limited by the application
or the Link Layer, TCP *will* increase its transmission
rate *until* there are segment drops).

So clearly, the absence of markers imposes a *severe*
penalty on RNICs optimized for alignment preserving
environments. In contrast, markers are a nuisance, but they
are far from an implementation-breaker for any option.

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