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

[Toerless Eckert <[e-mail]>]

> 1: What is the authors' full analysis of why RSVP failed?
> 2: How does the proposed solution avoid the same failure?

Not an author, but some thoughts:

Given the existance of RSVP-TE and GMPLS, i wouldn't say RSVP failed.

IMHO there are lots and lots of issues with RSVP-IPs history that we now know how to
avoid. I think inband signaling is the one core architecture option we have explored
way too little and has only practically become feasible within the last maybe 10
years.

IMHO one key reason RSVP(-IP) was not adopted more is because of non-ubiquitous
support of the host stack/APIs. And OSs where it once was supported did withdrew
support for it. 

It was also killed by the initial focus on admission control - permit/deny flows.
Most customers thought thats what i was good for. And they needed that but came up
with faster to deply workarounds (eg: in IPTV).

As opposed to unequal bandwidth allocation. And nobody ever wrote a draft showing how
to implement the various options how to avoid eg: per-flow queues. By the time we wanted
to get back to these topics, there was already the generation of IETF'ler burned by prior
bad experience that where pushing back on any innovation in this space
("been there, done that, failed, go away").

Router alert also killed RSVP. Lots of router implementations punt packets with
router alert independent of the indicated protocol. So even if you don't run RSVP,
your router would punt RSVP router alert packets. So SPs try to get rid of router-alerts
on their network edge. I personally think we can't resurrect router alert option
like we resurrect ECN but have to choose other options (like what Lin propooses).

Onpath signalling from RSVP is also fundamentally different from inband signalling.
Just try to get RSVP through a NAT or firewall. Or try to make it stay onpath
when you have ECMP. I once had to work through all the path selection rules of one
back then popular router OS to propose an architecture how to expose all the options so
RSVP could stay onpath. Short summary: @$^%*$(@*&(*&@^$*&.

There was absoutely no consideration for RSVP to be designed in a way that would
allow for it to be easily processable in the forwarding plane (called NPU in the draft).
Or "inband" as we like to call it now.

The industry has a lot of experience with high performance per-flow state building
from control-plane (CPU) signaling. IP multicast. So we know how much of a pain it
is. And the industry hated it. Unlike RSVP they just didn't find any workarounds
for IP multicast and had intra-domain end-to-end use-cases (IPTV, finance) so individual
vendors could push vendors to make it work - over 20 year. Just check out the interest
in BIER to see how the industry wants to get rid of per-flow state maintenance and
instead prefers a more lightweight "in-band-singnaling" of replication.

In fact, both RSVP/IP-multicast state building was a lot more scaleable on
CPU-only forwarding plane type devices 20 years ago then it is in todays CPU/NPU
separated systems. Its getting through the bottleneck of IPC between CPU and NPU for
example.

I could go on...

Cheers
    Toerless

On Sat, Oct 14, 2017 at 03:16:16PM +1300, Brian E Carpenter wrote:
> Hi,
> 
> RSVP in IPv6 [RFC2205] uses packets with a Router Alert hop-by-hop
> option. So although it is not embedded in application packets, it is
> otherwise very similar: in band, following the same path as application
> packets, and triggering hop-by-hop processing in the same routers.
> RSVP for Integrated Services was a complete failure. So my first
> questions are:
> 
> 1: What is the authors' full analysis of why RSVP failed?
> 2: How does the proposed solution avoid the same failure?
> 
> In particular, I do not understand your argument about
> scalability. While that was an obvious issue for RSVP, it
> could be fixed in the way you describe: by limiting the number
> of using applications. The fundamental scaling issue for
> RSVP was the number of session state items per router, and your
> solution needs exactly the same number of session state items.
> So why will you succeed where RSVP failed?
> 
> > End user application cannot directly use DiffServ.
> 
> Not true. The advanced socket API allows the transport user to set
> the DSCP via IPV6_TCLASS [RFC3542]. It's been done for many years,
> for example in IP telephones.
> 
> What is lacking is a host software package to make this API feature
> useful, but any QoS solution needs that. In your terminology, that
> is the application interface to the closed-loop control system.
> 
> Note that RTCWEB has chosen to support Diffserv
> [https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/]
> 
> > 3.2.  IP In-band signaling
> > 
> >    There is no definition for IP in-band signaling.
> 
> Not true. That's exactly what DiffServ is. You could argue that
> it's too limited, but after 19 years we have not exhausted the
> DSCP code space defined in [RFC2474]. (As far as I know, nobody
> has yet combined use of the DSCP with the Flow Label. There is
> scope for creativity there.)
> 
> >    Flow level In-band Signaling
> >       The control message and data packet share the same flow
> >       identification.  The flow identification could be 5 tuples ...
> 
> I agree with the comment that the IPv6 flow label is a much better
> choice. It is already well defined [RFC6437] and widely supported
> by operating systems, it works for any transport protcol, works
> for encrypted packets, and works for packets with multiple extension
> headers. If you want per-flow granularity, the flow label is perfect.
> 
> >  The HbH-EH may be examined and processed by the nodes that are
> >    explicitly configured to do so [RFC8200]
> 
> which also says in section 4.8:
> 
> "  New hop-by-hop options are not recommended because nodes may be
>    configured to ignore the Hop-by-Hop Options header, drop packets
>    containing a Hop-by-Hop Options header, or assign packets containing
>    a Hop-by-Hop Options header to a slow processing path.  Designers
>    considering defining new hop-by-hop options need to be aware of this
>    likely behavior.  There has to be a very clear justification why any
>    new hop-by-hop option is needed before it is standardized."
> 
> I believe you need much more explanation of why we should ignore
> this recommendation.
> 
> > 8.  Security Considerations
> > 
> >    There is no security issue introduced by this document
> 
> I think this section needs more work.
> 
> Regards
>    Brian Carpenter
> 
> On 12/10/2017 07:05, [e-mail] wrote:
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > 
> > 
> >         Title           : IPv6 in-band signaling for the support of transport with QoS
> >         Authors         : Lin Han
> >                           Guoping Li
> >                           Boyan Tu
> >                           Xuefei Tan
> >                           Frank Li
> >                           Richard Li
> >                           Jeff Tantsura
> >                           Kevin Smith
> > 	Filename        : draft-han-6man-in-band-signaling-for-transport-qos-00.txt
> > 	Pages           : 40
> > 	Date            : 2017-10-11
> > 
> > Abstract:
> >    This document proposes a method to support the IP transport service
> >    that could guarantee a certain level of service quality in bandwidth
> >    and latency.  The new transport service is fine-grained and could
> >    apply to individual or aggregated TCP/UDP flow(s).
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-han-6man-in-band-signaling-for-transport-qos/
> > 
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-han-6man-in-band-signaling-for-transport-qos-00
> > https://datatracker.ietf.org/doc/html/draft-han-6man-in-band-signaling-for-transport-qos-00
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
[e-mail]