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

From: [email-masked]
Date: Fri, 21 Feb 2003 12:18:35 -0500

> 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.

> 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:
> 
> >> 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?
> >
> >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
> http://asomi.com/CaitlinBestler/
> 
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 21 Feb 2003 13:10:35 -0600

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

>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.
>

I would agree that the extra delay can be avoided if the
passive side is allowed to send its confirmation message on
a speculative basis. If the other side's message does not
confirm those assumptions the connection MUST be aborted.

Caitlin Bestler