Subject: RE: [Tsvwg] Re: "DO IT RIGHT", or "DON'T DO IT AT ALL"

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 6 Dec 2002 08:52:10 -0600

While I try not to horn in on intense conversations about topics that I'm not wise on, I'm seeing a fundamental disconnect between

- running DDP with unmodified TCPs in user space, and 

- changing the "order of delivery" semantics for TCP.

I Would Have Thought that you'd have to modify at least the system call interface for sockets (on Unix, for instance), to change TCP delivery semantics.

Can anyone explain how you do both at the same time? ("Caitlin and Joe, are you sure you're discussing the same topic?")

Spencer

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 10:45 PM
> To: Caitlin Bestler
> Cc: [email-masked]'; [email-masked]'
> Subject: [Tsvwg] Re: "DO IT RIGHT", or "DON'T DO IT AT ALL"
> 
> 
> > 
> > By riding on existing transports, DDP avoids duplication of
> > efforts and solutions related to:
> 
> All good ideas. Except for overriding what the transport 
> protocol thinks 
> is the order of delivery. That's when it tries to undo something the 
> transport layer already does. 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: David Borman <[email-masked]>
Date: Fri, 13 Dec 2002 12:40:26 -0600 (CST)

> Date: Fri, 13 Dec 2002 11:17:33 -0600
> From: Caitlin Bestler <[email-masked]>
> Subject: Re: [rddp] Re: [Tsvwg] Re: "DO IT RIGHT", or "DON'T DO IT AT ALL"
...
> An optimal interface supporting MPA will make validated TCP
> segments available for *placement* to MPA out-of-order, but
> it does not *deliver* them early. The data is not
> "available".
>
> This is merely co-operative buffer management -- something
> already done in existing stacks.

I guess it gets down to semantics.  If you view it as MPA
providing information to TCP, that it uses to place the data
into the shared buffer, then everything is legit.  But if
you view it as TCP giving the packet to MPA which places
the data, then technically even though the data isn't being
made available out-of-order to the ULP, it is being made
available out-of-order to the MPA layer.  The problem is that
MPA can't tell TCP where place the data without first looking
at the TCP data in question.  That's why it looks to me more
like TCP delivering data out-of-order to the MPA layer, rather
than the MPA layer telling TCP where to put the data.  Which
leads into:

> Yes, the placement is based upon the contents of the packet.
> But if that is a violation of the rules, consider that the
> following would also be illegal:
>
> - placing the data from TCP segment into a reassembly buffer
>   at the correct offset for the specific connection.

Sorry, this doesn't use any of the TCP data to make it's decision,
all the needed information is in the TCP header.

> - Redirecting an IP packet based upon a TCP or UDP port
>   even when the IP packet is received out of order.

At the IP layer, there is no packet ordering.  Packets
are processed as they are received.

> Beyond the semantics games, it is important to remember
> the following important things about MPA:
>
> - It is compatible with *ALL* existing network equipment.
>
> - It is compatible with *ALL* existing TCP stacks. The
>   optimizing "placement" interface is an optional
>   enhancement. The protocol works without it.
>   
> - It is compatible with *ALL* network traffic shaping,
>   monitoring, firewalling and policy controls.

This is probably what bugs me most.  All these arguments for MPA
really feel like the tail wagging the dog, especially the third
statement.  I totally understand the desire to have a protocol
that allows out-of-order packets to not take a sever performance
penalty, but there are too many constraints being placed upon
the protocol design that are dictated strictly by current
implementations and middle boxes.  The IETF should not be in
the business of standardizing protocols based on hacks around
bad implementations and middleboxes.  I'm not saying that the
issue should be ignored, but there has to be some sanity.  Take a
look at the ECN spec (RFC 3168), section 6.1.1.1, "Middlebox Issues"
for one example of dealing with middleboxes without having them
dictate the protocol.

> Maintaining compatability with existing networking equipment
> and software is a vital goal. Maintaining compatability with

Understood, but that is not the primary goal of the IETF
standards process.  Sometimes existing implementations
are *wrong*, and folding to those issues are only somewhat useful
in the short term, and provide long-term restrictions that
have to be maintained forever.

		-David Borman

---

From: "Williams, Jim" <[email-masked]>
Date: Fri, 13 Dec 2002 14:20:16 -0500

TCP delivers data to DDP/MPA that is IN ORDER.  DDP/MPA
receives data from TCP that is IN ORDER, but may place this
data OUT OF ORDER in the application buffers.  These are 
the defined semantics for these layers.

A merged implementation (not internally layered) may
do direct out of order placement, but must maintain
the external illusion that the semantics of the
individual internal layers are observed.

The above definitions do hold water, although
they seem to leak a bit at the seams, especially
under certain error conditions.  Patching
these leaks requires that the application
scrupulously avoid looking at any data in its 
buffers whose presence might violate the 
transport semantics.

Overall, I find the above architecture messy
and strained, but not broken.  It's particularly
messy in that it includes heavyweight mechanisms
that are unrelated to the architecture, but included
just to facilitate certain optimized implementations.

Using SCTP unordered delivery as the basic building block
for DDP would provide a much cleaner and stronger
architectural base.

> From: David Borman [mailto:[email-masked]]
> 
> 
> than the MPA layer telling TCP where to put the data.