Seminar Sparkz Inc

1. Source Quench Messages: Traditionally, Source Quench messages are the only ECN mechanism in the TCP/IP networks. However, Source Quench messages are rarely used in the current Internet. RFC 1009 required routers to generate Source Quench messages when they run out of buffers, the current draft on requirements for routers specifies that a router shouldn't originate Source Quench messages and a router that does originate source Quench message should limit the rate at which they are generated. The reasons why Source Quench messages are not used are because of the following problems
   
   
   
• It is not a general solution, particularly for multicast. Some connections have receiver-based congestion control instead of sender-based congestion control. (And in addition, one would not like to have a "Source Quench" implosion in a multicast tree.)
• Source Quench packets can be dropped, so they are not reliable.
• Even if well done, Source Quench packets add traffic in the reverse direction on what might be a congested path. While there are some applications/environments where it might be highly advantageous for the sender to receive some indication of congestion without having to wait a round-trip time, this is not the common case.
2. DECbit congestion avoidance scheme: In the DECbit congestion avoidance scheme, the gateway uses a congestion-­notification bit in packet headers to provide feedback about congestion in the network. When a packet arrives at the gateway, the gateway calculates the average queue length. When the average queue size at the gateway exceeds one(for that particular source), the gateway sets the ECN bit in the packet header of arriving packets. The source uses window flow control, and updates its window once every two roundtrip times. If at least half of the packets in the last window had the ECN bit set, then the congestion window is decreased multiplicatively. Otherwise, the congestion window is increased additively.
    
3. A range of ECN based rate­based congestion control schemes have been proposed for use within ATM networks. These include proposals both for Forward ECN (FECN) and for Backward ECN (BECN).

• As we have seen above, it works only when duration of congestion is greater than one Round-trip time.
• It accommodates migration so that ECN can be adopted gradually. Both routers and end-nodes may not be ECN capable.
• It also assumes that asymmetric routing is likely to be a normal occurrence in the Internet. The path followed by data packets may be different from the path followed by the acknowledgment packets.
• Not all end systems may cooperate in the congestion control mechanisms. The new mechanism is made such that the benefit of lying about participating in the new mechanism should be small. That is one user should not get undue benefits by advertising that it is participating in ECN control while it is actually not participating.

• Estimation of Average Queue Size
• Packet Drop Decision: In the second portion of the algorithm, RED decides whether or not to drop an incoming packet. It is RED's particular algorithm for dropping that results in performance improvement for responsive flows. Two RED parameters, minth (minimum threshold) and maxth (maximum threshold), figure prominently in this decision process. Minth specifies the average queue size below which no packets will be dropped, while maxth specifies the average queue size above which all packets will be dropped. As the average queue size varies from minth to maxth, packets will be dropped with a probability that varies linearly from 0 to maxp (maximum probability of dropping a packet).

• Non-compliance by end nodes: In fact, Internet is no longer a very closely-knit community as it was when it first came up. It may be possible that the end nodes may not respond to received packets with CE bit set. This can result in both unfairness and "congestion collapse" in the Internet. The unfairness is because of bandwidth starvation can inflict on well-behaved responsive traffic. The dangers of congestion collapse stems from a network busy transmitting packets before reaching the final destination. A node may set the ECT bit in its packets so that his packets are marked and not dropped, but he will not do any congestion control when he receives a packet with CE bit set. However, this is a problem in normal TCP also. A node may not reduce its congestion window in response to a packet drop and quietly keep on re-sending the dropped packets. It has been argued that ECN mark packets only when the congestion levels are low. It obviously drops packets when average queue size levels are above a limit. Moreover, handling unfavorable flows is a field of current research, and ECN doesn't hamper the deployment of mechanisms to restrict non-compliant flows. In fact, ECN would in fact help in detecting some unresponsive flows. For example, a router can monitor packets and keep track of congestion that has occurred earlier in the network.
• Non compliance in the Network: There are three main issues relating to loss of information in the network.

1. Encapsulated Packets: Some care must be taken when encapsulating and de-encapsulating headers, so that correct information can flow to subsequent routers and the destination. For example, when de-encapsulating the packet, the router must ensure that the CE bit is the "or" of the inner header and the outer header.
2. IPsec Tunnel Considerations: The IPsec protocol doesn't contain doesn't contain the IP header's ECN field in any of its cryptographic calculations (in the case of tunnel mode, the outer IP header's ECN field is not included). Hence modification of the ECN field by a network node has no effect on IPsec's end-to-end security, because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an adversary's modification of the ECN field. The adversary can do the following
• Erase Congestion indication
• Falsely report congestion
• Disable ECN capability
• Falsely indicate ECN capability
3. Dropped or Corrupted Packets: If a CE packet is dropped in a subsequent router, then there is no problem as the dropped packet would be detected and appropriate action taken. However, if a pure ACK packet is dropped, then there is no way a node can detect it. However, the current ECN mechanism doesn't set the ECT bit in pure ACK packets and it is a subject of future research.
    

1. The proposal's congestion notification is coupled to the transport layer (TCP) via the use of header information (ECE bit). To extend this proposal to other transport protocols will require changes to each of their respective headers.
2. The proposed scheme requires the congestion notification to incur a round trip time (RTT) before the sender can react. In a path with high delay-bandwidth product this would be problematic for two reasons:
• In the scenario where the delay-bandwidth product is dominated mostly by the high bandwidth (for example, high-speed networks), a large amount of traffic will pass through the intermediate routers causing an increase in congestion level before the sender is notified.
• In the scenario where the delay-bandwidth product is dominated mostly by the high latency/RTT (as in satellite networks), the reaction will take too long to address the congestion issue.

3. Because of the binary nature of the feedback, the reaction is limited to halving the window size even if the congestion level is very low. Network resources could be more effectively utilized if the feedback was indicative of the congestion level at the overloaded point in the network.

• ICMP Source Quench messages (ISQ) are generated by the intermediate congested RED router and sent back to the source as an indication of incipient congestion whenever that router decides to mark the CE bit.
• ISQs are usually not generated for a packet that has already been marked previously by another router regardless of whether that packet is contributing to some congestion.
• However, when the router queue level mandates that the packet be dropped then an ISQ is sent back to the source regardless of whether the packet was marked previously or not.
• The source reacts at the transport protocol level by lowering its data throughput into the network. For example, in TCP, upon identifying the flow causing the congestion, the sender reacts by halving both the congestion window and the slow start threshold value for that flow.

• CPU wastage: They consume a lot of resources at the router that has to generate these messages.
• Bandwidth Consumption in the reverse path: This will be especially problematic if there is congestion in the reverse path or the frequency of generation of ISQs is very high.

• Less time to react to congestion.
• CPU is no longer a constraint today and the benefits of having less packets being retransmitted will ameliorate the effect of CPU wastage at the routers.
• As RED is being used at the routers, there will be fewer packets dropped than in the tail-drop scheme. Moreover using source quench messages will result in faster reaction time and this will result in fewer packet drops.
• Moreover, suppose there are multiple congested routers on the way. Then, at most two source quench messages can be sent to the router per packet. This is because a router can send a Source Quench message for a marked packet only if it is dropping the packet. Please note that the routers don't send ISQs for non-ECN capable packets that are dropped.

• Suppose congestion levels are from 1 to 100. Now if the packet is dropped, then the level is set to 100.
• If the packet is marked and not dropped, then the average queue size is between minth and maxth as we defined in RED algorithm above. Let the packet marking probability be Pb. Then level is calculated so that we get a value 1 on queue size = minth and a value 99 on queue size = maxth. It is calculated as follows

• If the congestion level is set to 100, then we know that packet has been dropped and the source has to retransmit the packet. It also reduces the congestion window and threshold by half.
• If the level in the ISQ message >= 50, then reduce the congestion window and threshold by half.
• If the level in the ISQ < 50, then the congestion window is reduced linearly by 1.

• The most important merit is that it reduces the job of explicit congestion indication to the network layer. We donot have to change the header of the Transport layer protocol.
• The sources can react to the congestion very fast, especially in case when congestion is experienced in routers which are close to the source.
• It also introduces the concept of Multilevel ECN so that source can react to congestion notification according to the congestion levels.
• The MECN variant is partial to routers closer to the source. The source will react to their congestion notification first rather than that of routers farther away.
• One of the nice things about the existing ECN scheme is that it can be integrated into reliable multicast protocols. With unicast, ECN is a win, but with reliable multicast, the improvement is likely to be that much greater because it removes or at least reduces the need to re-send different missing packets to different receivers. It's difficult to see how BECN can be used with multicast at all. In fact we may probably have to prohibit routers responding to multicast with a BECN message.

• The basic idea is same in both these schemes. Until explicitly conveyed, assume that the packet losses are due to errors on the link. Only upon the receipt of an ECN or Source Quench message, congestion control is done.
• One of the main problems in both the schemes is that problems will occur if the packets carrying the ECN flag is lost. Then the source will not get to know that congestion has occurred because it will assume that errors has occurred due to link errors. This will result in increased congestion in the path and it may lead to congestion collapse. The authors have suggested some remedies for this problem.
• One of them uses both Source Quench messages as well as WECN bit for detection of congestion.
• Other uses only ACK packets for telling the source that congestion has occured.

• It is one of the premises of WECN mechanism that all the end nodes in the experiment are WECN capable. Otherwise, congestion control would be invoked in response to packet loss whenever it is due to congestion or transmission errors. If the end node is not WECN capable, then normal congestion control algorithms have to be invoked.
• It is assumed that each node in the network can add WECN bit in the packets to indicate congestion once packet losses occur. This is a very big problem because this will leave no scope for transitional schemes. Moreover, it also results in decreased robustness of the scheme. This is because there is some problem with some router which doesnot participate in this scheme. Then the whole mechanism will break down.

• The TCP congestion window can only be reduced by Wireless-ECN message, which is set due to congestion losses.
• TCP should react to an ECN at most once per round-trip time. The sender would react to the subsequent ECN only after the outstanding data before the sender entered into loss recovery phase upon receiving the first W-CE bit have all been acknowledged.
• The bit 5 of the ECN flag has been described as the WECN echo flag. When TCP receives a W-CE data packet at the destination end-system, the TCP data receiver sets the ECN-Echo flag in the TCP header of the subsequent ACK packet.
• To provide robustness against the possibility of a dropped ACK packet carrying a Wireless-ECN-Echo flag, the TCP receiver must set the WECN-Echo flag in a series of ACK packets. The TCP receiver uses the CWR (Congestion Window Reduced) flag at the bit 8 of reserved field of TCP header to determine when to stop setting the WECN-Echo flag.
• As only one Wireless-ECN is required to be added in a router, the frequency of Wireless-ECN to be set in a congestion window will not exceed the number of total network nodes where packets must travel across. This could relieve the burden of providing interface facility between IP and TCP at the receiver side.

• Obviously, the source can be sure that congestion has occurred before it reacts to congestion. Hence unnecessary wastage of bandwidth is prevented.
• As it doesn't use RED, there is no need for the routers to deploy RED.
• One main problem in this scheme is that it assumes that all routers are WECN capable. This is a very big handicap. If any of the routers donot deploy WECN, this scheme will fail.
• Though it suggests some remedies, the scheme doesnot guarantee that the source will react to congestion. This is because WECN messages may be lost on the way.
• Another problem is that routers here does not use RED. Hence we do not get benefits of RED. Congestion is detected only when buffer size is greater than threshold.
• Hence we see that though the scheme is easy to deploy, it is not very versataile and robust. In my view, the second scheme seems to be better. It is described below.

• If the incoming message causes average queue size go above maximum threshold or causes buffer overflow, the packet is dropped and an ISQ then sent back to the source of the incoming packet.
• Otherwise, if the RED probability picks this packet then, if the ECT bit is set and the CE bit is not already marked then CE bit is marked.
• Else if RED chooses this packet and ECT bit is not set then, send an ISQ back and drop the packet.

• The scheme is very effective in decreasing the amount of Source Quench messages sent as the routers send Source Quench messages are sent only on dropping a packet. This will be very low especially when RED is deployed (only 1%-5%).
• The amount of work in deploying WECN is very low as RED is already installed in several routers. Also ICMP is mandatory to be deployed in all routers.
• Moreover, it makes effective use of the parameter W_max, so that even when WECN packets or ISQs are lost, congestion control can be done effectively.
• It also has the problem that routers have to be WECN capable.
• It also uses Source Quench messages, which increases traffic on the reverse path, which is an obvious disadvantage.
• It can take long to react to congestion if the ISQs or WECN packets are lost.

• Also it was found out that fairness in situations where all flows were ECN capable was also close to 1. This is expected since RED marks packets probabilistically.
• When experiments were carried out using both ECN and non-ECN flows, it was found out that the number of packets marked with ECN flows were almost equal to number of packets dropped for non-ECN flows. This is because RED marks packets probabilistically. However, ECN flows would still get some benefits as they react to congestion fast
• Hence, we can conclude that ECN brings no unfairness in the networks.

·  We model the bulk data as large amount of data being transferred as one way traffic from source to destination. Here, we compare RED without ECN with RED with ECN traffic. The performance of ECN for bulk data is shown in figures below.

• If the congestion levels are low, then ECN provides no obvious advantage over nonECN packets. This is expected, as there are no packet marks and drops at low loads.
• As congestion level increases, the relative advantage of ECN over nonECN increases but absolute advantage decreases (expected as most flows are competing for one resource).
• For the same traffic, when the probability was varied, the relative advantage of ECN increases with increasing maxp. This may be because as maxp increases, the number of packets marked increases. Hence source will react faster to congestion. However, in non-ECN traffic, the packets are dropped. Hence, the number of dropped packets increases. Hence goodput will decrease as number of retransmitted packets decrease.
• There were hardly any retransmissions for ECN traffic. The only exception was when maxp was low and congestion levels were high.
• In non-ECN traffic, there were hardly any timeouts. This shows the effectiveness of Fast Retransmit/Fast Recovery algorithms in case of bulk traffic. Here window is halved and hence reaction to congestion is same as that of ECN. But we have to retransmit the packet which results in some delay in case of nonECN traffic.The main benefit of ECN is less time in recovering from congestion(nonECN traffic retransmits the data).

• As congestion level increases, the relative advantage of ECN over non-ECN increases but absolute advantage decreases. This is same as bulk transfer and is expected.
• As above, when the probability was varied, the relative advantage of ECN increases with increasing maxp.
• As the transactional data size increases, ECN's relative advantage decreases. Hence TCP with ECN has a huge advantage when size of data transactions are small.

• It is seen that ECN effectively reduces packet delay, especially for interactive traffic like telnet.
• Without ECN, the network traffic is significantly affected by clock granularity, by the level of congestion, and by whether the RED gateway is using a dropping policy that is sensitive to packet size.
• With coarse timer (the granularity of the TCP clock is high), it has been shown that ECN significantly decreases delay. This may be because a number of links may wait for timer to expire, resulting in idle link time. This can be mitigated by ECN because here packets are not dropped, but they are marked. Hence they can know of congestion faster.
• Thus ECN is very effective for interactive traffic like telnet.

• There are less packet drops in ECN as the RED routers mark the packets instead of marking. Hence there is less retransmission and hence there is less traffic in the network. There is also an improvement in goodput(effective data rate seen by sender).

• This also implies that ECN will be useful in situations where we need reliability, but we want to avoid retransmissions.
• ECN avoids timeouts by getting faster notification ( this as opposed to Fast Retransmit/Recovery or timeouts in traditional TCPs). This implies greater time spent in error recovery. This also improves goodput.
• We have seen that ECN works very well in case the traffic is transactional and of smaller size. This is a characteristic of HTTP traffic, and hence it will work well in the Internet.
• It is very useful in networks where effectiveness of TCP retransmit timers is limited by coarseness of the clock. This is especially true in LANs where the RTT is low.

• One obvious disadvantage is that a non-compliant user can take undue advantage of ECN to get more bandwidth. This is obviously a problem, but non-compliant nodes are a problem in the Internet in general.
• If the packet with the ECN echo bit set is lost, then ECN behaves like normal TCP. However, the source sends multiple packets with ECN-echo field set. Then there is high probability that packets will be sent by
• Another problem is that it is not guaranteed to be compliant with previous uses of the TOS headers. This may cause some problems. There has to be several changes made in IP to adapt to ECN. Here, incremental deployment is a plus point.

• Hence we can conclude by saying that deploying ECN can effectively help in congestion control in the Internet, even though it has few problems.