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

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

On 16/10/2017 16:49, Matao (D) wrote:
> On 14 Oct. 2017 13:41, Brian E Carpenter <brian.e.carpenter at gmail.com<mailto:[e-mail]>> 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.

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