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

From: [email-masked]
Date: Tue, 18 Feb 2003 19:42:22 -0500

Roy,

> At the risk of missing the point yet again, I have looked at the MPA draft
> and could not find a requirement that TCP must change to support MPA.  It
> clearly differentiates performance benefits that can be derived with a
"MPA
> aware" TCP implementation but allows interoperable operation with an
> unmodified TCP stack.  As Caitlin and others have pointed out above, it is
> not possible for a receiver to detect whether I am sending from a MPA
aware
> implementation or not.

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.

Please have the respect to avoid spend list bandwidth splitting
hairs on whether words like "SHOULD" were/are/could be upper or
lower case (either in MPA or RFC 1122), or on discussion of
circumstances in which it's ok to disregard a "SHOULD" or a
"should".  It's very clear to all concerned that MPA intends
to change TCP sender segmentation behavior to enable receiver
optimizations.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 18 Feb 2003 19:23:30 -0600

On 2/18/03, [email-masked] wrote:

>Roy,
>
>> At the risk of missing the point yet again, I have
>> looked at the MPA draft and could not find a requirement
>> that TCP must change to support MPA.  It clearly
>> differentiates performance benefits that can be derived
>> with a "MPA aware" TCP implementation but allows
>> interoperable operation with an unmodified TCP stack. 
>> As Caitlin and others have pointed out above, it is not
>> possible for a receiver to detect whether I am sending
>> from a MPA aware implementation or not.
>
> 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.

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