Subject: RE: [rddp] Reality Check: Avoiding confusion on MPA TCP use

From: "Barron, Dwight" <[email-masked]>
Date: Wed, 19 Feb 2003 18:14:19 -0600

David, I am only copying specific excerpts from your message in hopes that ensuing discussions on this thread stay focused on this thread topic, "Avoiding confusion on MPA TCP use." 

I believe the objections to having an MPA-generic <MPA Hello> exchange are a) where/how to unambiguously insert it into a TCP bytestream and b) how does that significantly improve the error quadrants in Fig 5 of Draft-Elzur? This is based on the assumption that a ULP that wants to use DDP/MPA will explicitly know of the opportunity and treat the transition as a command operation rather than a data transfer operation. Only the ULP can safely deduce when and how it is appropriate to insert such a command operation in the TCP bytestream. Note that the position of this command in the bytestream is dictated by the ULP's own protocol design (e.g. iSCSI, SMB, DNS) and is independent of any form of transmitter alignment, PUSH flags and other whatnot. Requiring the <MPA Hello> sequence as the first bytes transmitted on a connection does not significantly improve the error detection characteristics in the upper right quadrant of Fig 5. Given your example of the difficulty knowing all !
the private protocols running on TCP, I don't believe we can design a provably correct <MPA Hello> sequence that would never confuse any existing or future TCP application. What we can provably do is show that very little forward progress will be made before the an error is detected, due primarily to the lower left quadrant of Fig 5. I also believe that we can show that a ULP specific transition-to-MPA-command, when injected into the ULP-specific command portion of the TCP bytestream, is at no greater risk of being mis-interpreted than any other ULP-specific command and that this is an equal or lower risk of error than an MPA-generic hello sequence that is equally mis-configured. 

However, if this is an open book test and you have already given us the "correct" answer, we can craft a generic <MPA Hello> and turn in our test books. 

Regards,
Dwight
  
> Turning to a more positive topic, there is a path forward available
> in the Elzur MPA TCP analysis draft.  Section 8.1 says:
> 
>    The third model is by negotiation of MPA transition by the ULP
>    using octet stream messages to accomplish a ULP specific
>    <MPA Hello>, <MPA Hello ACK>, <MPA ACK> three way exchange.
> 
> If this exchange were made MPA-generic instead of ULP-specific and
> applied to all transitions to MPA, including those that occur
> immediately at the start of a connection, then Figure 5 in that
> draft contains much of the "proof" structure and content.
> 
> 
.... snip
> 
> If I can obtain rough consensus to proceed in this direction
> (initial MPA-generic Hello/Hello ACK/ACK exchange used in all cases),
> I can then consult with the ADs on the strength of "proof" that the
> design of the MPA Hello/Hello ACK/ACK needs to provide.
> 
> At the moment, I don't understand the level of emotion surrounding 
> the opposition to some sort of initial negotiation.  I was under
> the impression that RDDP connections were likely to be long-lived
> "elephants" rather than short-lived "mice" and that the networks
> of primary interest were low-latency (e.g., data center).  If
> that's the case, the latency of the extra round trip and overhead
> of the extra bytes transferred are going to vanish into the noise
> (of the three messages, only MPA Hello can't carry data) - what
> have I missed?
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: [email-masked]
Date: Wed, 19 Feb 2003 21:03:39 -0500

Dwight,

> I believe the objections to having an MPA-generic <MPA Hello> 
> exchange are a) where/how to unambiguously insert it into a 
> TCP bytestream and b) how does that significantly improve the 
> error quadrants in Fig 5 of Draft-Elzur?

My primary concern is with improving the upper right hand
error quadrant in Figure 4 of Draft-Elzur.  I suggested an
MPA-generic mechanism based on Figure 5 in the hope of using
the same mechanism in both cases, but that's not necessary.

> This is based on the 
> assumption that a ULP that wants to use DDP/MPA will 
> explicitly know of the opportunity and treat the transition 
> as a command operation rather than a data transfer operation. 
> Only the ULP can safely deduce when and how it is appropriate 
> to insert such a command operation in the TCP bytestream. 
> Note that the position of this command in the bytestream is 
> dictated by the ULP's own protocol design (e.g. iSCSI, SMB, 
> DNS) and is independent of any form of transmitter alignment, 
> PUSH flags and other whatnot.

The ULP could send the command in non-MPA mode and then wait
until some sort of ULP <ready for MPA transition> response is
received from the other side before instructing the RNIC to go
into MPA mode (send <MPA Hello>, etc.) on that connection.  OTOH,
my primary concern is with the upper right quadrant in Figure 4,
so for the Figure 5 case, I agree that:

> Requiring the <MPA Hello> 
> sequence as the first bytes transmitted on a connection does 
> not significantly improve the error detection characteristics 
> in the upper right quadrant of Fig 5.

except that the <MPA Hello> won't necessarily be the first
bytes transmitted on the connection in the Figure 5 case.
OTOH, if Figure 4 was intended in the above, I disagree.

So, while using the same mechanism independent of when
a connection goes into MPA mode has the virtue of consistency
and might simplify things, doing so is in the domain
of "nice to have", as opposed to an absolute requirement.
An alternative design approach is fine provided that the
rationale for the design selected is solid and well-documented,
and, in addition, there is adequate implementation guidance to
make it likely that a ULP implementer who is not part of this
community will get the synchronization aspects of the transition
to MPA right (these provisos apply no matter what design approach
is selected).

For example, sending a ULP "<switch to MPA now>" command and
immediately following it with an MPA-based transmission may
cause problems if the receiver has to retrieve the command before
it can switch into MPA mode on that connection, as by then,
the first MPA-based transmission may have passed through
without any MPA-based processing.  Section 8.1 of the MPA
draft falls short in the area of guidance to implementers.
In addition, it will be necessary to address the means of
ascertaining sender behavior so that the BufferAF level of
required buffering resources (Section 7 of Draft-Elzur) can
be achieved.

It appears that Draft-Elzur envisions passing of explicit ULP
<MPA Hello> and the like tokens, rather than allowing a ULP to
determine the MPA start point implicitly via other means.  If that
was intended as a requirement for all connections that transition
into MPA mode other than at initial establishment, it'll need
to go into the main MPA draft as a "MUST" requirement imposed
on ULP designers.

When the full description of the ULP-based mechanism including
both full ULP requirements (e.g., cf. immediately preceding
paragraph) and ULP implementation guidance/recommendations are
available, it will be possible to ascertain the level of assurance
it provides on getting the transition to MPA correct in the Figure
5 case.

> Given your example of 
> the difficulty knowing all the private protocols running on 
> TCP, I don't believe we can design a provably correct <MPA 
> Hello> sequence that would never confuse any existing or 
> future TCP application.

It seems that "provably correct" is being routinely over-interpreted
as requiring "absolute proof of correctness in all circumstances".
As I've said, not even security protocols can reach that level of
assurance, and I would hope that the level of assurance required
here will be less than that demanded of security protocols.  OTOH,
Section 8.2 of Draft-Elzur ("we spent some time looking for a
counterexample and didn't find one") is insufficient, and the
size of Section 8.2 by comparison to Figure 5 is indicative of
the relative ability of the two approaches to provide a concise
"proof".

> However, if this is an open book test and you have already 
> given us the "correct" answer, we can craft a generic <MPA 
> Hello> and turn in our test books. 

Ah, but this is one of those truly annoying test questions that
doesn't have a single right answer :-), and I make no claim to
have provided the "best" answer.  OTOH, I believe this approach
to be workable.  Under ordinary circumstances, I wouldn't do this
level of design as a WG Chair, but I've received complaints that
the design task being set for the WG in this area is impossible,
and hence I've described a design approach as a counterexample
to demonstrate that the task is feasible.

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