Subject: RE: [Tsvwg] RE: [rddp] RE: Placement "outside of" TCP

From: [email-masked]
Date: Thu, 19 Dec 2002 11:47:55 -0500

Brian,

I'll let Joe speak for himself, but the important point here is
that not only can DDP essentially as proposed be cleanly layered
on top of an RFC 793-class TCP interface, but there is also "running
code" that does so.  While the RDDP WG is clearly interesting in
implementations that optimize across the TCP and DDP layers, the
existence of this "running code" should put an end to arguments
that DDP can only be implemented via cross-layer optimizations.

If someone wants to argue invalidity of cross-layer optimizations
(which have a long history in implementations), I'd really like to
see an explanation of how the specific optimizations fail to
comply with either the requirements for an exposed interface or
protocol requirements on the wire -- I'm not impressed by claims
that an implementation is non-compliant because a "fictional"
(RFC 793's word) unexposed interface has been optimized out without
functional change, which is essentially how the dead horse is
being beaten at the moment ;-).

MPA is a different beast - as currently proposed, it changes TCP,
although I don't believe it involves a change to the RFC 793
"fictional" interface.  The whole area of TCP framing, including MPA,
is in flux at the moment - when it stabilizes there will be more than
adequate opportunity for you, Joe and the rest of the TSVWG community
to make the case that a framing-modified TCP proposal that finally
emerges is enough of a TCP' that it ought not to be allowed to use
TCP's protocol number.

Thanks,
--David

> David,
> 
> I thought Joe was just expaining to Jim how that approach breaks
> RFC 793 semantics when you offered the "Bundle-Fly Supposition". ;)
> 
> --brian
> 
> On Thu, 19 Dec 2002, [email-masked] wrote:
> 
> > Brian,
> > 
> > > I supppose the point is that it cannot be implemented as separate
> > > layers without breaking TCP semantics to the ULP, therefore your
> > > "black box" cannot contain the equivalent of an RFC 793 compliant
> > > interface.  What you "black box" contains is DDP/TCP 
> bundle-fly. ;)
> > 
> > That supposition would be wrong.  There is at least one example
> > of a system built using DDP/RDMA (VI to be precise) over TCP along
> > the lines of what the RDDP WG proposes that contains a clear
> > separation of TCP from DDP/RDMA.  It's based on an enhanced TOE
> > with a lot of outboard memory to handle its own TCP buffering, but
> > derives significant performance benefits from DDP/RDMA.  Not only
> > is this an implemented counterexample, but it's deployed and in
> > use.  I'm sure Jim Williams will be happy to explain in more detail
> > if you're curious, as he did quite a bit of work on it :-).
> > 
> > The IETF has generally stayed out of this sort of area of
> > implementation internals, and (IMHO) that's a good thing (tm) -
> > for example, I suspect TCP would have been far less widely
> > adopted if every TCP implementation had been required to
> > use BSD-style mbufs.
> > 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Dec 2002 10:11:00 -0700

Black_David,

As DDP without TCP framing is not terribly useful, I think we have
always been talking about the different beast.

Besides, I'm find it goes against logic to in one breath say that
DDP/TCP in a black box (with some efficiencies exploited) does not
alter TCP, and, in the other breath say that  MPA/TCP in a black box
(with some efficiencies exploited) does alter TCP.

In fact neither performs cross-layer optimizations (where two already
useful layers are optimized), but exist solely to attempt to impose
efficiencies upon TCP.  The argument is that in forcing certain
efficiencies into TCP, you make it un-TCP.  As it is a different
protocol internally, even with a different API, use a different
protocol number.

--brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Dec 2002 10:53:32 -0800

[email-masked] wrote:
> code" that does so. 

Speaking for myself ;-), that's fine. I am concerned with ensuring that 
no protocol above TCP (as far as TCP is concerned, that's called the 
"user") receives data out of order without a tag that says "use this and 
you violate the API".

That requires that DDP, when placing the data, must block things above 
it from accessing its contents unless:
	a) TCP indicates it is OK to do so
	b) DDP passes the flag along to that protocol/process as well

I.e., for unmodified applications, (a) is the only valid choice.

> being beaten at the moment ;-).

The horse, FWIW, is in the spec, and alive and kicking:

  From RFC793:

-------------------------------

1.3.  About this Document

    This document represents a specification of the behavior required of
    any TCP implementation, both in its interactions with higher level
    protocols and in its interactions with other TCPs. ...

-------------------------------

3.8.  Interfaces

    There are of course two interfaces of concern:  the user/TCP interface
    and the TCP/lower-level interface....

-------------------------------

    RECEIVE Call
      ...
      ESTABLISHED STATE
      FIN-WAIT-1 STATE
      FIN-WAIT-2 STATE
        ...
        When the TCP takes responsibility for delivering data to the user
        that fact must be communicated to the sender via an
        acknowledgment.
      ....

-------------------------------

I.e.,

	1. the API and its behavior are as much a part of the spec
	of TCP as are the packets

	2. user means anything above TCP

	3. data cannot be delivered to the user until ackd.
	We all agree that delivery occurs when the data is
	tagged valid, _provided the tag is enforced_.

So:

	DDP _requires_ the tag from TCP
		- data MUST be provided with the tag if
		  received before ack'd
		- DDP MUST NOT place data delivered without a tag

That has to be in the spec. Those whose heads are wrapped around DDP can 
address that.

Anything else changes the semantics of the underlying TCP, by 'letting 
the cat out of the bag'.

The issue, IMO is:

	i. whether DDP, MPA, or some combination is
	 _required_ to sufficiently _ensure_ that
	the cat is contained

	ii. if there are ANY combinations (MPA+DDP, MPA alone, etc.)
	that allow the cat out, then whatever it provides:
		a) MUST NOT be called TCP
		   i.e., MUST NOT be available as a "SOCK_STREAM"
		   using default configuration.
		b) IMO, MUST NOT (at least SHOULD NOT) use
		   TCP's protocol number

Joe