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

["Manfredi, Albert E" <[e-mail]>]

From: Mark Smith [mailto:[e-mail]] 

> From: Lin Han [mailto:[e-mail]]

>> [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