Subject: [rddp] Problems with MPA Hello

From: Caitlin Bestler <[email-masked]>
Date: Thu, 20 Feb 2003 12:41:03 -0600

The introduction of an MPA Hello offers no actual solutions
to any real problems. It merely complicates the protocols,
and lengthens the minimum time for connection establishment.

Point 1: MPA Mode can only be initiated by the ULP.

An MPA Hello cannot be used to initialize the MPA state.
The most it can do is confirm the the peer ULP's intent.

Rationale: Under existing RFCs, an incoming TCP stream
may consist of any sequence of bytes. There are no
restrictions. Period. If MPA cannot "alter" TCP by
specifying segmentation points that would have been legal
anyway, then it *certainly* cannot place restrictions on
what can be a TCP stream's payload.

A combined receicer that support Non-MPA and MPA over TCP
MUST NOT enter MPA mode for any TCP connection prior to
the point in the stream authorized by the local ULP.

Point 2: There is no such thing as an aligned TCP stream.
There are only TCP streams that are currently alligned.

The only information the the sending MPA layer has that
the sending ULP lacks is whether the sending MPA will
align the TCP segments it generates with FPDUs.

It CANNOT know that there will be no middlebox that will
resegment the TCP stream for the simple reason that it
CANNOT know what set of middleboxes will deliver the
IP datagram.

Just as a reciever MUST be prepared to handle PMTU changes,
it MUST be prepared to handle "unexpected" drops in
alignment.

More fundamentally, I would submit that for MPA to claim
forward knowledge of the behavior of an IP network is a
violation of the most basic IP principles. If such network
knowledge were available and legitimate to use, RDDP would
benefit far more by simply ensuring that ALL DDP Segments
were sized to conform with the *future* PMTU.

Point 3: Whether or not the sender MPA aligns is at best
a hint to the receiver.

Niether the set of packets that will be accepted, nor the
ULP required response to them, is affected by alignment.

A server MUST NOT drop a connection because it unexpectedly
changes PMTU or drops alignment.

Point 4: There is no information for the sender MPA to add
to an MPA Hello.

The sending MPA layer has no data that can be placed in an
MPA Hello that was not already available to both ULPs.

Point 5: The ULPs are already responsible for ULP matching.

As with every other IP protocol ever created, it is a ULP
responsibility to know that its peer is complying wth the
same protocol, and to take reasonable protections from both
accidental connections and malicious attacks.

The use of MPA/TCP is already implicit in the identity of
the ULP itself. There are no ULP protocols that work over
*either* TCP or RDDP.

Point 6: A confirming MPA Hello delays processing of
other DDP segments received out-of-order.

If the purpose of an MPA Hello is to confirm the operative
MPA mode *before* any MPA processing then all segments
received out of order must be held for deferred processing.

Point 7: The MPA Hello message wastes an entire TCP segment
or violates DDP / LLP layering.

An MPA Hello message reduces the space available in the
first LLP message. The DDP layer will be relying upon the
normal PMTU when it creates DDP Segments. These will not
fit in the same segment 

IF DDP layer reduces the size of the first segment to
accomodate the MPA Hello then it is violating layering, by
modifying its behavior based upon knowledge of the LLP.
Unless we want to modify the LLP/DDP interface to report
a suggested DDP segment size on a per request basis there
is no way to accomodate this exception in an LLP neutral
fashion.

For a *new* connection, especially a long haul one, wasting
a single TCP segment is signifigant.

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