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

[Toerless Eckert <[e-mail]>]

On Fri, Oct 20, 2017 at 01:20:40PM +1300, Brian E Carpenter wrote:
> 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.

If you failed twice betting your architecture on correct implementations,
maybe its time to try stronger DO and DONTs and explore other options
to achieve a better result. 

Lets also remember that TLS is also seen as a tool to avoid broken
middleboxes to mess up your traffic flow. However good intentioned
the middlebox may be. So its not a bad idea to consider using encryption
to allow only those onpath devices that you trust (to at least work
correctly) to be able to do anything. Not easy to design, but possible.
But something that would make me prefer doing it in a common "flow-layer"
above IP instead of IP extension headers. Like what SPUD was suggesting
as well. I also hate the fact that we're redefining the transport prototcol
every time we need to improve something. Like we do now with QUIC.  Should
really start to think more about reusable transport layers.

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

"Judge, its in my genes, my mother already exposed the same bad traits"

Yeah, that defense is known to reduce sentencing time but should
also make you want to design the next generation differently.

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

http://dilbert.com/strip/2001-04-14

Enough comic relief ;-)

Cheers
    Toerless

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

-- 
---
[e-mail]