Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

[Brian E Carpenter <[e-mail]>]

On 20/10/2017 10:23, Toerless Eckert wrote:
> On Wed, Oct 18, 2017 at 08:57:35AM +1300, Brian E Carpenter wrote:
>>> 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.
>>
>> That's pretty much what RFC7045/RC8200 say, except that they
>> say it as a warning.
> 
> It does not analyze the fact that the existing hop-by-hop option (and options
> carried via it like router alert) are burned because existing router imple entations
> punt packets with hop-by-hop options even though they do ultimately not
> need to process the packets (hop by hop option they don't do or router-alert
> protocol they don't do). 

We discussed that before agreeing on the words in 7045, which were +- adopted
in 8200.

> And IMHO the existing hop-by-hop option is burned because the architecture
> RFCs did not well enough express in MUST statements that you must never
> speed down packets because of hop-by-hop/router-alert unless you really know
> you will support/do-something with that option. And that you achieve this eg.:
> by filtering/punting based on option/protocol. And that you can NOT do anything else.

The protocol design really shouldn't talk about implementation choices
in routers and the fact that FPGA people hate the IPv6 extension header
design like the plague, which has led to broken implementations. In 1994
there weren't any 'fast path' router designs, iirc, and the design simply
didn't consider this problem to be a problem. So the assumption was that
the forwarder CPU would pass on the whole header, and would only branch
off the main code path if it saw a HbH header. I know we're 20 years
later, but logically that hasn't changed. The problem is that many vendors
didn't implement it; they sacrificed correctness for speed.

> This is also the root cause why in our analysis a hacky extraction by
> eg: STUN signature inside UDP is a lot safer for existing networks than relying
> on any hop-by-hop option. Badly standardized, badly implemented.

We agree on badly implemented ;-). IPv4 Options are badly implemented, too.

>> As Ole said - within a domain where hop-by-hop option X is
>> supported, you can reasonably expect that all routers process X.
> 
> Ask an enterprise operator with 10 different router models from 3 vendors ;-)

If they want to use X they need to buy routers that support X.

   Brian

> 
> Cheers
>     Toerless
> 
>> But (excuse me repeating myself), whether X is worth doing is not
>> really a question for 6man. In this case, it belongs where QoS is
>> discussed, which is TSVWG.
>>
>>     Brian
>>
>>> 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
>>> 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 ;-))
>>>
>>> Cheers
>>>     Toerless
>>>
>>> On Tue, Oct 17, 2017 at 09:54:52AM -0700, Tom Herbert wrote:
>>>> On one hand, IETF defined extension headers as the extensibility
>>>> mechanism of IPv6, but yet on the other hand the message seems to be
>>>> to not use them because deployed devices don't correctly support the
>>>> protocol. The upshot is that we see proposals in other WGs of stuffing
>>>> network layer information into transport protocols (options or
>>>> payloads) with the full expectation that intermediate nodes will parse
>>>> into the transport layer, process the embedded information, and
>>>> possibly even overwrite transport layer information. IMO that is an
>>>> architectural abomination and further abandonment of the end to end
>>>> model!
>>>>
>>>>> While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else.
>>>>> And it might be a little too early to go into the details of packet formats etc.
>>>>>
>>>> Agreed, but I do think the 6man working group has a vested interest to
>>>> make sure that network layer information stays in the network layer.
>>>> At some point the information needed is going to be so complex that it
>>>> won't be able to be conveyed in any fields of the IP header.
>>>>
>>>> Tom
>>>>
>>>>> Best regards,
>>>>> Ole
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>