Subject: [rddp] Reality Check: Avoiding confusion on MPA TCP use

From: [email-masked]
Date: Wed, 19 Feb 2003 12:48:55 -0500

I need to be more careful about what I wish for - I forgot how
enthusiastic some folks can be about discussing TCP framing and the
IETF process issues that surround it (a momentary lapse - it won't
happen again, at least not anytime soon ;-) ).  This message is an
attempt to sort out some of issues raised recently on the list
and/or in private and suggest a productive path forward.

Let me start with an attempt at a consensus call:

	I believe the rough consensus of the RDDP WG is to pursue
	an RDDP over TCP solution that allows cooperating TCP
	implementations to employ sender alignment, provided that:
	- Alignment is optional
	- Receiver support/usage of alignment does not lock out sender
		implementations that use unmodified TCP stacks.

I hope this is not controversial, but send objections to the list
(as is usual for any attempted consensus call).

In case anyone finds the above to be at odds with some of what I've
posted recently, all of my comments along the lines of "doing <XXX>
would require removal of sender alignment from MPA" have been with
the intent of identifying unproductive courses of action (i.e., I
know the MPA advocates don't want to remove alignment from MPA,
hence the intended inference from a statement like "doing <XXX> would
require removal of alignment" is: "doing <XXX> would be a bad idea").

Assuming the acceptance of the above attempt at consensus, the
following three items are *facts*, and should not be discussed
further on this list:

(1) Applications that use TCP don't make changes to TCP.  Sender
    alignment is a TCP change, so MPA is not just an application.
(2) The "proof" requirement is linked to the TCP sender alignment
    change, so the above rough consensus entails providing a "proof".
(3) The Transport ADs hold all the cards, specifically the RDDP WG
    charter is at high risk of being withdrawn or modified to exclude
    TCP if the WG insists on extensive exploration of the tarpits
    of whether TCP is being changed and whether "proof" is necessary.

Those with questions/concerns/objections to the above are welcome to
contact me directly off the list, but the above three items are not
open to change and should not be discussed further on the list
(yes, the ADs are watching ...).

Turning to a more positive topic, there is a path forward available
in the Elzur MPA TCP analysis draft.  Section 8.1 says:

   The third model is by negotiation of MPA transition by the ULP
   using octet stream messages to accomplish a ULP specific
   <MPA Hello>, <MPA Hello ACK>, <MPA ACK> three way exchange.

If this exchange were made MPA-generic instead of ULP-specific and
applied to all transitions to MPA, including those that occur
immediately at the start of a connection, then Figure 5 in that
draft contains much of the "proof" structure and content.

This approach would also provide a means of dealing with the
current unrealistic buffer size analysis in Section 7.  The
problem is that *if*, as a number of people have posted, a
receiver cannot tell the difference between the bytestream
arriving from an unmodified TCP vs. an MPA-enabled TCP, then
a receiver has to assume the former, and cannot achieve the
desired "BufferSizeAF = K2 * EMSS".  FWIW, the approach of
requiring that unmodified TCPs and MPA-enabled TCPs contact
receivers on different ports is unlikely to be acceptable, and
kicking transport buffer sizing issues up to ULPs to deal with
is silly.

In addition, this sort of exchange would also provide a means of
making the current 512-byte fixed marker interval variable, which
is probably going to be needed to seriously deal with unmodified
TCP stacks (e.g., are 16 syscalls or other send events/descriptors
really reasonable to send an 8k DDP data block?).

If I can obtain rough consensus to proceed in this direction
(initial MPA-generic Hello/Hello ACK/ACK exchange used in all cases),
I can then consult with the ADs on the strength of "proof" that the
design of the MPA Hello/Hello ACK/ACK needs to provide.

At the moment, I don't understand the level of emotion surrounding 
the opposition to some sort of initial negotiation.  I was under
the impression that RDDP connections were likely to be long-lived
"elephants" rather than short-lived "mice" and that the networks
of primary interest were low-latency (e.g., data center).  If
that's the case, the latency of the extra round trip and overhead
of the extra bytes transferred are going to vanish into the noise
(of the three messages, only MPA Hello can't carry data) - what
have I missed?

As indicated above, any discussion of items (1) - (3) should be
sent to me directly off the list.  Discussion of MPA-generic
negotiation is welcome, but objections to it should suggest
alternate means of providing the "proof" and providing
receivers with information about sender alignment behavior.

I really am trying to move this forward, and I believe sender
alignment can be part of the solution, but we need to play the
hand we've been dealt, rather than the one we'd like to have.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             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: "Somesh Gupta" <[email-masked]>
Date: Wed, 19 Feb 2003 10:58:26 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, February 19, 2003 9:49 AM
> To: [email-masked]
> Subject: [rddp] Reality Check: Avoiding confusion on MPA TCP use
> Importance: High
> 
> 

  There was a previous discussion of a protocol design objective
  here that it not prevent optimization of (i.e. allow implementations
  that optimize for)

  a. unmodified TCP senders or
  b. MPA aware TCP senders