Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00

[David Borman <[e-mail]>]

On Oct 27, 2008, at 8:58 PM, Fernando Gont wrote:

> Hello, David,
>
> Thanks for your timely response. You'll find my comments inline....
>
>
>> First, despite what 793 and 1122 say, TCP does *not* have urgent data
>> in the sense that people think.  TCP has an urgent *pointer*, that
>> indicates an interesting point in the data stream.  *All* the data
>> prior to, and including, the Urgent pointer is the urgent data.
>
> Agreed. However, there are two issues here:
>
> Firstly, the recv(2) with MSG_OOB only returns a single byt of  
> urgent data, whereas according to your explanation it should return  
> all data prior to, and including, the Urgent pointer.

No, applications shouldn't be using recv() with MSG_OOB on TCP  
sockets.  That is the interface for the old, broken BSD interpretation  
of the urgent pointer.  TCP does not have out of band data.  The  
SO_OOBINLINE option was added so that new applications (new, circa  
1989, the date of RFC 1122) could turn this broken interface off and  
leave the data in the data stream where it belongs.  It was felt that  
we couldn't just change the BSD TCP implementation to the new  
behavior, because that would break all the existing applications.   
With SO_OOBINLINE, applications could switch over without there  
needing to be a flag day.


> Secondly, virtually all implementations intepret that the Urgent  
> pointer point to the byte following the last byte of urgent data.  
> And this is what RFC 1122 aims at correcting. (However, this  
> correction didn't reflect into actual implementations.)
>
>
>> It is
>> up to the application to decide what that means, and which data
>> relative to the urgent pointer is interesting, but typically it would
>> be the data just after the urgent pointer.  The application can't say
>> "these x bytes of data are the urgent data".
>
> mmm... why couldn't it say, e.g.,  that all the bytes up to the  
> urgent pointer are urgent data? (currently, only the byte before the  
> Urgent Pointer is interpreted as Urgent data... which does not seem  
> to agree with what the RFCs specify....)

The RFC more or less does say that.  The moment you get a packet with  
the URG bit, you enter urgent mode for all data until you get past the  
urgent pointer, hence that is all urgent data.  The key things are:

1) The urgent pointer only tells you where the urgent data ends
2) Urgent pointers are cumulative, a new urgent pointer updates where  
you leave urgent mode.
3) The urgent pointer can point beyond the data in the packet in which  
it is sent.

The problem is that (most of) the urgent data, as defined in RFC 793,  
is typically the uninteresting data.  For example, in telnet the  
urgent data is the data you want to read and flush, until you get to  
the Telnet Sync command.


>> If a TCP data stream writes some data in normal mode and the data  
>> gets
>> lost, then there is a successive write in urgent mode, then when the
>> lost packet is re-transmitted it'll now be transmitted with the URG
>> bit and the urgent pointer, turning that data into "urgent data" by
>> the 793 definition.  That's not what people think when they first  
>> hear
>> the term "urgent data", but that's how it works.
>
> Agreed.
>
>
>> it to the application out-of-band.  To fix that, the SO_OOBINLINE
>> socket option was introduced, and is still around today.  All
>> applications that use urgent data should be using the SO_OOBINLINE
>> option, there's no excuse for using the old, broken BSD  
>> interpretation
>> about urgent data.
>
> Well, this seems to be the default for all major TCP implementations  
> (see our survey).

Ok, there are two issues here.  First, SO_OOBINLINE turns off the old,  
broken BSD interpretation that removed a byte of data from the data  
stream and presented it to the application with the recv()/MSG_OOB  
call.  The second issue is which byte is indicated in the packet with  
the urgent pointer.  If the application knows what the kernel does, it  
can adjust accordingly so that the correct byte gets marked in the TCP  
data stream.


>> There isn't anything wrong with the 793/1122 definition of the Urgent
>> Pointer.
>
> The specific issue we are discussing is that the Urgent pointer is  
> defined in RFC 793 as pointing "to the byte following the last byte  
> of urgent data". RFC 1122 later corrected this definitation, stating  
> that it points to "the last byte of urgent data".

That's why I said 793/1122.  RFC 793 defined it both ways, and in RFC  
1122 we clarified that the definition on page 56 is correct, and the  
one on page 17 is wrong.

>> It might be useful to clarify the description if people are
>> still implementing and/or using it wrong, but the definition in
>> 793/1122 is still correct.
>
> Section 4.2.2.4 of RFC 1122 states:
> "The second sentence is in error: the urgent pointer points
> to the sequence number of the LAST octet (not LAST+1) in a
> sequence of urgent data. The description on page 56 (last
> sentence) is correct."
>
> This is where I'm saying that RFC 1122 differs from RFC 793.

Yes, of course.  RFC 1122 says that this definition is wrong.  In RFC  
793 the urgent pointer is also defined on page 56:

       If the urgent flag is set, then SND.UP <- SND.NXT-1 and set the
       urgent pointer in the outgoing segments.

which conflicts with the definition on page 17.  RFC 1122 clarifies  
that this definition on page 56 is the correct definition.

I'll also point out that RFC 961 also says that the definition on page  
17 is wrong; RFC 1122 re-enforces what was already documented.

I will say that using the recv()/MSG_OOB interface is the bigger  
issue.  You just have to look at the BSD Telnet implementation and the  
dances that it does if SO_OOBINLINE isn't defined to understand why  
that broken interface is such a bad idea.

			-David Borman

>
>
> Thanks!
>
> Kind regards,
>
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm