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

Hi, Tom

Agreed with you.
Actually we come out the solution by using IPv6 extension header after we failed in using upper layer information, such as TCP or UDP options.
>From the NPU processing point of view, retrieving the signaling message from either part of the data packet have almost no difference in terms of complexity and performance; 
We selected using transport layer information at the beginning was because it is independent of IPv4 and IPv6. But later on, we found that this solution will be limited in the case of un-encrypted TCP and UDP, and it cannot apply to other newer protocol such as QUIC. Considering the encrypted transport service is almost a default configuration in the future, this limit is absolutely un-acceptable. We got the same feedback after we chat with some ICCRG folks in previous IETF meeting. To use upper layer information for the network layer purpose is strongly opposed by TCP community.
One more thing to inspire us to use the IPv6 HbH is that the very original in-band singling proposed by John Harper (quoted in the draft) was finally resulting the TCP Quick-Start (RFC4782). Our draft could be seen as a further step to provide a more complete QoS support for all transport protocols.

Regards

Lin

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert
Sent: Tuesday, October 17, 2017 12:39 PM
To: Toerless Eckert <tte@cs.fau.de>
Cc: 6man WG <ipv6@ietf.org>
Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt

On Tue, Oct 17, 2017 at 11:16 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> As mentioned in my prior mail: RSVP-IP deployments got killed by SPs 
> that filtered packets with router-alert because common network devices 
> punted packets because of the presence of router-alert. Instead of 
> punting them because of presence of RSVP-router-alert option. And of 
> course you can blame IP multicast: every router started to punt 
> router-alert because of MLD (and of course us multicast folks missed 
> the chance to fix this in MLDv2 because it only tried to duplicate IGMPv3), but no RFC told developers to punt because of router-alert + value in the router alert.
> AFAIK, the same applies to hop-by-hop option in general. Alas, even 
> rfc7045 did not discuss this issue.
>
> IMHO we need a mechanism that specifies: devices MUST NOT punt/slow 
> down packets because of the presence of this mechanism, but only 
> because of presence of
> (mechanism,value) where value is intended to be supported by device. 
> If the device can not do this, then it MUST IGNORE this mechanism and 
> forward packets with the mechanism as if the option was not present.
>
> One simple way to do this is to define hop-by-hop-fixed that does say 
> exactly this and then hopefully allow all existing hop-by-hop TLV to 
> live underneath that fixed hop-by-hop-fixed option. But i would 
> certainly suggest to review processing complexity and extensibility before such a conclusion.
>
> Personally i prefer inband UDP layer signaling, not because i do not 
> like IPv6 option headers but because there is just no ubiquitous API 
> to allow apps independent of OS enhancements to set arbitrary options 
> headers, especially ones

The API does exist. OSes like Linux have implemented APIs described in
RFC2292 and other common APIs.

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

Tom

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------