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

From: David Borman <[email-masked]>
Date: Thu, 19 Dec 2002 13:29:57 -0600 (CST)

Dave Clark said it best years ago, when he more or less said that
strict protocol layering was an excellent way to design protocols,
but a terrible way to implement them.

I don't care about whether or not an implementation is a black box, or
how much mucking around with the protocol layering has been done in
the implementation.  If you can blur the lines in your implementation
to get better performance, more power to you, as long at the
implementation is conformant at all points where it interacts with
others, e.g. in on-the-wire packet format, in the externally visible
processing of those packets (for example, TCP can't delay ACKs forever.
and in the interface provided to layers above/below it.

So, I don't have any problem with a DDP/TCP implementation having its
layers intertwined and doing direct placement of data, since as far as
I'm concerned that is an implementation issue.

From my view, the main issue here is that the introduction of markers
into the DDP/TCP data stream is only there for the express purpose
of making it easy for an implementor to blur the protocol boundaries.
Markers have nothing to do with the design of the protocol itself, and
everything to do with the implementation of the protocol.  (If all the
data is received in-order, then markers have no useful purpose!)

Now designing a protocol without giving any thought to the implementation
is silly.  That's why we require multiple inter-operable implementations
in order to move protocols along the standards track.  Clearly designing
a protocol that is easy to implement and optimize is desirable, the
only question is how far to you let the ease of implementation and
optimization drive the protocol design.

Markers really feel to me like an explicit protocol layering violation.
Yes, there is precedence for them, as iSCSI has them.  But just because
there is a precedence doesn't mean it's a *good* precedence.

From a protocol standpoint, what is really needed is an extension
to TCP to allow out-of-order delivery of data, with the additional
feature that along with the delivery of that out-of-order data, an
optional resequencing point may also be delivered.  If TCP had this
extension, then the whole MPA marker issue goes poof and is gone,
and the DDP/TCP spec becomes much cleaner from a protocol design
point of view.

		-David Borman, [email-masked]
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

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

David,

On Thu, 19 Dec 2002, David Borman wrote:
> to TCP to allow out-of-order delivery of data, ...

This extension would give TCP an option to be un-TCP.  If you want
out-of-order delivery, use UDP.  If you want reliable out-of-order
delivery, use RUDP, or more recently, SCTP.

Regardless of your beliefs on the values of APIs, RFC 793 happens
to place requirements on the TCP API.  Anyone wanting to get away
from that needs to strike a few MUSTs from that standard.

If the only problem were efficient reodering, why not reorder the
delivery of IP packet indications from the NIC to TCP's lower
boundary, using only information in the TCP header (without even
copying)?  Then TCP sees a network where everything arrives in sequence
and there is no need for markers or out-of-order delivery.  TCP can
direct place to the user, perhaps in response to a standard readv(),
and maintain in-sequence delivery.

Why not?  I suspect the answer is because DDP applications really
want framing too.  Then use a record-based protocol (UDP, RUDP, SCTP)
instead of a stream-based protocol (TCP) or take the performance
disadvantage of using the wrong tool for the wrong job.

--brian

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

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 19 Dec 2002 16:12:22 -0600

On 12/19/02, Joe Touch wrote:

>David Borman wrote:
>....
>Perhaps, but that would require that the extended TCP be
>activated deliberately, i.e., off by default.
>
>Were it on, current apps would break, since the semantics
>would change.
>

As currently proposed, both DDP and MPA are non-default
behaviors that MUST be activated on a per-connection
(or per-stream for SCTP) basis.

Existing TCP connections (and SCTP associations) must flow
through to their existing ULPs without any modification.
That requirement has been understood from the beginning,
but perhaps it has not been re-iterated strongly enough.

Deployment of DDP and/or MPA has *no* impact on exsiting
applications (other than the deployment of *any* new
application steals some bandwidth).

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Dec 2002 13:02:26 -0800

David Borman wrote:
...
> and the DDP/TCP spec becomes much cleaner from a protocol design

Perhaps, but that would require that the extended TCP be activated 
deliberately, i.e., off by default.

Were it on, current apps would break, since the semantics would change.

Further, out-of-order is part of the issue; the other part regards 
segments. The MPA assumes that 'compliant implementations' will pass 
application segments as a whole as single TCP segments, and that the 
receiver MPA can detect when that's not the case. However, the intent is 
that a set of implementations will abide by those rules, effectively 
changing the API.

IMO, the pair of "out of order delivery" and "segment boundary 
enforcement" is sufficiently different to imply a different protocol, 
ala DCP. For that matter, why isn't it closer to DCP than TCP?

(TCP is a byte stream, and doesn't make as much sense if there can be 
gaps that are unfilled)

Joe