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

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

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
>