Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft)

[Jerry Leichter <leichter at lrw.com>]

On Mar 12, 2009, at 4:45 PM, David Borman wrote:
> On Mar 3, 2009, at 10:50 AM, Fernando Gont wrote:
>
> > Jerry Leichter wrote:
> >
> > >  You refer to the data pointed to by the urgent pointer as the  
> > > urgent
> > > data.  This is incorrect.  TCP doesn't directly have a concept of  
> > > urgent
> > > *data*; what it has is an urgent *mode*.
> > [....]
> >
> > This was the intent of the text. I'll go through the I-D again and  
> > will
> > try to remove any instances of what you describe.
>
> RFC 793 specifies all three: the urgent pointer, urgent mode, and  
> urgent data.  Urgent data is *all* the data before the urgent  
> pointer.  Urgent mode is when you are reading the urgent data.  What  
> TCP does not have is out of band (OOB) data.  Writing just one byte  
> in urgent mode makes all the previously written and unread data  
> urgent data....
A couple of comments:

	- *TCP* has no notion of "unread data" - as it has no notion of
	  *read* data either.  TCP can't possibly be altered to introduce
	  any such concept without first adding in a whole model of
	  the interaction between the TCP stack and its buffering and
	  user mode and its interaction with that buffering.  I can't
	  imagine why you would want to do that - or how you would do it
	  in a way that accurately reflects all existing implementations.

	- Because of this, "urgent data" is not a very interesting concept.
	  Urgent mode is to some degree, but even that's a mess.  Actual
	  TCP implementations involve two weakly-synchronized state
	  machines, one implementing TCP, one implementing the user code.
	  Urgent mode is a property of the former.  You mention later that
	  you can use the exception flags from select() to tell if you
	  entered urgent mode - one of the synchronization points between
	  the two machines.  However, it's a very limited synchronization.
	  For one thing, entering urgent mode is not the only thing that
	  causes the exception flag to be set - and you have no effective
	  way to check what the bit really means.  For another, if you're
	  executing a read() at user level when a segment with URG bit
	  set arrives, you're stuck.  I suppose you could alternate
	  select()'s with one-byte read()'s, but let's get real here.

	- I completely agree with you that TCP doesn't have OOB data.  I
	  said as much.  So?  TCP doesn't "have" ASCII or Unicode or HTTP
	  either.  All of these can be *built on top of* TCP.

	- Then again, *TCP* doesn't have a user API either.  That, too, is
	  built over a TCP implementation.

	- *The socket API* has OOB data.  The implementer's problem is how
	  to build a correct implementation of the socket API's OOB data
	  on top of the TCP primitives.  In fact, as I showed in a separate
	  message to Mr. Gont (which I'd be happy for forward if you're
	  interested; it's a bit long, and I don't want to just dump it
	  on a list of unknown size), it's actually not hard to implement
	  the socket OOB semantics of TCP, using urgent mode, as it is
	  specified today.  The implementation can even be equivalent in
	  performance to today's implementations, for streams that never
	  use OOB data.  It's true that one can improve the implementation
	  by making minor changes to TCP - but realistically the costs
	  would far outweigh the benefits.

In summary:  This is not, and has never been, a TCP problem.  The  
issues are at the boundary between the TCP stack and the socket API,  
affecting code on both sides of that boundary.

Finally, on the question of whether the socket API should be changed  
to eliminate OOB data:  That's perhaps an arguable position, exactly  
because the implementations are so bad; but the implicit message in  
the way you state it - that TCP is what matters, and the socket API is  
just some minor thing - is exactly backwards.  There are at most,  
what, a couple of hundred engineers in the entire world, working on at  
most a few tens of distinct code bases, who actually deal with *TCP*.   
There are hundreds of thousands of engineers dealing with millions of  
applications that depend on the socket API.

Changing TCP is a big job, but one that would be doable if there were  
sufficient need:  Look at IPv6.  Changing the socket API is impossible  
- if you think IPv6 is taking a long time to roll out, that's nothing  
compared to how long it would take a new, incompatible socket API  
replacement.  Chances are it would never happen.

                                                        -- Jerry