RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

[snip]
That's been my reaction here too. I think, at a most fundamental level, IP is a technique that allows for plenty of *cheap bandwidth*, which has made QoS guarantees mostly unnecessary. Cheap bandwidth allows, even begs for over-provisioning in the network, which makes complicated QoS guarantees unnecessary. And furthermore, apps that do require certain quality levels take it upon themselves to adjust to what's available, rather than giving that responsibility to the intervening network. I think that RTP/RTSP was quite revolutionary, in the telecom world.

On the other hand, schemes like ATM assume *expensive bandwidth*, so they make a big deal about doling out bandwidth with fine granularity. Or, more realistically, they optimistically created the knobs for doing so, which proved way too complicated, in the face of the "cheap bandwidth" connectionless IP competition of the day. But there has been a succession of efforts, from early on in IP, to add QoS knobs.
[snip]

Hi, Bert

This solution tries to use a simplest way to provide a decent QoS, and keep the IP network architecture and benefits of best effort service. As I emphasize in the document, it aimed to be a supplementary for the current best-effort based transport service, and only used for the service which really needs it.

"cheap bandwidth" solution can certainly solve a lot QoS problem, as we experienced in last decades. But can it solve all problems in all use case? Obviously not. For example, our current access speed does not mean E2E bandwidth. Why we don’t complain? since most of applications can tolerate the insufficient bandwidth. But some application has already show a lot challenge to network. If you want a 8K video or AR/VR service with decent quality now, no SP can provide it in a short time. 
On the other hand, "cheap bandwidth" sometime is not cheap, it actually pushes the SP to upgrade network devices to obtain more room for bandwidth. If this is practical, it will be easier to ask SP to design a network with no oversubscription at the beginning. All come to the cost of SP.

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Manfredi, Albert E
Sent: Sunday, October 22, 2017 4:07 PM
To: Mark Smith <markzzzsmith@gmail.com>
Cc: 6man WG <ipv6@ietf.org>
Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

From: Mark Smith [mailto:markzzzsmith@gmail.com] 

> From: Lin Han [mailto:Lin.Han@huawei.com]

>> [LH] Yeah, everything has cost. But it is still different, ATM UBR is 
>> connection oriented, it needs setup and involves the control protocol 
>> such as PNNI. In our case, the IP architecture is not touched at all.
>> IP best effort is as simple as before.
>
> Not at all.
>
> You're creating state in the forwarding plane. State created based on 
> traffic characteristics  is vulnerable to state exhaustion attacks.

I think that all Lin was saying was, "if you use best effort, then you haven’t sacrificed scalability." Which is true enough, I think. Whereas, with ATM, you are still having to set up that VC ahead of time, even if, with UBR service, you aren't specifying any QoS requirements along that path.

> Even in closed domains this can be an issue, because "closed" domains 
> attached to the Internet aren't guarateed to stay closed.

Yes, although I think Lin was saying, if you encounter routers that don’t know diddly about his in-band signaling, AND these routers aren't particularly congested, then all should still work fine. This traffic would hopefully sail through these lightly loaded inter-carrier routers, and then the QoS knobs would come into play in his own ISP network.

> RFC791 and RFC8200 forwarding is stateless.
>
> I'd even say traffic created state is worse than connection oriented 
> state such as switched virtual circuits in ATM. In that model, hosts 
> are requesting permission to send traffic on the network before 
> they're able to - if the network can't set up a connection for a host, 
> the host cannot contribute traffic load to the network.

That's been my reaction here too. I think, at a most fundamental level, IP is a technique that allows for plenty of *cheap bandwidth*, which has made QoS guarantees mostly unnecessary. Cheap bandwidth allows, even begs for over-provisioning in the network, which makes complicated QoS guarantees unnecessary. And furthermore, apps that do require certain quality levels take it upon themselves to adjust to what's available, rather than giving that responsibility to the intervening network. I think that RTP/RTSP was quite revolutionary, in the telecom world.

On the other hand, schemes like ATM assume *expensive bandwidth*, so they make a big deal about doling out bandwidth with fine granularity. Or, more realistically, they optimistically created the knobs for doing so, which proved way too complicated, in the face of the "cheap bandwidth" connectionless IP competition of the day. But there has been a succession of efforts, from early on in IP, to add QoS knobs.

Bert

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------