Subject: [rddp] IFT-01 - Two Phase Negotiation.

From: Caitlin Bestler <[email-masked]>
Date: Thu, 20 Feb 2003 22:20:35 -0600

While I am opposed to an MPA/IFT confirmation message in
general, I am doubly opposed to requiring it to be a
two-phase negotiation.

Would it be permissable for ULPs that believed that they
had pre-negotiated all details to simply confirm their
understanding by having them *both* skip directly to
the second phase?

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

---

From: "Talpey, Thomas" <[email-masked]>
Date: Fri, 21 Feb 2003 14:54:07 -0500

At 12:18 PM 2/21/2003, [email-masked] wrote:
>> That said, a negotiation is worse. It is not only an
>> additional TCP segment, it is an extra wait state. As
>> drafted the responding MPA must *wait* for the phase 0
>> MPA-config message to arrive. That is a round-trip delay.
>
>Yes, there's a "wait," but it's not a round-trip delay
>if the MPA-config message is back-to-back with the TCP
>ACK that completes the 3-way TCP handshake.  Remember
>that the passive side of the TCP connection setup has
>to wait for that TCP ACK before it can send.

I don't see why the passive TCP must await the ACK of its
SYN. It's perfectly acceptable for TCPs to include data with
their initial handshake, on both sides.

But more to the point, what of the upper layer protocols,
which must also exchange messages? If framing handshake
must complete, then the initial upper layer handshake is
delayed for a full roundtrip. Imposing additional handshakes
in the lower layers will certainly impact availability.

Tom.

>
>> If each side can merely announce its configuration, based on
>> whatever pre-MPA negotiations that may have taken place (see
>> my reply to Tom Talpey), then no additional states have been
>> created. The unjustified damage is limited to the wasted TCP
>> segment.
>
>That's an acceptable approach, but the difference in "damage"
>is small between whether the passive side blindly sends
>the configuration announcement vs. looks at the MPA-config
>message that is usually immediately behind the ACK that it
>has to wait for anyway.  There may be a gain in error-case
>behavior (if the response depends on the input, the response
>can say "do this" (or "go away"), vs. relying on both sides
>to draw the same conclusion about what will work from the
>exchanged configurations.  There are delay and computation
>costs, but a round-trip delay is definitely *not* involved.
>
>Either design approach is acceptable. 
>
>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
>----------------------------------------------------
>
>> -----Original Message-----
>> From: Caitlin Bestler [mailto:[email-masked]]
>> Sent: Friday, February 21, 2003 12:01 PM
>> To: [email-masked]; [email-masked]
>> Subject: RE: [rddp] IFT-01 - Two Phase Negotiation.
>> 
>> 
>> On 2/21/03, [email-masked] wrote:
>> 
>> >As I understand "phases" in the IFT draft, each "phase"
>> >is one-way:
>> >
>> >PH          Adoption is two phase negotiation, with phases
>> >            numbered 0, and 1.  Phase 0 is sent from node A
>> >            to node B.  On receipt of phase 0, node B sends
>> phase
>> >            1 back to node A.  This bit indicates phase 0
>> or 1.
>> >
>> >So, the request to "skip directly to the second phase" is
>> >a request to send only the B to A adaption indication, and
>> >not the A to B one.  That seems questionable - is this
>> >about optimizing the size of the first TCP segment in only
>> >one of the two directions?
>> >
>> 
>> Let me repeat my earlier caveat: I don't believe MPA-mode
>> confirmation messages are required at all. I believe an
>> MPA-mode confirmation message will waste a TCP segment,
>> and it solves no real problem. Even a single TCP segment
>> wasted is unacceptable if it does not provide anything of
>> real value. Further, on long-haul connections one TCP
>> segment while the connection is still in its slow start
>> is not insignifigant.
>> 
>> That said, a negotiation is worse. It is not only an
>> additional TCP segment, it is an extra wait state. As
>> drafted the responding MPA must *wait* for the phase 0
>> MPA-config message to arrive. That is a round-trip delay.
>> It is an extra state. The MPA engine must be capable of
>> *generating* messages, not merely wrapping messages given to
>> it. The result is far uglier than just the addition of an
>> MPA-Mode confirmation message.
>> 
>> If each side can merely announce its configuration, based on
>> whatever pre-MPA negotiations that may have taken place (see
>> my reply to Tom Talpey), then no additional states have been
>> created. The unjustified damage is limited to the wasted TCP
>> segment.
>> 
>> IHow does it truly made sense for MPA/IFT layer
>> characteristics to be dynamically determined on a per
>> connection basis in a manner transparent to the ULP?
>> 
>> It seems to me that the existence of a large number of
>> protocol options is not an argument for a mode-initializing
>> packet, rather it is an argument to eliminate those options
>> (or to make them mandatory).
>> 
>> Most of the options discussed, if needed at all, would
>> properly be decided by a ULP profile. I have seen no
>> justification for establishing any of them on a
>> per-connection basis.
>> 
>> 
>> Caitlin Bestler

---

From: [email-masked]
Date: Fri, 21 Feb 2003 15:24:46 -0500

> their initial handshake, on both sides.

I stand corrected, but this doesn't help as much as it might,
as RFC 793 says:

  Several examples of connection initiation follow.  Although these
  examples do not show connection synchronization using data-carrying
  segments, this is perfectly legitimate, so long as the receiving TCP
  doesn't deliver the data to the user until it is clear the data is
  valid (i.e., the data must be buffered at the receiver until the
  connection reaches the ESTABLISHED state).

So, while the adaption indications could be sent in the TCP
handshake segments, one can't actually do anything with them
until the TCP handshake is complete.

> in the lower layers will certainly impact availability.

It doesn't have to complete before data is sent - as I've
said earlier, I have no problem with sending framed data
immediately after the adaption indications.  The only minor
drawback is that if arrival of the second message at the
sender tells the sender that the data it sent previously
wasn't formatted in a fashion the receiver could deal with,
the connection is probably unrecoverable at that point
and likely needs to be terminated.

Thanks,
--David