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

From: [email-masked]
Date: Fri, 21 Feb 2003 10:52:28 -0500

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

I think the exchange of adaption indications to confirm the
ULP understanding is still needed.  I don't see much of a
gain in allowing the adaption indications to be exchanged
independently (i.e., responder does not wait for the initial
indication to arrive before sending its indication) as with
a little care, the initial adaption indication should come
right behind the ACK that completes TCP's 3-way handshake.
Having the second adaption indication respond to the first
one (rather than be independent of it) allows the receiver
to tell the sender *exactly* what's wrong when things don't
work, which can help ensure that a retry will work.

OTOH, I don't see a problem with both sides sending traffic
immediately behind their adaption indications.  An issue
that arises is that the initial sender has to guess or
have other knowledge as to whether to use markers and/or
what marker interval to use.  If the guess is wrong,
the connection probably has to be abandoned, but the
returned adaption indication should indicate what will
work on retry.  As long as there's language about how
the receiver is supposed to deal with this "sender
guessed wrong" case, I don't see a problem.

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: Fri, 21 Feb 2003 11:00:55 -0600

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

>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