Subject: Re: [Tsvwg] FW: I-D ACTION:draft-culley-iwarp-mpa-00.txt

From: Joe Touch <[email-masked]>
Date: Thu, 19 Sep 2002 13:37:49 -0700

Teisberg, Robert wrote:
>>I have the same concerns the last time I saw this sort of thing:
>>
>>- TCP semantics change:
>>	consider a sequence of FPDUs (or in TCP, segments) sent:
>>	1,2,3,4
>>	and let '2' be dropped by the channel.
>>
>>	now close the connection.
>>
>>	what does the receiver pass to the application?
>>	- in TCP, only 1
>>
>>	- in this (not-TCP), 1,3,4
> 
> 
> Your characterization of MPA+TCP as "not-TCP" is inconsistent with the
> authors' explicit intention as stated in the abstract and in the charter
> for the rddp WG.  If you think MPA changes TCP semantics, please point out
> where it fails to address its own goals.

I did - TCP delivers only the data up to and including that which has 
been received in order. That is not TCP semantics.

Addressing its own, changed semantics isn't sufficient rationale.

> The purpose of MPA is twofold: to define FPDU boundaries, and to enable
> zero-copy optimizations.  It appears that it's the latter that is
> provoking concern.

Both, actually.

> Correct behavior in the error case you describe would be for the application
> to see only 1, with the understanding that the contents of the buffers for
> 2,3,4 would be undefined.  An implementation that passed all of 1,3,4 to the
> application would not comply with the spirit of the draft, and would
> comply at best maliciously with the letter.
> 
> (Let me point out that the draft is careful to specify "ULP" rather than
> "application" when referring to the layer above MPA.

TCP cannot let the data out of its control. Unless MPA is part of TCP, 
this would violate TCP semantics.

>  It's true that the
> MPA draft doesn't make it clear that the application, or ultimate consumer
> of network services, is meant to reside several layers above MPA.  This is
> because it seemed inappropriate for this draft to impose specific MUSTs on
> the ULP.  This decision does admittedly risk opening the door to malicious
> compliance.  Would it help to add some explicit ULP requirements?)

As per above, TCP cannot let the data out of its control and be 
semantically equivalent.

> [cut discussion of implication of changing TCP semantics, since MPA is
> explicitly intended to respect and preserve TCP semantics, as the abstract
> states]

Since MPA is explicitly intended to preserve TCP semantics, it's exactly 
  relevent to discuss where it fails to do so.

>>- not-TCP specifies PDU sizes that cause problems
>>	in particular, TCP uses the interface MTU or path MTU
>>	as the unit of both transmission and congestion control.
>>
>>	this uses the application PDU as the unit in both cases.
> 
> No, the ULPDU is adapted to the path MTU, not the other way around.  A ULP
> that consistently uses too large a ULPDU will suffer from its own
> maladaptive behavior, but it won't affect other participants or the network
> as a whole.  TCP's behavior with respect to MTU size is unchanged.
> 
> [cut discussion of implications of use of inappropriate MTU sizes, since
> it's not relevant]

 From the draft:

     MPA MUST encapsulate the ULPDU such that there is exactly one ULPDU
     contained in one FPDU.

     An MPA-aware TCP sender SHOULD segment the outbound TCP stream such
     that there is exactly one FPDU per TCP segment.

     An MPA-aware TCP sender SHOULD, with an EMSS large enough to contain
     the FPDU, segment the outgoing TCP stream such that the first octet
     of every FPDU is aligned with the beginning of a TCP segment, and is
     entirely contained in the TCP segment.

The draft needs to address the issue of using MTUs that are smaller than 
FPDUs in particular, since this is a likely case.

Again, from the draft:

    A possible, but less desirable, alternative is to use IP
    fragmentation on accepted FPDUs to deal with MTU reductions or
    extremely small EMSS.

There are significant issues with this alternative, which obviate the 
utility of the protocol as a whole. The issue of FPDUs larger than MSSs 
must be addressed.

----

Finally, and as importantly, address these issues with content, not 
directives. This is an open list, and you are not the moderator.

Joe

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Sep 2002 14:26:15 -0700

>> explicitly intended to respect and preserve TCP semantics, as the 
...

> directives. This is an open list, and you are not the moderator.

To all,

Looks like I parsed "cut discussion" as "please stop the discussion...", 
rather than (as per off-line exchange) "I have edited your reply".

My apologies to Robert.

Joe

---

From: "Teisberg, Robert" <[email-masked]>
Date: Thu, 19 Sep 2002 15:22:57 -0500

"application" when referring to the layer above MPA.  It's true that the