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

Williams, Jim wrote:
> The subject under discussion here is transforming
> TCP into a record aligned transport to allow receivers
> to do some level of ULP processing prior reassembly
> of the TCP stream.  The specific goal is to enable
> an RDDP protocol to directly place incoming
> data even if TCP segments arrive out of order.
> 
> At least two drafts have been submitted which
> propose mechanisms:
> 
>      draft-ietf-tsvwg-tcp-ulp-frame-01.txt [tuf] (expired)
> and
>      draft-culley-iwarp-mpa-00.txt [mpa]
> 
> In Atlanta I argued the case for "DON'T DO IT AT ALL".
> The case being that TCP is a stream protocol and should
> not be used otherwise.  SCTP is a record protocol and
> should be used when a record protocol is needed.
> And that "fixing" TCP rather than switching to SCTP
> is the wrong architectural direction.
> 
> However in that aftermath of Atlanta I fear that
> my argument is losing within the RDDP group, so I would
> like to at least explore the alternative.

I'd say "DON'T BOTHER AT ALL". Here's why:

	1- anything that really does something useful
	is going to require EITHER a change to
	TCP semantics (the SEND/RECEIVE etc. API) OR
	to default to current semantics

	2- changing semantics of the default case is
	simply not an option. There's too many
	critical (e.g., financial, commerce, etc.)
	systems that are based on existing semantics.
	We don't know what will break or when, and
	setting up a wide-scale gamble simply isn't
	appropriate.

	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.

	The answer I've been hearing is "we need
	it now, and need it to work for legacy apps".
	But that means you also need legacy semantics,
	which means #2 applies.

Finally, I'd appreciate hearing a discussion of why this should all work 
that doesn't include some glaring errors. E.g., at the last meeting we 
all heard about how TCP with Nagle off (NODELAY) sends packets that 
match what the send calls issue. That simply isn't the case, never was, 
and cannot be assumed regardless. E.g., how do you know the path MTU 
didn't change between when you checked it/issued the write and when the 
packet is emitted?

Many of the other debates about these other protocols ignore the fact 
that the TCP spec is defined in terms of two interfaces - one below (the 
packets) and one above (the API, in terms of generic 
SEND/RECV/OPEN/CLOSE etc.) The API appears to be ignored in most cases.

...
> Both [tuf] and [mpa] state
> that the receiver might or might not get record aligned
> segments, and they both add another layer of protocol
> processing to allow the receiver to determine whether
> the alignment attempt was or was not successful.  They
> both require that the receiver to support the dual 
> complexity of handling both aligned and unaligned
> segments on a given connection.
> 
> To me, this seems to have the type of undesirable 
> complexity often associated with ill advised, ad hoc
> solutions.  I would encourage that some thought
> be given to a more cleanly architected solutions
> even if the down side is greater impact on TCP
> bahavior.

How about realizing that: these are TWO different transport protocols, 
and deserve two different protocol numbers?

> There are two fundamental problems with guaranteeing
> record alignment to the receiver.
> 
>   1.  How can the sender always align.
> 
>   2.  How can middle-boxes be prevented from
>       re-segmenting the TCP stream.
> 
> With respect to 1., both drafts state that alignment
> will usually be done, but list a number of exception
> cases under which the sender will not attempt to 
> align.  
> 
> I would propose as part of "doing it right" that
> a sender which agrees to align must ALWAYS align
> records with TCP segments.  I will not attempt
> now to list here all the implication of this, but 
> the summary is that this will require
> small but substantive changes to TCP
> sender behavior, and that these changes, if done
> right, will not break interoperability with 
> existing implementations.  (However this is
> a tricky area, and until the work is done, 
> it is not possible to be sure.)
> 
> With respect to 2., I would propose that senders
> that agree to align should announce this intention
> by adding a newly defined RECORD_ALIGNED TCP option
> to the SYN segments used to set up the connection.

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?

...
> However, in practice this will not be a big enough
> problem that it should drive protocol design in a
> major way.  Middle boxes that re-segment, and also
> send a TCP option agreeing not to re-segment
> are engaging in aberrant and erroneous behavior,
> and will cause connections to quickly close in error.

Yeah, right. Or the will cause the applications to break, and not work 
at all, as NATs often do. Then what?

> The result is either they will be fixed, or
> the affected receivers will be configured to
> not assume alignment (ignore incoming RECORD_ALIGNED
> options).

How? When you're at a meeting and need to get to your email, then what? 
Did the NAT boxes that hit you last time magically disappear, or did 
your end or your servers' get reconfigured to work?

This is not a useful path to spend further energy, IMO.

Joe

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg