Subject: Re: [rddp] Adaption Indication for TCP

From: "Talpey, Thomas" <[email-masked]>
Date: Tue, 10 Dec 2002 12:36:27 -0500

You might want to add one or more "registry" scenarios, lying
between options A and B.

A1) Some form of service mapper performs lookups of registered
ports enabled for DDP, a la RFC2608 (SLP) / Sun RPC portmap.

A2) The service mapper dynamically invokes a DDP-enabled
service and replies with a connection handle, a la distributed
RPC frameworks.

Both of these models avoid the "legacy listener" problem.

As for negotiation of DDP after connection (your option C in
particular), it's clear that a standard exchange can be proposed,
which would be over "pure TCP", to be used prior to enabling
DDP. I predict an Internet Draft :-).

Finally, option A, I agree, is interesting and tractable (automatic
RDMA mode with fixed parameters). I believe it will be useful for
certain RDMA apps. As you point out though, the more general
exchange is option C, and done each in a one-way, one-time
message, practically the same overhead.

Tom.
	
At 02:07 PM 12/9/2002, Caitlin Bestler wrote:
>On 12/9/02, Williams, Jim wrote:
>
>>
>>The current thinking is to allow each ULP to negotiate use
>>of DDP and start using DDP at an agreed upon point within
>>an already established connection.  The advantage of this
>>is that it allows pre-existing ULPs to negotiate an
>>upgrade to DDP mode without causing any backward
>>incompatability. If either end doesn't understand DDP,
>>then the negotiation defaults to non-DDP mode with no ill
>>effects.  The down side of this is that the negotiation
>>must necessarily by ULP specific.  Therefore each ULP must
>>solve this problem for itself.
>>
>
>There are a few distinct scenarios that need to be
>supported. The current approach supports all of them, and
>one additional scenario which is nice, but in my opinion not
>essential.
>
>
>A - Pre-designated port / Daemon level:
>
>The ULPs have pre-designated the DDP/RDMAP configuration for
>certain ports. Incoming connections for those ports are
>routed automatically to a DDP/RDMAP specific connection
>accepting daemon (whether hardware and/or software).
>
>Immediate pre-posting of receive buffers may be slightly
>tricky here, but there are solutions.
>
>
>
>B - LLP Establishment / Instant DDP/RDMAP configuration:
>
>The LLP Connection is established using existing LLP means.
>This includes any automatic logging of connections,
>validation of remote addresses, etc. (Some hosts may require
>these steps, and hence not allow a NIC to accept a
>connection).
>
>The ULP having been delivered the LLP connection (by
>whatever existing means, including INETD and TCPSERVER)
>immediately places it in DDP/RDMAP mode. This is "instant"
>but the "reflex" response is being exercised by the ULP
>itself, rather than by a transport/DDP level daemon.
>
>
>
>
>C - LLP Establishment / Private Data Exchange before Config:
>
>The LLP is established as above, but each ULP sends a single
>message (MSS size or smaller). Each side uses the message
>received to determine the DDP/RDMAP configuration.
>
>This is equivalent to InfiniBand's exchange of Private Data.
>
>
>
>
>D - LLP Establishment / Extended Login before Config:
>
>The LLP is established as in scenario B, followed by an
>indefinite period of LLP negotiation before entering
>DDP/RDMAP mode.
>
>This is the scenario that I do not feel is essential, but
>the current draft encompasses it as well. It places some
>demands on DDP-only RNICs in terms of their ability to
>retroactively interpret material as DDP messages when
>notified asynchronously of DDP mode entry.
>
>But this is solveable in pure software, assuming the
>existing IP stack can be modified to "give back" either the
>Ethernet Frames it was fed or the raw TCP stream.
>(Interestingly the local native OS IP stack could end up
>becoming one of those dreaded alignment destroying
>middleboxes).
>
>
>
>
>I see very high value in each of scenarios A, B and C.
>Unlike SCTP, an adaptation indication in TCP cannot be
>obtained "for free". It would be an additional message
>sent after the three-way handshake had completed.
>
>I know that theoretically data can be sent with the SYN,
>but I do not believe you can reliably get that data through
>two arbitrary IP stacks all the way to the other ULP.
>
>Given that limiation, I do not think we should add an
>additional round-trip to the setup period when it is not
>required by the ULP.
>
>
>
>Caitlin Bestler
>http://asomi.com/CaitlinBestler/
>_______________________________________________
>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: Caitlin Bestler <[email-masked]>
Date: Tue, 10 Dec 2002 12:19:24 -0600

On 12/10/02, Talpey, Thomas wrote:

>You might want to add one or more "registry" scenarios,
>lying between options A and B.
>
>A1) Some form of service mapper performs lookups of
>registered ports enabled for DDP, a la RFC2608 (SLP) / Sun
>RPC portmap.
>
>service and replies with a connection handle, a la
>distributed RPC frameworks.
>

I would view these as variants on A or B. The information
sharing is still taking place "before" the connection. Use
of a registry or SLP, when available, has advantages over
compile or configuration time sharing. So these options
expand the range of scenarios where the modes are all fully
known before the connection is requested.

Caitlin Bestler