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

Hello David,

thanks a lot for the comments. Addition to Fernando's comments inline.

On Mon, 27 Oct 2008, Fernando Gont wrote:

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

Just to add - the code I created for testing was deliberately 
without the SO_OOBINLINE - under the "naive" premise that indeed
this protocol implementation bug would've been corrected by 
now and the "standards-compliant" behaviour would be the default.

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

Again, the deliberate "naive expectation" was that the old and known 
broken implementation is *not* the default in the today's TCP stacks, but 
would require a configuration tweak to fallback to buggy behaviour used in 
the legacy applications.

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

So, we have three options:

- "old and buggy" semantics
   -> default with no additional effort 
- the incorrect semantics from the RFC793 - correct by the RFC1122
   -> default after adding the additional code to set
      the socket to SO_OOBINLINE to get away from the "old and buggy" one
- the "standard" RFC1122 semantics
   -> achievable with SO_OOBINLINE setsockopt *and* the
      host-global configuration switch.

The latter two are split because at least in one scenario within 
the set that we tested there was an observable difference in the 
behaviour - while again this can be classified as a "bug",
it pretty much leaves the reasonable answer to the question
"How to interoperably use the urgent pointer/data in TCP for my 
application?" to be "Don't" ?

thanks,
andrew
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm