Subject: [tcpm] draft-ietf-rddp-mpa-03.txt review request

From: Ted Faber <[email-masked]>
Date: Thu, 18 May 2006 10:48:43 -0700

Hi,

The draft draft-ietf-rddp-mpa-03.txt is up for review as a Proposed
Standard, and Lars thinks that TCPM review is essential.  Mark and I
agree.  Here's the abstract:

   MPA (Marker Protocol data unit Aligned framing) is designed to work
   as an "adaptation layer" between TCP and the Direct Data Placement
   [DDP] protocol, preserving the reliable, in-order delivery of TCP,
   while adding the preservation of higher-level protocol record
   boundaries that DDP requires. MPA is fully compliant with applicable
   TCP RFCs and can be utilized with existing TCP implementations. MPA
   also supports integrated implementations that combine TCP, MPA and
   DDP to reduce buffering requirements in the implementation and
   improve performance at the system level.

I'd like to get a couple reviewers now who are committed to providing
reviews by the end of the month or so.  David Black, the RDDP chair, is
interested in our feedback and in working out issues that arise.

Lars has read this and claims that though it's long, it is very
readable.  I don't think it'll be another ROHC or behave multi-draft
scavenger hunt.

If you're interested in this and willing to provide a review, please let
me and Mark know.  If we don't get volunteers, we'll start calling on
people.

A cool thing that Lars has subtlely pointed out to me is that an easy
way to reach Mark and me, or our eventual replacements, is
[email-masked].  That would be a great address to test by
volunteering to review this draft.

Thanks!

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 May 2006 11:31:16 -0700

> agree.  Here's the abstract:
...
> readable.  I don't think it'll be another ROHC or behave multi-draft

Really? (I do)... ;-(

TCP senders and receivers can be MPA-aware, but this is completely and 
utterly outside the scope of the interface between TCP and its 
application layer.

Some other things came up in a _very_ quick scan:

The requirement in 3.1 is already a requirement of TCP (793, top page 
75); that sort of thing is inappropriate to respecify.

3.1.1 incorrectly assumes that turning Nagle off will correlate sends 
with segment boundaries; TCP is under _no_ obligation to do this. 
possible changes in pmtu would definitely change that behavior

TCP should never assume 1500-byte segments; 576 is the assumption 
_unless other information is specifically available_.

---

I _really_ don't want to burn time on _yet another_ round of explaining 
to MP-folks why boundary alignment in TCP is a bad thing, and how badly 
it interacts with TCP's mechanisms even if they wanted to add it.

This is a case where I'll ask that they use SCTP and please leave TCPM 
alone.

At the very least, modifying TCP to be MPA-aware redefines the TCP 
interface; that needs to happen __before and separately__ from the use 
of MPA of that interface.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Fri, 19 May 2006 00:49:57 +0200

On May 18, 2006, at 19:48, Ted Faber wrote:
> an easy way to reach Mark and me, or our eventual replacements, is
> [email-masked].

FWIW, it's [email-masked]. (All cool things happen under  
tools these days.) Works for all other WGs, too.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Ted Faber <[email-masked]>
Date: Thu, 18 May 2006 18:07:40 -0700

> tools these days.) Works for all other WGs, too.

That must be why all those review volunteer messages haven't been coming
in.

Thanks.

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2006 11:52:38 -0700

Ted Faber wrote:
> agree.  

OK, so I gave this a quick (very quick) look yesterday for some deeper 
feedback. Here are the two primary points. For those of you in a rush, 
jump to item #2. It's sufficient, IMO.

Joe

----
#1
First, I'm not in favor of a protocol spec that passively depends on 
implementation-specific behavior of another protocol. IMO, there are two 
valid options:

	a) discover the behavior explicitly, e.g., by trying
	sends with offsets of garbage, and see when your PDU aligns
	with TCPs segment

	(i.e., how buffer offset tuning works, e.g., where using
	buffers slightly offset from page boundaries tends to have
	higher performance)

	b) negotiate the desired behavior via an API, e.g.,
	a socket parameter

This document does neither; it presents a mechanism for exploiting 
implementation artifacts. I'm very worried about a spec that has that 
basis; it will tend to encourage defacto-standardization of those 
artifacts, which would be a bad thing.

----
#2
However, second - and probably more important is that this document 
redefines TCP ("MPA-aware TCP"); that's not in the purvue of RDDP, and I 
would expect this change to be _the_ impediment to this document going 
forward. Here are some examples:

Page 14, section 3.1.2 makes SHOULD recommendations that TCP deliver 
out-of-order segments to the application layer (i.e., the layer above 
TCP) even when there are gaps. Let's call that data 'partly received', 
i.e., SACK-able and stored by the receiver but _prohibited_ from being 
passed to the app.

It requires that TCP MUST NOT overwrite partly-received data; this is 
allowed by TCP. I.e., the received stream of MPA-enabled TCP and TCP 
would be different.

----
#3
FURTHER, MPA-enabled is indicated by a port or service locator protocol 
(see page 31, sec 6.1); this suggests that a _change to TCP semantics_ 
is governed by an application layer signal alone, rather than by a 
socket option.

I do not believe that RDDP should be designing variants of TCP 
regardless (that should occur in TCPM or TSVWG). When such variants are 
designed, IMO they MUST be signalled by a socket option (from app to 
TCP) and/or TCP flag/option (between TCP endpoints). It is inappropriate 
to rely solely on the combination application layer signals and TCP's 
parsing of the data stream for this operation (e.g., checking for MPA 
payloads).

----

IMO, MPA is using TCP where it really should be using one of RDP or 
SCTP. I see no reason to modify the semantics of TCP - even as an option 
- to support capabilities already present in these other protocols.

Joe

Here's the abstract:
> ------------------------------------------------------------------------
>