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

---

From: "Williams, Jim" <[email-masked]>
Date: Fri, 6 Dec 2002 22:25:31 -0500

Joe Touch wrote:
> I'd say "DON'T BOTHER AT ALL". Here's why:
> 
> [...]
>
> 	2- changing semantics of the default case is
> 	simply not an option.
> 
> [...]
>
> 	3- changing semantics of a non-default case
> 	begs the question: why not just compile in
> 	a different protocol? SCTP, DCP, or write
> 	your own on UDP.

Caitlin Bestler wrote:
> The goal for DDP over TCP has always been twofold:
> 
> - to allow DDP to work the way it was intended to work.
> 
> - to allow DDP to work with the IP networks as they are,
>   without any adverse effect on any middleboxes, or
>   any dependency on network architecture.
>   
> I would maintain that however messy MPA might be, it meets
> both of these objectives.

I guess these responses are no surprise.  The problem
is that the WG Chair has tentatively rejected my proposal
to preserve TCP semantics, and ruled in favor of modified
TCP semantics that allow out of order data placement.  He has also
come pretty close to rejecting MPA style markers as
a mechanism to achieve this.  (Correct me if I am 
wrong, David.)

The proposal in question was an honest attempt on my
part to investigate the remaining solution space.  I would
appreciate constructive criticism and alternatives within
these ground rules as opposed to restatement of positions
outside the currently defined scope of discussion.

Joe Touch wrote:
> Good luck on that. Middleboxes exist because the middlebox owners want 
> them to, and often don't want to be seen. They already violate the E2E 
> argument, and many aspects of the core specifications of the Internet 
> (1122,1123, etc.).
> 
> Now you expect them to respect a flag you put in the header. Why do you 
> expect them to respect a new spec, when the don't respect the existing
ones?

This strikes me as a rather extreme position.  Middle boxes can reasonably
be expected to avoid breaking currently established and widely deployed
protocols, otherwise people wouldn't buy them.  The paranoid position
is to design new protocols assuming they break everything else.

At this point, the only way to design new protocols is to make a
conservative estimate of how deeply middle boxes parse the packets
they see, and then tunnel the new protocol one layer deeper.
This will probably achieve some short term success, but is a really
bad strategy for defining the future architectural direction 
of the internet.  Pretty soon we're using uuencoded email as our
basic datagram transport.

The RECORD_ALIGNED TCP option works now when the rules are followed.
Layer three routers don't resegment the TCP stream.  And layer
four middle boxes (TCP aware) are required to ignore unknown
options on received SYN packets, and not include any unknown
TCP options on outgoing SYN packets.  Even middle boxes that
mess this up are unlikely to make the alignment situation
any worse than it is without the new option.

I am, however, under no illusion that the rules will always
be followed.  But the right way to protect against rule violations
is with additional end to end checking.  This checking
should be done with a reasonable and appropriate level
of caution.  It should not be done with an absolute
sense of paranoid protection against any conceivable
middle box misbehavior.

> Once up a time in IETF, when the
> participation was less industry-oriented, I
> remembered often hearing advice like
> "take your time, do it right and make it
> architecturally correct." I still think it is a good advice...
> 
> -Qiaobing

Thank you for that.  That sentiment was the motivation for
the title of my post. 
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

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.