Subject: FW: New Version Notification for draft-han-6man-in-band-signaling-for-transport-qos-00.txt

From: Lin Han <[email-masked]>
Date: Wed, 11 Oct 2017 18:29:22 +0000

Dear all,

I have just uploaded a new draft. 
This draft describes a IPv6 in-band signaling method for QoS support for transport service.
The method can be used for fine-grained flows such as individual TCP session.
We also have done some experiments with in-house hardware to prove the concept, performance and scalability, which I may present in the IETF100 (up to the approve of WG chairs).
Your comments and questions are always welcome and greatly appreciated.

Thanks

Lin

----------------------------------------------
A new version of I-D, draft-han-6man-in-band-signaling-for-transport-qos-00.txt
has been successfully submitted by Lin Han and posted to the IETF repository.

Name:		draft-han-6man-in-band-signaling-for-transport-qos
Revision:	00
Title:		IPv6 in-band signaling for the support of transport with QoS
Document date:	2017-10-11
Group:		Individual Submission
Pages:		40
URL:            https://www.ietf.org/internet-drafts/draft-han-6man-in-band-signaling-for-transport-qos-00.txt
Status:         https://datatracker.ietf.org/doc/draft-han-6man-in-band-signaling-for-transport-qos/
Htmlized:       https://tools.ietf.org/html/draft-han-6man-in-band-signaling-for-transport-qos-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-han-6man-in-band-signaling-for-transport-qos-00

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

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.

The IETF Secretariat

---

From: Tom Herbert <[email-masked]>
Date: Thu, 12 Oct 2017 08:32:19 -0700

On Wed, Oct 11, 2017 at 11:29 AM, Lin Han <[email-masked]> wrote:

> We also have done some experiments with in-house hardware to prove the
> concept, performance and scalability, which I may present in the IETF100
> (up to the approve of WG chairs).

Hi,

I looked at the draft and really like the idea. This seems to be a type of
inband opportunistic RSVP with soft state.

My major comment is that it is too closely tied to TCP and UDP.
Specifically, the requirement that network devices in the datapath identify
the state by 5-tuple that includes port numbers seems restrictive. That
technique has all the known problems of doing DPI in intermediate nodes and
is only applicable to TCP and UDP or at least transport protocols that
include port numbers.

The alternative I would suggest is to only use the three tuple-- src addr,
dst addr, flow label. I believe all the major OSes are now properly setting
the flow label to be hash value represented the encapsulated transport
layer flow. WIth this, parsing beyond HbH is no longer needed and it works
with any transport protocol (even ESP for instance).

Tom

> URL:            https://www.ietf.org/internet-
> drafts/draft-han-6man-in-band-signaling-for-transport-qos-00.txt
> 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.
>
> The IETF Secretariat
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Lin Han <[email-masked]>
Date: Fri, 13 Oct 2017 00:53:09 +0000

Hi, Tom

Thanks for the comments, see inline answers with [LH].

Regards

Lin

From: Tom Herbert [mailto:[email-masked]]
Sent: Thursday, October 12, 2017 8:32 AM
To: Lin Han <[email-masked]>
Cc: [email-masked]
Subject: Re: FW: New Version Notification for draft-han-6man-in-band-signaling-for-transport-qos-00.txt

On Wed, Oct 11, 2017 at 11:29 AM, Lin Han <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Hi,

I looked at the draft and really like the idea. This seems to be a type of inband opportunistic RSVP with soft state.

My major comment is that it is too closely tied to TCP and UDP. Specifically, the requirement that network devices in the datapath identify the state by 5-tuple that includes port numbers seems restrictive. That technique has all the known problems of doing DPI in intermediate nodes and is only applicable to TCP and UDP or at least transport protocols that include port numbers.

[LH] Yeah, the port number in tuples will limit the solution to non-encrypted TCP, UDP. This document only exemplify the in-band signaling for non-encrypted TCP flow case. If a flow is identified by 3 tuples (src addr, dst addr, flow label), the mechanism is the same, as long as we define the “FI” as 3 tuples.

The alternative I would suggest is to only use the three tuple-- src addr, dst addr, flow label. I believe all the major OSes are now properly setting the flow label to be hash value represented the encapsulated transport layer flow. WIth this, parsing beyond HbH is no longer needed and it works with any transport protocol (even ESP for instance).

[LH] If the flow label is widely used by major OS, definitely we can define 3 tuples, instead of 5 tuples, for a flow identification. Before, I thought the flow label is not used in OS. All the details of the signaling method and message format, will only be finalized up to the decision of the IPv6 community.

Tom

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------