Quality of Service requirements are realized in LCOS by using different queues for the data packets. For the transmission side, the following queues are utilized:
- Urgent queue I
This queue is always processed at first before all others. The following
data packets are handled here:
- Packets with ToS “Low Delay“
- Packets with DiffServ “Expedited Forwarding“
- All packets that have been assigned a certain minimum bandwidth, as long as the guaranteed minimum bandwidth is not exceeded.
- TCP control packets can be likewise dispatched by this queue preferentially .
- Urgent queue II This is for all packets that have been assigned a guaranteed minimum bandwidth, but whose connection has exceeded this minimum bandwidth. As long as the interval for the minimum bandwidth is not exceeded (i.e. up to the end of the current second), all packets in this queue are treated without further special priority. All packets of this queue, of the "secured queue" and the "standard queue" share now the existing bandwidth. The packets are taken in order from the queues when sending in exactly the same sequence, in which they have been placed into these queues. If the interval runs off, all blocks, which are at this time still in the "Urgent queue II" up to the exceeding of the in each case assigned minimum bandwidth, are placed again into the "Urgent queue I". The rest remains in the "Urgent queue II". With this procedure it is guaranteed that prioritized connections do not crush the remaining data traffic.
- Secured
queue
This queue does not have a separate priority. However, packets in this
queue are never dropped (transmission guaranteed).
- Packets with ToS “High Reliability“
- Packets with DiffServ “Assured Forwarding“
- Standard queue The standard queue contains all not classified data traffic. Packets in this queue are dropped at first when packets cannot be delivered fast enough.
The queue concept can, however, only work out when a “traffic congestion“ of data packets has been accumulated at the interface from LAN to the WAN. Such a congestion is created when the interface within the LANCOM can submit fewer data to the WAN than data are delivered in peak periods from the LAN. This is e.g. the case, if the interface to the WAN is an integrated ADSL interface with comparatively low transmission speed (“upstream”). The integrated ADSL modem automatically reports back to the LANCOM how many data packets it is still able to receive, and thus brakes the data stream already within the router. As a result, the queues will automatically fill up.
Different is the case, if an Ethernet interface represents the connection to the WAN. From the LANCOM’s point of view, the connection to the Internet via an external broadband modem looks like an Ethernet segment. On the distance from the LANCOM to the DSL modem, data will be transferred with full LAN speed of 10 or 100 Mbps. Because of an equal input and output speed, no natural congestion will be produced then. Furthermore, the Ethernet between the LANCOM and the broadband modem does not report anything about the capacity of the connection. The consequence: a congestion will only be happen within the broadband modem. But because no queues are deployed therein, surplus data will be lost. Thus a prioritization of “preferred” data is not possible!
To solve this problem, the transfer rate of the LANCOM’s WAN interface will be reduced artificially. This interface will thereby be adjusted to the transfer rate that is available for the actual data transport towards the WAN. For a standard DSL connection, the DSL interface is thus adjusted in the LANCOM to the appropriate upstream rate (e.g. 128 kbps).
Data rates indicated by providers are mostly likely net rates. The gross data rate, which is available for the interface is a little bit higher than the net data rate guaranteed by the provider. If you know the gross data rate of your provider, you can enter this value for the interface and slightly increase in this way the data throughput. However, with entering the net data rate you play safe in any case!