Subject: RE: changes to TCP? (was [rddp] RDDP Atlanta agenda)

From: "Uri Elzur" <[email-masked]>
Date: Mon, 28 Oct 2002 08:46:51 -0800

I agree with Caitlin that there is no change, proposed by MPA, to TCP sender
behavior. It can be layered on top of TCP like any other ULP. TCP should
provide service to App emitting PDUs at any length and in any case this is
not visible from the wire.

Cut through is problematic, as it is a clear violation of layering. A
decision is taken before TCP XSUM is verified and therefore there is way to
validate the TCP header yet. Note also that the "data" may be copied to
memory before ALL checks of L2/L3 and L4 are done (can get a L2 CRC error,
IP length error or TCP XSUM error, etc). Moreover, in the case of a middle
box present, there is no mechanism to verify the IFT header is indeed a
header as the CRC check is statistical in nature. The IFT proposed
mechanism, can make an erroneous decision as to what is header and what is
data based on this statistical probability.

Therefore, it seems perfectly ok to me to let ONE Work Group discuss it. I
have not seen the difference that makes MPA not meet the criteria set in the
RDDP charter. Moreover, no draft is perfect when it first gets to the WG,
and the WG can morph it to get to where it needs to be. More protocols may
have interest in such a service and therefore MPA deserves a broader
discussion. On the flip side, there is no reason why it can't meet the
limited scope of RDDP

Uri

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Sunday, October 27, 2002 8:11 AM
To: [email-masked]; [email-masked]
Subject: RE: changes to TCP? (was [rddp] RDDP Atlanta agenda)

On 10/27/02, [email-masked] wrote:

>> I'm confused whether Framing protocols are discussed by
>> RDDP or TSVWG? Pls advise.
>
>The answer is "both" because it depends on what is meant
>by "Framing".  MPA and IFT should both be on the TSVWG
>agenda and TSVWG should meet before RDDP.  IFT will also
>be on the RDDP agenda as it appears to be a good start on
>the following RDDP work item:
>
> 4) A mapping of the direct data placement protocol onto
> TCP, for informational, because TCP's service is a less
> good match to RDDP, including an applicability statement
> of the issues regarding the service available from the
> mapping. 
>
>MPA cannot be taken up in RDDP because it makes changes to
>TCP, specifically TCP sender behavior.
>

How does MPA (or IFT for that matter) change TCP? Nothing
that either sends cannot be accomplished with existing TCP
stacks. (I wouldn't implement that way, but you *could*).

I think a more valid distinction between the roles of RDDP
and TSVWG is that RDDP is only interested in solving this
problem for one protocol, whil e TSVWG is presumably looking
for a general solution.

The RDDP-specific solution might have problem-specific
features, such as enabling out-of-order processing and
providing greater error checking than TCP alone does.

In that sense MPA has either one or two features that are
probably not of wider TSVWG interest (out-of-order and CRC32
protection). IFT has split CRC32 protection. While not
explicitly for DDP, it has hard to imagine a use for
splitting header/payload CRC protection in a wire protocol
other than enablilng cut-through direct placement of the
payload.

Despite the fact that both of these proposals solve problems
that might not be viewed as universal to all protocols, they
are both still very simple. It might make sense to deploy
them for more applications that just DDP.

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