M. Allman. TCP byte counting refinements. ACM Computer Communication Review, 29(3), July 1999.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....about the unicast sessions and requires minimal per flow information about the virtual sessions (which may be required for the successful implementation of multirate multicast) Such a scheme is well suited for Internet. Explicit Congestion Notification for flow control was first proposed in [3] and such a mechanism is highly desirable if we want the network to operate at low loss. We propose an easy to implement one bit ECN marking scheme to implement the congestion control algorithm. The receivers adapt their rates accordingly based on the marks received. For layered video, rate ....

S. Floyd. TCP and explicit congestion notification. ACM Computer Communication Review, 24:10--23, October 1994.

....sources. A related issue is to adapt TCP to accept new feedback from the routers, ensuring more stable performance and yet retaining complete backward compatibility. The first approach in the direction of router and TCP cooperation is the Explicit Congestion Notification (ECN) scheme proposed in [5, 6]. ECN is based on a binary feedback from routers to sources that triggers a window size reduction identical to that caused by the fast retransmit fast recovery mechanism of TCP Reno, yet without requiring the drop of a packet. ECN is effective in reducing packet loss. However, because of its ....

....of IP routers which advertise or the available bandwidth . The 6 TCP implementations are: TCP Reno and standard FCFS queuing IP routers, in the sequel named Drop Tail; TCP Reno and RED IP routers [29] named RED; TCP Reno with ECN (Explicit Congestion Notification) capabilities [5, 6] and tagging RED IP routers, named ECN; TCP Reno with GWA capabilities and per flow queuing, RR IP routers, named GWA RR; TCP Reno with GWA capabilities and FCFS queuing IP routers, named GWA FCFS; TCP Reno with Bandwidth Aware GWA capabilities; FCFS IP routers capable of measuring the ....

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, Vol. 24 No. 5, Pages 10-- 23, Oct. 1994.

....To cope with this lack of coordination among users and the unpredictability of congestion epochs, networks send congestion signals to users to help them share its resources in a fair and satisfactory fashion. For example, packets at a congested router may be either dropped or marked [5]. This work was supported by DARPA grant F30602 00 2 0598 and by a Stanford Graduate Fellowship. Preprint submitted to Elsevier Science 22 April 2002 A great deal of network congestion is not only caused by a lack of coordination, but also by users who aim to selfishly maximize the bandwidth ....

S. Floyd. Tcp and explicit congestion notification. ACM Computer Communication Review, 24(5):10--23, October 1994.

....accurate only in certain regimes. The shortcomings of these models suggest a need for a unified model that is accurate in all regimes, instead of being restricted to a specific regime. In this paper, we present a novel approach to modeling an ECN RED bottleneck with a large number of TCP flows [1], 2] Our model incorporates not only the interaction of congestion control mechanism of TCP with ECN RED mechanism, but also session dynamics and variable RTTs of the flows. It builds upon the approach used in [7] and [8] Such macroscale modeling of aggregate TCP flows can be developed by ....

....an idle period is geometrically distributed with parameter # ## and has a mean of ### ## . This attempts to capture the dynamics of connection arrivals, where the interarrival times are reported to be exponentially distributed [6] be a collection of i.i.d. rvs uniformly distributed on [0, 1] and ## # ## ##### ## # be the indicator function of the event that a new file object arrives in the timeslot ## #######for an idle session #. be a collection of i.i.d. non negative integer valued rvs with a general distribution function # . The workload of a connection of session # ....

S. Floyd. TCP and explicit congestion notification. ACM Computer Communication Review, 24:10--23, October 1994.

....not delivered in order. The inference of congestion from duplicate ACKs us no longer valid. Ramakrishnan and Jain s work in [8] which has been popularly called the DECbit scheme, uses a single bit in the network layer header to signal the congestion. The Explicit Congestion Notification (ECN) [9, 10], motivated by the DECbit scheme, provides a mechanism for intermediate routers to send early congestion feedback to the source before actual packet losses happen. The routers monitor their queue length. If the queue length exceeds a threshold, the router marks the Congestion Experienced bit in ....

S. Floyd, TCP and explicit congestion notification, ACM Computer Communication Review, V. 24 N. 5, pp. 10-23, October 1994.

....network s task is to simply notify the end systems whenever it detects congestion in the network. Congestion detection is based on the aggregate flow behavior at the router, and the end hosts are notified by simply dropping or by marking packets using the explicit congestion notification (ECN) bit [4]. The end host reacts to this information by decreasing its transmission rate, thus adapting to network congestion. In this manner, end to end control is maintained using only minimal network resources. This end to end design philosophy has motivated a lot of work [7] 10] using a utility ....

S. Floyd, TCP and explicit congestion notification, ACM Computer Communication Review, 24:10-23, October, 1994.

....scheme should combine the benefits of both the link quality dependent scheduling approaches and end to end approaches, so that high bandwidth efficiency and fairness can be achieved without imposing a heavy burden on the base station. We notice that in many proposed end to end wireless TCP schemes [11, 12, 14 16], the end host can differentiate wireless losses from congestion losses. Therefore in TCPELSA, instead of putting the link quality dependent rate adjustment in the base station, we implement this functionality in the end host to relieve the burden of packet scheduling on the base station. The ....

Floyd, S., TCP and Explicit Congestion Notification. ACM Computer Communication Review, Oct., 1994. 24(5).

....interchangeably messages which do not suffer any packet (fluid) loss due to threshold discarding or buffer overflow) exiting the node to the total packets (fluid) arriving at its input. In view of the rich recent research on improving the performance by some sort of congestion notification [4] [14] to sources, it becomes interesting to study the performance of message discarding policies with responsive sources. Thus we need to model the feedback system consisting of a network node with selective burst (the burst can be seen as a message) discarding and a source which responds to congestion ....

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 24(5):10--23, October 1994.

....number of packets that can arrive during a period where the operating system cannot process them immediately. 6x1Gbps 6x1Gbps 2.4Gbps, 120ms Geneva Chicago Figure 4: Testbed topology used for experiments. effect of delayed acknowledgments a was set to 0.02. The implementation of byte counting [1], which updates the congestion window in proportion to the exact number of bytes acknowledged, would remove the need to adjust for delayed acknowledgments. The DataTAG testbed consists of 12 high performance PCs that have Supermicro P4DP8 G2 motherboards with dual 2.4GHz Xeon processors and 2 ....

M. Allman. TCP Byte Counting Refinements. ACM Computer Communication Review, 29(3), July 1999.

....routine was changed to not make this extra copy. Both of these changes were simple and significantly improved TCP throughput; they will be termed the gigabit kernel modifications. In order to adjust for the e#ect of delayed acknowledgments a was set to 0.02. The implementation of byte counting [1], which updates the congestion window in proportion to the exact number of bytes acknowledged, would remove the need to adjust for delayed acknowledgments. The DataTAG testbed consists of 12 high performance PCs that have Supermicro P4DP8 G2 motherboards with dual 2.4GHz Xeon processors and 2 ....

M. Allman. TCP Byte Counting Refinements. ACM Computer Communication Review, 29(3), July 1999.

....graph remains the same ( LE(B0 G ; 2 ) as in figure 3. The increased results in a high queue size ( T E(B0 ; packets) which is now close to the upper limit . Forced packet drops already occur. They may cause global synchronization (see original RED paper in [5] and may hamper ECN [7] congestion signaling. To avoid such a behavior in the case of high load situations and with the queue size close to , a relatively high drop probability is required. Therefore in the simulation for the right graph a higher L(10HG0 2 is implemented. Now the arranged buffer can ....

S. Floyd, TCP and Explicit Congestion Notification, ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23.

....congestion to end nodes. One is to use packet drops. Alternatively, it can set a Congestion Experienced (CE) bit in a packet header as an indication of congestion, instead of relying solely on packet drops. The latter method is commonly referred to as explicit congestion notification (ECN) [17, 42, 43]. The major advantage of active queue management mechanisms like RED is that the transport protocols with congestion control (e.g. TCP) do not have to rely on buffer overflow as the only indication of congestion. This can potentially reduce unnecessary queuing delay for all traffic sharing that ....

....weighted moving average: q (1 w q ) q w q q, where w q is a fixed (small) parameter and q is the instantaneous queue length. When the average queue length exceeds a minimum threshold (min th ) incoming packets are probabilistically dropped or marked with the Congestion Experienced bit [17, 42, 43]. The probability that a packet arriving at the RED queue is either dropped or marked depends upon several control parameters of the algorithm. An initial drop mark probability P b is computed using a drop function D based on the average queue length q and three control parameters max p , min th ....

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 24(5):10-23, October 1994.

....mechanism. Therefore, the control parameters of the RED mechanism are u . The network with an AQM mechanism can be modeled as a feedback system, where sources adjust their transmission rates based on the feedback from the AQM mechanism in the form of marked or dropped packets [3], 5] If Explicit Congestion Notification (ECN) mechanism is implemented, the RED gateway marks the packet by setting the ECN bit in the IP header of the packet if the transport layer is ECN capable. This is indicated in the packet through ECN Capable Transport (ECT) bit in the IP header. If the ....

....is implemented, the RED gateway marks the packet by setting the ECN bit in the IP header of the packet if the transport layer is ECN capable. This is indicated in the packet through ECN Capable Transport (ECT) bit in the IP header. If the source is not ECN capable, the RED gateway drops the packet [3]. The connections are assumed to be long lived connections, and the set of connections remains fixed for the time period of interest. In order to have a tractable model we assume that all connections have the same round trip propagation delay, i.e. 8L A 8 for all 56 . Rather than interpreting ....

S. Floyd. TCP and explicit congestion notification. ACM Computer Communication Review, 24:10--23, October 1994.

.... required for information to be communicated from source to destination and back to source, is a useful timescale to categorise mechanisms such as TCP ( Postel81b, Nagle85, Lottor88, Stevens97, Mathis96] and explicit congestion notification schemes proposed as alternatives to it [Ramakrishnan90, Floyd94, Ramakrishnan99, Key99, Gibbens99] Section 2.3.4 summarises the significant quantity of literature that exists describing control techniques at the call level, the timescale over which flows of data are connected. A call example would be a connection in the telephone network. Calls also exist ....

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 24(5):10--23, October 1994. (p 49)

....delaying ACKs in the congested intermediate nodes. Fast TCP shapes the TCP traffic indirectly by ACK delaying rather than modifying the implement of TCP senders in other techniques, e.g. Internet control message protocol (ICMP) source quench messages [1] and explicit congestion notification (ECN) [2]. Therefore Fast TCP is easier to be introduced into the networks by upgrading the software of edge routers without any modification of larger number of TCP implement of end users. Router Delyed ACK DATA ACK Congested Figure 1 Prototype of Fast TCP Figure 1 shows the prototype of ....

S. Floyd, TCP and Explicit Congestion Notification, ACM Computer Communication Review, Vol. 24, 1994 Oct.

....] Lehman et al. 1998 ] and [ Levine and Garcia Luna Aceves, 1997 ] as well as Cisco s PGM . ffl Explicit Congestion Notification. By allowing routers to notify hosts of impending congestion, it is possible to avoid unnecessary packet drops in short or delay sensitive connections [ Floyd, 1994, Ramakrishnan and Floyd, 1999 ] ffl QOS route establishment. Current reservation mechanisms such as RSVP [ Braden et al. 1997 ] are based on shortest paths. To achieve a desired bandwidth, latency, Internet Draft, PGM Reliable Transport Protocol Specification, D. Farinacci et al. January ....

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communications Review, 24(5):10--23, October 1994.

....betterbest effort services, such as an end to end lossless TCP service illustrated in the paper. Our overlay architecture is unique in that it: a) does not require any support from intermediate network nodes or end systems (unlike ATM ABR [16] credit based schemes [20] bit based schemes [26] [7] or TCP modifications [13] 24] b) operates in a lossless (conditionally) manner with bounded buffers unlike TCP which uses packet loss to indicate congestion [12] c) aims to complement, not substitute existing end to end congestion control (eg: TCP) d) enables new edge based ....

.... to detect congestion epochs and the reverse direction involves the explicit feedback of the measured output rates ( i ) This positions the implementation requirements of our scheme in between purely implicit congestion detection schemes (eg: TCP [12] and explicit feedback schemes ( 26] [7], 16] 20] Moreover, our rate increase decrease policy differs from the well known additive increase multiplicative decrease (AIMD) policy [2] We call our increase decrease policy AIMD ER. The steady state dynamics are demonstrated in Figure 2. In particular, the multiplicative decrease ....

FLOYD, S. TCP and Explicit Congestion Notification. ACM Computer Communication Review 24, 5 (October 1994), 10--23.

....is familiar to teletraffic theorists, and our analytical approximations are taken from [16] In Section 2 we also outline some strategies by which packets may be marked, to indicate congestion. Packet marking strategies are familiar to flow control specialists, and are an active research area ([3,6,7,9,12,15]) In Section 3 we present a simple model of a gateway, and show that gateways are able to effect a distributed connection acceptance control for the network. We compare their performance with the performance achieved by a centralized controller, roughly summarized by Erlang s formula. In Section ....

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communications Review, 24:10-23, 1994. http://www-nrg.ee.lbl.gov/floycYecn.html.

....congestion from reaching the end nodes. To add robustness, the standards track specification [RFC3168] specified an additional codepoint in the IP header s ECN field, to use for an ECN nonce . The development of the ECN nonce was motivated by earlier research on specific robustness issues in TCP [SCWA99]. RFC 3168 explains that the addition of the codepoint is motivated primarily by the desire to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE ....

TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.

....perform traffic policing by means of shapers such as leaky buckets, we will explore the possibility of considering the violation of QoS guarantees as a congestion control problem rather than an admission control problem. Congestion control has been extensively studied in the context of TCP traffic [27, 29, 36, 37, 62], which accounts for more than 90 of the total traffic on the Internet [5] As illustrated in Figure 2, TCP provides feedback mechanisms that permit to resolve congestion problems, by reducing the sending rate of a source when a packet drop is detected. However, to the best of our knowledge, with ....

S. Floyd. TCP and explicit congestion notification. ACM Computer Communication Review, 24(5):10--23, October 1994.

....packet drops. AQM can also reduce queuing delays by keeping a lower average queue length. Moreover, since AQM routers are able to predict impending congestion before buffer overflows, they can explicitly notify end systems of network congestion by using Explicit Congestion Notification (ECN) [5], rather than implicitly notify end systems by dropping packets. Random Early Detection (RED) 6] is a well known lightweight AQM that uses the average queue size and minimum threshold (min th ) and maximum threshold (max th ) to detect impending congestion and determine congestion notification ....

S Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 24.

No context found.

S. Floyd. TCP and explicit congestion notification. ACM Computer Communication Review, 24(5):8--23, October 1994. http://www.aciri.org/floyd/.

No context found.

S. Floyd, TCP and explicit congestion notification, ACM Computer Communication Review, V. 24 N. 5, p. 10-23, October 1994.

No context found.

Mark Allman. TCP Byte Counting Refinements. ACM Computer Communication Review, 29(3), July 1999.

....congestion packet loss. Loss detection can avoid the long wait of timeout. Both timeout and loss detection use packet losses as congestion signals. Packet losses not only increase the traffic in the network, but also add large transfer delay. The Explicit Congestion Notification (ECN) proposed in [3, 4] provides a light weight mechanism for routers to send a direct indication of congestion to the source. It makes use of two experimental bits in the IP header and two experimental bits in the TCP header. When the average queue length exceeds a threshold, the incoming packet is marked as congestion ....

....halves its congestion window to help alleviate the congestion. Many authors have pointed out that marking provides more information about the congestion state than packet dropping [5, 6] and ECN has been proven to be a better way to deliver congestion signal and exhibits a better performance [4, 5, 7]. This research was sponsored in part by grants from Nokia Corporation, Burlington, Massachusetts and NASA Glenn Research Center, Cleveland, Ohio. In most ECN implementations, when congestion happens, the congested router marks the incoming packet that just entered the queue. When the buffer ....

S. Floyd, TCP and explicit congestion notification, ACM Computer Communication Review, V. 24 N. 5, p. 10-23, October 1994.

No context found.

M. Allman. TCP byte counting refinements. ACM Computer Communication Review, 29(3), July 1999.

No context found.

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review (1994).

No context found.

M. Allman. TCP byte counting refinements. ACM Computer Communication Review, 29(3), July 1999.

No context found.

Sally Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 24(5):10--23, 1994.

No context found.

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communications Review, pages 10--23, October 1994. 13

No context found.

S. Floyd, TCP and Explicit Congestion Notification, ACM Computer Communication Review, Vol. 24, No. 5, pp. 10-23, Oct. 1994.

No context found.

S. Floyd, iTCP and Explicit Congestion Noticationj, ACM Computer Communication Review, Oct 1994.

No context found.

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review (1994).

No context found.

S. Floyd,To and explicit congestion notification, ACM Computer Communications Review 24 (5) (1994) 10--23.

No context found.

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, vol. 24, pp. 10-23, October 1994.

No context found.

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 24(5), October 1994.

No context found.

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 24(5):10--23, 1994.

No context found.

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 24(5), October 1994.

No context found.

Sally Floyd. TCP and Explicit Congestion Notification, ACM Computer Communication Review, V. 24 N. 5, October 1994.

No context found.

FLOYD, S. TCP and Explicit Congestion Notification. ACM Computer Communication Review 24, 5 (1994), 10--23.

No context found.

Sally Floyd. TCP and explicit congestion notification. ACM Computer Communication Review, 24(5):10--23, 1994.

No context found.

"TCP and Explicit Congestion Notification", Sally Floyd, ACM Computer Communication Review, 1994.

No context found.

S. Floyd, TCP and explicit congestion notification, ACM Computer Communication Review,V.24N.5, p. 10-23, October 1994.

No context found.

Sally Floyd. TCP and Explicit Congestion Notification, ACM Computer Communication Review, V. 24 N. 5, October 1994.

No context found.

S. Floyd, TCP and explicit congestion notification, ACM Computer Communication Review,V.24N.5, p. 10-23, October 1994.

No context found.

S. Floyd, TCP and explicit congestion notification, ACM Computer Communication Review 24 (5) (1994) 10--23.

No context found.

S. Floyd. TCP and explicit congestion notification. ACM Computer Communication Review, 24:10--23, October 1994. 26

No context found.

Sally Floyd. TCP and Explicit Congestion Notification. ACM Computer Communication Review, 24(5):10--23, 1994.

No context found.

S. Floyd. Tcp and explicit congestion notification. ACM Computer Communication Review, 24(5):10--23, October 1995.

No context found.

S. Floyd. TCP and Explicit Congestion Notification. ACM Computer Communications Review, 24(5):10--23, October 1994.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC