QOS

[Yura-Mi]

Let's say we have 100mbps ethernet link, if we give video traffic 20mbps and we give 40mbps for FTP traffic.

Does it mean we are only using 20mbps of that 100mbps link when video traffic is being transfered across that link? Is the remaining 80mbps of 100mbps not used while video traffic(20mbps) is being transfered across that link?

Does it mean we are only using 40mbps of that 100mbps link when video traffic is being transfered across that link? Is the remaining 60mbps of 100mbps not used while FTP traffic(40mbps) is being transfered across that link?

I am confusing as ethernet is serial transfer and baseband. Is that right? And baseband means only one signal channel is used on the link? Does it mean we can not transfer FTP traffic while video traffic is getting transfered on the link???

Thanks for any answer.

[Georg Pauwen]

Hello,

in general, QoS is only applied when there is congestion. In your case, congestion would mean that your 100MB link is saturated, and let's say 150MB wants to traverse that link. If that is the case, your QoS will make sure that voice/video will get whatever you assign. The rest goes to the default class. In any case, the 100MB is available, if there is 20MB worth of voice traffic, 80MB will be available for all other traffic, if there is 20MB of voice and 20MB of video traffic, 60MB will be available for other traffic...

The exception is when you police or rate limit traffic, which simply cuts off traffic when the specified limit is reached.

You are right about Ethernet, it uses baseband (digital) transmission, as opposed to broadband (analog). Have a look at the link below:

https://www.geeksforgeeks.org/difference-between-broadband-and-baseband-transmission/

[Joseph W. Doherty]

"in general, QoS is only applied when there is congestion."

BTW, depends on the "kind" of QoS.

"In your case, congestion would mean that your 100MB link is saturated, . . ."

Hmm, perhaps, perhaps not.

I define congestion whenever a frame/packet cannot be immediately transmitted, i.e. it must be queued.  This does not require a link to be saturated.  Further, even when a link is truly running at 100%, you might not have any congestion.

". . . and let's say 150MB wants to traverse that link."

If we're speaking of 150 megabytes, of data volume, and FTP, just want to add there are many variables involved whether that data transmission would congest the link, saturate the link, or cause any issues with other concurrent traffic.

I only mention these points because often it's assumed a "saturated" link is always bad while a lightly load link is always good.  Often, both are true, but both are often untrue more often than many realize.

[Joseph W. Doherty]

"Let's say we have 100mbps ethernet link, if we give video traffic 20mbps and we give 40mbps for FTP traffic."

You would need to further define how you will "give" these bandwidth allocations.  Reason I say that, there are various forms of QoS allocating bandwidth, which besides setting minimums and/or maximums limits sometimes have additional parameters which impact how traffic is actually "metered" and controlled.  (I.e. # bps on a physical port often "behaves" differently from the "same" # bps allocation when using QoS bandwidth settings.)  Also, you did not mention how the "remaining" 40 Mbps will be "allocated".

I.e. many of your questions cannot be answered until we get into specific QoS bandwidth management command functions.

In general, though, only one frame/packet, from some traffic flow can actually be transmitted at one time.  However, in answer to several of your questions, the next frame/packet, to be transmitted, does NOT need to be from the same flow as the frame/packet currently being transmitted.

Generally, frames/packets queue up at an interface awaiting transmission.  The usual default is to transmit those frames/packets in the same order they were received.  I.e. we have a single FIFO (first in first out) queue.

QoS, though, tends often transmits the queued frames/packets, not as FIFO, at least between different flow packets.

So, for example, a device has no frames/packets, and receives 3 FTP frame/packets.  The device begins transmitting the first FTP frame/packet.

While doing so, the device receives a VoIP frame/packet.  With "pure" FIFO, that frame/packet would be transmitted after the earlier received FTP frames/packets.  However, with QoS, we might have the VoIP frame/packet "jump the line", i.e. it will be transmitted after the FTP frame/packet currently being transmitted, completes its transmission.

As to things like bandwidth allocations, again, they are used in different ways, but one way, basically, "counts" transmission rates between types of traffic.  So, it might be (but again, depends on exactly the ways you are managing "bandwidth") with your video "allocated" 20 Mbps and your FTP "allocated" 40 Mbps, the two classes of traffic "share" available bandwidth in the ratio of 20:40 or 1:2.

BTW, for something like video traffic, depending on the "kind" of video, assuming the 1:2 sharing provides sufficient average bandwidth for your video stream's need, that (i.e. "sufficient" bandwidth), alone, may result in poor video results.