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

Hi,

below is one review by a TCPM member on the MPA draft. (There were  
some additional messages on that TCPM list that the MPA authors  
probably want to look at.)

There may be additional reviews on their way out of TCPM, but this  
one already raises some significant concerns that I'd like to see  
discussed.

(As far as I can tell, the recent draft-ietf-rddp-mpa-04.txt does not  
reflect this yet.)

Lars

Begin forwarded message:

> From: Joe Touch <[email protected]>
> Date: May 19, 2006 8:52:38 PM GMT+02:00
> To: Ted Faber <[email protected]>
> Cc: [email protected]
> Subject: Re: [tcpm] draft-ietf-rddp-mpa-03.txt review request
>
>
>
> Ted Faber wrote:
>> 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.
>
> 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:
>>    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 protected].  That would be a great address to test by
>> volunteering to review this draft.
>> Thanks!
>> --------------------------------------------------------------------- 
>> ---
>> _______________________________________________
>> tcpm mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/tcpm

-- 
Lars Eggert                                     NEC Network Laboratories

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