Subject: RE: [rddp] MPA TCP analysis draft; avoiding confusion on use

From: David Borman <[email-masked]>
Date: Wed, 19 Feb 2003 08:24:28 -0600 (CST)

> Date: Tue, 18 Feb 2003 19:23:30 -0600
> From: Caitlin Bestler <[email-masked]>
> Subject: RE: [rddp] MPA TCP analysis draft; avoiding confusion on use
>
> On 2/18/03, [email-masked] wrote:
...
> >From draft-culley-iwarp-mpa-01.txt:
> >
> >5.1.1  TCP Transmit side
> >
> > To provide optimum performance, an MPA-aware transmit
> > side TCP implementation SHOULD be enabled to:
> >
> > *   With an EMSS large enough to contain the FPDU(s),
> > segment the outgoing TCP stream such that the first octet
> > of every TCP Segment begins with an FPDU.  
> >
> >That "SHOULD" is a change to TCP.  Among other things, it
> >is at odds with the Bulk Transfer discussion in Section
> >4.2.3.11 of RFC 1122, which I have pointed out before.
> >
>
> I would submit that the more relevant section of RFC 1122
> is 4.2.4.3:
>
> >4.2.4.3  Flush Call
> > 
> > Some TCP implementations have included a FLUSH call,
> > which will empty the TCP send queue of any data for which
> > the user has issued SEND calls but which is still to the
> > right of the current send window.  That is, it flushes as
> > much queued send data as possible without losing sequence
> > number synchronization.  This is useful for implementing
> > the "abort output" function of Telnet. 
>
>
> MPA 5.1.1's SHOULD can be implemented using a 4.2.4.3
> compliant flush call. Therefore it does contradict RFC 1122.

Perhaps you meant "does not contradict"?  But no matter, because
the FLUSH call *throws away* any unsent data (the data to the right
of the send window).  I don't think that is what you want.

You can implement sender alignment over an unmodified TCP stack.
Unfortunately, the most portable way to do that is to have application
level per-segment acks, and only allow one outstanding segment at a time.
Thus, it'd probably be a performance hit.  (Another implementation could
be done if you could query the TCP stack to see how much data is waiting
to be ACKed, and just wait for that to go to zero before writing the next
segment.)

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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 19 Feb 2003 10:04:50 -0600

On 2/19/03, David Borman wrote:

>Perhaps you meant "does not contradict"?  But no matter,
>because the FLUSH call *throws away* any unsent data (the
>data to the right of the send window).  I don't think that
>is what you want.
>
>You can implement sender alignment over an unmodified TCP
>stack. Unfortunately, the most portable way to do that is
>to have application level per-segment acks, and only allow
>one outstanding segment at a time. Thus, it'd probably be
>a performance hit.  (Another implementation could be done
>if you could query the TCP stack to see how much data is
>waiting to be ACKed, and just wait for that to go to zero
>before writing the next segment.)
>

Oops, up too late yesterday. 

The section I should have cited was

>4.2.2.2  Use of Push: RFC-793 Section 2.8
> When an application issues a series of SEND calls without
> setting the PUSH flag, the TCP MAY aggregate the data
> internally without sending it.  Similarly, when a series
> of segments is received without the PSH bit, a TCP MAY
> queue the data internally without passing it to the
> receiving application. 
>
> The PSH bit is not a record marker and is independent of
> segment boundaries.  The transmitter SHOULD collapse
> successive PSH bits when it packetizes data, to send the
> largest possible segment.
> 
> A TCP MAY implement PUSH flags on SEND calls.  If PUSH
> flags are not implemented, then the sending TCP: (1) must
> not buffer data indefinitely, and (2) MUST set the PSH
> bit in the last buffered segment (i.e., when there is no
> more queued data to be sent).
> 
> The discussion in RFC-793 on pages 48, 50, and 74
> erroneously implies that a received PSH flag must be
> passed to the application layer.  Passing a received PSH
> flag to the application layer is now OPTIONAL .
> 
> An application program is logically required to set the
> PUSH flag in a SEND call whenever it needs to force
> delivery of the data to avoid a communication deadlock. 
> However, a TCP SHOULD send a maximum-sized segment
> whenever possible, to improve performance (see Section
> 4.2.3.4 ).

Note that it does not send TCP MUST send a maximum-sized
segment whenever possible to improve performance.

MPA/TCP overrides that recomendation *for the purpose of
improving performance*. In my mind this is precisely the
type of justification that is required to justify overriding
a SHOULD.

An argument could be made that the use of this facility is
not what was intended when the RFC was drafted. But by that
criteria a vast majority of the Web is RFC non-compliant.

The criteria has always been interoperability. MPA/TCP does
not do anything to a TCP stream that any ULP has not been
free to do all along. Therefore it does not change TCP.

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