Subject: RE: [rddp] Alignment Consensus attempt

From: "Culley, Paul" <[email-masked]>
Date: Thu, 23 Jan 2003 10:15:34 -0600

I agree with your consensus calls:
1) RDDP Must work over unmodified TCP stacks
2) The WG Must Not set Performance requirements (for any operating mode)
but SHOULD allow a variety of performance points.

For what it is worth, the authors expect to shortly deliver an updated
MPA draft that will allow packing and explain in greater detail how MPA
can be used on unmodified TCP.

Paul R. Culley
HP Senior Fellow
281-514-5543

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 22, 2003 4:29 PM
To: [email-masked]
Subject: [rddp] Alignment Consensus attempt

With my WG chair hat (and Kevlar[tm] suit) on, here's
an attempt to call consensus on the alignment issue.

My original post on January 2nd phrased the primary issue as:

  So, I believe the primary issue before the WG is whether to accept:
	- The RDDP protocols must allow implementations over
		unmodified TCP/IP stacks.
  as a requirement.

Based on discussion since then, I believe the rough consensus of the
RDDP WG is to accept this as a requirement.

Restating the implications from that original message, (I've rephrased
the second bullet to discuss RDDP [DDP/RDMA] operations rather than
placement), some important things that this implies are:
	- Unmodified means 100% unmodified, not even "minor" changes.
	- An RDDP sender using an unmodified TCP stack can send RDDP
		payloads that result in the correct execution of RDDP
		operations by an RDDP receiver even if the sends are
		not aligned.
	- There don't appear to be any receiver implications, as
		nothing has been proposed that would prevent a receiver
		from having TCP buffer as usual and then run RDDP
		functionality on the resulting in-order TCP bytestream.
	- The practical meaning of "allow" is that a sender
		implementation is possible without violating any
		MUST, MUST NOT, SHOULD, or SHOULD NOT requirement.

OTOH, conditional requirements for stack modification are not ruled out.
For example: "If a sender notifies a receiver that the sender is
operating in alignment-modified-mode by <means TBD>, then the sender
SHOULD ..., MUST ..., etc."  If this sort of approach is followed, the
second bullet still applies at the receiver, e.g., an unmodified sender
would not use <means TBD>, but would still be able to send RDDP payloads
that invoke RDDP operations at the receiver.

Beyond this, I also believe there is rough consensus for the RDDP WG to
*not* set requirements (MUST/SHOULD) for receiver performance when the
sender does not align traffic.  It is apparent to me from list
discussion that different implementers favor rather different
implementation approaches that have different performance consequences
for this scenario.

Repeating Jim Williams's spectrum of possibilities:

>     1.  Only functional correctness matters, performance is not an 
> issue.
> 
>     2.  Performance must be as good as conventional (non-RDMA) TCP.
>
>     3.  Performance must be significantly better than conventional
>         (non-RDMA) TCP otherwise RDMA should not be used in this case.

If this second consensus holds, the WG chair intends to hold the WG to
an approach of avoiding design approaches and decisions that have the
effect of ruling out any of the three alternative views listed above.
This should have the effect of broadening the applicability of the WG's
protocols.

Nonetheless, I think the WG's results should capture some of the list
discussion about scenarios that involve unmodified stacks, including
when loss of alignment in such stacks is unavoidable despite reasonable
efforts by an application/ULP (not including stop-and-wait), as it'll
provide some useful insight to implementers.

Anyone who disagrees with either of these consensus calls should explain
why on the list.

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
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Williams, Jim" <[email-masked]>
Date: Fri, 24 Jan 2003 11:21:43 -0500

David Black wrote:
> Based on discussion since then, I believe the rough consensus
> of the RDDP WG is to accept this as a requirement.
> 
> [...]
> 
> Beyond this, I also believe there is rough consensus for the RDDP WG
> to *not* set requirements (MUST/SHOULD) for receiver performance
> when the sender does not align traffic.

I am a little bothered by the implication here.

If vendor A has a product which performs super when receiving
aligned PDUs, but performs worse than non-RDDP when receiving
unaligned PDUs, we say that this is a valid implementation
choice.

Vendor B has a product which performs super when
receiving aligned PDUs, but when receiving unaligned PDUs
it simply refuses to negotiate use of RDDP and defaults
back to non-RDDP version of ULP.  Therefore, vendor B
actually performs better than vendor A in the unaligned
case.  But we say that vendor B's implementation is 
non-compliant.

So, I would suggest that it is reasonable that an RDDP
endpoint ought to be allowed to negotiate not to use
RDDP with a sender of unaligned PDUs.  We could, however,
push this back to the ULP, and say that the receiver
should advise (as part of the ULP negotiation) that
is doesn't want to do RDDP with an unaligned sender,
and the sender should have sense enough in that
case to just not use RDDP (unless there is some
overriding consideration).

So, I don't necessarily disagree with the above 
consensus attempt, but would hope that this case
is handled in a sensible manner.  If a
particular connection is better off not being
in RDDP mode, then the negotiation process should
leave it in non-RDDP mode, and this should happen
naturally and automatically without requiring
undue ULP or operator intervention.

---

From: [email-masked]
Date: Fri, 24 Jan 2003 20:16:25 -0500

Jim,

> case.  But we say that vendor B's implementation is 

This has walked across the line from "MUST implement" to
"MUST use" requirements very quickly.  The "allow [sender]
implementation over unmodified TCP/IP stacks" requirement
is a "MUST implement".  If Vendor B has not implemented
unaligned PDU reception support, and cannot receive from
such stacks under any circumstances, then it's not compliant.

What vendor B is or is not required to negotiate under
what circumstances is a different matter.  Unfortunately,
if vendor B refuses to negotiate unaligned reception in
all circumstances, the fact that it has implemented
unaligned reception cannot be demonstrated, and that
probably puts vendor B out of compliance with a
"MUST implement" requirement.  As long as vendor B
can negotiate and perform unaligned reception, there's
probably a good degree of administrator flexibility
available in what to configure vendor B's device to
do based on performance, resource usage, etc.

> overriding consideration).

While this is probably reasonable, I think there's another
important case to consider - the ULP has only implemented
the RDDP support and can't cope with RDDP being turned
off.  Vendor B may deal with this case by passing the
unaligned PDUs through to software that takes care of the
RDDP [esp. RDMA] functionality so the ULP still works.
One of the benefits often claimed for RDMA is that it
simplifies protocol development, but that won't come to
pass if every RDMA-using protocol has to be implemented
in both an RDMA and a non-RDMA version.

> undue ULP or operator intervention.

As noted above, the IETF distinguishes between
"implementation" and "use" requirements.  Anything
involving "negotiation" tends to fall into the
"use" category, which is not what the consensus
attempt was about.

Thanks,
--David