Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt

[Toerless Eckert <[e-mail]>]

On Tue, Oct 17, 2017 at 12:38:52PM -0700, Tom Herbert wrote:
> The API does exist. OSes like Linux have implemented APIs described in
> RFC2292 and other common APIs.

>From limited experience in the past, support is fragmented and frustrating.
But we only tried to get a few of these things work across various OSs 
(including android, iOS) and ran into variety of issues. ANd that was all
from C. Once you try to go into python, Java or (yikes) javascript, the
likelyhood of getting access to any API not needed by 99% of stupid apps
becomes lower and lower.

> > that are not yet defined (allow apps to fully defined the whole header bit by bit).
> > Lets say from a javascript app in a browser. And i am more interested in ease of
> > adoption than in architectural cleanlyness. But of course its perfectly valid to
> > do the architectural clean appraoch and then prove me wrong and get that option
> > adopted more ;-))
> 
> It's not just about architectural cleanliness, it's about correctness.
> In the case that an intermediate node parses a UDP payload it is
> likely doing this based on the some common destination port number.
> Port numbers don't have global and persistent meaning (e.g. TCP port
> 80 does not always have to be HTTP) so this leads to the possibility
> of misinterpretation as described in RFC7605. If the node improperly
> writes data into the UDP payload and updates the checksum, then this
> becomes silent data corruption.

Preaching to the choir. Reminds me when i got from IANA one of those sparse < 512 port
number for router interception with the explicit intent to minimize use by
random other applications - only to run into some obnoxious folks a few years
later who said they had used (but of course never registered) that port forever
in their app and do not intend to change that.

> Extension headers do not have this
> possibility of misinterpretation in the network.

> This potential misinterpretation of UDP ports and many other issues
> with trying to turn UDP into a network layer protocol were brought up
> in the SPUD/PLUS discussions.

So....

I wish we would have ever gotten to the point where we could really discuss
how to best do inband signaling. Alas, SPUD/PLUS was killed way in before
by what i would characterize as a perpass crowd attack.

IMHO, any inband solution needs to well define an efficient way to do per-flow
signaling, aka: not only per-packet. We're talking about per-flow behavior
in many cases anyhow, and we well understand what can and can-not be done with
per-flow state in middleboxes.

Check out 2013 MALICE/DISCUSS which proposed to use STUN packets to
signal inband (not every data packet like SPUD but just some STUN packets), and rely on
STUN cookie as signature to recognize those inband signaling packets. 

If we agreed that we wanted per-flow inband signaling, then the STUN signature
would be great option to get going. And a redefined router-alert-NG IP extension
header might be the architectural correct "look-at-me" option long term.

Finally wrt. architectural cleanlyness: Per-flow service negotition IMHO is
clearly a transport layer function, there is no concept of 5-tuple flows
at IP layer. So there should be no reason to constrain it only to the network layer.
We just need to revisit over transport-layer is end-to-end-only dogma.

Cheers
    Toerless

> Tom
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
[e-mail]