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

From: "Matao (D)" <[email-masked]>
Date: Mon, 16 Oct 2017 03:49:36 +0000

On 14 Oct. 2017 13:41, Brian E Carpenter <brian.e.carpenter at gmail.com<mailto:[email-masked]>> wrote:

>> 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?
IMHO, the fundamental scaling issue for RSVP was not the number of session state items, the real issue was the overhead of maintaining the session state items.
RSVP needs periodic signaling messages to refresh the session state. Actually, the overhead of generating and handling the periodic refresh messages limits the number of session state.
To the contrary, this solution needs no explicit signaling message, but applies the data packets to maintain the session state (seen in section 3.5.7). It adds no extra overhead to refresh states, which improves its scalability.
Although this solution needs exactly the same number of session state items, but the overhead of maintaining the same number of session state items is much smaller than overhead of RSVP. So this solution scales to much more session state items than RSVP.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Oct 2017 08:49:07 +1300

> Although this solution needs exactly the same number of session state items, but the overhead of maintaining the same number of session state items is much smaller than overhead of RSVP. So this so…

Yes, I agree that there are no additional messages, but of course there is still
a more complicated state lookup and some processing for each packet, whereas for
diffserv there is just a 6-bit switch to select a queue.

I recommend taking this discussion to the transport area in the TSVWG. That is 
where we find the IETF expertise on this topic.

Regards
    Brian

---

From: Tom Herbert <[email-masked]>
Date: Mon, 16 Oct 2017 13:42:25 -0700

> diffserv there is just a 6-bit switch to select a queue.

Hi Brian,

I think the intent here is to allow network resource allocation at
flow granularity. This sort of thing is already being done on some
large scale deployments (Google's B4 for instance), but most those
seem to use out of band signaling to do resource scheduling for
anything that goes beyond basic QoS. One advantage of using HBH
options is they can be written so that should enable some nice
features to report network conditions, queue occupancy to implement
QCN, etc.

I agree that this is new complexity for intermediate nodes, but at
least it can properly use flow label to eliminate the need to parse in
transport layer. Also, doing this in EH is far better than putting
network layer information into TCP options (like proposed in
draft-flinck-mobile-throughput-guidance) or having intermediate
devices parse UDP payloads (like PLUS proposed).

Tom

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Oct 2017 10:33:24 +1300

On 17/10/2017 09:42, Tom Herbert wrote:
> flow granularity. 

Yes, of course. But whether that is practical is not a 6man issue;
6man of course has a word to say on defining new extension headers
and options, but the main discussion is definitely in the Transport
area (IMNSHO).

    Brian

> This sort of thing is already being done on some