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

[Fernando Gont <[e-mail]>]

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.

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....)


>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).


>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".


>  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.

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