Subject: RE: [Tsvwg] FW: I-D ACTION:draft-culley-iwarp-mpa-00.txt

From: "Williams, Jim" <[email-masked]>
Date: Fri, 20 Sep 2002 12:56:42 -0400

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, September 20, 2002 11:00 AM
> To: Uri Elzur
> Cc: allyn; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] FW: I-D ACTION:draft-culley-iwarp-mpa-00.txt
> 
> The word "placement" occurs exactly twice in the ID, in reference to 
> DDR. Please clarify.
> 
> I think you mean that TCP passes the data to the ULP as soon as 
> possible, and that there is an additional mechanism for TCP 
> to indicate 
> that the right window edge has passed. HOWEVER, the ID is 
> very clear to 
> avoid specifying properties of the ULP.
> 
> As far as TCP is concerned, the ULP _IS_ the application. TCP cannot 
> pass data to the ULP until the right window edge has passed, 
> precisely 
> because it cannot ensure that the ULP won't use information 
> in that data 
> until the right window edge has passed.
> 
> To use that information prior to that event would constitute 
> a change in 
> semantics, period, whether by an ULP or an application.

I believe the goal of MPA is to allow two possible
implementations.

  A.  A fully layered implementation in which the TCP 
      semantics are fully preserved and respected.

  B.  An optimized implementation in which the TCP
      and MPA layers are merged such that the
      semantics of the individual layers are merged
      and not preserved, but the combined semantics
      of the two layers are correct.  I.e. the 
      layer above MPA sees the semantics defined
      by the upper boundary of MPA, and the wire
      protocol is fully consistent with TCP.

I am unclear if your criticism is that MPA fails
in this objective, or that the objective itself
is ill conceived and should not be pursued.

If the latter, it might be helpful to explain
in a bit more detail why this is bad.
Saying that it "would constitute a change in 
semantics, period", puts the period a bit too 
soon for me.  Implementations often merge layers
in such a way that if one were to peek inside,
one would see that the semantics of the 
individual layers are quite blurred.  This
might or might not be a bad thing.
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Sep 2002 10:24:42 -0700

>       semantics are fully preserved and respected.

This is the case where it runs the existing TCP stack.

>       protocol is fully consistent with TCP.

Please see my earlier note about "wire protocol". TCP isn't a wire 
protocol. FWIW, 'semantics' is exactly where 'wire protocol' and 
'protocol' differ.

> is ill conceived and should not be pursued.

1) MPA fails. it isn't TCP+MPA that is equivalent; at best, it might be 
TCP+MPA+ some ULP that enforces the fact that data isn't used when there 
are gaps. But the ID specifically avoids pinning that sort of behaviour 
down by the ULP.

2) at best, even if 1) were nott true or were somehow fixed (e.g., by 
including all the requisite properties of the ULP), there are two 
remaining questions:

	a) why doesn't SCTP suffice
		it isn't enough to say "my employer wants
		it to be called TCP". there has to be
		a reason for modifying such a widely-used protocol.

	b) why does it have to be inside TCP
		at best, if not TCP, this is a variant ala DCP.
		the behavior clearly flips between TCP and something
		that is, by the agreement of both sides, not TCP.
		that clearly calls for a new protocol number.

		i.e., this isn't an extension; it's a new protocol.

In the absence of overwhelming evidence for all three (1, 2a, 2b), as 
well as addressing how this overcomes the known shortcomings of previous 
attempts at this kind of solution, this proposal is premature.

> soon for me.

er, uh - you want to call it TCP. That means you have to preserve 
something. And no, just preserving the protocol number isn't enough.

> Implementations often merge layers

We're talking about a specification of a protocol. If the implementation 
blurs semantics, then it incorrectly implements the specification.

Joe

---

From: Randall Stewart <[email-masked]>
Date: Fri, 20 Sep 2002 17:06:02 -0500

Joe:

I have watched this ROI/RDMA activity for 
quite some time now. I have been fascinated
to see the vendors working diligently in 
getting SCTP/RDMA mappings in place.. I think
this is a good thing since SCTP seems to
have most of the features that RDMA needs.

Now I have also noted that there was a considered
and careful move to separate any mapping to
SCTP from the actual base protocol (which
I think is probably a good thing). I have on 
one of my numerous screens one of the iwarp
proposals I am reading through so that I can
proceed to lend my assistance to getting the
small draft about SCTP (it does not take much
to specify) rev'd. 

But one thing I find fascinating is that RDMA
does not want to use unordered delivery in SCTP
even though it may be desired (at least so I was
told in the distant past)... at the same
time the RDMA descriptions reserve 16 bytes in
there message so that MPA/TCP can place its
data information intact... rather an interesting
situation.. on one hand you don't want to use
features on the bases that other reliable transports
might not be able to supply the feature (something
like unordered... my conjecture here now), but
we make special allowances in the protocol byte
stream for another mapping... a bit of a conflict
don't you think?

I begin to wonder if Doug Otis might not have been
correct in his assessment that there was not a
very big intention to do SCTP with RDMA.. but instead
use SCTP as the cover to get the definition out and
then get it up over a modified TCP... (Doug please
correct me here if I have mis-read some of your
past posts... its a brief summary but I think a
correct one).

I wonder why this attitude? It should not be
a deployment problem.. we had a very successful SCTP
bakeoff two weeks ago. I was quite pleased with the
results actually... All of the implementations interoperated
and worked fairly well (note for scores and results you
can check the sctp-impl list archive...  Not sure if that
particular post made it to the new ietf archive if not
go to the older one at http://www.sctp.org). Very stable
code is available inside kame and at other sites such
as sctp.de and others... I just don't get this bent on
only using a "modified" TCP... (if it really is present).

I think any efforts to bend TCP would be better placed
at either adopting SCTP or getting a new protocol number
and writing a TCP'

Regards

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg