- "Nam Dinh Province: 207,323,835,000 VND" [39]
- "Hanoi City: 11,677,340,567,000 VND" [37]
- The amount of money to be executed is 56.3 times.
Comparing the workload in the 2015 working year of the Department of Natural Resources and Environment of My Loc district - Nam Dinh province and the Department of Natural Resources and Environment of Thanh Xuan district, Hanoi city as follows:
Total work to be done:
- "My Loc District Civil Judgment Enforcement Office: 189 cases" [20]
- "Thanh Xuan District Civil Judgment Enforcement Office: 1,341 cases" [36]
- The ratio of the work to be performed by Thanh Xuan unit/My Loc unit: 7.09 times. Total amount to be performed:
- "My Loc District Civil Judgment Enforcement Office: 3,796,379,000 VND" [20]
- "Thanh Xuan District Civil Judgment Enforcement Office: 1,525,966,491,000 VND" [36]
- Thanh Xuan/My Loc's enforcement ratio: 401 times.
For district-level units of Hanoi city, due to geographical characteristics and uneven economic and social development, there is a huge difference in the number of tasks and values to be performed between units.
Table 2 : Comparison of the number of cases and value to be executed between the two district-level enforcement units in 2014 and 2015.
STT
Branch THADS | 2014 | 2015 | |||
Job | Value (1000 VND) | Job | Value (1000 VND) | ||
1 | Thanh Xuan District (A) | 1,424 | 414,846,511 | 1,341 | 1,525,966,491 |
2 | Thanh Oai District (B) | 457 | 58,516,705 | 613 | 67,874,467 |
A/B Comparison | 3.1 times | 7.09 times | 2.18 times | 22.48 times | |
Maybe you are interested!
-
Comparison of Total Number of Cases and Total Number of Defendants Brought to Trial by the Court Regarding Articles 289, 290 and 291 of the Penal Code During a 5-Year Period (2008 - 2012) -
![Qos Assurance Methods for Multimedia Communications
zt2i3t4l5ee
zt2a3gs
zt2a3ge
zc2o3n4t5e6n7ts
low. The EF PHB requires a sufficiently large number of output ports to provide low delay, low loss, and low jitter.
EF PHBs can be implemented if the output ports bandwidth is sufficiently large, combined with small buffer sizes and other network resources dedicated to EF packets, to allow the routers service rate for EF packets on an output port to exceed the arrival rate λ of packets at that port.
This means that packets with PHB EF are considered with a pre-allocated amount of output bandwidth and a priority that ensures minimum loss, minimum delay and minimum jitter before being put into operation.
PHB EF is suitable for channel simulation, leased line simulation, and real-time services such as voice, video without compromising on high loss, delay and jitter values.
Figure 2.10 Example of EF installation
Figure 2.10 shows an example of an EF PHB implementation. This is a simple priority queue scheduling technique. At the edges of the DS domain, EF packet traffic is prioritized according to the values agreed upon by the SLA. The EF queue in the figure needs to output packets at a rate higher than the packet arrival rate λ. To provide an EF PHB over an end-to-end DS domain, bandwidth at the output ports of the core routers needs to be allocated in advance to ensure the requirement μ > λ. This can be done by a pre-configured provisioning process. In the figure, EF packets are placed in the priority queue (the upper queue). With such a length, the queue can operate with μ > λ.
Since EF was primarily used for real-time services such as voice and video, and since real-time services use UDP instead of TCP, RED is generally
not suitable for EF queues because applications using UDP will not respond to random packet drop and RED will strip unnecessary packets.
2.2.4.2 Assured Forwarding (AF) PHB
PHB AF is defined by RFC 2597. The purpose of PHB AF is to deliver packets reliably and therefore delay and jitter are considered less important than packet loss. PHB AF is suitable for non-real-time services such as applications using TCP. PHB AF first defines four classes: AF1, AF2, AF3, AF4. For each of these AF classes, packets are then classified into three subclasses with three distinct priority levels.
Table 2.8 shows the four AF classes and 12 AF subclasses and the DSCP values for the 12 AF subclasses defined by RFC 2597. RFC 2597 also allows for more than three separate priority levels to be added for internal use. However, these separate priority levels will only have internal significance.
PHB Class
PHB Subclass
Package type
DSCP
AF4
AF41
Short
100010
AF42
Medium
100100
AF43
High
100110
AF3
AF31
Short
011010
AF32
Medium
011100
AF33
High
011110
AF2
AF21
Short
010010
AF22
Medium
010100
AF23
High
010110
AF1
AF11
Short
001010
AF12
Medium
001100
AF13
High
001110
Table 2.8 AF DSCPs
The AF PHB ensures that packets are forwarded with a high probability of delivery to the destination within the bounds of the rate agreed upon in an SLA. If AF traffic at an ingress port exceeds the pre-priority rate, which is considered non-compliant or “out of profile”, the excess packets will not be delivered to the destination with the same probability as the packets belonging to the defined traffic or “in profile” packets. When there is network congestion, the out of profile packets are dropped before the in profile packets are dropped.
When service levels are defined using AF classes, different quantity and quality between AF classes can be realized by allocating different amounts of bandwidth and buffer space to the four AF classes. Unlike
EF, most AF traffic is non-real-time traffic using TCP, and the RED queue management strategy is an AQM (Adaptive Queue Management) strategy suitable for use in AF PHBs. The four AF PHB layers can be implemented as four separate queues. The output port bandwidth is divided into four AF queues. For each AF queue, packets are marked with three “colors” corresponding to three separate priority levels.
In addition to the 32 DSCP 1 groups defined in Table 2.8, 21 DSCPs have been standardized as follows: one for PHB EF, 12 for PHB AF, and 8 for CSCP. There are 11 DSCP 1 groups still available for other standards.
2.2.5.Example of Differentiated Services
We will look at an example of the Differentiated Service model and mechanism of operation. The architecture of Differentiated Service consists of two basic sets of functions:
Edge functions: include packet classification and traffic conditioning. At the inbound edge of the network, incoming packets are marked. In particular, the DS field in the packet header is set to a certain value. For example, in Figure 2.12, packets sent from H1 to H3 are marked at R1, while packets from H2 to H4 are marked at R2. The labels on the received packets identify the service class to which they belong. Different traffic classes receive different services in the core network. The RFC definition uses the term behavior aggregate rather than the term traffic class. After being marked, a packet can be forwarded immediately into the network, delayed for a period of time before being forwarded, or dropped. We will see that there are many factors that affect how a packet is marked, and whether it is forwarded immediately, delayed, or dropped.
Figure 2.12 DiffServ Example
Core functionality: When a DS-marked packet arrives at a Diffservcapable router, the packet is forwarded to the next router based on
Per-hop behavior is associated with packet classes. Per-hop behavior affects router buffers and the bandwidth shared between competing classes. An important principle of the Differentiated Service architecture is that a routers per-hop behavior is based only on the packets marking or the class to which it belongs. Therefore, if packets sent from H1 to H3 as shown in the figure receive the same marking as packets from H2 to H4, then the network routers treat the packets exactly the same, regardless of whether the packet originated from H1 or H2. For example, R3 does not distinguish between packets from h1 and H2 when forwarding packets to R4. Therefore, the Differentiated Service architecture avoids the need to maintain router state about separate source-destination pairs, which is important for network scalability.
Chapter Conclusion
Chapter 2 has presented and clarified two main models of deploying and installing quality of service in IP networks. While the traditional best-effort model has many disadvantages, later models such as IntServ and DiffServ have partly solved the problems that best-effort could not solve. IntServ follows the direction of ensuring quality of service for each separate flow, it is built similar to the circuit switching model with the use of the RSVP resource reservation protocol. IntSer is suitable for services that require fixed bandwidth that is not shared such as VoIP services, multicast TV services. However, IntSer has disadvantages such as using a lot of network resources, low scalability and lack of flexibility. DiffServ was born with the idea of solving the disadvantages of the IntServ model.
DiffServ follows the direction of ensuring quality based on the principle of hop-by-hop behavior based on the priority of marked packets. The policy for different types of traffic is decided by the administrator and can be changed according to reality, so it is very flexible. DiffServ makes better use of network resources, avoiding idle bandwidth and processing capacity on routers. In addition, the DifServ model can be deployed on many independent domains, so the ability to expand the network becomes easy.
Chapter 3: METHODS TO ENSURE QoS FOR MULTIMEDIA COMMUNICATIONS
In packet-switched networks, different packet flows often have to share the transmission medium all the way to the destination station. To ensure the fair and efficient allocation of bandwidth to flows, appropriate serving mechanisms are required at network nodes, especially at gateways or routers, where many different data flows often pass through. The scheduler is responsible for serving packets of the selected flow and deciding which packet will be served next. Here, a flow is understood as a set of packets belonging to the same priority class, or originating from the same source, or having the same source and destination addresses, etc.
In normal state when there is no congestion, packets will be sent as soon as they are delivered. In case of congestion, if QoS assurance methods are not applied, prolonged congestion can cause packet drops, affecting service quality. In some cases, congestion is prolonged and widespread in the network, which can easily lead to the network being frozen, or many packets being dropped, seriously affecting service quality.
Therefore, in this chapter, in sections 3.2 and 3.3, we introduce some typical network traffic load monitoring techniques to predict and prevent congestion before it occurs through the measure of dropping (removing) packets early when there are signs of impending congestion.
3.1. DropTail method
DropTail is a simple, traditional queue management method based on FIFO mechanism. All incoming packets are placed in the queue, when the queue is full, the later packets are dropped.
Due to its simplicity and ease of implementation, DropTail has been used for many years on Internet router systems. However, this algorithm has the following disadvantages:
− Cannot avoid the phenomenon of “Lock out”: Occurs when 1 or several traffic streams monopolize the queue, making packets of other connections unable to pass through the router. This phenomenon greatly affects reliable transmission protocols such as TCP. According to the anti-congestion algorithm, when locked out, the TCP connection stream will reduce the window size and reduce the packet transmission speed exponentially.
− Can cause Global Synchronization: This is the result of a severe “Lock out” phenomenon. Some neighboring routers have their queues monopolized by a number of connections, causing a series of other TCP connections to be unable to pass through and simultaneously reducing the transmission speed. After those monopolized connections are temporarily suspended,
Once the queue is cleared, it takes a considerable amount of time for TCP connections to return to their original speed.
− Full Queue phenomenon: Data transmitted on the Internet often has an explosion, packets arriving at the router are often in clusters rather than in turn. Therefore, the operating mechanism of DropTail makes the queue easily full for a long period of time, leading to the average delay time of large packets. To avoid this phenomenon, with DropTail, the only way is to increase the routers buffer, this method is very expensive and ineffective.
− No QoS guarantee: With the DropTail mechanism, there is no way to prioritize important packets to be transmitted through the router earlier when all are in the queue. Meanwhile, with multimedia communication, ensuring connection and stable speed is extremely important and the DropTail algorithm cannot satisfy.
The problem of choosing the buffer size of the routers in the network is to “absorb” short bursts of traffic without causing too much queuing delay. This is necessary in bursty data transmission. The queue size determines the size of the packet bursts (traffic spikes) that we want to be able to transmit without being dropped at the routers.
In IP-based application networks, packet dropping is an important mechanism for indirectly reporting congestion to end stations. A solution that prevents router queues from filling up while reducing the packet drop rate is called dynamic queue management.
3.2. Random elimination method – RED
3.2.1 Overview
RED (Random Early Detection of congestion; Random Early Drop) is one of the first AQM algorithms proposed in 1993 by Sally Floyd and Van Jacobson, two scientists at the Lawrence Berkeley Laboratory of the University of California, USA. Due to its outstanding advantages compared to previous queue management algorithms, RED has been widely installed and deployed on the Internet.
The most fundamental point of their work is that the most effective place to detect congestion and react to it is at the gateway or router.
Source entities (senders) can also do this by estimating end-to-end delay, throughput variability, or the rate of packet retransmissions due to drop. However, the sender and receiver view of a particular connection cannot tell which gateways on the network are congested, and cannot distinguish between propagation delay and queuing delay. Only the gateway has a true view of the state of the queue, the link share of the connections passing through it at any given time, and the quality of service requirements of the
traffic flows. The RED gateway monitors the average queue length, which detects early signs of impending congestion (average queue length exceeding a predetermined threshold) and reacts appropriately in one of two ways:
− Drop incoming packets with a certain probability, to indirectly inform the source of congestion, the source needs to reduce the transmission rate to keep the queue from filling up, maintaining the ability to absorb incoming traffic spikes.
− Mark “congestion” with a certain probability in the ECN field in the header of TCP packets to notify the source (the receiving entity will copy this bit into the acknowledgement packet).
Figure 3. 1 RED algorithm
The main goal of RED is to avoid congestion by keeping the average queue size within a sufficiently small and stable region, which also means keeping the queuing delay sufficiently small and stable. Achieving this goal also helps: avoid global synchronization, not resist bursty traffic flows (i.e. flows with low average throughput but high volatility), and maintain an upper bound on the average queue size even in the absence of cooperation from transport layer protocols.
To achieve the above goals, RED gateways must do the following:
− The first is to detect congestion early and react appropriately to keep the average queue size small enough to keep the network operating in the low latency, high throughput region, while still allowing the queue size to fluctuate within a certain range to absorb short-term fluctuations. As discussed above, the gateway is the most appropriate place to detect congestion and is also the most appropriate place to decide which specific connection to report congestion to.
− The second thing is to notify the source of congestion. This is done by marking and notifying the source to reduce traffic. Normally the RED gateway will randomly drop packets. However, if congestion
If congestion is detected before the queue is full, it should be combined with packet marking to signal congestion. The RED gateway has two options: drop or mark; where marking is done by marking the ECN field of the packet with a certain probability, to signal the source to reduce the traffic entering the network.
− An important goal that RED gateways need to achieve is to avoid global synchronization and not to resist traffic flows that have a sudden characteristic. Global synchronization occurs when all connections simultaneously reduce their transmission window size, leading to a severe drop in throughput at the same time. On the other hand, Drop Tail or Random Drop strategies are very sensitive to sudden flows; that is, the gateway queue will often overflow when packets from these flows arrive. To avoid these two phenomena, gateways can use special algorithms to detect congestion and decide which connections will be notified of congestion at the gateway. The RED gateway randomly selects incoming packets to mark; with this method, the probability of marking a packet from a particular connection is proportional to the connections shared bandwidth at the gateway.
− Another goal is to control the average queue size even without cooperation from the source entities. This can be done by dropping packets when the average size exceeds an upper threshold (instead of marking it). This approach is necessary in cases where most connections have transmission times that are less than the round-trip time, or where the source entities are not able to reduce traffic in response to marking or dropping packets (such as UDP flows).
3.2.2 Algorithm
This section describes the algorithm for RED gateways. RED gateways calculate the average queue size using a low-pass filter. This average queue size is compared with two thresholds: minth and maxth. When the average queue size is less than the lower threshold, no incoming packets are marked or dropped; when the average queue size is greater than the upper threshold, all incoming packets are dropped. When the average queue size is between minth and maxth, each incoming packet is marked or dropped with a probability pa, where pa is a function of the average queue size avg; the probability of marking or dropping a packet for a particular connection is proportional to the bandwidth share of that connection at the gateway. The general algorithm for a RED gateway is described as follows: [5]
For each packet arrival
Caculate the average queue size avg If minth ≤ avg < maxth
div.maincontent .s1 { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 15pt; }
div.maincontent .s2 { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 15pt; }
div.maincontent .p { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 14pt; margin:0pt; }
div.maincontent p { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 14pt; margin:0pt; }
div.maincontent .s3 { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 14pt; }
div.maincontent .s4 { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 14pt; }
div.maincontent .s5 { color: black; font-family:Times New Roman, serif; font-style: italic; font-weight: normal; text-decoration: none; font-size: 14pt; }
div.maincontent .s6 { color: black; font-family:Times New Roman, serif; font-style: italic; font-weight: bold; text-decoration: none; font-size: 14pt; }
div.maincontent .s7 { color: black; font-family:Wingdings; font-style: normal; font-weight: normal; text-decoration: none; font-size: 14pt; }
div.maincontent .s8 { color: black; font-family:Arial, sans-serif; font-style: italic; font-weight: bold; text-decoration: none; font-size: 15pt; }
div.maincontent .s9 { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 14pt; }
div.maincontent .s10 { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 9pt; vertical-align: 6pt; }
div.maincontent .s11 { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 13pt; }
div.maincontent .s12 { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 10pt; }
div.maincontent .s13 { color: black; font-family:Times New Roman, serif; font-style: normal; font-weight: normal; text-d](https://tailieuthamkhao.com/uploads/2022/05/15/danh-gia-hieu-qua-dam-bao-qos-cho-truyen-thong-da-phuong-tien-cua-chien-6-1-120x90.jpg)
Qos Assurance Methods for Multimedia Communications
zt2i3t4l5ee
zt2a3gs
zt2a3ge
zc2o3n4t5e6n7ts
low. The EF PHB requires a sufficiently large number of output ports to provide low delay, low loss, and low jitter.
EF PHBs can be implemented if the output port's bandwidth is sufficiently large, combined with small buffer sizes and other network resources dedicated to EF packets, to allow the router's service rate for EF packets on an output port to exceed the arrival rate λ of packets at that port.
This means that packets with PHB EF are considered with a pre-allocated amount of output bandwidth and a priority that ensures minimum loss, minimum delay and minimum jitter before being put into operation.
PHB EF is suitable for channel simulation, leased line simulation, and real-time services such as voice, video without compromising on high loss, delay and jitter values.
Figure 2.10 Example of EF installation
Figure 2.10 shows an example of an EF PHB implementation. This is a simple priority queue scheduling technique. At the edges of the DS domain, EF packet traffic is prioritized according to the values agreed upon by the SLA. The EF queue in the figure needs to output packets at a rate higher than the packet arrival rate λ. To provide an EF PHB over an end-to-end DS domain, bandwidth at the output ports of the core routers needs to be allocated in advance to ensure the requirement μ > λ. This can be done by a pre-configured provisioning process. In the figure, EF packets are placed in the priority queue (the upper queue). With such a length, the queue can operate with μ > λ.
Since EF was primarily used for real-time services such as voice and video, and since real-time services use UDP instead of TCP, RED is generally
not suitable for EF queues because applications using UDP will not respond to random packet drop and RED will strip unnecessary packets.
2.2.4.2 Assured Forwarding (AF) PHB
PHB AF is defined by RFC 2597. The purpose of PHB AF is to deliver packets reliably and therefore delay and jitter are considered less important than packet loss. PHB AF is suitable for non-real-time services such as applications using TCP. PHB AF first defines four classes: AF1, AF2, AF3, AF4. For each of these AF classes, packets are then classified into three subclasses with three distinct priority levels.
Table 2.8 shows the four AF classes and 12 AF subclasses and the DSCP values for the 12 AF subclasses defined by RFC 2597. RFC 2597 also allows for more than three separate priority levels to be added for internal use. However, these separate priority levels will only have internal significance.
PHB Class
PHB Subclass
Package type
DSCP
AF4
AF41
Short
100010
AF42
Medium
100100
AF43
High
100110
AF3
AF31
Short
011010
AF32
Medium
011100
AF33
High
011110
AF2
AF21
Short
010010
AF22
Medium
010100
AF23
High
010110
AF1
AF11
Short
001010
AF12
Medium
001100
AF13
High
001110
Table 2.8 AF DSCPs
The AF PHB ensures that packets are forwarded with a high probability of delivery to the destination within the bounds of the rate agreed upon in an SLA. If AF traffic at an ingress port exceeds the pre-priority rate, which is considered non-compliant or “out of profile”, the excess packets will not be delivered to the destination with the same probability as the packets belonging to the defined traffic or “in profile” packets. When there is network congestion, the out of profile packets are dropped before the in profile packets are dropped.
When service levels are defined using AF classes, different quantity and quality between AF classes can be realized by allocating different amounts of bandwidth and buffer space to the four AF classes. Unlike
EF, most AF traffic is non-real-time traffic using TCP, and the RED queue management strategy is an AQM (Adaptive Queue Management) strategy suitable for use in AF PHBs. The four AF PHB layers can be implemented as four separate queues. The output port bandwidth is divided into four AF queues. For each AF queue, packets are marked with three “colors” corresponding to three separate priority levels.
In addition to the 32 DSCP 1 groups defined in Table 2.8, 21 DSCPs have been standardized as follows: one for PHB EF, 12 for PHB AF, and 8 for CSCP. There are 11 DSCP 1 groups still available for other standards.
2.2.5.Example of Differentiated Services
We will look at an example of the Differentiated Service model and mechanism of operation. The architecture of Differentiated Service consists of two basic sets of functions:
Edge functions: include packet classification and traffic conditioning. At the inbound edge of the network, incoming packets are marked. In particular, the DS field in the packet header is set to a certain value. For example, in Figure 2.12, packets sent from H1 to H3 are marked at R1, while packets from H2 to H4 are marked at R2. The labels on the received packets identify the service class to which they belong. Different traffic classes receive different services in the core network. The RFC definition uses the term behavior aggregate rather than the term traffic class. After being marked, a packet can be forwarded immediately into the network, delayed for a period of time before being forwarded, or dropped. We will see that there are many factors that affect how a packet is marked, and whether it is forwarded immediately, delayed, or dropped.
Figure 2.12 DiffServ Example
Core functionality: When a DS-marked packet arrives at a Diffservcapable router, the packet is forwarded to the next router based on
Per-hop behavior is associated with packet classes. Per-hop behavior affects router buffers and the bandwidth shared between competing classes. An important principle of the Differentiated Service architecture is that a router's per-hop behavior is based only on the packet's marking or the class to which it belongs. Therefore, if packets sent from H1 to H3 as shown in the figure receive the same marking as packets from H2 to H4, then the network routers treat the packets exactly the same, regardless of whether the packet originated from H1 or H2. For example, R3 does not distinguish between packets from h1 and H2 when forwarding packets to R4. Therefore, the Differentiated Service architecture avoids the need to maintain router state about separate source-destination pairs, which is important for network scalability.
Chapter Conclusion
Chapter 2 has presented and clarified two main models of deploying and installing quality of service in IP networks. While the traditional best-effort model has many disadvantages, later models such as IntServ and DiffServ have partly solved the problems that best-effort could not solve. IntServ follows the direction of ensuring quality of service for each separate flow, it is built similar to the circuit switching model with the use of the RSVP resource reservation protocol. IntSer is suitable for services that require fixed bandwidth that is not shared such as VoIP services, multicast TV services. However, IntSer has disadvantages such as using a lot of network resources, low scalability and lack of flexibility. DiffServ was born with the idea of solving the disadvantages of the IntServ model.
DiffServ follows the direction of ensuring quality based on the principle of hop-by-hop behavior based on the priority of marked packets. The policy for different types of traffic is decided by the administrator and can be changed according to reality, so it is very flexible. DiffServ makes better use of network resources, avoiding idle bandwidth and processing capacity on routers. In addition, the DifServ model can be deployed on many independent domains, so the ability to expand the network becomes easy.
Chapter 3: METHODS TO ENSURE QoS FOR MULTIMEDIA COMMUNICATIONS
In packet-switched networks, different packet flows often have to share the transmission medium all the way to the destination station. To ensure the fair and efficient allocation of bandwidth to flows, appropriate serving mechanisms are required at network nodes, especially at gateways or routers, where many different data flows often pass through. The scheduler is responsible for serving packets of the selected flow and deciding which packet will be served next. Here, a flow is understood as a set of packets belonging to the same priority class, or originating from the same source, or having the same source and destination addresses, etc.
In normal state when there is no congestion, packets will be sent as soon as they are delivered. In case of congestion, if QoS assurance methods are not applied, prolonged congestion can cause packet drops, affecting service quality. In some cases, congestion is prolonged and widespread in the network, which can easily lead to the network being "frozen", or many packets being dropped, seriously affecting service quality.
Therefore, in this chapter, in sections 3.2 and 3.3, we introduce some typical network traffic load monitoring techniques to predict and prevent congestion before it occurs through the measure of dropping (removing) packets early when there are signs of impending congestion.
3.1. DropTail method
DropTail is a simple, traditional queue management method based on FIFO mechanism. All incoming packets are placed in the queue, when the queue is full, the later packets are dropped.
Due to its simplicity and ease of implementation, DropTail has been used for many years on Internet router systems. However, this algorithm has the following disadvantages:
− Cannot avoid the phenomenon of “Lock out”: Occurs when 1 or several traffic streams monopolize the queue, making packets of other connections unable to pass through the router. This phenomenon greatly affects reliable transmission protocols such as TCP. According to the anti-congestion algorithm, when locked out, the TCP connection stream will reduce the window size and reduce the packet transmission speed exponentially.
− Can cause Global Synchronization: This is the result of a severe “Lock out” phenomenon. Some neighboring routers have their queues monopolized by a number of connections, causing a series of other TCP connections to be unable to pass through and simultaneously reducing the transmission speed. After those monopolized connections are temporarily suspended,
Once the queue is cleared, it takes a considerable amount of time for TCP connections to return to their original speed.
− Full Queue phenomenon: Data transmitted on the Internet often has an explosion, packets arriving at the router are often in clusters rather than in turn. Therefore, the operating mechanism of DropTail makes the queue easily full for a long period of time, leading to the average delay time of large packets. To avoid this phenomenon, with DropTail, the only way is to increase the router's buffer, this method is very expensive and ineffective.
− No QoS guarantee: With the DropTail mechanism, there is no way to prioritize important packets to be transmitted through the router earlier when all are in the queue. Meanwhile, with multimedia communication, ensuring connection and stable speed is extremely important and the DropTail algorithm cannot satisfy.
The problem of choosing the buffer size of the routers in the network is to “absorb” short bursts of traffic without causing too much queuing delay. This is necessary in bursty data transmission. The queue size determines the size of the packet bursts (traffic spikes) that we want to be able to transmit without being dropped at the routers.
In IP-based application networks, packet dropping is an important mechanism for indirectly reporting congestion to end stations. A solution that prevents router queues from filling up while reducing the packet drop rate is called dynamic queue management.
3.2. Random elimination method – RED
3.2.1 Overview
RED (Random Early Detection of congestion; Random Early Drop) is one of the first AQM algorithms proposed in 1993 by Sally Floyd and Van Jacobson, two scientists at the Lawrence Berkeley Laboratory of the University of California, USA. Due to its outstanding advantages compared to previous queue management algorithms, RED has been widely installed and deployed on the Internet.
The most fundamental point of their work is that the most effective place to detect congestion and react to it is at the gateway or router.
Source entities (senders) can also do this by estimating end-to-end delay, throughput variability, or the rate of packet retransmissions due to drop. However, the sender and receiver view of a particular connection cannot tell which gateways on the network are congested, and cannot distinguish between propagation delay and queuing delay. Only the gateway has a true view of the state of the queue, the link share of the connections passing through it at any given time, and the quality of service requirements of the
traffic flows. The RED gateway monitors the average queue length, which detects early signs of impending congestion (average queue length exceeding a predetermined threshold) and reacts appropriately in one of two ways:
− Drop incoming packets with a certain probability, to indirectly inform the source of congestion, the source needs to reduce the transmission rate to keep the queue from filling up, maintaining the ability to absorb incoming traffic spikes.
− Mark “congestion” with a certain probability in the ECN field in the header of TCP packets to notify the source (the receiving entity will copy this bit into the acknowledgement packet).
Figure 3. 1 RED algorithm
The main goal of RED is to avoid congestion by keeping the average queue size within a sufficiently small and stable region, which also means keeping the queuing delay sufficiently small and stable. Achieving this goal also helps: avoid global synchronization, not resist bursty traffic flows (i.e. flows with low average throughput but high volatility), and maintain an upper bound on the average queue size even in the absence of cooperation from transport layer protocols.
To achieve the above goals, RED gateways must do the following:
− The first is to detect congestion early and react appropriately to keep the average queue size small enough to keep the network operating in the low latency, high throughput region, while still allowing the queue size to fluctuate within a certain range to absorb short-term fluctuations. As discussed above, the gateway is the most appropriate place to detect congestion and is also the most appropriate place to decide which specific connection to report congestion to.
− The second thing is to notify the source of congestion. This is done by marking and notifying the source to reduce traffic. Normally the RED gateway will randomly drop packets. However, if congestion
If congestion is detected before the queue is full, it should be combined with packet marking to signal congestion. The RED gateway has two options: drop or mark; where marking is done by marking the ECN field of the packet with a certain probability, to signal the source to reduce the traffic entering the network.
− An important goal that RED gateways need to achieve is to avoid global synchronization and not to resist traffic flows that have a sudden characteristic. Global synchronization occurs when all connections simultaneously reduce their transmission window size, leading to a severe drop in throughput at the same time. On the other hand, Drop Tail or Random Drop strategies are very sensitive to sudden flows; that is, the gateway queue will often overflow when packets from these flows arrive. To avoid these two phenomena, gateways can use special algorithms to detect congestion and decide which connections will be notified of congestion at the gateway. The RED gateway randomly selects incoming packets to mark; with this method, the probability of marking a packet from a particular connection is proportional to the connection's shared bandwidth at the gateway.
− Another goal is to control the average queue size even without cooperation from the source entities. This can be done by dropping packets when the average size exceeds an upper threshold (instead of marking it). This approach is necessary in cases where most connections have transmission times that are less than the round-trip time, or where the source entities are not able to reduce traffic in response to marking or dropping packets (such as UDP flows).
3.2.2 Algorithm
This section describes the algorithm for RED gateways. RED gateways calculate the average queue size using a low-pass filter. This average queue size is compared with two thresholds: minth and maxth. When the average queue size is less than the lower threshold, no incoming packets are marked or dropped; when the average queue size is greater than the upper threshold, all incoming packets are dropped. When the average queue size is between minth and maxth, each incoming packet is marked or dropped with a probability pa, where pa is a function of the average queue size avg; the probability of marking or dropping a packet for a particular connection is proportional to the bandwidth share of that connection at the gateway. The general algorithm for a RED gateway is described as follows: [5]
For each packet arrival
Caculate the average queue size avg If minth ≤ avg < maxth
div.maincontent .s1 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 15pt; }
div.maincontent .s2 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 15pt; }
div.maincontent .p { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 14pt; margin:0pt; }
div.maincontent p { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 14pt; margin:0pt; }
div.maincontent .s3 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 14pt; }
div.maincontent .s4 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 14pt; }
div.maincontent .s5 { color: black; font-family:"Times New Roman", serif; font-style: italic; font-weight: normal; text-decoration: none; font-size: 14pt; }
div.maincontent .s6 { color: black; font-family:"Times New Roman", serif; font-style: italic; font-weight: bold; text-decoration: none; font-size: 14pt; }
div.maincontent .s7 { color: black; font-family:Wingdings; font-style: normal; font-weight: normal; text-decoration: none; font-size: 14pt; }
div.maincontent .s8 { color: black; font-family:Arial, sans-serif; font-style: italic; font-weight: bold; text-decoration: none; font-size: 15pt; }
div.maincontent .s9 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 14pt; }
div.maincontent .s10 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 9pt; vertical-align: 6pt; }
div.maincontent .s11 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 13pt; }
div.maincontent .s12 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 10pt; }
div.maincontent .s13 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-d -
Comparison of Distribution by Number of Cesarean Sections Between Studies -
Procedure for Applying Law in Criminal Investigation Cases -
Applying the law in resolving marriage and family cases in Hanoi - 2
Source : [37], [38].
Through the table above, we can clearly see the huge difference between these two units, the number of jobs is 2-3 times larger and the value is 7-22 times larger.
2.2. Practical application of measures to enforce payment obligations in Hanoi city in 2015 - 2016
To evaluate the effectiveness of the application of regulations on compulsory enforcement of payment obligations under the Law on Civil Judgment Enforcement in Hanoi, the author conducted statistics on the number of compulsory enforcement cases applied at the Hanoi Civil Judgment Enforcement Department and some district-level civil judgment enforcement units.
2.2.1. Results of applying compulsory measures to enforce payment obligations at the Civil Judgment Enforcement Department of Hanoi City
Table 3: Statistics of survey results on the actual application of payment enforcement measures by the Hanoi City Department of Civil Judgment Enforcement in 2015-2016
Year
Number of cases of enforcement | Total | ||
Number of CC jobs not in use dynamic force | Number of CC jobs mobilized force | ||
2015 | 250 | 236 | 486 |
2106 | 546 | 364 | 910 |
Source : [38], [39].
2.2.2. Results of applying compulsory measures to enforce payment obligations at some district and county level units
Table 4. Statistics of the results of the actual survey on the application of measures to enforce payment obligations of some Hanoi City THADS Sub-Departments in 2016
(unit: work)
STT
Number of cases of enforcement | Total | |||
THA Department | Number of CC jobs no mobilization | Number of CC jobs mobilized | ||
1 | THA Department of Hai Ba Trung District | 12 | 1 | 13 |
2 | Cau Giay District THA Department | 49 | 1 | 50 |
3 | Ba Dinh District THA Department | 24 | 0 | 24 |
4 | Tay Ho District THA Branch | 11 | 4 | 15 |
Source : [12], [13], [14], [15], [16], [17], [18], [19].
Through the summary table of survey results on the application of compulsory measures to enforce payment obligations at some district-level THADS units in Hanoi, there are 03 compulsory measures that were not applied during the year:
Compulsory exploitation of assets to enforce judgments (Article 107).
Seizure, use and exploitation of intellectual property rights (Article 84).
Collect money from the business activities of the judgment debtor (Article 79).
The reason why the three enforcement measures mentioned above are not applied is not because the need to apply them does not arise in practice, but because the provisions of the law are lacking, leading to avoidance of applying these measures by the enforcement officers.
The number of cases requiring enforcement measures compared to the total number of cases requiring enforcement is not large. For example, in 2016, the Hanoi City Department of Civil Judgment Enforcement had to enforce 39,614 cases, but the total number of cases requiring enforcement was: 910 cases.
However, the role of enforcement should not be underestimated because the number of cases applying enforcement measures is small. At the Thanh Xuan District Civil Judgment Enforcement Unit in 2016, the total amount and value subject to enforcement was 459.2 billion, of which 01 case of compulsory seizure of assets to collect enforcement money was enforced.
21.5 billion. On the other hand, the fact that enforcement is rarely required proves that the application of voluntary enforcement measures by bailiffs in Thanh Xuan is very effective. In 2016, the Thanh Xuan District Enforcement Office only had to apply enforcement measures in 2 cases, but 906 cases were completed.
The application of compulsory measures to enforce payment obligations is common in developed socio-economic areas. For example, in 2016, the Department of Enforcement of Civil Judgments in Hoai Duc district had to enforce 135 cases, of which the Department of Enforcement of Civil Judgments in Thanh Tri district had to enforce 8 cases.
Through the survey, the application of compulsory measures to enforce payment obligations in Hanoi city only occurs mainly in civil, economic, and marriage and family cases, while in civil cases in criminal cases, it is usually only to handle the assets of the person who must pay the debt that have been seized by the investigation agency or the Court. Reason
The reason for the above phenomenon is that most people who are serving prison sentences do not have assets to apply coercive measures.
In summary, in Hanoi, the number of cases requiring compulsory payment enforcement measures is not common and accounts for a small proportion compared to the total number of cases eligible for enforcement. Only a few compulsory payment enforcement measures are regularly applied, such as deduction of money from accounts and seizure and auction of assets. Other compulsory measures are rarely applied, and there are some measures that are not applied, such as compulsory exploitation of assets for enforcement.
2.3. Measures to enforce payment obligations are commonly applied in Hanoi city.
2.3.1. Measures to deduct money from the judgment debtor's account
2.3.1.1. Overview of measures to enforce deduction of money from the judgment debtor's account
This enforcement measure was first prescribed in the 2004 THADS Ordinance. Previously, this measure was prescribed in the 1989 THADS Ordinance and the 1993 THADS Ordinance with the enforcement measure of Deducting money from the account and the person responsible for implementing the decision to deduct money of the CHV in this regulation when applying this measure is the bank or credit institution where the person subject to THA opens an account.
This measure is stipulated in Article 76 of the Law on Enforcement of Judgments as follows: "The enforcement officer shall issue a decision to deduct money from the account of the person subject to enforcement. The amount deducted must not exceed the obligation to enforce the judgment and the enforcement costs" [56].
To ensure the implementation of enforcement measures, the Law on THADS clearly stipulates the responsibilities of the State Treasury, banks and other credit institutions to coordinate with the enforcement officer in Article 176 as follows:
1. Provide correct, complete and timely information and data on the judgment debtor's account as requested by the Enforcement Officer and civil judgment enforcement agency.
2. Strictly and promptly implement the request of the Enforcement Officer regarding account freezing, asset freezing; deduction of money in the account; release of account freezing, asset freezing of the judgment debtor.
3. Fully comply with other requests of the Enforcement Officer and civil enforcement agencies as prescribed by this Law [56].
However, in practice, the Enforcement Officer must also use the provisions of Decree 70/2000/ND-CP dated November 21, 2000 of the Government on keeping secret, storing and providing information related to customers' deposits and assets to be able to apply this enforcement measure .
The priority of applying this measure comes from the fact that the procedure for applying this measure is quite simple, takes little time and often brings results immediately after issuing the Decision to deduct money from the account of the person subject to THA.
2.3.1.2. Practical application
As mentioned in Chapter 1, Hanoi is the second largest economic center in the country, so the development of the banking system and other credit institutions as well as the use of payment via accounts is very popular. On the other hand, as an important trading hub, businesses in Hanoi are quite common tax payers. For this reason, the measure of deducting money from the account is quite popular. In fact, if the tax payer is a business or organization, this is the first priority measure to be applied. Through a survey in 2015, the Hanoi Tax Department applied this measure 386 times and the amount collected was nearly 50 billion VND.
The difficulty in applying this measure in Hanoi is that there are too many banks in the area. Hanoi is the location of the headquarters and branches of all commercial banks in Vietnam and a large number of branches of foreign banks. Therefore, with a dense network of branches and transaction offices, the verification of accounts and available balances in the accounts of debtors by the Enforcement Officers has encountered many difficulties. In 2015, the Hanoi Department of Enforcement issued 386 Decisions to deduct money from accounts but still did not fully reflect the characteristics of this enforcement measure. Because in order to successfully apply this measure once, the Enforcement Officer must verify the available balances in the accounts of debtors at many banks.
Particularly, when working with foreign bank branches, due to limitations in understanding the laws of the host country, the provision of verification is often very slow because the leaders of these banks delay to wait for the opinion of the bank's legal department before providing the account balance of the person subject to THA. The THA agency itself is quite confused when having to work with foreign banks.
Currently, with the development of the stock market, it is quite common for individuals and organizations to open accounts to buy and sell stocks at securities companies. Hanoi is a locality with many securities companies, so the application of this enforcement measure according to the provisions of Article 76 to the accounts of the debtor is something that will happen. However, according to the provisions of Article 176, the responsibility to implement the request of the Enforcement Officer is only: State Treasury, banks and other credit institutions. According to the Law on Credit Institutions 2010, a securities company is not a type of credit institution. This will make it difficult to apply the law in practice.
We can learn about the application of this coercive measure through the following real case at the Department of Enforcement of Civil Judgments in Hanoi:
To enforce the judgment No. 125/2014/KDTM-ST dated September 28, 2014 of the Hanoi City Court, the Director of the Hanoi City Civil Judgment Enforcement Department issued Decision No. 397/QD.THA-CD dated March 2, 2015 and Decision No. 398/QD.THA-TD dated March 2, 2015. To enforce the following amounts: Construction Joint Stock Corporation must pay commercial business court fees - first instance: VND 128,469,000; Construction Joint Stock Corporation must pay the Vietnam Joint Stock Commercial Bank for Industry and Trade the amount of VND 20,469,120,765.
Through verification at the Transaction Office of the Joint Stock Commercial Bank for Foreign Trade of Vietnam, the Enforcement Officer was informed by the Bank that the Construction Joint Stock Corporation had opened an account with an available balance of VND 352,416,894 on April 19, 2015. The Enforcement Officer issued Decision No. 21/QD-THA dated April 19, 2015 to freeze the amount of VND 352,416,894 in the account of the Construction Joint Stock Corporation from 11:00 a.m. on April 19, 2015. And immediately delivered this decision to
Joint Stock Commercial Bank for Foreign Trade of Vietnam. Then, the Enforcement Officer issued Notice of THA No. 72/TB-THA dated April 19, 2015 informing the Construction Joint Stock Corporation to complete the execution of the above judgment within 5 days. If it does not voluntarily execute the judgment, the Enforcement Officer will apply the measure of deducting money from the account to execute the judgment. After the deadline according to the notice, the Enforcement Officer based on Article 76 of the Law on THADS issued a decision to deduct money from account No. 26/QD-THA dated April 26, 2015 with the content of requesting to transfer the amount of VND 351,000,000 from the account of the Construction Joint Stock Corporation at the Joint Stock Commercial Bank for Foreign Trade of Vietnam to the account of the Hanoi City Department of THADS. The Enforcement Officer based on Article 47 of the Law on THADS collected court fees and paid the remaining amount to the Vietnam Joint Stock Commercial Bank for Industry and Trade according to the THA decision.
Through this example, we see that within 7 days, the Enforcement Officer has applied a measure to secure the execution of judgment and a measure to enforce the deduction of money from the account of the person subject to judgment. As a result, the court fees and a part of the money to pay the person subject to judgment have been completed. However, the Law on Enforcement of Judgments does not stipulate in which cases enforcement measures must be applied, but account freezing measures cannot be applied. Therefore, in practice, to avoid complaints due to the application of enforcement measures, the Enforcement Officer is always cautious by applying a security measure first. This has invisibly slowed down the judgment enforcement process.
2.3.2. Measures to seize and auction assets
2.3.2.1. Overview of measures to seize and auction assets
a) Asset seizure
Asset seizure is a fairly common term in legal documents as well as in the practice of law enforcement, but few people know the definition of the term asset seizure. In the dictionary of common legal terms published by Ho Chi Minh City Publishing House in 1999, asset seizure is defined as recording each asset, prohibiting its dispersal or destruction, to ensure trial and enforcement.
In THADS activities, the term property seizure can be understood as a coercive measure carried out by the enforcement officer to calculate and record assets in a certain order for the purpose of performing obligations according to the THA decision.
Seizing assets of the THA is also understood as restricting the right to dispose of the assets of the person subject to THA to ensure THA.
In fact, the measure of property seizure is the most effective enforcement measure and brings the highest enforcement value among all measures of enforcement of payment obligations . Therefore, the Law on THADS 2008 (amended and supplemented in 2014) has inherited the provisions of the THADS Ordinance 2004 and Decree 173/2004/ND-CP dated September 30, 2004 of the Government regulating the procedures for enforcement and sanctioning administrative violations in THADS and Decree 164/2004/ND-CP dated September 14, 2004 of the Government on seizure and auction of land use rights to ensure THA. At the same time, many regulations have been added to resolve difficulties in the process of applying the 2004 THADS Ordinance. Due to the diversity of types of assets as well as the complexity of situations when organizing seizure, the THADS Law has specific regulations for each group of assets, such as seizure of land use rights as prescribed in Article 111 or seizure of locked and packaged objects as prescribed in Article 93.
The basic principles when seizing assets are:
All assets legally owned by the person subject to enforcement may be seized for enforcement (except assets that cannot be seized according to the provisions of law), including jointly owned assets, privately owned assets, and assets managed and used by a third party.
According to this principle, the scope of assets of the person subject to the judgment enforcement that can be seized is very broad, including all forms of assets from tangible to intangible assets and in many forms of ownership. Assets that cannot be seized according to the provisions of Article 87 of the Law on Civil Judgment Enforcement can be divided into three main groups as follows:
Group 1: Assets prohibited from circulation according to the provisions of law; assets serving national defense, security, public interests; assets allocated by the state budget to agencies and organizations.
Group 2 : Assets that cannot be seized when the person subject to the THA is an individual:
a) Amount of food to meet the essential needs of the person who must pay compensation and his/her family during the period when there is no new income or harvest;
b) The number of medicines needed to prevent and treat diseases of the person having to take THA and his family;
c) Necessary items for the disabled, items used to care for the sick;