Subject: [rddp] MPA draft status/situation

From: [email-masked]
Date: Thu, 5 Dec 2002 00:20:02 -0500

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).

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

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

(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.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 5 Dec 2002 00:54:44 -0600

>   in at precisely the point of a drop).
There is also the case of the stream terminating and
re-originating middlebox.

Such a middlebox

a) totally destroy any alignment, and do so consistently.

b) is an appropriate strategy when acting as a gateway
between networks with radically different L2 layers.

It is also possible to have a resegmenting middlebox that
attempts more mild optimizations, and hence 'kicks in'
during the middle of an in-progress session. I contend that
this possibility eliminates any chance of ULP testing for
middleboxes before ULP work begins.

>   rule out software implementations.

I do not see how they rule out software implementations.
Having implemented both convolutional encoding and Reed
Solomon Forward Error Correction in software I am very
reluctant to state that software cannot do something.

It does require software to compact the buffer, or more
likely transfer data from a raw buffer to a post MPA buffer.
But I suspect this is fully compatible with network speeds
that you would implement in software anyway.

Additionally, software CRC calculations can be made to have
very low CPU impact with enough memory for lookup tables.

Hardware performs these functions *better* than software
does, which is generally true for any simple fixed function,
but they are quite doable in software.

One of the reasons I continue to favor markers, even though
I consider them inelegant, is that they strike me as at most
a nuisance and a slight bandwidth waste. Their impact on
software based solutions is slight. This is compared to the
very serious impact that the absence of markers would have
on a limited buffer RNIC.

The absence of markers would have a far more dictatorial
impact on RNIC design than their inclusion does.

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

It also is wasteful of network capacity. Under many
protocols, the untagged message signalling transaction
closer will be *very* short. Unless the prior tagged
transfers aligned perfectly with the PMTU there is a very
high chance that the ULPDU containing the untagged message
could fit within the same TCP segment.

I think this issue is worth serious review.

>   about whether the TCP bytestream is framed or not.
The only way to leave MPA mode is to terminate the
connection. No new connection can be initiated without the
consent of both ends. Therefore once MPA mode has been
agreed to, there is no chance of the non-MPA traffic being
interpreted as though it were MPA traffic.

You also left out the valid, but in my opinion insufficient,
arguments in favor of a header only CRC to allow more prompt
placement of resegmented headers. As that resegmenting
middleboxes *can* be avoided for the vast majority of
connections I believe that the complexity of the second CRC
is not justified. However this is based upon the assumption
that it is acceptable to optimize only for cases where
alignment is not broken, as long as the connection functions
even when it is.

If the consensus were to be that the protocol must support
high levels of performance (in excess of plain TCP) even for
connections where alignment is broken, then the second CRC
would be justified.

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

---

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 5 Dec 2002 10:18:37 -0800

Considering the amount of variance in the scenarios
(10G data center config with hardware acceleration all
the way to software implementations across WANs with
segmenting middleboxes), and the lack of uncertainty
about maintaining alignment at all times etc etc.,
it is better to go with protocol design approach
that is more flexible and does not burden (on the
send side)/relegate (on the the receive path) 
software implementations to the slow path.

I believe some of the issues arise from the desire
to have an IB replacement as a data center interconnect,
but at the same time as not limiting (or being able to
limit) the scope of the problem to only that configuration.

Perhaps a compromise of a separate header and data CRC,
combined with optional markers is the right compromise.
Alignment is something that high-speed data center configurations
could use to further accelerate the processing.

Somesh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Caitlin Bestler
> Sent: Wednesday, December 04, 2002 10:55 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [rddp] MPA draft status/situation
> 
>