Subject: [rddp] RE: MPA draft status/situation - PLS REVIEW IF YOU CAN. I'd like to post this afternoon

From: "Uri Elzur" <[email-masked]>
Date: Thu, 5 Dec 2002 13:18:17 -0800

David,

Thanks for straightening me up and focusing the discussion again on the technical issues. 

As for the technical issues pls see embedded comments below [UE] and in the other mail sent out yesterday.

Uri
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, December 04, 2002 9:20 PM
To: Uri Elzur; [email-masked]
Subject: MPA draft status/situation
Importance: High

Uri,

WG chair hat on for this message ...

> Seems like we have 2 camps:  one camp (Jim, anyone else?) 
> claiming RNIC can not be made cheaper with Markers and a 
> larger group claiming it does simplify the RNIC and makes it cheaper. 
> Should we keep re hashing it again and again on this list?
> 
> Citing a vendor specific existing implementation as a reason 
> to stop any progress essential for the feasibility of high 
> speed (10G+) NICs, is not a compelling reason.

That's definitely an off-beam summary of the current situation.

In hopes of focusing discussion on productive technical matters,
let me get out the clue-by-four and be explicit about what this
WG will have to do if the MPA draft is going to go anywhere.

The following serious technical issues have to be resolved
via compelling design rationale and/or changes to MPA:

(1) Markers in their current form appear to have a rather
	disproportionate impact on the protocol to deal with a
	relatively rare error case (resegmenting middlebox kicks
	in at precisely the point of a drop).

[UE] My understanding of how a middle box works is that it can re-segment a TCP byte stream without a drop. This makes the receiver sub-optimal. In that case in order to get Direct Data Placement, some buffering must take place before the receiver gets a complete FPDU with its placement information. This will be the case without a drop. 

Another scenario is a  drop due to a simple congestion in a switch or a router, may cause  the receiver to either buffer all the following out-of-order or be able to place it. [UE]

(2) Markers in their current form appear to (deliberately?)
	rule out software implementations.

[UE] agree that there is a need to show more analysis to make sure, the heavy weight operation of touching every byte for CRC is evidently the performance hitter more than inserting or removing markers. There is NO intention to rule out SW implementations nor do I think MPA prevents them. [UE]

(3) The prohibition on packing multiple ULPDUs into a single
	TCP segment departs seriously from RFC 1122.

[UE] absolutely agree this might be a place where the current MPA draft may have to change.[UE] 

(4) Assurance must be provided that in no case can two
	communicating TCPs (MPA-modified or not) get confused
	about whether the TCP bytestream is framed or not.

[UE] "two communicating TCPs (MPA-modified or not) get confused about whether the TCP bytestream is framed or not". I believe framing is an ULP for TCP. Framed stream should not be communicating with non-framed stream in the same way HTTP has no interoperability with another app say NFS. I believe, correct me if I'm wrong, that the goal is to ensure non-framing-aware-application using framing-aware-TCP (with framing disabled for THIS app) has no interoperability issues with another non-framing-aware-application using non-framing-aware-TCP. All similar cases like, framing-aware-application using framing-aware-TCP communicating with framing-aware-application using non-framing-aware-TCP should be shown to interoperate with no issues. [UE]

In the absence of solutions (compelling design rationale and/or
design changes) to at least these four issues, WG rough consensus
will not be sufficient to advance the MPA draft.  The above
list of issues may not be complete (e.g., NFSv4 as a ULP is
not on it), but that should be enough to get some useful work
underway.  Sorry to have to wield the clue-by-four, but some
people seem to have lost sight of the situation that MPA is in.

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