Hello Bousso
Yes. Congestion avoidance relies on the TCP window size mechanisms kicking in when segments are purposefully dropped. This mechanism will not work for UDP traffic.
In this section, Rene mentions that congestion management is achieved by using queueing mechanisms. This is something that is performed by all networking equipment and is not exclusive to Cisco.
Tail drop occurs when you have a single queue that becomes full, and the next packet to arrive cannot enter the queue, and is thus dropped.
Queue starvation occurs when you have multiple queues on an interface, one of which is the priority queue. The priority queue is always served first, and the rest of the queues must wait. However, if you have enough priority traffic, it may happen that the scheduler is so busy serving the priority queue that the other queues are never served. When the non-priority queues get full, the next packets trying to enter them will be dropped, resulting in queue starvation. To resolve this, a limit is set on the priority queue to ensure that queue starvation is avoided.
Now both tail drop and queue starvation essentially look the same (packets trying to enter a full queue are dropped), but they occur due to different circumstances, and in different queueing scenarios, and this is what makes them different.
Both policing and shaping can be configured on the ISP, on an enterprise’s edge router, or on both! It really depends on what you want to achieve. For example, your ISP may apply policing on both upload and download data, which means they will drop packets that exceed the limits they place. In order to avoid losing those packets, you can set up an additional shaping policy on your edge device which will ensure that data will be sent to the ISP at speeds below their policing thresholds, while still attempting to avoid dropping packets by employing queueing. (See this section to refresh your memory on the difference between policing and shaping). So the words you use to describe it depend on what has been configured and on what device(s).
QoS mechanisms will “kick in” only when there is congestion. If there is no congestion, all arriving packets are immediately served. Congestion that occurs on the interface in an outbound direction can have QoS mechanisms applied. Congestion can occur in an inbound direction as well, but there is no way to employ QoS as an interface is obligated to simply receive whatever traffic it is sent, and has no way of queuing anything if more traffic arrives than it can handle. It is the responsibility of the interface on the other end to employ QoS so that incoming traffic on the local interface does not overwhelm it.
Now you are making a distinction between a link and an interface, but these are essentially the same. The actual wire (if that’s what you mean by link) will not be able to carry anything more than whatever the interface sends. The wire is not a limiting factor (unless you are trying to run GigabitEthernet over a category 3 UTP cable!), and even if it was, there are no mechanisms on the wire itself to employ QoS. All the intelligence and mechanisms occur at the interfaces.
I hope this has been helpful!
Laz