You are on page 1of 47

6.

Congestion Control and Resource Allocation (Control de Congestin y Asignacin de Recursos)


By now we have seen enough layers of the network protocol hierarchy to understand how data can be transferred among processes across heterogeneous networks. We now turn to a problem that spans the entire protocol stackhow to effectively and fairly allocate resources among a collection of competing users. The resources being shared include the bandwidth of the links and the buffers on the routers or switches where packets are queued awaiting transmission. Packets contend at a router for the use of a link, with each contending packet placed in a queue waiting its turn to be transmitted over the link. When too many packets are contending for the same link, the queue overflows and packets have to be dropped. When such drops become common events, the network is said to be congested. ost networks provide a congestion!control mechanism to deal with "ust such a situation. Por ahora hemos visto suficientes capas de la "erarqu#a de protocolo de red para entender c$mo los datos pueden ser transferidos entre los procesos a trav%s de redes heterog%neas. Pasamos ahora a un problema que abarca todo el protocolo de pila! c$mo asignar los los recursos de manera efectiva y "usta entre una colecci$n de usuarios que compiten. &os recursos est'n compartidos incluyen el ancho de banda de los enlaces y los buffers de los routers o switches donde los paquetes se ponen en cola en espera de transmisi$n. Paquetes luchan en un router para el uso de un enlace, con cada paquete contendiendo colocado en una cola esperando su turno para ser transmitido a trav%s del enlace. (uando demasiados paquetes compiten por el mismo enlace, los desbordamientos de cola y los paquetes tienen que ser descartados. (uando esas ca#das se convierten en acontecimientos comunes, se dice que la red est' congestionada. &a mayor#a de las redes proporcionan un mecanismo de control de congesti$n para hacer frente a tal situaci$n. (ontrol de congesti$n y asignaci$n de recursos son las dos caras de la misma moneda. Por un lado, si la red tiene un papel activo en la asignaci$n de recursos! por e"emplo, la programaci$n de circuito virtual que llega a utili-ar un enlace f#sico dado durante un cierto per#odo de tiempo! entonces la congesti$n puede ser evitada, haciendo as# el control de congesti$n innecesario. &a asignaci$n de los recursos de red con precisi$n es dif#cil, sin embargo, debido a que los recursos en cuesti$n se distribuyen por toda la red, varios enlaces que conectan una serie de routers necesitan ser programada. Por otra parte, siempre se puede permitir que las fuentes de paquetes env#en tantos datos como ellos desean y luego recuperarse de la congesti$n en caso de producirse. 0ste es el enfoque m's f'cil, pero puede ser per"udicial debido a que muchos paquetes pueden ser descartados por la red antes de la congesti$n puede ser controlada. Por otra parte, es precisamente en esos momentos cuando la red est' congestionada! es decir, los recursos se han vuelto escasos en relaci$n a la demanda! que la necesidad de la asignaci$n de recursos entre los usuarios que compiten m's perentoriamente se sent#a. Tambi%n e*isten soluciones en el medio, por el cual se toman las decisiones de asignaci$n ine*actas, pero la congesti$n a1n puede ocurrir y por lo tanto, alg1n mecanismo a1n se necesita para recuperarse de ella. 2i se llama a una soluci$n mi*ta control de la congesti$n o la asignaci$n de recursos en realidad no importa. 0n cierto sentido, es ambas cosas. mechanism paces how fast sources are allowed to send packets. This is done in an effort to keep congestion from occurring in the first place and, should it occur, to help eliminate the congestion. (ontrol de congesti$n y asignaci$n de recursos afectan a ambos hosts y elementos de red tales como routers.

(ongestion control and resource allocation are two sides of the same coin. )n the one hand, if the network takes an active role in allocating resourcesfor e*ample, scheduling which virtual circuit gets to use a given physical link during a certain period of time then congestion may be avoided, thereby making congestion control unnecessary. +llocating network resources with any precision is difficult, however, because the resources in question are distributed throughout the network, multiple links connecting a series of routers need to be scheduled. )n the other hand, you can always let packet sources send as much data as they want and then recover from congestion should it occur. This is the easier approach, but it can be disruptive because many packets may be discarded by the network before congestion can be controlled. .urthermore, it is precisely at those times when the network is congestedthat is, resources have become scarce relative to demandthat the need for resource allocation among competing users is most keenly felt. There are also solutions in the middle, whereby ine*act allocation decisions are made, but congestion can still occur and hence some mechanism is still needed to recover from it. Whether you call such a mi*ed solution congestion control or resource allocation does not really matter. /n some sense, it is both. (ongestion control and resource allocation involve both hosts and network elements such as routers. /n network elements, various queuing disciplines can be used to control the order in which packets get transmitted and which packets get dropped. The queuing discipline can also segregate traffic to keep one user3s packets from unduly affecting another user3s packets. +t the end hosts, the congestion control

0n los elementos de red, las diversas disciplinas de cola se pueden utili-ar para controlar el orden en el que los paquetes son transmitidos y que los paquetes se caen. &a disciplina de colas tambi%n puede separar el tr'fico para impedir que los paquetes de un usuario afecten indebidamente los paquetes de otro usuario. 0n This chapter starts with an overview of congestion control and resource allocation. We then discuss different queuing disciplines that can be implemented on the routers inside the network, followed by a description of the congestion!control algorithm provided by T(P on the hosts. The fourth section e*plores various techniques involving both routers and hosts that aim to avoid congestion before it becomes a problem. .inally, we e*amine the broad area of quality of service. We consider the needs of applications to receive different levels of resource allocation in the network and describe a number of ways in which they can request these resources and the network can meet the requests.

los hosts finales, el mecanismo de control de congesti$n marca el paso de c$mo fuentes r'pidas se les permite enviar paquetes. 0sto se hace en un esfuer-o para impedir que la congesti$n se produ-ca en primer lugar, y, si se producen, ayudar a eliminar la congesti$n. 0ste cap#tulo comien-a con una descripci$n general de control de la congesti$n y asignaci$n de recursos. &uego discutiremos diferentes disciplinas de cola que se pueden implementar en los routers dentro de la red, seguido de una descripci$n del algoritmo de control de congesti$n proporcionado por T(P en los hosts. &a cuarta secci$n e*plora diferentes t%cnicas que implican ambos routers y hosts que tienen como ob"etivo evitar la congesti$n antes de que sea un problema. .inalmente, e*aminamos el amplio campo de la calidad del servicio. (onsideramos que las necesidades de las aplicaciones para recibir diferentes niveles de asignaci$n de recursos en la red y describir una serie de formas en que se pueden solicitar estos recursos y la red pueden satisfacer las peticiones.

6.1 ISSUES IN RESOURCE ALLOCA ION (!ro"le#as en la Asignacin de Recursos)


4esource allocation and congestion control are comple* issues that have been the sub"ect of much study ever since the first network was designed. They are still active areas of research. )ne factor that makes these issues comple* is that they are not isolated to one single level of a protocol hierarchy. 4esource allocation is partially implemented in the routers, switches, and links inside the network and partially in the transport protocol running on the end hosts. 0nd systems may use signalling protocols to convey their resource requirements to network nodes, which respond with information about resource availability. )ne of the main goals of this chapter is to define a framework in which these mechanisms can be understood, as well as to give the relevant details about a representative sample of mechanisms. &a asignaci$n de recursos y el control de la congesti$n son problemas comple"os que han sido el ob"eto de muchos estudios desde que la primera red fue dise5ada. Todav#a son 'reas activas de investigaci$n. 6n factor que hace estos problemas comple"os es que no se a#slan a un solo nivel de una "erarqu#a de protocolo. &a asignaci$n de recursos se implementa parcialmente en los routers, switches y enlaces dentro de la red y parcialmente en el protocolo de transporte se e"ecutan en los hosts finales. &os sistemas finales pueden utili-ar protocolos de se5ali-aci$n para transmitir sus necesidades de recursos a los nodos de la red, que responden con informaci$n sobre la disponibilidad de recursos. 6no de los principales ob"etivos de este cap#tulo es definir un marco en el que estos mecanismos pueden ser comprendidos, as# como para dar los detalles relevantes sobre una muestra representativa de los mecanismos.

We should clarify our terminology before going any further. By resource allocation, we mean the process by which network elements try to meet the competing demands that applications have for network resources primarily link bandwidth and buffer space in routers or switches. )f course, it will often not be possible to meet all the demands, meaning that some users or applications may receive fewer network resources than they want. Part of the resource allocation problem is deciding when to say no and to whom. 7ebemos aclarar nuestra terminolog#a antes de seguir We use the term congestion control to describe the efforts made by network nodes to prevent or respond to

adelante. Por asignaci$n de recursos, nos referimos al proceso por el cual los elementos de red tratan de satisfacer las demandas competitivas que las aplicaciones tienen para los recursos de red 8 principalmente ancho de banda de enlace y espacio de b1fer en los routers o switches. Por supuesto, a menudo no se puedan satisfacer todas las demandas, lo que significa que algunos usuarios o aplicaciones pueden recibir menos recursos de red que lo deseen. Parte del problema de asignaci$n de recursos es decidir cu'ndo decir no y para qui%n. overload conditions. 2ince congestion is generally bad for everyone, the first order of business is making

congestion subside, or preventing it in the first place. This might be achieved simply by persuading a few hosts to stop sending, thus improving the situation for everyone else. 9owever, it is more common for congestion!control mechanisms to have some aspect of fairnessthat is, they try to share the pain among all users, rather than causing great pain to a few. Thus, we see that many congestion!control mechanisms have some sort of resource allocation built into them. 6samos el t%rmino control de congesti$n para describir los esfuer-os reali-ados por los nodos de la red para /t is also important to understand the difference between flow control and congestion control. .low control, as we have seen in 2ection :.;, involves keeping a fast sender from overrunning a slow receiver. (ongestion control, by contrast, is intended to keep a set of senders from sending too much data into the network because of lack of resources at some point. These two concepts are often confused, as we will see, they also share some mechanisms.

prevenir o responder a condiciones de sobrecarga. 7ado que la congesti$n es generalmente mala para todos, la primera orden del negocio es hacer disminuir la congesti$n, o prevenirla en primer lugar. 0sto puede lograrse simplemente persuadiendo a pocos hosts para detener el env#o, lo que me"ora la situaci$n de todos los dem's. 2in embargo, es m's com1n que los mecanismos de control de congesti$n tengan alg1n aspecto de equidad! es decir, tratan de compartir el dolor entre todos los usuarios, en lugar de causar un gran dolor a algunos. Por lo tanto, vemos que muchos mecanismos de control de congesti$n tienen alg1n tipo de asignaci$n de recursos incorporado en ellas. Tambi%n es importante entender la diferencia entre control de flu"o y control de congesti$n. (ontrol de flu"o, como hemos visto en la 2ecci$n :.;, consiste en mantener un emisor r'pido sature un receptor lento. (ontrol de congesti$n, por el contrario, pretende mantener un con"unto de emisores enviando demasiados datos en la red, debido a la falta de recursos en alg1n momento. 0stos dos conceptos se confunden a menudo, como veremos, tambi%n comparten algunos mecanismos.

6.1.1 Net$or% &odel (&odelo de la Red)


We begin by defining three salient features of the network architecture. .or the most part, this is a summary of material presented in the previous chapters that is relevant to the problem of resource allocation. 0mpe-amos definiendo tres caracter#sticas m's destacadas de la arquitectura de red. 0n su mayor parte, se trata de un resumen de los materiales presentados en los cap#tulos anteriores que son relevantes para el problema de la asignaci$n de recursos.

Packet-Switched Network We consider resource allocation in a packet!switched network <or internet= consisting of multiple links and switches <or routers=. 2ince most of the mechanisms described in this chapter were designed for use on the /nternet, and therefore were originally defined in terms of routers rather than switches, we use the term router throughout our discussion. The problem is essentially the same, whether on a network or an internetwork.

Red de conmutacin de paquetes (onsideramos que asignaci$n de recursos en una red de conmutaci$n de paquetes <o /nternet= que consta de m1ltiples enlaces y switches <o routers=. 7ado que la mayor#a de los mecanismos descritos en este cap#tulo fueron dise5ados para su uso en /nternet, y por lo tanto se definieron originalmente en t%rminos de routers en lugar de conmutadores <swithces=, se utili-a el t%rmino enrutador <router= a trav%s de nuestra discusi$n. 0l problema es esencialmente el mismo, ya sea en una red o una intercone*i$n de redes. :=. These access!control algorithms are, in some sense, analogous to congestion!control algorithms in a switched network. 0n ese entorno, una fuente dada podr' tener m's capacidad suficiente en el enlace de salida inmediata para enviar un paquete, pero en alg1n lugar en el medio de una red sus paquetes encontrar'n un enlace que est' siendo utili-ado por muchas fuentes de tr'fico diferentes. .igura >.? ilustra esta situaci$n!dos enlaces de alta velocidad est'n alimentando un enlace de ba"a

/n such an environment, a given source may have more than enough capacity on the immediate outgoing link to send a packet, but somewhere in the middle of a network its packets encounter a link that is being used by many different traffic sources. .igure >.? illustrates this situation two high!speed links are feeding a low! speed link. This is in contrast to shared!access networks like 0thernet and wireless networks, where the source can directly observe the traffic on the network and decide accordingly whether or not to send a packet. We have already seen the algorithms used to allocate bandwidth on shared!access networks <(hapter

velocidad. 0sto est' en contraste con las redes de acceso compartido como 0thernet y redes inal'mbricas, donde la fuente puede observar directamente el tr'fico en la red y decidir en consecuencia si se env#a o no un paquete. 9emos visto

ya los algoritmos utili-ados para asignar ancho de banda en las redes de acceso compartido <(ap#tulo :=. 0stos algoritmos de control de acceso son, en cierto sentido, de forma an'loga a los algoritmos de control de congesti$n en una red conmutada.

@ote that congestion control is a different problem than routing. While it is true that a congested link could be assigned a large edge weight by the routing protocol, and, as a consequence, routers would route around it, Arouting aroundB a congested link does not generally solve the congestion problem. To see this, we need look no further than the simple network depicted in .igure >.?, where all traffic has to flow through the same router to reach the destination. +lthough this is an e*treme e*ample, it is common to have a certain router that it is not possible to route around.? This router can become congested, and there is nothing the routing mechanism can do about it. This congested router is sometimes called the bottleneck router. Connectionless Flows .or much of our discussion, we assume that the network is essentially connectionless, with any connection!oriented service implemented in the transport protocol that is running on the end hosts. <We e*plain the qualification AessentiallyB in a moment.= This is precisely the model of the /nternet, where /P provides a connectionless datagram delivery service and T(P implements an end!to!end connection abstraction. @ote that this assumption does not hold in virtual circuit networks such as +T and D.:; <see 2ection E.?.:=. /n such networks, a connection setup message traverses the network when a circuit is established. This setup message reserves a set of buffers for the connection at each router, thereby providing a form of congestion controla connection is established only if enough buffers can be allocated to it at each router. The ma"or shortcoming of this approach is that it leads to an underutili-ation of resources buffers reserved for a particular circuit are not available for use by other traffic even if they were not currently being used by that circuit. The focus of this chapter is on resource allocation approaches that apply in an internetwork, and thus we focus mainly on connectionless networks.

@ote que el control de congesti$n es un problema diferente de enrutamiento. +unque es verdad que un enlace congestionado podr#a ser asignado un gran peso borde por el protocolo de enrutamiento, y, como consecuencia, routers enrutar#a a su alrededor Cenrutamiento alrededorC un enlace congestionado generalmente no resuelve el problema de la congesti$n. Para ver esto, tenemos que mirar m's all' de la simple red representada en la figura >.?, donde todo el tr'fico debe fluir a trav%s del mismo router para llegar al destino. +unque este es un e"emplo e*tremo, es com1n tener una cierta router que no es posible enrutar alrededor. 0ste router puede congestionarse, y no hay nada que el mecanismo de enrutamiento pueda hacer al respecto. 0ste router congestionado a veces se llama el router cuello de botella. Flujos sin conexin 7urante gran parte de la discusi$n, se supone que la red es esencialmente sin cone*i$n, con cualquier servicio orientado a cone*i$n implementado en el protocolo de transporte que se est' e"ecutando en los hosts finales. <0*plicamos la calificaci$n CesencialmenteC en un momento.= 0ste es precisamente el modelo de la /nternet, donde /P proporciona un servicio de entrega de datagramas sin cone*i$n y T(P implementa una abstracci$n cone*i$n de e*tremo a e*tremo. @ote que esta hip$tesis no se sostiene en las redes de circuitos virtuales como +T and D.:; <v%ase la 2ecci$n E.?.:=. 0n tales redes, un mensa"e de establecimiento de cone*i$n atraviesa la red cuando se establece un circuito. 0ste mensa"e de establecimiento reserva un con"unto de buffers para la cone*i$n en cada router, proporcionando as# una forma de control de congesti$n! se establece una cone*i$n s$lo si suficientes buffers pueden ser asignados al respecto en cada router. 0l principal inconveniente de este enfoque es que conduce a una subutili-aci$n de los recursos! buffers reservados para un circuito en particular no est'n disponibles para su uso por el resto del tr'fico, incluso si no estaban actualmente siendo utili-ados por ese circuito. 0l ob"etivo de este cap#tulo es sobre los enfoques de asignaci$n de recursos que se aplican en una intercone*i$n de redes, y por lo tanto nos centramos principalmente en las redes de cone*i$n. classification of networks as being either

We need to qualify the term connectionless because our

connectionless or connection oriented is a bit too restrictive, there is a gray area in between. /n particular, the assumption that all datagrams are completely independent in a connectionless network is too strong. The datagrams are certainly switched independently, but it is usually the case that a stream of datagrams between a particular pair of hosts flows through a particular set of routers. This idea of a flow a sequence of packets sent between a sourceFdestination pair and following the same route through the networkis an important abstraction in the conte*t of resource allocation, it is one that we will use in this chapter. Tenemos que calificar el t%rmino sin cone*i$n debido a )ne of the powers of the flow abstraction is that flows can be defined at different granularities. .or e*ample, a flow can be host!to!host <i.e., have the same sourceFdestination host addresses= or process!to! process <i.e., have the same sourceFdestination hostFport pairs=. /n the latter case, a flow is essentially the same as a channel, as we have been using that term throughout this book. The reason we introduce a new term is that a flow is visible to the routers inside the network, whereas a channel is an end!to!end abstraction. .igure >.: illustrates several flows passing through a series of routers.

nuestra clasificaci$n de las redes como cualquiera de los dos sin cone*i$n o cone*i$n orientada es un demasiado restrictiva, hay una -ona gris en el medio. 0n particular, el supuesto de que todos los datagramas son completamente independientes en una red sin cone*i$n es demasiado fuerte. &os datagramas son ciertamente conmutados de forma independiente, pero es usualmente el caso de que un flu"o de datagramas entre un par particular de hosts fluye a trav%s de un con"unto particular de los routers. 0sta idea de un flu"o! una secuencia de paquetes enviados entre una fuenteFdestino par y siguiendo la misma ruta a trav%s de la red! es una abstracci$n importante en el conte*to de la asignaci$n de recursos, que es la que vamos a utili-ar en este cap#tulo. 6no de los poderes de la abstracci$n de flu"o es que los flu"os pueden ser definidos en diferentes granulaciones. Por e"emplo, un flu"o puede ser host!to!host <es decir, tienen las mismas direcciones de host origenFdestino= o de proceso a proceso <e", tienen los mismos pares origenFdestino hostFpuerto=. 0n este 1ltimo caso, un flu"o es esencialmente lo mismo que un canal, ya que hemos estado utili-ando ese t%rmino en este libro. &a ra-$n por la que introducimos un nuevo t%rmino es que un flu"o es visible para los routers dentro de la red, mientras que un canal es una abstracci$n de e*tremo a e*tremo. &a figura >.: ilustra varios flu"os que pasan a trav%s de una serie de enrutadores.

Because multiple related packets flow through each router, it sometimes makes sense to maintain some state information for each flow, information that can be used to make resource allocation decisions about the packets that belong to the flow. This state is sometimes called soft state, the main difference between soft state and hard state is that soft state need not always be e*plicitly created and removed by signalling. 2oft state represents a middle ground between a purely connectionless network that maintains no state at the routers and a purely connectionoriented network that maintains hard state at the routers. /n general, the correct operation of the network does not depend on soft state being present <each packet is still routed correctly without regard to this state=, but when a packet happens to belong to a flow for which the router is currently maintaining soft state, then the router is better able to handle the packet.

7ebido a que m1ltiples paquetes relacionados fluyen a trav%s de cada router, a veces tiene sentido mantener alguna informaci$n de estado para cada flu"o, informaci$n que puede ser utili-ada para tomar decisiones de asignaci$n de recursos sobre los paquetes que pertenecen al flu"o. 0ste estado es a veces llamado estado blando, la principal diferencia entre el estado blando y duro estado es el estado blando no necesita siempre ser creado y eliminado e*pl#citamente por la se5ali-aci$n. 0stado blando representa un t%rmino medio entre una red puramente cone*i$n que mantiene ning1n estado en los routers y una red puramente orientada a la cone*i$n que mantiene el estado duro en los routers. 0n general, el correcto funcionamiento de la red no depende de estado blando estar presente <cada paquete se enruta correctamente a1n sin tener en cuenta este estado=, pero cuando un paquete pasa a pertenecer a un flu"o para que el router est% actualmente manteniendo estado blando, entonces el router est' en me"ores condiciones para mane"ar el paquete. does this by inspecting the addresses in the header and treats these packets as belonging to the same flow for the purpose of congestion control. /n the latter case, the source sends a flow setup message across the

@ote that a flow can be either implicitly defined or e*plicitly established. /n the former case, each router watches for packets that happen to be traveling between the same sourceFdestination pairthe router

network, declaring that a flow of packets is about to start. While e*plicit flows are arguably no different than a connection across a connection oriented network, we call attention to this case because, even when e*plicitly established, a flow does not imply any end!to!end semantics and, in particular, does not imply the reliable and ordered delivery of a virtual circuit. /t simply e*ists for the purpose of resource allocation. We will see e*amples of both implicit and e*plicit flows in this chapter. Tenga en cuenta que un flu"o puede ser ya sea impl#citamente definido o establecido e*pl#citamente. 0n el primer caso, cada router vigila para los paquetes que pasan estar via"ando entre el mismo par Service Model /n the early part of this chapter, we will focus on mechanisms that assume the best!effort service model of the /nternet. With best!effort service, all packets are given essentially equal treatment, with end hosts given no opportunity to ask the network that some packets or flows be given certain guarantees or preferential service. 7efining a service model that supports some kind of preferred service or guaranteefor e*ample, guaranteeing the bandwidth needed for a video stream is the sub"ect of 2ection >.;. 2uch a service model is said to provide multiple qualities of service <Ho2=. +s we will see, there is actually a spectrum of possibilities, ranging froma purely best!effort service model to one in which individual flows receive quantitative guarantees of Ho2. )ne of the greatest challenges is to define a service model that meets the needs of a wide range of applications and even allows for the applications that will be invented in the future. Modelo de Servicio

fuenteFdestino!el router hace esto mediante la inspecci$n de las direcciones en la cabecera y trata estos paquetes como pertenecientes al mismo flu"o para el prop$sito de control de la congesti$n. 0n este 1ltimo caso, la fuente env#a un mensa"e de establecimiento de flu"o a trav%s de la red, declarando que un flu"o de paquetes est' a punto de comen-ar. +unque los flu"os e*pl#citos son posiblemente no diferentes de una cone*i$n a trav%s de una red orientada a la cone*i$n, llamamos la atenci$n sobre este caso, ya que, aun cuando establecido e*pl#citamente, un flu"o no implica ninguna sem'ntica de e*tremo a e*tremo y, en particular, no implica la entrega confiable y ordenada de un circuito virtual. 2implemente e*iste con el prop$sito de la asignaci$n de recursos. Geremos e"e de ambos flu"os en el cap. 0n la primera parte de este cap#tulo, nos centraremos en los mecanismos que asumen el modelo de servicio de me"or esfuer-o de la /nternet. (on el servicio de me"or esfuer-o, todos los paquetes se les da esencialmente igualdad de trato, con los hosts finales dando ninguna oportunidad para solicitar a la red que algunos paquetes o flu"os dan ciertas garant#as o servicio preferencial. 7efinici$n de un modelo de servicio que apoya alg1n tipo de servicio preferido o garant#a! por e"emplo, garanti-ando el ancho de banda necesario para un flu"o de v#deo! es ob"eto de la secci$n >.;. 0ste modelo de servicio se dice que proporciona m1ltiples cualidades de servicio <Ho2=. (omo veremos, en realidad hay un espectro de posibilidades, que van desde un modelo de servicio de me"or esfuer-o puramente a una en la que los flu"os individuales reciben garant#as cuantitativas de Ho2. 6no de los mayores desaf#os es definir un modelo de servicio que satisface las necesidades de una amplia gama de aplicaciones e incluso permite que las aplicaciones que se invente en el futuro.

6.1.' a(ono#y
There are countless ways in which resource allocation mechanisms differ, so creating a thorough ta*onomy is a difficult proposition. .or now, we describe three dimensions along which resource allocation mechanisms can be characteri-ed, more subtle distinctions will be called out during the course of this chapter. Router-Centric versus ost-Centric 4esource allocation mechanisms can be classified into two broad groupsI those that address the problem frominside the network <i.e., at the routers or switches= and those that address it from the edges of the network <i.e., in the hosts, perhaps inside the transport protocol=. 2ince it is the case that both the routers inside the network and the hosts at the edges of the network participate in resource allocation, the real issue is where the ma"ority of the burden falls. /n a router!centric design, each router takes responsibility for deciding when packets are forwarded 9ay innumerables maneras en que los mecanismos de asignaci$n de recursos difieren, por lo que la creaci$n de una ta*onom#a a fondo es una proposici$n dif#cil. Por ahora, se describen tres dimensiones en las que los mecanismos de asignaci$n de recursos pueden ser caracteri-ados, distinciones m's sutiles ser'n llamados a cabo durante el transcurso de este cap#tulo. Router-C!ntrico versus ost-C!ntrico &os mecanismos de asignaci$n de recursos se pueden clasificar en dos grandes gruposI los que abordan el problema del interior de la red <es decir, en los routers o switches= y los que abordan desde los bordes de la red <es decir, en los hosts, tal ve- dentro del protocolo de transporte=. 7ado que es el caso que ambos enrutadores dentro de la red y los hosts en los bordes de la red participen en la asignaci$n de recursos, el problema real es donde la mayor#a de la carga cae. and selecting which packets are to be dropped, as well as for informing the hosts that are generating the

network traffic how many packets they are allowed to send. /n a host!centric design, the end hosts observe the network conditions <e.g., how many packets they are successfully getting through the network= and ad"ust their behavior accordingly. 0n un dise5o de enrutador c%ntrica, cada router tiene la responsabilidad de decidir cuando los paquetes se @ote that these two groups are not mutually e*clusive. .or e*ample, a network that places the primary burden for managing congestion on routers still e*pects the end hosts to adhere to any advisory messages the routers send, while the routers in networks that use end!to!end congestion control still have some policy, no matter how simple, for deciding which packets to drop when their queues do overflow.

env#an y seleccionando qu% paquetes se van a caer, as# como informar a los hosts que est'n generando el tr'fico de la red el n1mero de paquetes se les permite enviar. 0n un dise5o de host c%ntrica, los hosts finales observan las condiciones de la red <por e"emplo, el n1mero de paquetes que est'n obteniendo con %*ito a trav%s de la red= y a"ustan su comportamiento de acuerdo. Tenga en cuenta que estos dos grupos no son mutuamente e*cluyentes. Por e"emplo, una red que pone la carga principal de la gesti$n de la congesti$n en los routers a1n espera que los hosts finales se adhieran a los mensa"es consultivos a los routers env#an, mientras que los routers en las redes que utili-an el control de congesti$n de e*tremo a e*tremo a1n tienen algo de pol#tica, no importa lo simple, para decidir qu% paquetes caer cuando sus colas hacen desbordamiento. "asado en Reserva versus "asado Retroalimentacin 6na segunda forma en que los mecanismos de asignaci$n de recursos a veces son clasificados es en funci$n de si utili-an reservas o retroalimentaci$n. 0n un sistema basado en reserva!, alguna entidad <por e"emplo, el host final= solicita a la red una cierta cantidad de capacidad para ser asignado para un flu"o. (ada router entonces asigna suficientes recursos <buffers yFo porcenta"e de ancho de banda del enlace= para satisfacer esta petici$n. 2i la solicitud no puede ser satisfecha en alg1n router, porque hacerlo ser#a sobreasignar sus recursos, entonces el router recha-a la reserva. 0sto es an'logo a obtener una se5al de ocupado cuando se trata de hacer una llamada telef$nica.0n un enfoque basado en retroalimentaci$n, los hosts finales comien-an a enviar datos sin antes reservar cualquier capacidad y luego a"ustar su tasa de env#o de acuerdo a la retroalimentaci$n que reciben. 0sta retroalimentaci$n puede ser e*pl#cita <es decir, un router congestionado env#a un mensa"e Cpor favor, m's despacioC para el host= o impl#cita <es decir, el host final a"usta su tasa de env#o de acuerdo al comportamiento e*ternamente observable de la red, tales como p%rdidas de paquetes=. Tenga en cuenta que un sistema basado en reservas! siempre implica un mecanismo de asignaci$n de recursos del router c%ntrica. 0sto se debe a que cada router es responsable de mantener un registro de cu'nto de su capacidad est' actualmente disponible y decidir si las nuevas reservas se pueden admitir. &os routers tambi%n tendr'n que asegurarse de que cada host vive dentro de la reserva que formul$. 2i un host env#a datos m's r'pido de lo afirmado que lo har#a cuando se hi-o la reserva, entonces los paquetes de ese host son buenos candidatos para descartar, el router debe estar congestionado. Por otro lado, un sistema basado en la retroalimentaci$n puede implicar ya sea un mecanismo de router!o!de host centrado. Por lo general, si la retroalimentaci$n es e*pl#cita, el enrutador est' involucrado, al menos en cierta medida, en el esquema de asignaci$n de recursos. 2i la realimentaci$n es impl#cita, entonces la casi totalidad de la carga cae al

Reservation-"ased versus Feed#ack-"ased + second way that resource allocation mechanisms are sometimes classified is according to whether they use reservations or feedback. /n a reservation!based system, some entity <e.g., the end host= asks the network for a certain amount of capacity to be allocated for a flow. 0ach router then allocates enough resources <buffers andFor percentage of the link3s bandwidth= to satisfy this request. /f the request cannot be satisfied at some router, because doing so would overcommit its resources, then the router re"ects the reservation. This is analogous to getting a busy signal when trying to make a phone call. /n a feedback!based approach, the end hosts begin sending data without first reserving any capacity and then ad"ust their sending rate according to the feedback they receive. This feedback can be either e*plicit <i.e., a congested router sends a Aplease slow downB message to the host= or implicit <i.e., the end host ad"usts its sending rate according to the e*ternally observable behavior of the network, such as packet losses=.

@ote that a reservation!based system always implies a router!centric resource allocation mechanism. This is because each router is responsible for keeping track of how much of its capacity is currently available and deciding whether new reservations can be admitted. 4outers may also have to make sure each host lives within the reservation it made. /f a host sends data faster than it claimed it would when it made the reservation, then that host3s packets are good candidates for discarding, should the router become congested. )n the other hand, a feedback!based system can imply either a router! or host!centric mechanism. Typically, if the feedback is e*plicit, then the router is involved, to at least some degree, in the resource allocation scheme. /f the feedback is implicit, then almost all of the burden falls to the end host, the routers silently drop packets when they become congested.

host final, los routers en silencio de"an caer los 4eservations do not have to be made by end hosts. /t is possible for a network administrator to allocate resources to flows or to larger aggregates of traffic, as we will see in 2ection >.;.E. $indow "ased versus Rate "ased + third way to characteri-e resource allocation mechanisms is according to whether they are window based or rate based. This is one of the areas, noted above, where similar mechanisms and terminology are used for both flow control and congestion control. Both flow!control and resource allocation mechanisms need a way to e*press, to the sender, how much data it is allowed to transmit. There are two general ways of doing thisI with a window or with a rate. We have already seen window!based transport protocols, such as T(P, in which the receiver advertises a window to the sender. This window corresponds to how much buffer space the receiver has, and it limits how much data the sender can transmit, that is, it supports flow control. + similar mechanismwindow advertisement can be used within the network to reserve buffer space <i.e., to support resource allocation=. T(P3s congestion!control mechanisms, described in 2ection >.E, are window based.

paquetes se congestionan. 4eservas no tienen que ser hecha por hosts finales. 0s posible que un administrador de red asigne recursos a los flu"os o agregados m's grandes de tr'fico, como veremos en la 2ecci$n >.;.E. "asada en %entana versus "asada en &asa 6na tercera forma de caracteri-ar los mecanismos de asignaci$n de recursos es en funci$n de si son basados en ventana o basada en tasa. 0sta es una de las 'reas, se ha indicado anteriormente, donde se utili-an mecanismos y terminolog#a similar tanto para el control de flu"o y control de congesti$n. +mbos mecanismos de control de flu"o y de asignaci$n de recursos necesita una manera de e*presar, al emisor, la cantidad de datos que se permite transmitir. 9ay dos formas generales de hacerloI con una ventana o con una tasa. Ja hemos visto los protocolos de transporte basados en ventanas, como T(P, en el que el receptor anuncia una ventana al remitente. 0sta ventana corresponde a cu'nto espacio tiene el b1fer del receptor, y limita la cantidad de datos que el emisor puede transmitir, es decir, que soporta control de flu"o. 6n mecanismo similar!ventana anunciada! se puede utili-ar dentro de la red para reservar espacio de b1fer <es decir, para apoyar la asignaci$n de recursos=. ecanismos de control de congesti$n del T(P, que se describen en la secci$n >.E, se basan ventana. Tambi%n es posible controlar el comportamiento de un emisor utili-ando una tasa! es decir, la cantidad de bits por segundo del receptor o la red es capa- de absorber. (ontrol basado en Tasa tiene sentido para muchas aplicaciones multimedia, que tienden a generar datos a una tasa promedio y que necesitan por lo menos alg1n m#nimo rendimiento para ser 1til. Por e"emplo, un c$dec de v#deo del tipo descrito en la 2ecci$n K.:.E podr#a generar v#deo a una tasa promedio de ? bps con una tasa m'*ima de : bps. (omo veremos m's adelante en este cap#tulo, la caracteri-aci$n basado en tasa de los flu"os es una opci$n l$gica en un sistema basado en la reserva! que soporta diferentes calidades de servicio! el emisor hace una reserva para tantos bits por segundo, y cada router a lo largo de la trayectoria determina si se puede soportar ese ritmo, teniendo en cuenta los otros flu"os que se ha comprometido.

/t is also possible to control a sender3s behavior using a ratethat is, how many bits per second the receiver or network is able to absorb. 4ate!based control makes sense for many multimedia applications, which tend to generate data at some average rate and which need at least some minimum throughput to be useful. .or e*ample, a video codec of the sort described in 2ection K.:.E might generate video at an average rate of ? bps with a peak rate of : bps. +s we will see later in this chapter, rate!based characteri-ation of flows is a logical choice in a reservation!based system that supports different qualities of servicethe sender makes a reservation for so many bits per second, and each router along the path determines if it can support that rate, given the other flows it has made commitments to.

Summar' o( Resource )llocation &axonom' (lassifying resource allocation approaches at two different points along each of three dimensions, as we have "ust done, would seem to suggest up to eight unique strategies. While eight different approaches are certainly possible, we note that in practice two general strategies seem to be most prevalent, these two

strategies are tied to the underlying service model of the network. )n the one hand, a best!effort service model usually implies that feedback is being used, since such a model does not allow users to reserve network capacity. This, in turn, means that most of the responsibility for congestion control falls to the end hosts, perhaps with

some assistance from the routers. /n practice, such networks use window!based information. This is the general strategy adopted in the /nternet and is the focus of 2ections >.E and >.L.

Resumen de la &axonom*a de )si+nacin de Recursos (lasificar la asignaci$n de recursos se acerca a dos puntos diferentes a lo largo de cada una de las tres dimensiones, como acabamos de hacer, parecer#a sugerir hasta ocho estrategias 1nicas. ientras que ocho enfoques diferentes son ciertamente posibles, )n the other hand, a Ho2!based service model probably implies some form of reservation <+s we will see in 2ection >.;, resource reservations might be made by network managers rather than by hosts=. 2upport for these reservations is likely to require significant router involvement, such as queuing packets differently depending on the level of reserved resources they require. oreover, it is natural to e*press such reservations in terms of rate, since windows are only indirectly related to how much bandwidth a user needs from the network.We discuss this topic in 2ection >.;.

observamos que en la pr'ctica dos estrategias generales parecen ser m's prevalentes, estas dos estrategias est'n ligados al modelo de servicio subyacente de la red. Por un lado, un modelo de servicio de me"or esfuer-o por lo general implica que se est' utili-ando la retroalimentaci$n, ya que un modelo de este tipo no permite a los usuarios reservar capacidad de la red. 0sto, a su ve-, significa que la mayor parte de la responsabilidad del control de la congesti$n cae a los hosts finales, tal ve- con un poco de ayuda de los routers. 0n la pr'ctica, estas redes utili-an informaci$n basada en la ventana. 0sta es la estrategia general adoptada en el /nternet y es el foco de las 2ecciones >.E y >.L. Por otro lado, un modelo de servicio basado en Ho2 probablemente implica alg1n tipo de reserva <como veremos en la secci$n >.;, las reservas de recursos pueden ser reali-adas por los administradores de red en lugar de los hosts=. 0l apoyo a estas reservas es probable que requiera la participaci$n del router significativa, tales como puesta en cola de paquetes de manera diferente dependiendo del nivel de los recursos reservados que requieren. Por otra parte, es natural de e*presar esas reservas en t%rminos de velocidad, ya que las ventanas est'n s$lo relacionados indirectamente con la cantidad de ancho de banda que necesita un usuario de la red. 7iscutimos este tema en la secci$n >.;.

6.1.) E*aluation Criteria (Criterios de e*aluacin)


The final issue is one of knowing whether a resource allocation mechanism is good or not. 4ecall that in the problem statement at the start of this chapter we posed the question of how a network effectively and fairly allocates its resources. This suggests at least two broad measures by which a resource allocation scheme can be evaluated. We consider each in turn. ,((ective Resource )llocation + good starting point for evaluating the effectiveness of a resource allocation scheme is to consider the two principal metrics of networkingI throughput and delay. (learly, we want as much throughput and as little delay as possible. 6nfortunately, these goals are often somewhat at odds with each other. )ne sure way for a resource allocation algorithm to increase throughput is to allow as many packets into the network as possible, so as to drive the utili-ation of all the links up to ?MMN. We would do this to avoid the possibility of a link becoming idle because an idle link necessarily hurts throughput. The problem with this strategy is that increasing the number of packets in the network also increases the length of the queues at each router. &onger queues, in turn, mean packets are delayed longer in the network. &a 1ltima cuesti$n es uno de saber si un mecanismo de asignaci$n de recursos es bueno o no. 4ecordemos que en el enunciado del problema en el inicio de este cap#tulo nos planteamos la cuesti$n de c$mo una red asigna de manera efectiva y "usta de sus recursos. 0sto sugiere, al menos, dos amplias medidas por las que un esquema de asignaci$n de recursos se puede evaluar. (onsideramos cada uno de ellos. )si+nacin e(ica- de recursos 6n buen punto de partida para evaluar la efectividad de un esquema de asignaci$n de recursos es considerar las dos principales m%tricas de las redesI rendimiento y retardo. 0st' claro que queremos mayor cantidad el rendimiento y la menor demora posible. Por desgracia, estos ob"etivos son a menudo un poco en desacuerdo uno con el otro. 6na forma segura para un algoritmo de asignaci$n de recursos para aumentar el rendimiento es permitir el mayor n1mero de paquetes en la red como sea posible, con el fin de impulsar la utili-aci$n de todos los enlaces hasta el ?MMN. Hueremos hacer esto para evitar la posibilidad de un enlace est% ocioso, ya que un enlace inactivo hace da5o necesariamente el rendimiento. 0l problema con esta estrategia es que el aumento del n1mero de paquetes en la red tambi%n aumenta la longitud de las colas en cada router. (olas m's largas, a su ve-, significa que los paquetes se demoran m's tiempo en la red. a metric for evaluating the effectiveness of a resource allocation scheme. This ratio is sometimes referred to

To describe this relationship, some network designers have proposed using the ratio of throughput to delay as

as the power of the network I <The actual definition is


Power O ThroughputPF7elay, where MQPQ ?, PO? results in power being ma*imi-ed at the knee of the delay curve. Throughput is measured in units of data <e.g., bits= per second, delay in seconds=.

rendimiento a retrasar como una m%trica para evaluar la efectividad de un esquema de asignaci$n de recursos. 0sta relaci$n se denomina a veces como el poder de la redI <&a definici$n real es potencia O
ThroughputP F 7elay, donde M QP Q?, P O ? da como resultado poder ser ma*imi-ados en la rodilla de la curva de retardo. 0l rendimiento se mide en unidades de datos <por e"emplo, bits= por segundo, retardo en segundos=.

Para describir esta relaci$n, algunos dise5adores de redes han propuesto utili-ar la relaci$n entre el @ote that it is not obvious that power is the right metric for "udging resource allocation effectiveness. .or one thing, the theory behind power is based on an F F? queuing network that assumes infinite queues <2ince
this is not a queuing theory book, we provide only this brief description of an F F? queue. The ? means it has a single server, and the s mean that the distribution of both packet arrival and service times is A arkovian,B or e*ponential.= ,

m%trica correcto para "u-gar la efectividad de asignaci$n de recursos. Por un lado, la teor#a tras el poder se basa en una red de colas F F? que asume infinitas colas <7ado que este no es un libro de teor#a de
colas, ofrecemos s$lo esta breve descripci$n de una cola F F?. 0l ? significa que tiene un 1nico servidor, y la s significa que la distribuci$n de ambos paquetes llegada y los tiempos de servicio es C arkovianC o e*ponencial=,. redes

real networks have finite buffers and sometimes have to drop packets. .or another, power is typically defined relative to a single connection <flow=, it is not clear how it e*tends to multiple, competing connections. 7espite these rather severe limitations, however, no alternatives have gained wide acceptance, and so power continues to be used. Tenga en cuenta que no es obvio que el poder sea la The ob"ective is to ma*imi-e this ratio, which is a function of how much load you place on the network. The load, in turn, is set by the resource allocation mechanism. .igure >.E gives a representative power curve, where, ideally, the resource allocation mechanism would operate at the peak of this curve. To the left of the peak, the mechanism is being too conservative, that is, it is not allowing enough packets to be sent to keep the links busy. To the right of the peak, so many packets are being allowed into the network that increases in delay due to queuing are starting to dominate any small gains in throughput.

reales tienen buffers finitos y a veces tienen que descartar los paquetes. Por otra, la potencia se define t#picamente en relaci$n con una 1nica cone*i$n <flu"o=, no est' claro c$mo se e*tiende a m1ltiples, las cone*iones de la competencia. + pesar de estas limitaciones m's graves, sin embargo, ninguna alternativa ha ganado una amplia aceptaci$n, y as# poder contin1a siendo utili-ado. 0l ob"etivo es ma*imi-ar esta relaci$n, que es una funci$n de la cantidad de carga que se coloca en la red. &a carga, a su ve-, se establece por el mecanismo de asignaci$n de recursos. &a fig >.E muestra una curva de potencia representativa, donde, idealmente, el mecanismo de asignaci$n de recursos operar#a en el pico de la curva. + la i-quierda del pico, el mecanismo est' siendo demasiado conservador, es decir, no est' permitiendo suficientes paquetes para ser enviados para mantener los enlaces ocupados. + la derecha del pico, muchos paquetes se est' permitiendo en la red que el aumento de retraso debido a las colas est'n empe-ando a dominar las peque5as ganancias en el rendimiento.

/nterestingly, this power curve looks very much like the system throughput curve in a timesharing computer system. 2ystem throughput improves as more "obs are admitted into the system, until it reaches a point when there are so many "obs running that the system begins to thrash <spends all of its time swapping memory pages= and the throughput begins to drop.

(uriosamente, esta curva de potencia se parece mucho a la curva de rendimiento del sistema en un sistema inform'tico de tiempo compartido. 0l rendimiento del sistema me"ora a medida que m's puestos de traba"o son admitidos en el sistema, hasta que llega un momento en que hay tantos puestos de traba"o en e"ecuci$n que el sistema comien-a a agitarse <dedica todo su tiempo intercambiando p'ginas de memoria= y el rendimiento comien-a a disminuir. only very crude ways, that is, it is simply not possible to turn the AknobB a little and allow only a small

+s we will see in later sections of this chapter, many congestion!control schemes are able to control load in

number of additional packets into the network. +s a consequence, network designers need to be concerned about what happens even when the system is operating under e*tremely heavy loadthat is, at the rightmost end of the curve in .igure >.E. /deally, we would like to avoid the situation in which the system throughput goes to -ero because the system is thrashing. /n networking terminology, we want a system that is stablewhere packets continue to get through the network even when the network is operating under heavy load. /f a mechanism is not stable, the network may e*perience congestion collapse. (omo veremos en secciones posteriores de este cap#tulo, muchos esquemas de control de congesti$n Fair Resource )llocation The effective utili-ation of network resources is not the only criterion for "udging a resource allocation scheme. We must also consider the issue of fairness. 9owever, we quickly get into murky waters when we try to define what e*actly constitutes fair resource allocation. .or e*ample, a reservation!based resource allocation scheme provides an e*plicit way to create controlled unfairness. With such a scheme, we might use reservations to enable a video stream to receive ? bps across some link while a file transfer receives only ?M kbps over the same link.

son capaces de controlar carga de una manera 1nica muy crudas, es decir, simplemente no es posible girar el CmandoC un poco y permitir s$lo un peque5o n1mero de paquetes adicionales en la red. (omo consecuencia de ello, los dise5adores de redes deben estar preocupados por lo que sucede incluso cuando el sistema est' operando ba"o muy pesada carga! es decir, en el e*tremo derecho final de la curva en la .igura >.E. /dealmente, nos gustar#a evitar la situaci$n en la que el rendimiento del sistema va a cero porque el sistema est' agit'ndose. 0n la terminolog#a de redes, queremos un sistema que sea estable! donde los paquetes contin1an obteniendo a trav%s de la red, incluso cuando la red est' funcionando ba"o carga pesada. 2i un mecanismo no es estable, la red puede e*perimentar colapso de congesti$n. )si+nacin de Recursos .usto-,quitativa &a utili-aci$n efectiva de los recursos de la red no es el 1nico criterio para "u-gar un esquema de asignaci$n de recursos. Tambi%n debemos considerar la cuesti$n de la equidad. 2in embargo, obtenemos r'pidamente en aguas turbias cuando tratamos de definir lo que constituye e*actamente asignaci$n de recursos equitativa. Por e"emplo, un esquema de asignaci$n de recursos basado en reserva!proporciona una forma e*pl#cita para crear in"usticia controlada. (on este esquema, podr#amos usar reservaciones para permitir un flu"o de v#deo para recibir ? bps a trav%s de alg1n enlace mientras que una transferencia de archivos recibe s$lo ?M kbps sobre el mismo enlace. 0n la ausencia de informaci$n e*pl#cita en contrario, cuando varios flu"os comparten un enlace especial, nos gustar#a para cada flu"o recibir una parte igual del ancho de banda. 0sta definici$n supone que una parte equitativa del ancho de banda significa una parte igual del ancho de banda. Pero, incluso en ausencia de reservaciones, partes iguales no pueden igualar a las acciones "ustas. 7eber#amos considerar tambi%n la longitud de las trayectorias que se est'n comparandoR Por e"emplo, como se ilustra en la .igura >.L, lo que es "usto cuando un flu"o de cuatro saltos est' compitiendo con tres flu"os de un saltoR

/n the absence of e*plicit information to the contrary, when several flows share a particular link, we would like for each flow to receive an equal share of the bandwidth. This definition presumes that a fair share of bandwidth means an equal share of bandwidth. But, even in the absence of reservations, equal shares may not equate to fair shares. 2hould we also consider the length of the paths being comparedR .or e*ample, as illustrated in .igure >.L, what is fair when one four!hop flow is competing with three one!hop flowsR

6n flu"o de cuatro salto compitiendo con tres flu"os de un salto.

+ssuming that fair implies equal and that all paths are of equal length, networking researcher 4a" Sain proposed a metric that can be used to quantify the fairness of a congestion!control mechanism. Sain3s fairness inde* is defined as follows. Tiven a set of flow throughputs <*?,*:, . . . ,*n= <measured in consistent units such as bitsFsecond=, the following function assigns a fairness inde* to the flowsI

2uponiendo que "usto implica igual y que todos los caminos son de igual longitud, investigador de redes 4a" Sain propone una m%trica que se puede utili-ar para cuantificar la imparcialidad de un mecanismo de control de congesti$n. Undice de equidad de Sain se define de la siguiente manera. 7ado un con"unto de rendimientos flu"o <*?, *:, ..., *n= <medido en unidades consistentes, tales como bitsFsegundo=, la siguiente funci$n asigna un #ndice de equidad a las flu"osI

The fairness inde* always results in a number between M and ?, with ? representing greatest fairness. To understand the intuition behind this metric, consider the case where all n flows receive a throughput of ? unit of data per second. We can see that the fairness inde* in this case is

0l #ndice de "usticia siempre resulta en un n1mero entre M y ?, donde ? representa mayor equidad. Para entender la intuici$n detr's de este indicador, considere el caso en que todos los n flu"os reciben un rendimiento de ? unidad de datos por segundo. Podemos ver que el #ndice de "usticia en este caso es

@ow, suppose one flow receives a throughput of ?VW. @ow the fairness inde* is

+hora, supongamos que un flu"o recibe un caudal de ? V W. +hora el #ndice de "usticia es

@ote that the denominator e*ceeds the numerator by <nX?=W:. Thus, whether the odd flow out was getting more or less than all the other flows <positive or negative W=, the fairness inde* has now dropped below one. +nother simple case to consider is where only % of the n flows receive equal throughput, and the remaining n+% users receive -ero throughput, in which case the fairness inde* drops to %,n.

Tenga en cuenta que el denominador e*cede el numerador por <n!?= W:. Por lo tanto, si el flu"o en discordia estaba recibiendo m's o menos que todos los otros flu"os <positivo o negativo W=, el #ndice de "usticia ha ca#do por deba"o de uno. )tro caso simple de tener en cuenta es que s$lo % de los n flu"os reciben el mismo rendimiento, y los usuarios de n!k restantes reciben rendimiento cero, en cuyo caso el #ndice de "usticia cae a kFn.

6.' -UEUIN. /ISCI!LINES (/isci0linas de Cola)


4egardless of how simple or how sophisticated the rest of the resource allocation mechanism is, each router must implement some queuing discipline that governs how packets are buffered while waiting to be transmitted. The queuing algorithm can be thought of as allocating both bandwidth <which packets get transmitted= and buffer space <which packets get discarded=. /t also directly affects the latency e*perienced by a packet by determining how long a packet waits to be transmitted. This section introduces two common queuing algorithmsfirst!in, first!out <./.)= and fair queuing <.H=and identifies several variations that have been proposed. 2in importar cu'n simple o cu'n sofisticado el resto del mecanismo de asignaci$n de recursos es, cada router debe implementar cierta disciplina de colas que gobierna c$mo se almacenan en b1fer los paquetes en espera de ser transmitido. 0l algoritmo de puesta en cola puede ser considerado como la asignaci$n de ambos ancho de banda <que paquetes son transmitidos= y el espacio de b1fer <que paquetes se descartan=. Tambi%n afecta directamente a la latencia e*perimentada por un paquete mediante la determinaci$n de cu'nto tiempo un paquete espera para ser transmitido. 0sta secci$n introduce dos algoritmos de colas comunes primero en entrar, primero en salir <./.)= y de cola "usto <.H= ! e identifica muchas variaciones que se han propuesto.

6.'.1 1I1O (1irst in2 3irst out)


The idea of ./.) queuing, also called first!come, first! served <.(.2= queuing, is simpleI The first packet that arrives at a router is the first packet to be transmitted. This is illustrated in .igure >.;<a=, which shows a ./.) with AslotsB to hold up to eight packets. Tiven that the amount of buffer space at each router is finite, if a packet arrives and the queue <buffer space= is full, then the router discards that packet, as shown in .igure >.;<b=. This is done without regard to which flow the packet belongs to or how important the packet is. This is sometimes called tail drop, since packets that arrive at the tail end of the ./.) are dropped. &a idea de hacer cola ./.), tambi%n llamado primero que llega, primer servido <.(.2= de cola, es simpleI 0l primer paquete que llega a un router es el primer paquete a transmitir. 0sto se ilustra en la .igura >.; <a=, que muestra una ./.) con CslotsC para almacenar hasta ocho paquetes. 7ado que la cantidad de espacio de b1fer en cada router es finito, si un paquete llega y la cola <espacio de b1fer= est' lleno, entonces el router descarta ese paquete, como se muestra en la figura >.; <b=. 0sto se hace sin tener en cuenta cual flu"o de paquete pertenece a o lo importante que es el paquete. + veces se denomina ca#da de la cola, ya que los paquetes que llegan al e*tremo de cola del ./.) se descartan.

@ote that tail drop and ./.) are two separable ideas. ./.) is a scheduling disciplineit determines the order in which packets are transmitted. Tail drop is a drop policyit determines which packets get dropped. Because ./.) and tail drop are the simplest instances of scheduling discipline and drop policy, respectively, they are sometimes viewed as a bundlethe vanilla queuing implementation. 6nfortunately, the bundle is often referred to simply as ./.) queuing, when it should more precisely be called ./.) with tail drop. 2ection >.L provides an e*ample of another drop policy, which uses a more comple* algorithm than A/s there a free bufferRB to decide when to drop packets. 2uch a drop policy may be used with ./.), or with more comple* scheduling disciplines. Tenga en cuenta que la ca#da de cola y ./.) son dos ./.) with tail drop, as the simplest of all queuing algorithms, is the most widely used in /nternet routers at the time of writing. This simple approach to queuing pushes all responsibility for congestion control and resource allocation out to the edges of the network. Thus, the prevalent formof congestion control in the /nternet currently assumes no help from the routersI T(P takes responsibility for detecting and responding to congestion.We will see how this works in 2ection >.E.

ideas separables. ./.) es una disciplina de programaci$n que determina el orden en que se transmiten paquetes. (a#da de cola es una pol#tica de ca#da! determina cuales paquetes ser descartados. Porque ./.) y ca#da de cola son los casos m's simples de la disciplina de la programaci$n y la pol#tica de ca#da, respectivamente, ellos son algunas veces visto como un con"unto! la implementaci$n de cola de vainilla. Por desgracia, el paquete se refiere a menudo simplemente como cola ./.), cuando m's precisamente deber#a llamarse ./.) con ca#da de la cola. 2ecci$n >.L proporciona un e"emplo de otra pol#tica de ca#da, que utili-a un algoritmo m's comple"o que CY0*iste un buffer libreRC para decidir cu'ndo descartar paquetes. Tal pol#tica de ca#da puede ser utili-ada con ./.), o con disciplinas de programaci$n m's comple"as. ./.) con una ca#da de cola, como el m's simple de todos los algoritmos de colas, es el m's utili-ado en los routers de /nternet al momento de la escritura. 0ste enfoque simple para la puesta en cola empu"a toda responsabilidad para control de congesti$n y asignaci$n de recursos a los bordes de la red. Por lo tanto, la forma predominante de control de congesti$n en el /nternet actualmente no asume ninguna ayuda de los routersI T(P asume la responsabilidad de detectar y responder a la congesti$n. Gamos a ver c$mo funciona esto en la secci$n >.E. of the highest!priority queue if that queue is nonempty before moving on to the ne*t priority queue. Within each priority, packets are still managed in a ./.) manner. This idea is a small departure from the best! effort delivery model, but it does not go so far as to make guarantees to any particular priority class. /t "ust

+ simple variation on basic ./.) queuing is priority queuing. The idea is to mark each packet with a priority, the mark could be carried, for e*ample, in the /P header, as we3ll discuss in 2ection >.;.E. The routers then implement multiple ./.) queues, one for each priority class. The router always transmits packets out

allows high!priority packets to cut to the front of the line. 6na variaci$n simple en cola b'sica ./.) es la prioridad de cola. &a idea es marcar cada paquete con una prioridad, la marca podr#a llevarse, por e"emplo, en la cabecera /P, como veremos en la 2ecci$n >.;.E. &os routers entonces implementan m1ltiples colas ./.), una por cada clase de prioridad. 0l router siempre The problem with priority queuing, of course, is that the high!priority queue can starve out all the other queues, that is, as long as there is at least one high! priority packet in the high!priority queue, lower! priority queues do not get served. .or this to be viable, there need to be hard limits on how much high!priority traffic is inserted in the queue. /t should be immediately clear that we can3t allow users to set their own packets to high priority in an uncontrolled way, we must either prevent them from doing this altogether or provide some form of ApushbackB on users. )ne obvious way to do this is to use economicsthe network could charge more to deliver high!priority packets than low!priority packets. 9owever, there are significant challenges to implementing such a scheme in a decentrali-ed environment such as the /nternet.

transmite paquetes fuera de la cola de mayor prioridad si esa cola no est' vac#a, antes de pasar a la siguiente cola de prioridad. 7entro de cada prioridad, los paquetes a1n se gestionan de una manera ./.). 0sta idea es una peque5a desviaci$n del modelo de entrega de me"or esfuer-o, pero no va tan le"os como para hacer garant#as de cualquier clase de prioridad particular. 2$lo permite que los paquetes de alta prioridad para cortar al frente de la l#nea. 0l problema con la cola de prioridad, por supuesto, es que la cola de alta prioridad puede matar de hambre a todas las otras colas, es decir, siempre que haya por lo menos un paquete de alta prioridad en la cola de alta prioridad, colas de menor prioridad no te sirven. Para que esto sea viable, es necesario que e*istan l#mites estrictos sobre la cantidad de tr'fico de alta prioridad es insertado en la cola. 7ebe quedar claro de inmediato que no podemos permitir a los usuarios configurar sus propios paquetes de alta prioridad de forma incontrolada, debemos evitar que cualquiera de ellos hagan esto en con"unto o proporcionar alg1n tipo de CretrocesoC en los usuarios. 6na manera obvia de hacerlo es utili-ar la econom#a! la red podr#a cobrar m's para entregar los paquetes de alta prioridad que los paquetes de ba"a prioridad. 2in embargo, e*isten importantes desaf#os para la implementaci$n de un esquema de este tipo en un entorno descentrali-ado, tales como /nternet. 6na situaci$n en la que la cola de prioridad se utili-a en la /nternet es para proteger a los m's importantes paquetes! t#picamente, las actuali-aciones de enrutamiento que son necesarias para estabili-ar las tablas de enrutamiento despu%s de un cambio de topolog#a. + menudo hay una cola especial para este tipo de paquetes, que puede ser identificado por el ($digo de 2ervicios 7iferenciados Point <anteriormente el campo T)2= de la cabecera /P. 0sto es, de hecho, un simple caso de la idea de los Cservicios diferenciados,C el ob"eto de la 2ecci$n >.;.E.

)ne situation in which priority queuing is used in the /nternet is to protect the most important packets typically, the routing updates that are necessary to stabili-e the routing tables after a topology change. )ften there is a special queue for such packets, which can be identified by the 7ifferentiated 2ervices (ode Point <formerly the T)2 field= in the /P header. This is in fact a simple case of the idea of A7ifferentiated 2ervices,B the sub"ect of 2ection >.;.E.

6.'.' 1I1O (1irst in2 3irst out)


The main problem with ./.) queuing is that it does not discriminate between different traffic sources, or, in the language introduced in the previous section, it does not separate packets according to the flow to which they belong. This is a problem at two different levels. +t one level, it is not clear that any congestion!control algorithm implemented entirely at the source will be able to adequately control congestion with so little help from the routers. We will suspend "udgment on this point until the ne*t section when we discuss T(P congestion control. +t another level, because the entire congestion!control mechanism is implemented at the sources and ./.) queuing does not provide a means to police how well the sources adhere to this mechanism, it is possible for an ill!behaved source <flow= to capture an arbitrarily large fraction of the network capacity. (onsidering the /nternet again, it is certainly possible for a given application not to use T(P and, as a consequence, to bypass its end!to!end congestion! control mechanism. <+pplications such as /nternet telephony do this today.= 2uch an application is able to flood the /nternet3s routers with its own packets, thereby causing other applications3packets to be discarded. 0l principal problema con colas ./.) es que no discrimina entre diferentes fuentes de tr'fico, o, en el lengua"e introducido en el apartado anterior, no separa paquetes de acuerdo con el flu"o a la cual pertenecen. 0ste es un problema en dos niveles diferentes. Por un lado, no est' claro que cualquier algoritmo de control de congesti$n implementado por completo en la fuente

ser' capa- de controlar adecuadamente la congesti$n con tan poca ayuda de los routers. Gamos a suspender el "uicio sobre este punto hasta la siguiente secci$n cuando hablamos de control de congesti$n T(P. 0n otro nivel, ya que todo el mecanismo de control de congesti$n se implementa en las fuentes y de cola ./.) no proporciona un medio para la pol#tica de que tan bien las fuentes se adhieren a este mecanismo, es posible para una fuente de mal comportamiento <flu"o= .air queuing <.H= is an algorithm that has been proposed to address this problem. The idea of .H is to maintain a separate queue for each flow currently being handled by the router. The router then services these queues in a sort of round!robin, as illustrated in .igure >.>. When a flow sends packets too quickly, then its queue fills up. When a queue reaches a particular length, additional packets belonging to that flow3s queue are discarded. /n this way, a given source cannot arbitrarily increase its share of the network3s capacity at the e*pense of other flows.

capturar arbitrariamente una grande fracci$n de la capacidad de la red. Teniendo en cuenta la /nternet de nuevo, es ciertamente posible para una aplicaci$n dada no utili-ar T(P y, como consecuencia, eludir su mecanismo de control de congesti$n de e*tremo a e*tremo. Tal aplicaci$n es capa- de inundar los routers de /nternet con sus propios paquetes, provocando de esta manera paquetes de otras aplicaciones sean desechados. 0ncolamiento "usto <.H= es un algoritmo que se ha propuesto para abordar este problema. &a idea de .H es mantener una cola separada para cada flu"o actualmente siendo mane"ado por el router. 0l router entonces los servicios de estas colas en una especie de por turnos, como se ilustra en la .igura >.>. (uando un flu"o env#a paquetes demasiado r'pido, entonces la cola se llena. (uando una cola alcan-a una longitud particular, los paquetes adicionales que pertenecen a la cola de ese flu"o se descartan. 7e esta manera, una fuente dada no puede aumentar arbitrariamente su cuota de la capacidad de la red a costa de otros flu"os.

@ote that .H does not involve the router telling the traffic sources anything about the state of the router or in any way limiting how quickly a given source sends packets. /n other words, .H is still designed to be used in con"unction with an end!to!end congestion!control mechanism. /t simply segregates traffic so that ill! behaved traffic sources do not interfere with those that are faithfully implementing the end!to!end algorithm. .H also enforces fairness among a collection of flows managed by a well!behaved congestion!control algorithm.

Tenga en cuenta que .H no implica el router diciendo la fuentes de tr'fico nada sobre el estado del router o limitar en forma alguna la rapide- con determinada fuente env#a paquetes. 0n otras palabras, .H est' a1n dise5ado para ser utili-ado en con"unci$n con un mecanismo de control de congesti$n de e*tremo a e*tremo. 2implemente segrega tr'fico para que fuentes de tr'fico de mal comportamiento no interfieran con los que est'n implementando fielmente el algoritmo de e*tremo a e*tremo. .H tambi%n hace cumplir la "usticia entre una colecci$n de flu"os gestionados por un algoritmo de control de congesti$n de buen comportamiento. peque5o n1mero de detalles que hay que hacerlo bien. &a principal complicaci$n es que los paquetes que est'n siendo procesados en un router no son necesariamente la misma longitud. Para asignar realmente el ancho de banda del enlace de salida de una manera "usta, es necesario tener en cuenta la longitud del paquete. Por e"emplo, si un router est' gestionando dos flu"os, uno con paquetes de ?.MMM bytes y el otro con paquetes de de ;MM bytes <tal vedebido a la fragmentaci$n arriba de este router=, a continuaci$n, un sencillo servicio por turnos de los paquetes de la cola de cada flu"o dar' el primer flu"o dos tercios de ancho de banda del enlace y el segundo flu"o s$lo un tercio de su ancho de banda.

+s simple as the basic idea is, there are still a modest number of details that you have to get right. The main complication is that the packets being processed at a router are not necessarily the same length. To truly allocate the bandwidth of the outgoing link in a fair manner, it is necessary to take packet length into consideration. .or e*ample, if a router is managing two flows, one with ?MMM!byte packets and the other with ;MM!byte packets <perhaps because of fragmentation upstream from this router=, then a simple round!robin servicing of packets from each flow3s queue will give the first flow two!thirds of the link3s bandwidth and the second flow only one!third of its bandwidth. Tan simple como la idea b'sica es, todav#a hay un

What we really want is bit!by!bit round!robin, where the router transmits a bit from flow ?, then a bit from flow :, and so on. (learly, it is not feasible to interleave the bits from different packets. The .H mechanism therefore simulates this behavior by first determining when a given packet would finish being transmitted if itwere being sent using bit!by!bit round! robin and then using this finishing time to sequence the packets for transmission. To understand the algorithm for appro*imating bit!by! bit roundrobin, consider the behavior of a single flow and imagine a clock that ticks once each time one bit is transmitted from all of the active flows. <+ flow is active when it has data in the queue.= .or this flow, let Pi denote the length of packet i, let 2i denote the time when the router starts to transmit packet i, and let .i denote the time when the router finishes transmitting packet i. /f Pi is e*pressed in terms of how many clock ticks it takes to transmit packet i <keeping in mind that time advances ? tick each time this flow gets ? bit3s worth of service=, then it is easy to see that .i O 2i VPi. Para entender el algoritmo para la apro*imaci$n de When do we start transmitting packet iR The answer to this question depends on whether packet i arrived before or after the router finished transmitting packet iX? from this flow. /f it was before, then logically the first bit of packet i is transmitted immediately after the last bit of packet iX?. )n the other hand, it is possible that the router finished transmitting packet iX? long before i arrived, meaning that there was a period of time during which the queue for this flow was empty, so the round!robin mechanism could not transmit any packets from this flow. /f we let +i denote the time that packet i arrives at the router, then 2i O ma*<.iX?,+i=. Thus, we can compute

&o que realmente queremos es bit a bit por turnos, donde el router transmite un bit desde flu"o ?, luego un bit desde flu"o :, y as# sucesivamente. 0videntemente, no es factible intercalar los bits de diferentes paquetes. Por consiguiente, el mecanismo de .H simula este comportamiento determinando en primer lugar, cuando un determinado paquete terminar#a siendo transmitida si se estuviera enviado a trav%s de bit a bit por turnos y despu%s de usar este tiempo final a la secuencia de los paquetes para su transmisi$n. operaci$n por turnos bit a bit, considerar el comportamiento de un solo flu"o e imaginar un relo" que marca una ve- cada ve- que un bit es transmitido desde todos los flu"os activos. <6n flu"o est' activo cuando tiene datos en la cola.= Para este flu"o, vamos a permitir que !i denote la longitud del paquete i, Si denota el momento en que el router comien-a a transmitir el paquete i, y 1i denota el momento en que el router termina de transmitir el paquete i. 2i !i est' e*presado en t%rminos de la cantidad de ciclos de relo" que se necesita para transmitir el paquete i <teniendo en cuenta que el tiempo avan-a ? tick cada ve- que este flu"o pone ? el valor de bit de servicio=, entonces es f'cil ver que Fi / Si 0 Pi. Y(u'ndo empe-amos a transmitir el paquete iR &a respuesta a esta pregunta depende de si el paquete i lleg$ antes o despu%s de que el router terminado de transmitir el paquete i!? desde este flu"o. 2i estaba antes, entonces l$gicamente el primer bit del paquete i es transmitido inmediatamente despu%s del 1ltimo bit de un paquete i!?. Por otro lado, es posible que el router termine de transmitir el paquete i!? mucho antes de que i llegu%, lo que significa que hubo un per#odo de tiempo durante el cual la cola para este flu"o fue vac#o, por lo que el mecanismo por turnos no pod#a transmitir cualquier paquetes desde este flu"o. 2i permitimos +i denota el tiempo que el paquete i llega al router, entonces podemos calcular . Por lo tanto,

@ow we move on to the situation in which there is more than one flow, and we find that there is a catch to determining +i. We can3t "ust read the wall clock when the packet arrives. +s noted above, we want time to advance by one tick each time all the active flows get one bit of service under bit!by!bit round!robin, so we need a clock that advances more slowly when there are more flows. 2pecifically, the clock must advance by one tick when n bits are transmitted if there are n active flows. This clock will be used to calculate +i. @ow, for every flow, we calculate .i for each packet that arrives using the above formula. We then treat all the .i as timestamps, and the ne*t packet to transmit is always the packet that has the lowest timestamp the packet that, based on the above reasoning, should

+hora pasamos a la situaci$n en la que hay m's de un flu"o, y nos encontramos con que hay un obst'culo para determinar +i. @o podemos limitarnos a leer el relo" de pared cuando llega el paquete. (omo se se5al$ anteriormente, queremos tiempo para avan-ar por un tic cada ve- que todos los flu"os activos obtienen un bit de servicio ba"o bit!por!bit por turnos, por lo que necesitamos un relo" que avan-a m's lentamente cuando hay m's flu"os. 0spec#ficamente, el relo" debe avan-ar por un tick cuando n bits se transmiten si hay n flu"os activos. 0ste relo" se utili-a para calcular +i. finish transmission before all others. +hora, para cada flu"o, se calcula .i para cada paquete que llega utili-ando la f$rmula anterior. + continuaci$n, tratamos todos los .i como marcas de

tiempo, y el siguiente paquete a transmitir es siempre el paquete que tiene el menor timestamp!el paquete que, @ote that this means that a packet can arrive on a flow, and, because it is shorter than a packet from some other flow that is already in the queue waiting to be transmitted, it can be inserted into the queue in front of that longer packet. 9owever, this does not mean that a newly arriving packet can preempt a packet that is currently being transmitted. /t is this lack of preemption that keeps the implementation of .H "ust described from e*actly simulating the bit!by!bit round! robin scheme that we are attempting to appro*imate. Tenga en cuenta que esto significa que un paquete To better see how this implementation of fair queuing works, consider the e*ample given in .igure >.K. Part <a= shows the queues for two flows, the algorithm selects both packets from flow ? to be transmitted before the packet in the flow : queue, because of their earlier finishing times. /n <b=, the router has already begun to send a packet from flow : when the packet from flow ? arrives. Though the packet arriving on flow ? would have finished before flow : if we had been using perfect bit!by!bit fair queuing, the implementation does not preempt the flow : packet.

basado en el ra-onamiento anterior, deber#a terminar la transmisi$n antes de todas los dem's. puede llegar en un flu"o, y, debido a que es m's corto que un paquete de alg1n otro flu"o que ya est' en la cola de esperando ser transmitida, que se puede insertar en la cola en frente de ese paquete m's largo . 2in embargo, esto no significa que un paquete reci%n llegado puede anticiparse a un paquete que se est' transmitiendo actualmente. 0s esta falta de tanteo que mantiene la implementaci$n de .H que acabamos de describir desde la simulaci$n e*actamente el esquema de bit a bit por turnos que estamos tratando de apro*imar. Para ver me"or c$mo esta implementaci$n de encolamiento "usto traba"a, considere el e"emplo de la .igura >.K. &a parte <a= muestra las colas de dos flu"os, el algoritmo selecciona tanto paquetes desde flu"o ? a ser transmitidos antes del paquete en la cola flu"o :, debido a su anterior tiempos de acabado. 0n <b=, el router ya ha comen-ado a enviar un paquete desde flu"o : cuando el paquete desde flu"o ? llega. +unque el paquete que llega en el flu"o de ? habr#a terminado antes de flu"o : si hubi%ramos estado utili-ando encolamiento "usto perfecto bit a bit, la implementaci$n no reempla-a el paquete de flu"o :.

0"emplo de colas equitativa en acci$nI <a= &os paquetes con los tiempos de acabado anteriores se env#an primero, <b= el env#o de un paquete ya en curso se ha completado. There are two things to notice about fair queuing. .irst, the link is never left idle as long as there is at least one packet in the queue. +ny queuing scheme with this characteristic is said to be work conserving. )ne effect of being work conserving is that if / am sharing a link with a lot of flows that are not sending any data then, / can use the full link capacity for my flow. +s soon as the other flows start sending, however, they will start to use their share and the capacity available to my flow will drop. 9ay dos cosas a destacar sobre de cola "usta. 0n primer lugar, el enlace no se de"a inactivo siempre que haya al menos un paquete en la cola. (ualquier esquema de cola con esta caracter#stica se dice que est' (onservando traba"o. 6no de los efectos de estar (onservando traba"o es que si yo estoy compartiendo un enlace con una gran cantidad de flu"os que no est'n enviando ning1n dato entonces, Puedo usar la capacidad del enlace completo para mi flu"o. Tan pronto como los otros flu"os empiecen a mandar, sin embargo, van a empe-ar a utili-ar su cuota y la capacidad disponible para mi flu"o se reducir'.

The second thing to notice is that if the link is fully loaded and there are n flows sending data, / cannot use more than ?Fnth of the link bandwidth. /f / try to send more than that, my packets will be assigned increasingly large timestamps, causing them to sit in the queue longer awaiting transmission. 0ventually, the queue will overflowalthough whether it is my packets or someone else3s that are dropped is a decision that is not determined by the fact that we are using fair queuing. This is determined by the drop policy, .H is a scheduling algorithm, which, like ./.), may be combined with various drop policies.

&a segunda cosa a notar es que si el enlace est' totalmente cargado y hay n flu"os el env#o de datos, no puedo usar m's de ?Fnth del ancho de banda del enlace. 2i trato de enviar m's de eso, mis paquetes se asignan cada ve- m's grandes marcas de tiempo, haciendo que se sientan en la cola m's tiempo esperando la transmisi$n. (on el tiempo, la cola se desbordar'! aunque si se trata de mis paquetes o de otra persona que se caen es una decisi$n que no est' determinado por el hecho de que estamos utili-ando colas "usto.

0sto se determina por la pol#tica de ca#da, .H es un algoritmo de planificaci$n, que, como ./.), se puede Because .H is work conserving, any bandwidth that is not used by one flow is automatically available to other flows. .or e*ample, if we have four flows passing through a router, and all of them are sending packets, then each one will receive one!quarter of the bandwidth. But, if one of them is idle long enough that all its packets drain out of the router3s queue, then the available bandwidth will be shared among the remaining three flows, which will each now receive one!third of the bandwidth. Thus, we can think of .H as providing a guaranteed minimum share of bandwidth to each flow, with the possibility that it can get more than its guarantee if other flows are not using their shares.

combinar con varias pol#ticas de ca#da. 7ebido a .H est' conservando el traba"o, cualquier ancho de banda que no se utili-a por un flu"o est' disponible autom'ticamente a otros flu"os. Por e"emplo, si tenemos cuatro flu"os que pasan a trav%s de un router, y todos ellos estamos enviando paquetes, entonces cada uno recibir' una cuarta parte del ancho de banda. Pero, si uno de ellos est' inactivo tanto tiempo que todos sus paquetes drenan de la cola del router, entonces el ancho de banda disponible se repartir' entre los tres flu"os restantes, lo que cada uno ahora recibir'n un tercio del ancho de banda. Por lo tanto, podemos pensar en .H como proporcionar una cuota m#nima garanti-ada de ancho de banda para cada flu"o, con la posibilidad de que pueda obtener m's de la garant#a en caso de otros flu"os no est'n utili-ando sus acciones. 0s posible implementar una variaci$n de .H, llamada colas equitativa ponderada <W.H=, que permite que un peso se asigna a cada flu"o <cola=. 0ste peso l$gicamente especifica el n1mero de bits a transmitir cada ve- que el router servicios de esa cola, que controla efectivamente el porcenta"e de ancho de banda del enlace que ese flu"o obtendr'. .H simple da cada cola un peso de ?, lo que significa que l$gicamente s$lo ? bit se transmite desde cada cola cada ve-. 0sto se traduce en cada flu"o recibiendo ?Fnth del ancho de banda cuando hay n flu"os. (on W.H, sin embargo, una cola podr#a tener un peso de :, una segunda cola puede tener un peso de ?, y tercera cola puede tener un peso de E. 2uponiendo que cada cola siempre contiene un paquete a la espera de ser transmitido, el primer flu"o obtendr' un tercio del ancho de banda disponible, el segundo obtendr' un se*to del ancho de banda disponible, y el tercero obtendr' la mitad del ancho de banda disponible.

/t is possible to implement a variation of .H, called weighted fair queuing <W.H=, that allows a weight to be assigned to each flow <queue=. This weight logically specifies how many bits to transmit each time the router services that queue, which effectively controls the percentage of the link3s bandwidth that that flow will get. 2imple .H gives each queue a weight of ?, which means that logically only ? bit is transmitted from each queue each time around. This results in each flow getting ?Fnth of the bandwidth when there are n flows.With W.H, however, one queue might have a weight of :, a second queue might have a weight of ?, and a third queue might have a weight of E. +ssuming that each queue always contains a packet waiting to be transmitted, the first flow will get one!third of the available bandwidth, the second will get one!si*th of the available bandwidth, and the third will get one!half of the available bandwidth.

While we have described W.H in terms of flows, note that it could be implemented on classes of traffic, where classes are defined in some other way than the simple flows introduced at the start of this chapter. .or e*ample, we could use some bits in the /P header to identify classes and allocate a queue and a weight to each class. This is e*actly what is proposed as part of the 7ifferentiated 2ervices architecture described in 2ection >.;.E. @ote that a router performing W.H must learn what weights to assign to each queue from somewhere, either by manual configuration or by some sort of signalling from the sources. /n the latter case, we are moving toward a reservation!based model. Sust assigning a weight to a queue provides a rather weak form of reservation because these weights are only indirectly related to the bandwidth the flow receives. <The bandwidth available to a flow also depends, for

+unque se han descrito W.H en t%rminos de flu"os, tenga en cuenta que se podr#a implementar en las clases de tr'fico, donde las clases se definen de alguna otra manera que los flu"os simples introducidas en el inicio de este cap#tulo. Por e"emplo, podr#amos utili-ar una serie de bits en el encabe-ado /P para identificar las clases y asignar una cola y un peso a cada clase. 0sto es e*actamente lo que se propone como parte de la arquitectura de servicios diferenciados se describe en la 2ecci$n >.;.E. e*ample, on how many other flows are sharing the link.= We will see in 2ection >.;.: how W.H can be used as a component of a reservation!based resource allocation mechanism. Tenga en cuenta que un router reali-ando W.H debe aprender que pesos asignar a cada cola de alguna parte, ya sea por configuraci$n manual o por alg1n tipo de

se5ali-aci$n de las fuentes. 0n este 1ltimo caso, nos estamos moviendo hacia un modelo basado en la reserva. 2$lo asignando un peso a una cola proporciona una forma m's bien d%bil de la reserva debido a que estos pesos son s$lo indirectamente relacionados con el ancho de banda del flu"o recibe. <0l ancho de banda .inally, we observe that this whole discussion of queue management illustrates an important system design principle known as separating policy and mechanism. The idea is to view each mechanism as a black bo* that provides a multifaceted service that can be controlled by a set of knobs. + policy specifies a particular setting of those knobs but does not know <or care= about how the black bo* is implemented. /n this case, the mechanism in question is the queuing discipline, and the policy is a particular setting of which flow gets what level of service <e.g., priority or weight=. We discuss some policies that can be used with the W.H mechanism in 2ection >.;.

disponible para un flu"o depende tambi%n, por e"emplo, de c$mo muchos otros flu"os est'n compartiendo el enlace.= Geremos en la 2ecci$n >.;.: c$mo W.H se puede utili-ar como un componente de un mecanismo de asignaci$n de recursos basado en reserva. Por 1ltimo, se observa que toda esta discusi$n sobre la gesti$n de colas ilustra un importante principio de dise5o de sistema conocido como la separaci$n de la pol#tica y mecanismo. &a idea es ver cada mecanismo como un cuadro negro que proporciona un servicio de m1ltiples facetas que puede ser controlado por un con"unto de botones. 6na pol#tica espec#fica una configuraci$n particular de los mandos, pero no sabe <o atenci$n= sobre c$mo se implementa el cuadro negro. 0n este caso, el mecanismo en cuesti$n es la disciplina de colas, y la pol#tica es un escenario particular de la que el flu"o obtiene qu% nivel de servicio <por e"emplo, prioridad o peso=. 2e discuten algunas de las pol#ticas que se pueden utili-ar con el mecanismo W.H en la secci$n >.;.

6.) C! CON.ES ION CON ROL (Control de Congestin C!)


This section describes the predominant e*ample of end!to!end congestion control in use today, that implemented by T(P. The essential strategy of T(P is to send packets into the network without a reservation and then to react to observable events that occur. T(P assumes only ./.) queuing in the network3s routers, but also works with fair queuing. 0n esta secci$n se describe el e"emplo predominante de control de e*tremo a e*tremo de la congesti$n en uso hoy en d#a, que implementa T(P. &a estrategia esencial de T(P es el env#o de paquetes en la red sin reservaci$n y luego reaccionar a eventos observables que se producen. T(P asume s$lo colas ./.) en los routers de la red, pero tambi%n traba"a con cola equitativa. finales de ?Z[M por Gan Sacobson, apro*imadamente ocho a5os despu%s de que la pila de protocolos T(PF/P hab#a entrado en funcionamiento. /nmediatamente antes de este tiempo, la /nternet estaba sufriendo de colapso de congesti$n!hosts podr#an enviar sus paquetes en /nternet tan r'pido como la ventana anunciada permitir#a que, la congesti$n se producir#a en alg1n enrutador <causando paquetes sean descartados=, y los hosts tendr#a tiempo de espera y retransmisi$n de sus paquetes, lo que resulta en m's congesti$n. any given source must be able to ad"ust the number of packets it has in transit. This section describes the algorithms used by T(P to address these and other problems.

T(P congestion control was introduced into the /nternet in the late ?Z[Ms by Gan Sacobson, roughly eight years after the T(PF/P protocol stack had become operational. /mmediately preceding this time, the /nternet was suffering from congestion collapsehosts would send their packets into the /nternet as fast as the advertised window would allow, congestion would occur at some router <causing packets to be dropped=, and the hosts would time out and retransmit their packets, resulting in even more congestion. (ontrol de congesti$n T(P se introdu"o en /nternet a Broadly speaking, the idea of T(P congestion control is for each source to determine how much capacity is available in the network, so that it knows how many packets it can safely have in transit. )nce a given source has this many packets in transit, it uses the arrival of an +(\ as a signal that one of its packets has left the network and that it is therefore safe to insert a new packet into the network without adding to the level of congestion. By using +(\s to pace the transmission of packets, T(P is said to be self! clocking. )f course, determining the available capacity in the first place is no easy task. To make matters worse, because other connections come and go, the available bandwidth changes over time, meaning that

0n t%rminos generales, la idea de control de congesti$n del T(P es para cada fuente determinar la cantidad de capacidad disponible en la red, para que cono-ca cu'ntos paquetes puede tener con seguridad en el tr'nsito. 6na ve- una fuente determinada tiene esta cantidad de paquetes en tr'nsito, utili-a la llegada de un +(\ como una se5al de que uno de sus paquetes ha

de"ado la red y que por lo tanto es seguro insertar un nuevo paquete en la red sin agregar al nivel de congesti$n. ediante el uso de +(\s para marcar el paso de la transmisi$n de paquetes, el T(P se dice que est' auto sincroni-ado. Por supuesto, la determinaci$n de la capacidad disponible en el primer lugar no es una tarea f'cil. Para empeorar las cosas, debido al resto de @ote that, although we describe the T(P congestion! control mechanisms one at a time, thereby giving the impression that we are talking about three independent mechanisms, it is only when they are taken as a whole that we have T(P congestion control. +lso, while we are going to begin here with the variant of T(P congestion control most often referred to as standard T(P, we will see that there are actually quite a few variants of T(P congestion control in use today, and researchers continue to e*plore new approaches to addressing this problem. 2ome of these new approaches are discussed below.

cone*iones van y vienen, el ancho de banda disponible cambia con el tiempo, lo que significa que cualquier fuente debe ser capa- de a"ustar el n1mero de paquetes que tiene en tr'nsito. 0n esta secci$n se describen los algoritmos utili-ados por T(P para abordar estos y otros problemas. Tenga en cuenta que, aunque se describen los mecanismos de control de congesti$n del T(P de uno en uno, dando as# la impresi$n de que estamos hablando de tres mecanismos independientes, es s$lo cuando se toman como un todo que tenemos control de congesti$n T(P. adem's, mientras que vamos a empe-ar aqu# con la variante de control de congesti$n T(P con mayor frecuencia se hace referencia a T(P como est'ndar, veremos que en realidad hay un buen n1mero de variantes de control de congesti$n T(P en uso hoy en d#a, y los investigadores contin1an e*plorando nuevos enfoques para abordar este problema. +lgunos de estos nuevos enfoques se discuten a continuaci$n.

6.).1 Additi*e Increase,&ulti0licati*e /ecrease (Incre#ento Aditi*o,/ecre#ento &ulti0licati*o)


T(P maintains a new state variable for each connection, called (ongestionWindow, which is used by the source to limit how much data it is allowed to have in transit at a given time. The congestion window is congestion control3s counterpart to flow control3s advertised window. T(P is modified such that the ma*imum number of bytes of unacknowledged data allowed is now the minimum of the congestion window and the advertised window. Thus, using the variables defined in 2ection ;.:.L, T(P3s effective window is revised as followsI T(P mantiene una nueva variable de estado para cada cone*i$n, llamada (ongestionWindow, que es utili-ado por la fuente para limitar la cantidad de datos que se le permite tener en tr'nsito en un momento dado. &a ventana de congesti$n es la contraparte de control de congesti$n a la ventana anunciada de control de flu"o. T(P est' modificado de tal manera que el n1mero m'*imo de bytes de datos no reconocidos permitido es ahora el m#nimo de la ventana de congesti$n y la ventana anunciada. Por lo tanto, el uso de las variables definidas en la 2ecci$n ;.:.L, ventana efectiva de T(P se revisa la siguiente maneraI

That is, a*Window replaces +dvertisedWindow in the calculation of 0ffectiveWindow. Thus, a T(P source is allowed to send no faster than the slowest componentthe network or the destination hostcan accommodate. The problem, of course, is how T(P comes to learn an appropriate value for (ongestionWindow. 6nlike the +dvertisedWindow, which is sent by the receiving side of the connection, there is no one to send a suitable (ongestionWindow to the sending side of T(P. The answer is that the T(P source sets the (ongestionWindow based on the level of congestion it perceives to e*ist in the network. This involves decreasing the congestion window when the level of congestion goes up and increasing the congestion

0s decir, a*Window reempla-a +dvertisedWindow en el c'lculo de 0ffectiveWindow. Por lo tanto, una fuente T(P podr' enviar no m's r'pido que la capacidad del componente m's lento ! la red o el host de destino!. window when the level of congestion goes down. Taken together, the mechanism is commonly called additive increaseFmultiplicative decrease <+/ 7=, the reason for this mouthful of a name will become apparent below. 0l problema, por supuesto, es c$mo viene T(P para aprender un valor apropiado para (ongestionWindow. + diferencia de la +dvertisedWindow, que se env#a por el lado receptor de la cone*i$n, no hay nadie para

enviar un (ongestionWindow adecuada para el lado emisor de T(P. &a respuesta es que la fuente T(P establece la (ongestionWindow basado en el nivel de congesti$n que percibe que e*isten en la red. 0sto implica la disminuci$n de la ventana de congesti$n cuando el nivel de congesti$n sube y el aumento de la The key question, then, is how does the source determine that the network is congested and that it should decrease the congestion windowR The answer is based on the observation that the main reason packets are not delivered, and a timeout results, is that a packet was dropped due to congestion. /t is rare that a packet is dropped because of an error during transmission. Therefore, T(P interprets timeouts as a sign of congestion and reduces the rate at which it is transmitting. 2pecifically, each time a timeout occurs, the source sets (ongestionWindow to half of its previous value. This halving of the (ongestionWindow for each timeout corresponds to the Amultiplicative decreaseB part of +/ 7. +lthough (ongestionWindow is defined in terms of bytes, it is easiest to understand multiplicative decrease if we think in terms of whole packets. .or e*ample, suppose the (ongestionWindow is currently set to ?> packets. /f a loss is detected, (ongestionWindow is set to [. <@ormally, a loss is detected when a timeout occurs, but as we see below, T(P has another mechanism to detect dropped packets.= +dditional losses cause (ongestionWindow to be reduced to L, then :, and finally to ? packet. (ongestionWindow is not allowed to fall below the si-e of a single packet, or in T(P terminology, the ma*imum segment si-e < 22=.

ventana de congesti$n cuando el nivel de congesti$n disminuye. 0n con"unto, el mecanismo es com1nmente llamado incremento aditivoFdisminuci$n multiplicativa <+/ 7=, la ra-$n de esto bocado de un nombre se pondr' de manifiesto a continuaci$n. &a pregunta clave es, entonces, Yc$mo determinar el origen de que la red est' congestionada y que deber#a disminuir la ventana de congesti$nR &a respuesta est' basada en la observaci$n de que la ra-$n principal por que los paquetes no se entregan, y un tiempo de espera resulta, es que el paquete fue abandonado debido a la congesti$n. 0s raro que un paquete sea descartado debido a un error durante la transmisi$n. Por lo tanto, los tiempos de espera de T(P se interpreta como una se5al de congesti$n y reduce la velocidad a la que se est' transmitiendo. 0spec#ficamente, cada ve- que se produce un tiempo de espera, la fuente establece (W@7 a la mitad de su valor anterior. 0sta reducci$n a la mitad de la (W@7 para cada tiempo de espera corresponde a la parte Cdisminuci$n multiplicativoC de +/ 7. +unque (ongestionWindow se define en t%rminos de bytes, es m's f'cil de entender disminuci$n multiplicativo si pensamos en t%rminos de paquetes enteros. Por e"emplo, supongamos que el (ongestionWindow actualmente est' establecida en ?> paquetes. 2i se detecta una p%rdida, (ongestionWindow se establece en [. <@ormalmente, se detecta una p%rdida cuando se produce un tiempo de espera, pero como vemos a continuaci$n, T(P tiene otro mecanismo para detectar paquetes perdidos.= &as p%rdidas adicionales hacen que (ongestionWindow se redu-ca a L, luego :, y finalmente a ? paquete. (ongestionWindow no se le permite caer por deba"o del tama5o de un 1nico paquete, o en la terminolog#a de T(P, el tama5o m'*imo de segmento < 22=. 6na estrategia de control de congesti$n que s$lo disminuye el tama5o de la ventana es, obviamente, demasiado conservador. Tambi%n tenemos que ser capaces de aumentar la ventana de congesti$n para tomar venta"a de la nueva capacidad disponible en la red. 0sta es la parte Cincremento aditivoC de +/ 7, y funciona de la siguiente manera. (ada ve- que la fuente env#a con %*ito el valor de un (ongestionWindow de paquetes! es decir, cada paquete enviado durante el 1ltimo tiempo de ida y vuelta <4TT= ha sido +(\ed! se agrega el equivalente de ? paquete a (ongestionWindow. 0ste aumento lineal se ilustra en la .igura >.[. Tenga en cuenta que, en la pr'ctica, el T(P no espera por un valor de la ventana completa de +(\s para a5adir ? valor de paquetes a la ventana de congesti$n, sino que incrementa (ongestionWindow por un poco para cada +(\ que llega. 0n concreto, la ventana de congesti$n se incrementa de la siguiente manera cada ve- que llega un +(\I

+ congestion!control strategy that only decreases the window si-e is obviously too conservative. We also need to be able to increase the congestion window to take advantage of newly available capacity in the network. This is the Aadditive increaseB part of +/ 7, and it works as follows. 0very time the source successfully sends a (ongestionWindow3s worth of packetsthat is, each packet sent out during the last round!trip time <4TT= has been +(\edit adds the equivalent of ? packet to (ongestionWindow. This linear increase is illustrated in .igure >.[. @ote that, in practice, T(P does not wait for an entire window3s worth of +(\s to add ? packet3s worth to the congestion window, but instead increments (ongestionWindow by a little for each +(\ that arrives. 2pecifically, the congestion window is incremented as follows each time an +(\ arrivesI

That is, rather than incrementing (ongestionWindow by an entire 22 bytes each 4TT, we increment it by a

fraction of 22 every time an +(\ is received. +ssuming that each +(\ acknowledges the receipt

of 22bytes, then 22F(ongestionWindow.

that

fraction

is

0s decir, en lugar de incrementar (ongestionWindow por toda una bytes 22 cada 4TT, tenemos

incrementarlo en una fracci$n de 22 cada ve- que se recibe un +(\. 2uponiendo que cada +(\ reconoce la recepci$n de 22 bytes, entonces esa fracci$n es 22F(ongestionWindow.

Paquetes en tr'nsito durante aditivo aumento, con un paquete que se a5ade cada 4TT. This pattern of continually increasing and decreasing disminuyendo la ventana de congesti$n contin1a the congestion window continues throughout the durante toda la vida 1til de la cone*i$n. 7e hecho, si se lifetime of the connection. /n fact, if you plot the grafica el valor actual de (ongestionWindow como una current value of (ongestionWindow as a function of funci$n del tiempo, se obtiene un 0atrn de diente de time, you get a sa$toot4 0attern, as illustrated in sierra, como se ilustra en la .igura >.Z. 0l concepto .igure >.Z. The important concept to understand about importante para entender sobre +/ 7 es que la fuente +/ 7 is that the source is willing to reduce its est' dispuesta a reducir su ventana de congesti$n a un congestion window at a much faster rate than it is ritmo mucho m's r'pido de lo que est' dispuesta a willing to increase its congestion window. This is in aumentar su ventana de congesti$n. 0sto es en contrast to an additive increaseFadditive decrease contraste a una estrategia incremento strategy in which the window would be increased by ? aditivoFdisminuci$n aditiva en el que la ventana se packet when an +(\ arrives and decreased by ? when aumenta en ? paquete cuando llega un +(\ y a timeout occurs. /t has been shown that +/ 7 is a disminuye en ? cuando se produce un tiempo de necessary condition for a congestion!control espera. 2e ha demostrado que +/ 7 es una condici$n mechanism to be stable <see the .urther 4eading necesaria para un mecanismo de control de congesti$n section=. )ne intuitive reason to decrease the window para ser estable <ver la secci$n de lectura adicional=. aggressively and increase it conservatively is that the 6na ra-$n intuitiva para reducir la ventana consequences of having too large a window are much agresivamente y aumentarla de manera conservadora es worse than those of it being too small. .or e*ample, que las consecuencias de tener demasiado grande una when the window is too large, packets that are dropped ventana son mucho peores que las de que sea will be retransmitted, making congestion even worse, demasiado peque5o. Por e"emplo, cuando la ventana es thus, it is important to get out of this state quickly. demasiado grande, los paquetes que se de"an caer se retransmitir'n, por lo que la congesti$n a1n peor, por lo tanto, es importante salir de este estado r'pidamente. 0ste patr$n continuamente aumentando y

coarse!grained <;MM!ms= clock. .inally, since a timeout is an indication of congestion that triggers multiplicative decrease, T(P needs the most accurate timeout mechanism it can afford.We already covered T(P3s timeout mechanism in 2ection ;.:.>, so we do not repeat it here. The two main things to remember about that mechanism are that <?= timeouts are set as a function of both the average 4TT and the standard deviation in that average, and <:= due to the cost of measuring each transmission with an accurate clock, T(P only samples the round!trip time once per 4TT <rather than once per packet= using a

.inalmente, desde un tiempo de espera es una indicaci$n de la congesti$n que desencadena disminuci$n multiplicativa, T(P necesita el mecanismo de tiempo de espera m's e*acta que puede permitirse. Ja hemos cubierto el mecanismo de tiempo de espera de T(P en la 2ecci$n ;.:.>, as# que no repitamos aqu#. &as dos cosas principales que debe recordar acerca de

ese mecanismo son que <?= los tiempos de espera se establecen en funci$n tanto del 4TT promedio y la desviaci$n est'ndar en ese promedio, y <:= debido al coste de la medici$n de cada transmisi$n con un relo"

de precisi$n, T(P s$lo muestras el tiempo de ida y vuelta una ve- por 4TT <en lugar de una ve- por paquete= utili-ando un 4elo" de grano grueso <;MM ms=.

6.).' Slo$ Start (Arran5ue Lento SS)


The additive increase mechanism "ust described is the right approach to use when the source is operating close to the available capacity of the network, but it takes too long to ramp up a connection when it is starting from scratch. T(P therefore provides a second mechanism, ironically called slow start, which is used to increase the congestion window rapidly from a cold start. 2low start effectively increases the congestion window e*ponentially, rather than linearly. 0l mecanismo de incremento aditivo que acabamos de describir es el enfoque correcto para utili-ar cuando la fuente est' operando cerca de la capacidad disponible de la red, pero se tarda demasiado tiempo a la rampa hasta una cone*i$n cuando empie-a desde cero. Por lo tanto, T(P proporciona un segundo mecanismo, ir$nicamente llamada arranque lento, que se utili-a para aumentar la ventana de congesti$n r'pidamente desde un arranque en fr#o. (omien-o lento aumenta efectivamente la ventana de congesti$n e*ponencialmente, en lugar de lineal. 0spec#ficamente, la fuente comien-a estableciendo (ongestionWindow a un paquete. (uando el +(\ para este paquete llega, T(P agrega ? a (ongestionWindow y luego env#a dos paquetes. Tras la recepci$n de los correspondientes dos +(\s, T(P incrementa (ongestionWindow por : ! uno para cada +(\! y "unto env#a cuatro paquetes. 0l resultado final es que T(P duplica efica-mente el n1mero de paquetes que tiene en tr'nsito cada 4TT. &a figura >.?M muestra el crecimiento en el n1mero de paquetes en tr'nsito durante el arranque lento. (ompare esto con el crecimiento lineal de aditivo incremento ilustrado en .igura >.[.

2pecifically, the source starts out by setting (ongestionWindow to one packet. When the +(\ for this packet arrives, T(P adds ? to (ongestionWindow and then sends two packets. 6pon receiving the corresponding two +(\s, T(P increments (ongestionWindow by :one for each +(\and ne*t sends four packets. The end result is that T(P effectively doubles the number of packets it has in transit every 4TT. .igure >.?M shows the growth in the number of packets in transit during slow start. (ompare this to the linear growth of additive increase illustrated in .igure >.[.

Why any e*ponential mechanism would be called AslowB is pu--ling at first, but it can be e*plained if put in the proper historical conte*t. We need to compare

slow start not against the linear mechanism of the previous subsection, but against the original behavior of T(P.

Por qu% alg1n mecanismo e*ponencial ser#a llamado ClentoC es desconcertante al principio, pero se puede e*plicar si se pone en el conte*to hist$rico. (onsider what happens when a connection is established and the source first starts to send packets that is, when it currently has no packets in transit. /f the source sends as many packets as the advertised window allowswhich is e*actly what T(P did before slow start was developedthen even if there is a fairly large amount of bandwidth available in the network, the routers may not be able to consume this burst of packets. /t all depends on how much buffer space is available at the routers. 2low start was therefore designed to space packets out so that this burst does not occur. /n other words, even though its e*ponential growth is faster than linear growth, slow start is much AslowerB than sending an entire advertised window3s worth of data all at once.

@ecesitamos comparar arranque lento no contra el mecanismo lineal de la subsecci$n anterior, sino contra el comportamiento original de T(P. (onsidere lo que sucede cuando se establece una cone*i$n y la fuente primero comien-a a enviar paquetes! es decir, cuando en ese momento no tiene paquetes en tr'nsito. 2i el origen env#a tantos paquetes como la ventana anunciada permite! que es e*actamente lo que hi-o T(P antes de que arranque lento fue desarrollado! entonces incluso si hay una cantidad significativa de ancho de banda disponible en la red, los routers pueden no ser capaces de consumir esta r'faga de paquetes. Todo depende de la cantidad de b1fer espacio disponible en los routers. +rranque lento fue por lo tanto dise5ado para espaciar paquetes de modo que esta r'faga no se produ-ca. 0n otras palabras, a pesar de que su crecimiento e*ponencial es m's r'pido que el crecimiento lineal, arranque lento es mucho Cm's lentoC que el env#o del valor entero de datos de una ventana anunciada todos a la ve-. 9ay realmente dos situaciones diferentes en las que arranque lento e"ecuta. 0l primero es en el comien-o de una cone*i$n, momento en el que la fuente no tiene idea de cu'ntos paquetes va a ser capa- de tener en tr'nsito en un momento dado. <Tenga en cuenta que T(P se e"ecuta sobre todo desde enlaces Z>MM bps a enlaces :,L Tbps, as# que no hay manera para que la fuente cono-ca la capacidad de la red.= 0n esta situaci$n, arranque lento contin1a duplicando (ongestionWindow cada 4TT hasta que haya una p%rdida, momento en el que un tiempo de espera provoca disminuci$n multiplicativa para dividir (ongestionWindow por :. &a segunda situaci$n en la que se utili-a arranque lento es un poco m's sutil, que se produce cuando la cone*i$n se agota mientras se espera que se produ-ca un tiempo de espera. 4ecordemos c$mo funciona el algoritmo de ventana desli-ante de T(P! cuando se pierde un paquete, la fuente finalmente alcan-a un punto en el que ha enviado todos los datos que la ventana anunciada permite, y as# lo bloquea mientras se espera un +(\ que no va a llegar. .inalmente, un tiempo de espera sucede, pero en este momento no hay paquetes en tr'nsito, lo que significa que la fuente no recibir' +(\s a Crelo"C de la transmisi$n de nuevos paquetes. &a fuente en cambio recibir' un 1nico +(\ acumulativo que reabre toda la ventana anunciada, pero, como se ha e*plicado anteriormente, la fuente utili-a entonces arranque lento para reiniciar el flu"o de datos en lugar de vaciar un valor de toda una ventana de datos sobre la red de una sola ve-.

There are actually two different situations in which slow start runs. The first is at the very beginning of a connection, at which time the source has no idea how many packets it is going to be able to have in transit at a given time. <\eep in mind that T(P runs over everything from Z>MM!bps links to :.L!Tbps links, so there is no way for the source to know the network3s capacity.= /n this situation, slow start continues to double (ongestionWindow each 4TT until there is a loss, at which time a timeout causes multiplicative decrease to divide (ongestionWindow by :.

The second situation in which slow start is used is a bit more subtle, it occurs when the connection goes dead while waiting for a timeout to occur. 4ecall how T(P3s sliding window algorithm workswhen a packet is lost, the source eventually reaches a point where it has sent as much data as the advertised window allows, and so it blocks while waiting for an +(\ that will not arrive. 0ventually, a timeout happens, but by this time there are no packets in transit, meaning that the source will receive no +(\s to AclockB the transmission of new packets. The source will instead receive a single cumulative +(\ that reopens the entire advertised window, but, as e*plained above, the source then uses slow start to restart the flow of data rather than dumping a whole window3s worth of data on the network all at once.

+lthough the source is using slow start again, it now knows more information than it did at the beginning of

a connection. 2pecifically, the source has a current <and useful= value of (ongestionWindow, this is the value

of (ongestionWindow that e*isted prior to the last packet loss, divided by : as a result of the loss. We can think of this as the target congestion window. 2low start is used to rapidly increase the sending rate up to this value, and then additive increase is used beyond this point. +unque la fuente est' utili-ando arranque lento de nuevo, se conoce ahora m's informaci$n que lo que @otice that we have a small bookkeeping problem to take care of, in that we want to remember the target congestion window resulting from multiplicative decrease as well as the actual congestion window being used by slow start. To address this problem, T(P introduces a temporary variable to store the target window, typically called (ongestionThreshold, that is set equal to the (ongestionWindow value that results from multiplicative decrease. The variable (ongestionWindow is then reset to one packet, and it is incremented by one packet for every +(\ that is received until it reaches (ongestionThreshold, at which point it is incremented by one packet per 4TT.

hi-o en el comien-o de una cone*i$n. 0spec#ficamente, la fuente tiene un valor presente <y 1til= de (ongestionWindow, este es el valor de (ongestionWindow que e*ist#a antes de la 1ltima p%rdida de paquetes, dividido por : como resultado de la p%rdida. Podemos pensar en esto como el ob"etivo de la ventana de congesti$n. +rranque lento se utili-a para aumentar r'pidamente la velocidad de env#o hasta este valor, y luego incremento aditivo es utili-ado m's all' de este punto. Tenga en cuenta que tenemos un peque5o problema contable para cuidar, en que queremos recordar la ventana de congesti$n ob"etivo resultante de la disminuci$n multiplicativa, as# como la ventana de congesti$n real que es utili-ada por un arranque lento. Para hacer frente a este problema, T(P introduce una variable temporal para almacenar la ventanilla ob"etivo, t#picamente llamado (ongestionThreshold, que se establece igual al valor (ongestionWindow que resulta de la disminuci$n multiplicativa. &a variable (ongestionWindow se restablece a un paquete, y se incrementa en un paquete para cada +(\ que se recibe hasta que alcan-a (ongestionThreshold, momento en el cual se incrementa en un paquete por 4TT. 0n otras palabras, T(P aumenta la ventana de congesti$n como se define por el fragmento de c$digo siguienteI

/n other words, T(P increases the congestion window as defined by the following code fragmentI ] u^int u^int cw O state!_(ongestionWindow, incr O state!_ma*seg,

if <cw _ state!_(ongestionThreshold= incr O incr ` incr F cw, state!_(ongestionWindow O a

/@<cw V incr, T(P^ +DW/@=, donde el estado representa el estado de una cone*i$n T(P en particular y T(P a*win define un l#mite superior del tama5o de la ventana de congesti$n se le permite crecer. .igura >.?? tra-a c$mo (ongestionWindow de T(P aumenta y disminuye con el tiempo y sirve para ilustrar la interacci$n de arranque lento y un incremento aditivoFdisminuci$n multiplicativa. 0sta tra-a se tom$ de una cone*i$n T(P actual y muestra el valor actual de (ongestionWindow! la l#nea de color! con el tiempo.

where state represents the state of a particular T(P connection and T(P +DW/@ defines an upper bound on how large the congestion window is allowed to grow. .igure >.?? traces how T(P3s (ongestionWindow increases and decreases over time and serves to illustrate the interplay of slow start and additive increaseFmultiplicative decrease. This trace was taken from an actual T(P connection and shows the current value of (ongestionWindowthe colored lineover time.

(omportamiento del control de congesti$n T(P. &#nea de color O valor de (ongestionWindow con el tiempo, vi5etas s$lidas en la parte superior del gr'fico O tiempos de espera, marcas de control en la parte superior de la gr'fica O tiempo en que se transmite cada paquete, barras verticales O tiempo cuando un paquete que finalmente se retransmiti$ fue transmitido primero. There are several things to notice about this trace. The first is the rapid increase in the congestion window at the beginning of the connection. This corresponds to the initial slow start phase. The slow start phase continues until several packets are lost at about M.L seconds into the connection, at which time (ongestionWindow flattens out at about EL \B. <Why so many packets are lost during slow start is discussed below.= The reason why the congestion window flattens is that there are no +(\s arriving, due to the fact that several packets were lost. /n fact, no new packets are sent during this time, as denoted by the lack of hash marks at the top of the graph. + timeout eventually happens at appro*imately : seconds, at which time the congestion window is divided by : <i.e., cut from appro*imately EL \B to around ?K \B= and (ongestionThreshold is set to this value. 2low start then causes (ongestionWindow to be reset to one packet and to start ramping up from there. 9ay varias cosas a destacar sobre esta tra-a. 0l primero es el r'pido aumento en la ventana de congesti$n en el inicio de la cone*i$n. 0sto corresponde a la fase inicial de arranque lento. &a fase de inicio lento contin1a hasta que varios paquetes se pierden en unos M,L segundos en la cone*i$n, momento en el cual (ongestionWindow se aplana en unos EL \B. <por qu% tantos paquetes se pierden durante arranque lento se discute a continuaci$n.= &a ra-$n por qu% la ventana de congesti$n se aplana es que no hay +(\ que llegan, debido al hecho de que varios paquetes se perdieron. 7e hecho, no hay nuevos paquetes enviados durante este tiempo, como se indica por la falta de marcas de control en la parte superior de la gr'fica. 6n tiempo de espera finalmente sucede en apro*imadamente : segundos, momento en el que la ventana de congesti$n se divide por : <es decir, corta de apro*imadamente EL \B a unos ?K \B= y (ongestionThreshold se establece en este valor. (omien-o lento provoca entonces (ongestionWindow se restable-ca a un paquete y para iniciar el aumento gradual a partir de ah#. @o hay suficiente detalle en la tra-a para ver e*actamente lo que sucede cuando un par de paquetes se pierden solo despu%s de : segundos, as# que saltamos adelante al incremento lineal en la ventana de congesti$n que ocurre entre : y L segundos. 0sto corresponde a incremento aditivo. + unos L segundos, (ongestionWindow se aplana, de nuevo debido a un paquete perdido. +hora, en unos ;,; segundosI ?. 6n tiempo de espera sucede, haciendo que la ventana de congesti$n sea dividida por :, de"'ndolo caer desde apro*imadamente :: \B a ?? \B, y (ongestionThreshold se establece en esta cantidad. :. (ongestionWindow se restablece en un paquete, como el emisor entra en arranque lento. E. +rranque lento hace que (ongestionWindow cre-ca e*ponencialmente hasta alcan-ar (ongestionThreshold. (ongestionWindow entonces crece linealmente

There is not enough detail in the trace to see e*actly what happens when a couple of packets are lost "ust after : seconds, so we "ump ahead to the linear increase in the congestion window that occurs between : and L seconds. This corresponds to additive increase. +t about L seconds, (ongestionWindow flattens out, again due to a lost packet. @ow, at about ;.; secondsI ?. + timeout happens, causing the congestion window to be divided by :, dropping it from appro*imately :: \B to ?? \B, and (ongestionThreshold is set to this amount. (ongestionWindow is reset to one packet, as the sender enters slow start. 2low start causes (ongestionWindow to grow e*ponentially until it reaches (ongestionThreshold. (ongestionWindow then grows linearly.

:. E.

L.

L.

The same pattern is repeated at around [ seconds when

another timeout occurs.

0l mismo patr$n se repite a alrededor de [ segundos We now return to the question of why so many packets are lost during the initial slow start period. +t this point, T(P is attempting to learn how much bandwidth is available on the network. This is a very difficult task. /f the source is not aggressive at this stagefor e*ample, if it only increases the congestion window linearlythen it takes a long time for it to discover how much bandwidth is available. This can have a dramatic impact on the throughput achieved for this connection. )n the other hand, if the source is aggressive at this stage, as T(P is during e*ponential growth, then the source runs the risk of having half a window3s worth of packets dropped by the network. Golvamos ahora a la cuesti$n de por qu% tantos To see what can happen during e*ponential growth, consider the situation in which the source was "ust able to successfully send ?> packets through the network, causing it to double its congestion window to E:. 2uppose, however, that the network happens to have "ust enough capacity to support ?> packets from this source. The likely result is that ?> of the E: packets sent under the new congestion window will be dropped by the network, actually, this is the worst!case outcome, since some of the packets will be buffered in some router. This problem will become increasingly severe as the delaybbandwidth product of networks increases. .or e*ample, a delaybbandwidth product of ;MM \B means that each connection has the potential to lose up to ;MM \B of data at the beginning of each connection. )f course, this assumes that both the source and the destination implement the Abig windowsB e*tension.

cuando otro tiempo de espera se produce. paquetes se pierden durante el per#odo de arranque lento inicial. 0n este punto, T(P intenta aprender cu'nto ancho de banda est' disponible en la red. 0sta es una tarea muy dif#cil. 2i la fuente no es agresiva en esta etapa! Por e"emplo, si s$lo aumenta la ventana de congesti$n linealmente! entonces se necesita mucho tiempo para que pueda descubrir cu'nto ancho de banda est' disponible. 0sto puede tener un impacto dram'tico en el rendimiento alcan-ado por este concepto. Por otro lado, si la fuente es agresiva en esta etapa, como T(P es durante el crecimiento e*ponencial, entonces la fuente corre el riesgo de tener la mitad del valor de la ventana de paquetes descartados por la red. Para ver lo que puede suceder durante el crecimiento e*ponencial, tenga en cuenta la situaci$n en la que la fuente era capa- de enviar correctamente ?> paquetes a trav%s de la red, haciendo que se duplique su ventana de congesti$n a E:. 2upongamos, sin embargo, que la red resulta tener suficiente capacidad para soportar ?> paquetes de esta fuente. 0l resultado probable es que ?> de los E: paquetes enviados ba"o la nueva ventana de congesti$n ser'n descartados por la red, realmente, este es el resultado del peor caso, ya que algunos de los paquetes ser'n almacenados en buffer en alg1n router. 0ste problema ser' cada ve- m's grave como aumenta el producto retrasobancho de banda de redes. Por e"emplo, un producto retrasobancho de banda de ;MM \B significa que cada cone*i$n tiene el potencial para perder hasta ;MM \B de datos al comien-o de cada cone*i$n. Por supuesto, esto supone que tanto la fuente como el destino implementan la e*tensi$n Cgrandes ventanasC. +lgunos dise5adores de protocolo han propuesto alternativas para arranque lento, mediante el cual la fuente intenta estimar el ancho de banda disponible por medios m's sofisticados. 6n e"emplo reciente es el mecanismo de inicio r'pido sometidos a la normali-aci$n en el /0T.. &a idea b'sica es que un emisor T(P puede pedir una tasa de env#o inicial mayor que arranque lento que permitir#a poniendo una tasa solicitada en su paquete 2J@ como opci$n /P. &os routers a lo largo de la trayectoria pueden e*aminar la opci$n, evaluar el nivel actual de la congesti$n en el enlace de salida para este flu"o, y decidir si esa tasa es aceptable, si una tasa m's ba"a ser#a aceptable, o si arranque lento est'ndar debe ser utili-ado. Para cuando el 2J@ llega al receptor, contendr' ya sea una tasa que era aceptable para todos los routers en la trayectoria o una indicaci$n de que uno o m's routers en la trayectoria no pod#an apoyar la solicitud de inicio r'pido. 0n el primer caso, el emisor T(P utili-a esta tasa para comen-ar la transmisi$n, en el segundo caso, se vuelve a caer a arranque lento est'ndar. 2i se permite que T(P empiece enviando a una tasa superior, una sesi$n podr#a alcan-ar m's

2ome protocol designers have proposed alternatives to slow start, whereby the source tries to estimate the available bandwidth by more sophisticated means. + recent e*ample is the quick!start mechanism undergoing standardi-ation at the /0T.. The basic idea is that a T(P sender can ask for an initial sending rate greater than slow start would allow by putting a requested rate in its 2J@ packet as an /P option. 4outers along the path can e*amine the option, evaluate the current level of congestion on the outgoing link for this flow, and decide if that rate is acceptable, if a lower rate would be acceptable, or if standard slow start should be used. By the time the 2J@ reaches the receiver, it will contain either a rate that was acceptable to all routers on the path or an indication that one or more routers on the path could not support the quick! start request. /n the former case, the T(P sender uses that rate to begin transmission, in the latter case, it falls back to standard slow start. /f T(P is allowed to start off sending at a higher rate, a session could more quickly reach the point of filling the pipe, rather than taking many round!trip times to do so.

r'pidamente el punto de llenado de la tuber#a, en lugar (learly one of the challenges to this sort of enhancement to T(P is that it requires substantially more cooperation from the routers than standard T(P does. /f a single router in the path does not support quick!start, then the system reverts to standard slow start. Thus, it could be a long time before these types of enhancements could make it into the /nternet, for now, they are more likely to be used in controlled network environments <e.g., research networks=.

de tomar muchos tiempos de ida y vuelta para hacerlo.

0s evidente que uno de los retos para este tipo de me"ora de T(P es que requiere mucho m's cooperaci$n por parte de los routers que lo que hace T(P est'ndar. 2i un solo router en la trayectoria no soporta arranque r'pido, el sistema vuelve al arranque lento est'ndar. Por lo tanto, podr#a ser un largo tiempo antes de que estos tipos de me"oras podr#an hacerlo en el /nternet, por ahora, son m's probable que se utilicen en entornos de red controlado <por e"emplo, redes de investigaci$n=. 6.).) 1ast Retrans#it and 1ast Reco*ery (Retrans#isin r60ida y Recu0eracin R60ida) The mechanisms described so far were part of the &os mecanismos descritos hasta ahora formaban parte original proposal to add congestion control to T(P. /t de la propuesta original para agregar el control de was soon discovered, however, that the coarse!grained congesti$n de T(P. Pronto se descubri$, sin embargo, implementation of T(P timeouts led to long periods of que la implementaci$n de grano grueso de los timeouts time during which the connection went dead while de T(P dio lugar a largos per#odos de tiempo durante waiting for a timer to e*pire. Because of this, a new el cual la cone*i$n qued$ muerta mientras espera que mechanism called fast retransmit was added to T(P. e*pire un tempori-ador. 7ebido a esto, se a5adi$ un .ast retransmit is a heuristic that sometimes triggers nuevo mecanismo llamado retransmisi$n r'pida en the retransmission of a dropped packet sooner than the T(P. &a retransmisi$n r'pida es una heur#stica que a regular timeout mechanism. The fast retransmit veces provoca la retransmisi$n de un paquete ca#do mechanism does not replace regular timeouts, it "ust m's pronto que el mecanismo de tiempo de espera enhances that facility. normal. 0l mecanismo de retransmisi$n r'pida no sustituye los tiempos de espera regulares, s$lo me"ora esa habilidad. The idea of fast retransmit is straightforward. 0very time a data packet arrives at the receiving side, the receiver responds with an acknowledgment, even if this sequence number has already been acknowledged. Thus, when a packet arrives out of orderwhen T(P cannot yet acknowledge the data the packet contains because earlier data has not yet arrivedT(P resends the same acknowledgment it sent the last time. &a idea de retransmisi$n r'pida es sencilla. (ada veThis second transmission of the same acknowledgment is called a duplicate +(\. When the sending side sees a duplicate +(\, it knows that the other side must have received a packet out of order, which suggests that an earlier packet might have been lost. 2ince it is also possible that the earlier packet has only been delayed rather than lost, the sender waits until it sees some number of duplicate +(\s and then retransmits the missing packet. /n practice, T(P waits until it has seen three duplicate +(\s before retransmitting the packet. .igure >.?: illustrates how duplicate +(\s lead to a fast retransmit. /n this e*ample, the destination receives packets ? and :, but packet E is lost in the network. Thus, the destination will send a duplicate +(\ for packet : when packet L arrives, again when packet ; arrives, and so on. <To simplify this e*ample, we think in terms of packets ?, :, E, and so on, rather than worrying about the sequence numbers for each byte.= When the sender sees the third duplicate +(\ for packet :the one sent because the receiver had gotten packet >it retransmits packet E. @ote that que un paquete de datos llega al lado receptor, el receptor responde con un acuse de recibo, a1n si este n1mero de secuencia ya ha sido reconocido. 0ntonces, cuando un paquete llega fuera de orden! cuando T(P no puede reconocer los datos que el paquete contiene ya que los datos anteriormente a1n no han llegado! T(P reenv#a el mismo reconocimiento que envi$ la 1ltima ve-. 0sta segunda transmisi$n de el mismo reconocimiento es llamado un +(\ duplicado. (uando el lado emisor ve un duplicado +(\, sabe que el otro lado tiene que haber recibido un paquete fuera de orden lo que sugiere que un paquete anterior se podr#a haber perdido. Puesto que tambi%n es posible que el paquete anterior 1nicamente se ha retrasado en lugar de perdido, el emisor espera hasta que ve alg1n n1mero de +(\s duplicados y despu%s retransmite el paquete perdido. 0n la pr'ctica, T(P espera hasta que ha visto tres +(\s duplicados antes de retransmitir el paquete. when the retransmitted copy of packet E arrives at the destination, the receiver then sends a cumulative +(\ for everything up to and including packet > back to the source. &a figura >.?: ilustra c$mo +(\s duplicados llevan a una retransmisi$n r'pida. 0n este e"emplo, el destino recibe los paquetes ? y :, pero paquete E se pierde en la red. Por lo tanto, el destino enviar' un +(\ duplicado para el paquete : cuando el paquete L llega, de nuevo

cuando llega el paquete ;, y as# sucesivamente. <Para simplificar este e"emplo, pensamos en t%rminos de paquetes de ?, :, E, y as# sucesivamente, en lugar de preocuparse por los n1meros de secuencia para cada byte.= (uando el remitente ve al tercer +(\ duplicado para el paquete : 8 el enviado porque el receptor hab#a

llegado paquete > ! retransmite el paquete E. Tenga en cuenta que cuando la copia retransmitida del paquete E llega a destino, el receptor env#a entonces un +(\ acumulativo por todo hasta e incluyendo el paquete de > de nuevo a la fuente.

.igure >.?E illustrates the behavior of a version of T(P with the fast retransmit mechanism. /t is interesting to compare this trace with that given in .igure >.??, where fast retransmit was not implementedthe long periods during which the congestion window stays flat and no packets are sent has been eliminated.

.igura >.?E ilustra el comportamiento de una versi$n de T(P con el mecanismo de retransmisi$n r'pida. 0s interesante comparar esta tra-a con la dada en la figura >.??, donde retransmisi$n r'pida no se implement$! los largos per#odos durante los cuales la ventana de congesti$n permanece plana y no se env#an paquetes ha sido eliminados.

Tra-a de T(P con retransmisi$n r'pida. &#nea de colorO(ongestionWindow, vi5eta s$lida O tiempo de espera, marcas de control O tiempo en que se transmite cada paquete, barras verticales Omomento en el que un paquete que finalmente se retransmite se transmite primero. /n general, this technique is able to eliminate about half of the coarse!grained timeouts on a typical T(P connection, resulting in roughly a :MN improvement in the throughput over what could otherwise have been achieved. @otice, however, that the fast retransmit strategy does not eliminate all coarse!grained timeouts. This is because for a small window si-e there will not be enough packets in transit to cause enough duplicate +(\s to be delivered. Tiven enough lost packetsfor e*ample, as happens during the initial slow start phase the sliding window algorithm eventually blocks the sender until a timeout occurs. Tiven the current >L!\B ma*imum advertised window si-e, T(P3s fast retransmit mechanism is able to detect up to three dropped packets per window in practice.

0n general, esta t%cnica es capa- de eliminar apro*imadamente la mitad del tiempos de espera de grano grueso en una cone*i$n t#pica T(P, lo que resulta en m's o menos un :MN de me"ora en el rendimiento en comparaci$n con lo que podr#an haberse alcan-ado. @$tese, sin embargo, que la estrategia de retransmisi$n r'pida no elimina todos los tiempos de espera de grano grueso. 0sto se debe por un peque5o tama5o de la ventana que no habr' suficientes paquetes en tr'nsito para causar suficientes +(\s

duplicados para ser entregados. 7ados suficientes paquetes perdidos! por e"emplo, como ocurre durante la fase inicial de arranque lento! el algoritmo de ventana desli-ante eventualmente bloquea el emisor hasta que un tiempo de espera ocurre. 7ada la actual de .inally, there is one last improvement we can make. When the fast retransmit mechanism signals congestion, rather than drop the congestion window all the way back to one packet and run slow start, it is possible to use the +(\s that are still in the pipe to clock the sending of packets. This mechanism, which is called fast recovery, effectively removes the slow start phase that happens between when fast retransmit detects a lost packet and additive increase begins. .or e*ample, fast recovery avoids the slow start period between E.[ and L seconds in .igure >.?E and instead simply cuts the congestion window in half <from :: \B to ?? \B= and resumes additive increase. /n other words, slow start is only used at the beginning of a connection and whenever a coarse!grained timeout occurs. +t all other times, the congestion window is following a pure additive increaseFmultiplicative decrease pattern.

>L \B m'*imo tama5o de la ventana anunciada, el mecanismo retransmisi$n r'pida del T(P es capa- de detectar hasta tres paquetes perdidos por ventana en la pr'ctica. .inalmente, hay una 1ltima me"ora que podemos hacer. (uando el mecanismo de retransmisi$n r'pida se5ala congesti$n, en lugar de de"ar caer la ventana de congesti$n todo el camino de vuelta a un paquete y e"ecutar arranque lento, es posible utili-ar los +(\s que todav#a est'n en la tuber#a para registrar el env#o de paquetes. 0ste mecanismo, que se llama recuperaci$n r'pida, elimina efica-mente la fase de arranque lento, que ocurre entre el momento en retransmisi$n r'pida detecta un paquete perdido y comien-a el incremento aditivo. Por e"emplo, recuperaci$n r'pida evita el per#odo de arranque lento entre E,[ y L segundos en la figura >.?E y en su lugar simplemente corta la ventana de congesti$n a la mitad <de :: \B a ?? \B= y reanuda incremento aditivo. 0n otras palabras, arranque lento s$lo se usa al comien-o de una cone*i$n y cada ve- que se produce un tiempo de espera de grano grueso. 0l resto del tiempo, la ventana de congesti$n est' siguiendo un puro patr$n incremento aditivoFdisminuci$n multiplicativa.

A 1aster C!7
any times in the last two decades the argument over how fast T(P can be made to run has reared its head. .irst there was the claim that T(P was too comple* to run fast in host software as networks headed toward the gigabit range. This claim was repeatedly disproved. ore recently however, an important theoretical result has shown that there are limits to how well standard T(P can perform in very high bandwidth!delay environments. +n analysis of the congestion!control behavior of T(P has shown that, in the steady state, T(P3s throughput is appro*imately uchas veces en las 1ltimas dos d%cadas, la discusi$n sobre qu% tan r'pido T(P puede ser obligado a correr ha levantado la cabe-a. Primero fue la afirmaci$n de que el T(P era demasiado comple"o para correr r'pido en el software de host como las redes dirig#an hacia el rango de gigabit. 0sta afirmaci$n fue desmentida repetidamente. 's recientemente, sin embargo, un importante resultado te$rico ha demostrado que hay l#mites con lo bien est'ndar T(P puede reali-ar en ambientes muy altos de ancho de banda!retardo. 6n an'lisis del comportamiento de control de la congesti$n de T(P ha demostrado que, en el estado de equilibrio <estado estacionario=, el rendimiento del T(P es apro*imadamente

/n a network with an 4TT of ?MM ms and ?M!Tbps links, it follows that a single T(P connection will only be able to achieve a throughput close to link speed if the loss rate is below one per ; billion packets equivalent to one congestion event every ?MM minutes. 0ven very rare packet losses due to bit errors on the fiber will typically produce a considerably higher loss rate than this, making it impossible to fill the pipe with a single T(P connection. + number of proposals to improve on T(P3s behavior in networks with very high bandwidth delay products have been put forward, and they range from the incremental to the dramatic. )bserving the dependency on 22, one simple change that has been proposed is to increase the packet si-e. 6nfortunately, increasing

0n una red con un 4TT de ?MM ms y enlaces de ?M Tbps, se deduce que una sola cone*i$n T(P s$lo ser' capa- de lograr un rendimiento cerca de la velocidad de enlace si la tasa de p%rdida es inferior a uno por cada ; billones de paquetes! equivalente a un evento de congesti$n de cada ?MM minutos. /ncluso muy raras las p%rdidas de paquetes debido a errores de bits en la fibra t#picamente producen una tasa de p%rdida considerablemente m's alto que este, por lo que es imposible llenar el tubo con una sola cone*i$n T(P. packet si-es also increases the chance that a given packet will suffer from a bit error, so at some point increasing the 22 alone may not be sufficient. )ther proposals that have been advanced at the /0T. and elsewhere make changes to the way T(P avoids congestion, in an attempt to make T(P better able to

use bandwidth that is available. The challenges here are to be fair to standard T(P implementations and also to avoid the congestion collapse issues that led to the current behavior of T(P. 6na serie de propuestas para me"orar el comportamiento de T(P en redes con productos muy altos de ancho de banda retardo se han propuesto, y van desde el gradual a lo dram'tico. )bservando la dependencia de 22, un cambio simple que se ha propuesto es incrementar el tama5o del paquete. 7esafortunadamente, el aumento de los tama5os de

paquete tambi%n aumenta la probabilidad de que un paquete dado sufrir' de un error de bit, por lo que en alg1n momento el aumento del 22 por s# sola no puede ser suficiente. )tras propuestas que se han avan-ado en la /0T. y en otros lugares hacen cambios en la forma T(P evita la congesti$n, en un intento de hacer T(P en me"ores condiciones para utili-ar el ancho de banda que est' disponible. &os desaf#os aqu# son para ser "ustos con las implementaciones de T(P est'ndar y tambi%n para evitar los problemas de colapso de congesti$n que llevaron al comportamiento actual de T(P.

The 9igh2peed T(P proposal, now an e*perimental 4.(, makes T(P more aggressive only when it is clearly operating in a very high bandwidth!delay product environment and not competing with a lot of other traffic. /n essence, when the congestion window gets very large, 9igh2peed T(P starts to increase (ongestionWindowby a larger amount that standard T(P. /n the normal environment where (ongestionWindow is relatively small <about LM b 22=, 9igh2peed T(P is indistinguishable from standard T(P. any other proposals have been made in this vein, some of which are listed in the .urther 4eading section. @otably, the default T(P behavior in the &inu* operating system is now based on a T(P variant called (6B/(, which also e*pands the congestion window aggressively in high bandwidth! delay product regimes, while maintaining compatibility with older T(P variants in more bandwidth!constrained environments.

&a T(P 9igh2peed propuesta, ahora un 4.( e*perimental, convierte T(P m's agresivo s$lo cuando se est' operando claramente en un entorno de producto muy alto ancho de banda!retardo y que no compiten con una gran cantidad de tr'fico. 0n esencia, cuando la ventana de congesti$n se hace muy grande, T(P 9igh2peed empie-a a aumentar (ongestionWindow por una cantidad mayor que el est'ndar T(P. 0n el ambiente normal donde (ongestionWindow es relativamente peque5o <alrededor de LM b 22=, T(P 9igh2peed es indistinguible de T(P est'ndar. uchos otros se han hecho propuestas en este sentido, algunos de los cuales se enumeran en la secci$n de lectura adicional. (abe destacar que el comportamiento de T(P por defecto en el sistema operativo &inu* se basa ahora en una variante T(P llamada (6B/(, que tambi%n ampl#a la ventana de congesti$n agresivamente en reg#menes altos de productos de ancho de banda!retardo, mientras que mantiene la compatibilidad con variantes m's vie"as de T(P en m's entornos de ancho de banda limitado. &a propuesta de inicio r'pido, que cambia el comportamiento de arranque de T(P, fue mencionada anteriormente. 7ado que puede permitir una cone*i$n T(P a elevar su tasa de env#o m's r'pidamente, su efecto sobre el rendimiento de T(P es m's notable cuando las cone*iones son cortas o cuando una aplicaci$n de"a de enviar datos peri$dicamente y T(P en caso contrario volver' a arranque lento. )tra propuesta, .+2T T(P, toma un enfoque similar a T(P Gegas descrito en la siguiente secci$n. &a idea b'sica es anticipar la aparici$n de la congesti$n y evitarla, por lo tanto no tomaron el impacto en el rendimiento asociado con la disminuci$n de la ventana de congesti$n. chapter for references to ongoing work in this area. Garias propuestas que implican cambios m's dr'sticos en T(P o incluso reempla-arlo con un nuevo protocolo se han desarrollado. 0stos tienen un potencial

The Huick!2tart proposal, which changes the start!up behavior of T(P, was mentioned above. 2ince it can enable a T(P connection to ramp up its sending rate more quickly, its effect on T(P performance is most noticeable when connections are short, or when an application periodically stops sending data and T(P would otherwise return to slow start. Jet another proposal, .+2T T(P, takes an approach similar to T(P Gegas described in the ne*t section. The basic idea is to anticipate the onset of congestion and avoid it, thereby not taking the performance hit associated with decreasing the congestion window. 2everal proposals that involve more dramatic changes to T(P or even replace it with a new protocol have been developed. These have considerable potential to fill the pipe quickly and fairly in high bandwidth!delay environments, but they also face higher deployment challenges. We refer the reader to the end of this

considerable para llenar el tubo de manera r'pida y "usta en entornos de alto ancho de banda!retardo, pero tambi%n se enfrentan a mayores retos de

implementaci$n. 4emitimos al lector al final de este cap#tulo para obtener referencias a los traba"os en curso en esta 'rea.

6.8 CON.ES ION2A9OI/ANCE &EC:ANIS&S (&ecanis#os e*itar congestin CA)


/t is important to understand that T(P3s strategy is to control congestion once it happens, as opposed to trying to avoid congestion in the first place. /n fact, T(P repeatedly increases the load it imposes on the network in an effort to find the point at which congestion occurs, and then it backs off from this point. 2aid another way, T(P needs to create losses to find the available bandwidth of the connection. +n appealing alternative, but one that has not yet been widely adopted, is to predict when congestion is about to happen and then to reduce the rate at which hosts send data "ust before packets start being discarded. We call such a strategy congestion avoidance, to distinguish it from congestion control. 0s importante entender que la estrategia de T(P es para controlar la congesti$n una ve- que sucede, en lugar de tratar de evitar la congesti$n en primer lugar. 7e hecho, T(P aumenta varias veces la carga que impone a la red en un esfuer-o para encontrar el punto en el que se produce la congesti$n, y entonces retrocede desde este punto. 7icho de otra manera, el T(P necesita crear p%rdidas para encontrar el ancho de banda disponible de la cone*i$n. 6na alternativa atractiva, pero que todav#a no ha sido ampliamente adoptado, es predecir cuando la congesti$n est' a punto de suceder y entonces reducir la velocidad a la que hosts env#an datos "usto antes de que los paquetes comien-an a ser descartados. &lamamos esta estrategia evitar la congesti$n, para distinguirlo de control de la congesti$n. 0sta secci$n describe tres mecanismos de evitaci$n de la congesti$n diferentes. &os dos primeros tienen un enfoque similarI Pusieron una peque5a cantidad de una funcionalidad adicional en el router para ayudar al nodo final en la anticipaci$n de la congesti$n. 0l tercer mecanismo es muy diferente de los dos primerosI 2e trata de evitar la congesti$n puramente a partir de los nodos finales. 0l primer mecanismo fue desarrollado para usar en la +rquitectura 7igital de 4ed <7@+=, una red sin cone*i$n con un protocolo de transporte orientado a la cone*i$n. 0ste mecanismo podr#a, por lo tanto, tambi%n se puede aplicar a T(P e /P. (omo se se5al$ anteriormente, la idea aqu# es dividir m's equitativamente la responsabilidad de control de congesti$n entre los routers y los nodos finales. (ada router controla la carga que est' e*perimentando y e*pl#citamente notifica al nodo final cuando la congesti$n est' a punto de ocurrir. 0sta notificaci$n se implementa estableciendo un bit de congesti$n binario en los paquetes que fluyen a trav%s del router, de ah# el nombre 70(bit. 0l host de destino entonces, copia este bit de congesti$n en el +(\ que env#a de vuelta a la fuente. .inalmente, la fuente a"usta su tasa de env#o con el fin de evitar la congesti$n. &a siguiente discusi$n describe el algoritmo con m's detalle, a partir de lo que sucede en el router. 6n 1nico bit de congesti$n se agrega a la cabecera del paquete. 6n router establece este bit en un paquete si su longitud promedio de la cola es mayor que o igual a

This section describes three different congestion! avoidance mechanisms. The first two take a similar approachI They put a small amount of additional functionality into the router to assist the end node in the anticipation of congestion. The third mechanism is very different from the first twoI /t attempts to avoid congestion purely from the end nodes.

6.8.1 /EC"it
The first mechanism was developed for use on the 7igital @etwork +rchitecture <7@+=, a connectionless network with a connection!oriented transport protocol. This mechanism could, therefore, also be applied to T(P and /P. +s noted above, the idea here is to more evenly split the responsibility for congestion control between the routers and the end nodes. 0ach router monitors the load it is e*periencing and e*plicitly notifies the end nodes when congestion is about to occur. This notification is implemented by setting a binary congestion bit in the packets that flow through the router, hence the name 70(bit. The destination host then copies this congestion bit into the +(\ it sends back to the source. .inally, the source ad"usts its sending rate so as to avoid congestion. The following discussion describes the algorithm in more detail, starting with what happens in the router.

+ single congestion bit is added to the packet header. + router sets this bit in a packet if its average queue length is greater than or equal to ? at the time the packet arrives.

? en el momento en que el paquete llega. This average queue length is measured over a time interval that spans the last busy V idle cycle, plus the current busy cycle. <The router is busy when it is transmitting and idle when it is not.= .igure >.?L shows the queue length at a router as a function of time. 0ssentially, the router calculates the area under the curve and divides this value by the time interval to compute the average queue length. 6sing a queue length of ? as the trigger for setting the congestion bit is a trade!off between significant queuing <and hence higher throughput= and increased idle time <and hence lower delay=. /n other words, a queue length of ? seems to optimi-e the power function. 0sta longitud promedio de la cola se mide durante un intervalo de tiempo que abarca el 1ltimo ocupado V ciclo inactivo, m's el ciclo de ocupado actual. <0l router est' ocupado cuando est' transmitiendo e inactivo cuando no est'.= .igura >.?L muestra la longitud de la cola en un router como una funci$n del tiempo. 0sencialmente, el router calcula el 'rea ba"o la curva y divide este valor por el intervalo de tiempo para calcular la longitud promedio de la cola. 6sando una longitud de cola de ? como el disparador para establecer el bit de congesti$n es un compromiso entre la cola significativa <y por lo tanto un mayor rendimiento= y el aumento de tiempo de inactividad <y por lo tanto retardo inferior=. 0n otras palabras, una longitud de la cola de ? parece optimi-ar la funci$n de potencia.

@ow turning our attention to the host half of the mechanism, the source records how many of its packets resulted in some router setting the congestion bit. /n particular, the source maintains a congestion window, "ust as in T(P, and watches to see what fraction of the last window3s worth of packets resulted in the bit being set. /f less than ;MN of the packets had the bit set, then the source increases its congestion window by one packet. /f ;MN or more of the last window3s worth of packets had the congestion bit set, then the source decreases its congestion window to M.[K; times the previous value. The value ;MN was chosen as the threshold based on analysis that showed it to correspond to the peak of the power curve. The Aincrease by ?, decrease by M.[K;B rule was selected because additive increaseFmultiplicative decrease makes the mechanism stable.

Golviendo ahora nuestra atenci$n al host de la mitad del mecanismo, la fuente registra cu'ntos de sus paquetes resultado en alg1n enrutador estableciendo el bit congesti$n. 0n particular, la fuente mantiene una ventana de congesti$n, tal como en T(P, y observa para ver qu% fracci$n del valor de la 1ltima ventana de paquetes result$ en el bit siendo establecido. 2i menos del ;MN de los paquetes ten#a activado el bit, entonces la fuente aumenta su ventana de congesti$n por un paquete. 2i el ;MN o m's del valor de la 1ltima ventana de los paquetes ten#a el bit de congesti$n, entonces la fuente disminuye su ventana de congesti$n a M.[K; veces el valor anterior. 0l valor ;MN se eligi$ como el umbral basado en el an'lisis que mostr$ que corresponde al pico de la curva de potencia. 0l Caumento de ?, decremento por M.[K;C regla fue seleccionado porque incremento aditivoFdecremento multiplicativo hace al mecanismo estable.

6.8.' Rando# Early /etection (RE/) (/eteccin e#0rana Aleatoria)


+ second mechanism, called random early detection <407=, is similar to the 70(bit scheme in that each router is programmed to monitor its own queue length and, when it detects that congestion is imminent, to notify the source to ad"ust its congestion window. 407, invented by 2ally .loyd and Gan Sacobson in the early ?ZZMs, differs from the 70(bit scheme in two ma"or ways. The first is that rather than e*plicitly sending a congestion notification message to the source, 407 is most commonly implemented such that it implicitly notifies the source of congestion by dropping one of its 6n segundo mecanismo, llamado detecci$n temprana aleatoria <407=, es similar al esquema 70(bit en que cada router est' programado para controlar su propia longitud de la cola y, cuando detecta que la congesti$n es inminente, notificar la fuente para a"ustar su ventana de congesti$n. 407, inventado por 2ally .loyd y Gan Sacobson a principios de ?ZZM, difiere del esquema 70(bit en dos formas principales. packets. The source is, therefore, effectively notified by the subsequent timeout or duplicate +(\. /n case you haven3t already guessed, 407 is designed to be used in con"unction with T(P, which currently detects

congestion by means of timeouts <or some other means of detecting packet loss such as duplicate +(\s=. +s the AearlyB part of the 407 acronym suggests, the gateway drops the packet earlier than it would have to, so as to notify the source that it should decrease its congestion window sooner than it would normally have. /n other words, the router drops a few packets before it has e*hausted its buffer space completely, so as to cause the source to slow down, with the hope that this will mean it does not have to drop lots of packets later on. @ote that 407 could easily be adapted to work with an e*plicit feedback scheme simply by marking a packet instead of dropping it, as discussed in the sidebar on 0*plicit (ongestion @otification.

&a primera es que en lugar de enviar un mensa"e de notificaci$n e*pl#cita congesti$n a la fuente, 407 es implementado con mayor frecuencia tal que notifica impl#citamente la fuente de congesti$n de"ando caer ,xplicit Con+estion Noti(ication 1,CN2 While current deployments of 407 almost always signal congestion by dropping packets, there has recently been much attention given to whether or not e*plicit notification is a better strategy. This has led to an effort to standardi-e 0(@ for the /nternet. The basic argument is that while dropping a packet certainly acts as a signal of congestion, and is probably the right thing to do for long!lived bulk transfers, doing so hurts applications that are sensitive to the delay or loss of one or more packets. /nteractive traffic such as telnet and web browsing are prime e*amples. &earning of congestion through e*plicit notification is more appropriate for such applications. Noti(icacin expl*cita de con+estin 1,CN2 Technically, 0(@ requires two bits, the proposed standard uses bits > and K in the /P type of service <T)2= field. )ne is set by the source to indicate that it is 0(@ capable, that is, it is able to react to a congestion notification.

uno de sus paquetes. &a fuente es, por lo tanto, efectivamente notificado por el tiempo de espera posterior o +(\ duplicado. 0n caso de que ya no lo ha adivinado, 407 est' dise5ado para ser usado en con"unto con T(P, que actualmente detecta congesti$n a trav%s de los tiempos de espera <o alg1n otro medio de detecci$n de p%rdida de paquetes como +(\s duplicados=. (omo la parte CtempranaC de la sigla 407 indica, la puerta de enlace <Tateway= descarta el paquete antes de lo que deber#a, a fin de notificar a la fuente que debe disminuir su ventana de congesti$n antes de lo que normalmente tendr#a. 0n otras palabras, el router descarta unos pocos paquetes antes de que haya agotado su espacio de b1fer completamente con el fin de hacer que la fuente redu-ca la velocidad, con la esperan-a de que esto significa que no tiene que de"ar caer una gran cantidad de paquetes m's adelante. Tenga en cuenta que 407 podr#a adaptarse f'cilmente para traba"ar con un esquema de retroalimentaci$n e*pl#cita, simplemente marcando un paquete en lugar de de"arlo caer, como se discute en la barra lateral de @otificaci$n e*pl#cita de congesti$n. ientras que las implementaciones actuales de 407 casi siempre indican la congesti$n de"ando caer los paquetes, recientemente ha habido mucha atenci$n a si es o no una notificaci$n e*pl#cita es una me"or estrategia. 0sto ha llevado a un esfuer-o para estandari-ar 0(@ para /nternet. 0l argumento b'sico es que mientras que descartar un paquete ciertamente act1a como una se5al de congesti$n, y es probablemente lo que se debe hacer por transferencias masivas de larga duraci$n, hacerlo hace da5o aplicaciones que son sensibles al retardo o la p%rdida de uno o m's paquetes. Tr'fico interactivo como telnet y navegaci$n por la web son los principales e"emplos. 0l aprendi-a"e de la congesti$n a trav%s de la notificaci$n e*pl#cita es m's apropiado para tales aplicaciones. T%cnicamente, 0(@ requiere dos bits, el est'ndar propuesto utili-a bits > y K en el tipo de campo de servicio /P <T)2=. 6no se establece por la fuente para indicar que es capa- 0(@, es decir, que es capa- de reaccionar a una notificaci$n de congesti$n.

The other is set by routers along the end!to!end path when congestion is encountered. The latter bit is also echoed back to the source by the destination host. T(P running on the source responds to the 0(@ bit set in e*actly the same way it responds to a dropped packet. 0l otro se establece por los routers a lo largo del +s with any good idea, this recent focus on 0(@ has caused people to stop and think about other ways in which networks can benefit from an 0(@!style e*change of information between hosts at the edge of the networks and routers in the middle of the network,

trayecto de e*tremo a e*tremo cuando se encuentra la congesti$n. 0ste 1ltimo bit tambi%n se hi-o eco de nuevo a la fuente por el host de destino. T(P se e"ecuta en la fuente responde al bit 0(@ establecido e*actamente de la misma manera que responde a un paquete descartado. piggybacked on data packets. The general strategy is sometimes called active queue management, and recent research seems to indicate that it is particularly valuable to T(P flows that have large delay!bandwidth products. The interested reader can pursue the relevant

references given at the end of the chapter. (omo con cualquier buena idea, este reciente %nfasis en 0(@ ha causado que la gente se detenga y piense acerca de otras formas en que las redes pueden beneficiarse de un intercambio al estilo de 0(@ de informaci$n entre los hosts en el borde de las redes y los routers en el medio de la red, llevado a cuestas The second difference between 407 and 70(bit is in the details of how 407 decides when to drop a packet and what packet it decides to drop. To understand the basic idea, consider a simple ./.) queue. 4ather than wait for the queue to become completely full and then be forced to drop each arriving packet <the tail drop policy of 2ection >.:.?=, we could decide to drop each arriving packet with some drop probability whenever the queue length e*ceeds some drop level. This idea is called early random drop. The 407 algorithm defines the details of how to monitor the queue length and when to drop a packet. &a segunda diferencia entre 407 y 70(bit est' en los /n the following paragraphs, we describe the 407 algorithm as originally proposed by .loyd and Sacobson. We note that several modifications have since been proposed both by the inventors and by other researchers, some of these are discussed in .urther 4eading. 9owever, the key ideas are the same as those presented below, and most current implementations are close to the algorithm that follows. .irst, 407 computes an average queue length using a weighted running average similar to the one used in the original T(P timeout computation. That is, +vg&en is computed as

sobre paquetes de datos. &a estrategia general es a veces llamado la gesti$n activa de colas, y la investigaci$n reciente parece indicar que es especialmente valioso para los flu"os T(P que tengan grandes productos retardo ancho de banda. 0l lector interesado puede e"ercer las referencias relevantes dadas al final del cap#tulo. detalles de c$mo 407 decide cu'ndo descartar un paquete y qu% paquete decide descartar. Para entender la idea b'sica, considere una cola ./.) simple. 0n lugar de esperar a que la cola se vuelva completamente lleno y entonces este obligado a abandonar cada paquete que llega <la pol#tica de ca#da de la cola de la 2ecci$n >.:.?=, podr#amos decidir descartar cada paquete que llega con algo de probabilidad de descarte cada ve- que la longitud de la cola e*ceda cierto nivel de ca#da. 0sta idea se llama ca#da temprana aleatoria. 0l algoritmo 407 define los detalles de c$mo supervisar la longitud de la cola y cuando descartar un paquete. 0n los p'rrafos siguientes se describe el algoritmo 407 como propuso inicialmente .loyd y Sacobson. )bservamos que varias modificaciones desde entonces se han propuesto tanto por los inventores y por otros investigadores, algunos de %stos se discuten en lecturas adicionales. 2in embargo, las ideas clave son las mismas que las que se presentan a continuaci$n, y las implementaciones actuales est'n m's cerca del algoritmo que sigue. Primero 407 calcula una longitud promedio de la cola usando un ponderado medio de funcionamiento similar a la utili-ada en el c'lculo de tiempo de espera de T(P originales. 0s decir, +vg&en se calcula como donde MQWeightQ? y 2ample&en es la longitud de la cola cuando se hace una medici$n de la muestra. 0n la mayor#a de las implementaciones de software, la longitud de la cola se mide cada ve- que un nuevo paquete llega al gateway. 0n el hardware, puede ser calculado en alg1n intervalo de muestreo fi"a. &a ra-$n para usar una longitud promedio de la cola en lugar de uno instant'nea es que captura m's precisa la noci$n de la congesti$n. 7ebido a la naturale-a de r'fagas del tr'fico de /nternet, las colas pueden llegar a ser llena muy r'pidamente y despu%s se vac#an de nuevo. 2i una cola est' gastando la mayor parte de su tiempo vac#o, entonces probablemente no es apropiado concluir que el router est' congestionado y para decirle a los hosts a disminuir. Por lo tanto, el c'lculo del promedio ponderado actual intenta detectar la congesti$n de larga vida, como se indica en la parte derecha de la figura >.?;, mediante la filtraci$n de los cambios a corto pla-o en la longitud de la cola. 6sted puede pensar en el promedio m$vil como un filtro paso ba"o donde el peso determina la constante de tiempo del filtro. &a cuesti$n de c$mo elegimos esta constante de tiempo se anali-an a continuaci$n.

where MQWeightQ? and 2ample&en is the length of the queue when a sample measurement is made. /n most software implementations, the queue length is measured every time a new packet arrives at the gateway. /n hardware, it might be calculated at some fi*ed sampling interval. The reason for using an average queue length rather than an instantaneous one is that it more accurately captures the notion of congestion. Because of the bursty nature of /nternet traffic, queues can become full very quickly and then become empty again. /f a queue is spending most of its time empty, then it3s probably not appropriate to conclude that the router is congested and to tell the hosts to slow down. Thus, the weighted running average calculation tries to detect long!lived congestion, as indicated in the right!hand portion of .igure >.?;, by filtering out short!term changes in the queue length. Jou can think of the running average as a low!pass filter, where Weight determines the time constant of the filter. The question of how we pick this time constant is discussed below.

2econd, 407 has two queue length thresholds that trigger certain activityI inThreshold and a*Threshold. When a packet arrives at the gateway, 407 compares the current +vg&en with these two thresholds, according to the following rulesI

2egundo, 407 tiene dos umbrales de longitud de cola que provocan cierta actividadI inThreshold y a*Threshold. (uando un paquete llega a la puerta de enlace, 407 compara la corriente +vg&en con estos dos umbrales, de acuerdo a las siguientes reglasI

if +vg&en inThreshold queue the packet inThreshold Q +vg&en Q a*Threshold calculate probability P drop the arriving packet with probability P if a*Threshold +vg&en drop the arriving packet /f the average queue length is smaller than the lower threshold, no action is taken, and if the average queue length is larger than the upper threshold, then the packet is always dropped. /f the average queue length is between the two thresholds, then the newly arriving packet is dropped with some probability P. This situation is depicted in .igure >.?>. The appro*imate relationship between P and +vg&en is shown in .igure >.?K. @ote that the probability of drop increases slowly when +vg&en is between the two thresholds, reaching a*P at the upper threshold, at which point it "umps to unity. The rationale behind this is that, if +vg&en reaches the upper threshold, then the gentle approach <dropping a few packets= is not working and drastic measures are called forI dropping all arriving packets. 2ome research has suggested that a smoother transition from random dropping to complete dropping, rather than the discontinuous approach shown here, may be appropriate. 2i la longitud promedio de la cola es m's peque5a que el umbral m's ba"o, no se toma ninguna acci$n, y si la longitud promedio de la cola es mayor que el umbral superior, entonces el paquete es siempre descartado. 2i la longitud promedio de la cola est' entre los dos umbrales, entonces el paquete reci%n llegado se descarta con cierta probabilidad P. 0sta situaci$n se representa en la .igura >.?>. &a relaci$n apro*imada entre P y +vg&en se muestra en la .igura >.?K. Tenga en cuenta que la probabilidad de ca#da aumenta lentamente cuando +vg&en est' entre los dos umbrales, alcan-ando a*P en el umbral superior, momento en el que salta a la unidad. &a ra-$n detr's de esto es que, si +vg&en alcan-a el umbral superior, entonces el enfoque amable <de"ando caer unos cuantos paquetes= no est' funcionando y las medidas dr'sticas son llamados paraI descartar todos los paquetes que llegan. +lgunas investigaciones han sugerido que una transici$n m's suave de descarte aleatorio para de"anr caer completa, en lugar del enfoque discontinua que se muestra aqu#, puede ser apropiado. if

+lthough .igure >.?K shows the probability of drop as a function only of +vg&en, the situation is actually a little more complicated. /n fact, P is a function of both +vg&en and how long it has been since the last packet was dropped. 2pecifically, it is computed as followsI +unque la figura >.?K muestra la probabilidad de ca#da

en funci$n s$lo de +vg&en, la situaci$n es en realidad un poco m's complicado. 7e hecho, P es una funci$n tanto de +vg&en y cu'nto tiempo ha sido desde que se cay$ el 1ltimo paquete. 0spec#ficamente, se calcula como sigueI

TempP is the variable that is plotted on the y!a*is in .igure >.?K, count keeps track of how many newly arriving packets have been queued <not dropped=, and +vg&en has been between the two thresholds. P increases slowly as count increases, thereby making a drop increasingly likely as the time since the last drop increases. This makes closely spaced drops relatively less likely than widely spaced drops.

TempP es la variable que se tra-a en el e"e y en la figura >.?K, count reali-a un seguimiento de cu'ntos paquetes reci%n llegados se han puesto en cola <no descartados=, y +vg&en ha sido entre los dos umbrales. P aumenta lentamente a medida que aumenta count, con lo que una ca#da cada ve- m's probable como el tiempo desde la 1ltima ca#da aumenta. 0sto hace que las ca#das estrechamente espaciados relativamente menos propensas que las ca#das muy espaciados. 0ste paso adicional en el c'lculo de P fue introducido por los inventores de 407 cuando observaron que, sin ella, las ca#das de paquetes no fueron bien distribuidos en el tiempo, sino que tienden a ocurrir en grupos. 7ebido a que las llegadas de paquetes de una determinada cone*i$n son probables llegar a r'fagas, esta acumulaci$n de ca#das puede causar m1ltiples ca#das en una sola cone*i$n. 0sto no es deseable, ya que s$lo una ca#da por tiempo de ida y vuelta es suficiente para causar que una cone*i$n redu-ca su tama5o de la ventana, mientras que m1ltiples ca#das podr#a enviarla de nuevo a arranque lento. and the initial value of P, would be half of a*P, or M.M?. +n arriving packet, of course, has a ZZ in ?MM chance of getting into the queue at this point. With

This e*tra step in calculating P was introduced by the inventors of 407 when they observed that, without it, the packet drops were not well distributed in time but instead tended to occur in clusters. Because packet arrivals from a certain connection are likely to arrive in bursts, this clustering of drops is likely to cause multiple drops in a single connection. This is not desirable, since only one drop per round!trip time is enough to cause a connection to reduce its window si-e, whereas multiple drops might send it back into slow start.

+s an e*ample, suppose that we set a*P to M.M: and count is initiali-ed to -ero. /f the average queue length were halfway between the two thresholds, then TempP,

each successive packet that is not dropped, P slowly increases, and by the time ;M packets have arrived without a drop, P would have doubled to M.M:. /n the unlikely event that ZZ packets arrived without loss, P reaches ?, guaranteeing that the ne*t packet is dropped. The important thing about this part of the algorithm is that it ensures a roughly even distribution of drops over time. (omo un e"emplo, supongamos que establecimos a*P a M,M: y count se iniciali-a a cero. 2i la longitud promedio de la cola eran a medio camino entre los dos The intent is that, if 407 drops a small percentage of packets when +vg&en e*ceeds inThreshold, this will cause a few T(P connections to reduce their window si-es, which in turn will reduce the rate at which packets arrive at the router. +ll going well, +vg&en will then decrease and congestion is avoided. The queue length can be kept short, while throughput remains high since few packets are dropped. @ote that, because 407 is operating on a queue length averaged over time, it is possible for the instantaneous queue length to be much longer than +vg&en. /n this case, if a packet arrives and there is nowhere to put it, then it will have to be dropped. When this happens, 407 is operating in tail drop mode. )ne of the goals of 407 is to prevent tail drop behavior if possible.

umbrales, entonces TempP, y el valor inicial de P, ser#a la mitad de a*P, o M.M?. 6n paquete que llega, por supuesto, tiene una oportunidad de ZZ en ?MM de entrar en la cola en este punto. (on cada paquete sucesivo que no se de"a caer, P aumenta lentamente, y por el tiempo ;M paquetes han llegado sin una ca#da, P se habr#a duplicado a M,M:. 0n el caso improbable de que ZZ paquetes llegaron sin p%rdida, P llega a ?, lo que garanti-a que se cae el siguiente paquete. &o importante de esta parte del algoritmo es que asegura una distribuci$n uniforme m's o menos de ca#das con el tiempo. &a intenci$n es que, si 407 descarta un peque5o porcenta"e de paquetes cuando +vg&en e*cede inThreshold, esto har' que unas pocas cone*iones T(P redu-can el tama5o de sus ventanas, que a su vereducir' la velocidad a la que los paquetes llegan al router. Todo va bien, +vg&en luego disminuir' y la congesti$n se evita. &a longitud de la cola puede ser corta, mientras que el rendimiento sigue siendo altos desde se descartan algunos paquetes. Tenga en cuenta que, debido a que 407 est' operando en una longitud de la cola promediada en el tiempo, es posible que la longitud de la cola instant'nea sea mucho m's largo que +vg&en. 0n este caso, si un paquete llega y no hay ning1n lugar para ponerlo, entonces tendr' que ser descartado. (uando esto sucede, 407 est' funcionando en modo de ca#da de la cola. 6no de los ob"etivos de 407 es prevenir el comportamiento ca#da de la cola si es posible.

The random nature of 407 confers an interesting property on the algorithm. Because 407 drops packets randomly, the probability that 407 decides to drop a particular flow3s packet<s= is roughly proportional to the share of the bandwidth that that flow is currently getting at that router. This is because a flow that is sending a relatively large number of packets is providing more candidates for random dropping. Thus, there is some sense of fair resource allocation built into 407, although it is by no means precise. &a naturale-a aleatoria de 407 confiere una propiedad @ote that a fair amount of analysis has gone into setting the various 407 parametersfor e*ample, a*Threshold, inThreshold, a*P, and Weight all in the name of optimi-ing the power function <throughput!to!delay ratio=. The performance of these parameters has also been confirmed through simulation, and the algorithm has been shown not to be overly sensitive to them. /t is important to keep in mind, however, that all of this analysis and simulation hinges on a particular characteri-ation of the network workload. The real contribution of 407 is a mechanism by which the router can more accurately

interesante en el algoritmo. 7ebido a que 407 descarta paquetes al a-ar, la probabilidad de que 407 decida abandonar paquete<s= de un determinado flu"o es apro*imadamente proporcional a la parte del ancho de banda que ese flu"o est' recibiendo en ese router. 0sto se debe a que un flu"o que est' enviando un n1mero relativamente grande de paquetes est' proporcionando m's candidatos para la ca#da aleatoria. Por lo tanto, hay cierto sentido de asignaci$n de recursos "usto incorporado en 407, aunque es de ninguna manera precisa. manage its queue length. 7efining precisely what constitutes an optimal queue length depends on the traffic mi* and is still a sub"ect of research, with real information now being gathered from operational deployment of 407 in the /nternet. Tenga en cuenta que una buena cantidad de an'lisis ha entrado en el establecimiento de los distintos par'metros 407! por e"emplo, a*Threshold, inThreshold, a*P y Peso! todo en el nombre de la optimi-aci$n de la funci$n de potencia <relaci$n

rendimiento!a retardo=. 0l desempe5o de estos par'metros tambi%n se ha confirmado a trav%s de la simulaci$n, y el algoritmo se ha demostrado no ser demasiado sensible a ellos. 0s importante tener en cuenta, sin embargo, que todo este an'lisis y simulaci$n depende de una caracteri-aci$n particular de la carga de traba"o de la red. &a verdadera (onsider the setting of the two thresholds, inThreshold and a*Threshold. /f the traffic is fairly bursty, then inThreshold should be sufficiently large to allow the link utili-ation to be maintained at an acceptably high level. +lso, the difference between the two thresholds should be larger than the typical increase in the calculated average queue length in one 4TT. 2etting a*Threshold to twice inThreshold seems to be a reasonable rule of thumb given the traffic mi* on today3s /nternet. /n addition, since we e*pect the average queue length to hover between the two thresholds during periods of high load, there should be enough free buffer space above a*Threshold to absorb the natural bursts that occur in /nternet traffic without forcing the router to enter tail drop mode. (onsiderar la configuraci$n de los dos umbrales,

contribuci$n de 407 es un mecanismo por el cual el router puede gestionar con m's e*actitud su longitud de la cola. &a definici$n precisa de lo que constituye una longitud $ptima de cola depende de la me-cla de tr'fico y sigue siendo un tema de investigaci$n, con informaci$n real que ahora se desprende de despliegue operativo de 407 en /nternet. inThreshold y a*Threshold. 2i el tr'fico es relativamente r'fagas, entonces inThreshold debe ser lo suficientemente grande como para permitir la utili-aci$n del enlace que se mantiene a un nivel aceptablemente alto. +dem's, la diferencia entre los dos umbrales debe ser mayor que el incremento t#pico en el calcula de longitud promedio de la cola en un 4TT. +"uste a*Threshold al doble inThreshold parece ser una regla ra-onable de oro dada la me-cla de tr'fico en la /nternet de hoy. +dem's, dado que se espera que la longitud promedio de la cola oscile en entre los dos umbrales en per#odos de alta carga, debe haber suficiente espacio de b1fer libre por encima a*Threshold para absorber las r'fagas naturales que se producen en el tr'fico de /nternet sin for-ar al router para entrar en el modo ca#da de la cola .

We noted above that Weight determines the time constant for the running average low!pass filter, and this gives us a clue as to how we might pick a suitable value for it. 4ecall that 407 is trying to send signals to T(P flows by dropping packets during times of congestion. 2uppose that a router drops a packet from some T(P connection and then immediately forwards some more packets from the same connection. When those packets arrive at the receiver, it starts sending duplicate +(\s to the sender. When the sender sees enough duplicate +(\s, it will reduce its window si-e. 2o, from the time the router drops a packet until the time when the same router starts to see some relief from the affected connection in terms of a reduced window si-e, at least one round!trip time must elapse for that connection. There is probably not much point in having the router respond to congestion on time scales much less than the round!trip time of the connections passing through it. +s noted previously, ?MM ms is not a bad estimate of average round!trip times in the /nternet. Thus, Weight should be chosen such that changes in queue length over time scales much less than ?MM ms are filtered out.

Ja hemos se5alado que el peso determina la constante de tiempo para el filtro de paso ba"o promedio de funcionamiento, y esto nos da una idea de c$mo podr#amos elegir un valor adecuado para ello. 4ecordemos que 407 est' tratando de enviar se5ales a los flu"os T(P de"ando caer paquetes durante momentos de congesti$n. 2upongamos que un router descarta un paquete de alguna cone*i$n T(P y luego reenv#a inmediatamente algunos m's paquetes de la misma cone*i$n. (uando los paquetes llegan al receptor, que comien-a a enviar +(\s duplicados al emisor. (uando el emisor ve suficientes +(\s duplicados, reducir' su tama5o de la ventana. Por lo tanto, desde el momento en que el router descarta un paquete hasta el momento en que el mismo router comien-a a ver algo de alivio de la cone*i$n afectada en t%rminos de una reducci$n de tama5o de la ventana, por lo menos una hora de ida y vuelta debe transcurrir para esa cone*i$n. Posiblemente no tiene mucho sentido tener el router responder a la congesti$n en las escalas de tiempo mucho menor que el tiempo de ida y vuelta de las cone*iones que pasan por %l. (omo se se5al$ anteriormente, ?MM ms, no es una mala estimaci$n del promedio de los tiempos de ida y vuelta en el /nternet. Por lo tanto, peso deber#a ser elegido de tal manera que los cambios en la longitud de la cola durante escalas de tiempo muy inferior a ?MM ms son filtrados. matter of some concern for several years. 6nresponsive flows use more than their fair share of network resources and could cause congestive collapse if there were enough of them, "ust as in the days before T(P

2ince 407 works by sending signals to T(P flows to tell them to slow down, you might wonder what would happen if those signals are ignored. This is often called the unresponsive flow problem, and it has been a

congestion control. 2ome of the techniques described in 2ection >.; can help with this problem by isolating certain classes of traffic from others. There is also the possibility that a variant of 407 could drop more heavily from flows that are unresponsive to the initial hints that it sends, this continues to be an area of active research. 7ado que 407 funciona enviando se5ales a T(P flu"os para decirles que reducir la velocidad, usted podr#a preguntarse qu% suceder#a si se ignoran esas se5ales. 0sto a menudo se llama el problema de flu"o no

responde, y que ha sido un motivo de preocupaci$n desde hace varios a5os. .lu"os que no responden usan m's de su cuota "usta de los recursos de red y podr#a causar colapso congestivo si hab#a suficiente de ellos, al igual que en los d#as previos a control de congesti$n T(P. +lgunas de las t%cnicas que se describen en la secci$n >.; puede ayudar con este problema mediante el aislamiento de ciertas clases de tr'fico de los dem's. Tambi%n e*iste la posibilidad de que una variante de 407 podr#a caer m's intensamente de los flu"os que no responden a las sugerencias iniciales que env#a, lo que sigue siendo un 'rea de investigaci$n activa.

6.8.) Source2;ased Congestion A*oidance (1uente "asada en e*itacin de congestin CA)


6nlike the two previous congestion!avoidance schemes, which depended on new mechanisms in the routers, we now describe a strategy for detecting the incipient stages of congestionbefore losses occur from the end hosts. We first give a brief overview of a collection of related mechanisms that use different information to detect the early stages of congestion, and then we describe a specific mechanism in some detail. + diferencia de las dos anteriores esquemas de evitaci$n de congesti$n, que depend#a de nuevos mecanismos en los routers, ahora describimos una estrategia para detectar la etapa inicial de la congesti$n! antes de que las p%rdidas ocurren! desde los hosts finales. 0n primer lugar, damos una breve descripci$n de un con"unto de mecanismos relacionados que utili-an informaci$n diferente para detectar las primeras etapas de la congesti$n y, a continuaci$n se describe un mecanismo espec#fico con cierto detalle. &a idea general de estas t%cnicas es observar por alguna se5al desde la red lo que alguna cola del router est' acumulando y que la congesti$n suceder' pronto si no se hace nada al respecto. Por e"emplo, la fuente puede notar que a medida que los paquetes de las colas se acumulan en los routers de la red, hay un aumento apreciable de la 4TT para cada paquete sucesivo que env#a. 6n algoritmo particular, aprovecha esta observaci$n como sigueI &a ventana de congesti$n aumenta normalmente como en T(P, pero cada dos ida y vuelta retarda el algoritmo comprueba para ver si el 4TT es mayor que el promedio de los valores de 4TT m#nimo y m'*imo visto hasta ahora. 2i lo es, entonces el algoritmo disminuye la ventana de congesti$n por un octavo. 6n segundo algoritmo hace algo similar. &a decisi$n en cuanto a si o no cambiar el tama5o actual de la ventana se basa en cambios tanto del 4TT y el tama5o de la ventana. &a ventana se a"usta una ve- cada dos retardos de ida y vuelta basado en el producto optimal point. 2i el resultado es positivo, la fuente disminuye el tama5o de la ventana por un octavo, si el resultado es negativo o M, la fuente aumenta la ventana en un

The general idea of these techniques is to watch for some sign from the network that some router3s queue is building up and that congestion will happen soon if nothing is done about it. .or e*ample, the source might notice that as packet queues build up in the network3s routers, there is a measurable increase in the 4TT for each successive packet it sends. )ne particular algorithm e*ploits this observation as followsI The congestion window normally increases as in T(P, but every two round!trip delays the algorithm checks to see if the current 4TT is greater than the average of the minimum and ma*imum 4TTs seen so far. /f it is, then the algorithm decreases the congestion window by one! eighth. + second algorithm does something similar. The decision as to whether or not to change the current window si-e is based on changes to both the 4TT and the window si-e. The window is ad"usted once every two roundtrip delays based on the product /f the result is positive, the source decreases the window si-e by one eighth, if the result is negative or M, the source increases the window by one ma*imum packet si-e. @ote that the window changes during every ad"ustment, that is, it oscillates around its

tama5o m'*imo de paquete. Tenga en cuenta que la ventana cambia durante cada a"uste, es decir, que oscila +nother change seen as the network approaches congestion is the flattening of the sending rate. + third scheme takes advantage of this fact. 0very 4TT, it increases the window si-e by one packet and compares the throughput achieved to the throughput when the window was one packet smaller. /f the difference is less than one!half the throughput achieved when only one packet was in transitas was the case at the beginning of the connectionthe algorithm decreases the window by one packet. This scheme calculates the throughput by dividing the number of bytes outstanding in the network by the 4TT. + fourth mechanism, the one we are going to describe in more detail, is similar to this last algorithm in that it looks at changes in the throughput rate or, more specifically, changes in the sending rate. 9owever, it differs from the third algorithm in the way it calculates throughput, and instead of looking for a change in the slope of the throughput it compares the measured throughput rate with an e*pected throughput rate. The algorithm, T(P Gegas, is not widely deployed in the /nternet, but the strategy it takes continues to be studied. <2ee the .urther 4eading section for additional information.= The intuition behind the Gegas algorithm can be seen in the trace of standard T(P given in .igure >.?[. <2ee the preceding sidebar for an e*planation of the name T(P Gegas.= The top graph shown in .igure >.?[ traces the connection3s congestion window, it shows the same information as the traces given earlier in this section. The middle and bottom graphs depict new informationI The middle graph shows the average sending rate as measured at the source, and the bottom graph shows the average queue length as measured at the bottleneck router. +ll three graphs are synchroni-ed in time. /n the period between L.; and >.M seconds <shaded region=, the congestion window increases <top graph=. We e*pect the observed throughput to also increase, but instead it stays flat <middle graph=. This is because the throughput cannot increase beyond the available bandwidth. Beyond this point, any increase in the window si-e only results in packets taking up buffer space at the bottleneck router <bottom graph=.

alrededor de su punto $ptimo. )tro cambio visto como la red se apro*ima a la congesti$n es el aplanamiento de la tasa de env#o. 6n tercer esquema se aprovecha de este hecho. (ada 4TT, aumenta el tama5o de la ventana por un paquete y compara el rendimiento alcan-ado a el rendimiento cuando la ventana era un paquete m's peque5o. 2i la diferencia es menos de la mitad el rendimiento alcan-ado cuando s$lo un paquete estaba en tr'nsito! como era el caso en el inicio de la cone*i$n! el algoritmo disminuye la ventana por un paquete. 0ste esquema calcula el rendimiento dividiendo el n1mero de bytes en circulaci$n en la red por el 4TT. 6n cuarto mecanismo, el que vamos a describir con m's detalle, es similar a este 1ltimo algoritmo que anali-a los cambios en la tasa de rendimiento o, m's espec#ficamente, los cambios en la tasa de env#o. 2in embargo, se diferencia del tercer algoritmo en la forma en que se calcula el rendimiento, y en lugar de buscar un cambio en la pendiente del rendimiento se compara la tasa de rendimiento medida con una tasa de rendimiento esperado. 0l algoritmo, T(P Gegas, no es ampliamente desplegado en la /nternet, pero la estrategia que toma contin1a en estudio. <Gea la secci$n de &ecturas +dicionales para informaci$n adicional.= &a intuici$n detr's del algoritmo Gegas se puede ver en la tra-a de T(P est'ndar dado en la .igura >.?[. <Gea el recuadro anterior para una e*plicaci$n del nombre T(P Gegas.= 0l gr'fico superior muestra en la .igura >.?[ tra-as ventana de congesti$n de la cone*i$n, muestra la misma informaci$n que las tra-as dadas anteriormente en esta secci$n. &os gr'ficos central e inferior representan la nueva informaci$nI 0l gr'fico central muestra la tasa de env#o promedio tal como se mide en la fuente, y el gr'fico inferior muestra la longitud de la cola promedio medida en el enrutador cuello de botella. Todas las tres gr'ficas est'n sincroni-ados en el tiempo. 0n el per#odo comprendido entre L,; y >,M segundos <regi$n sombreada=, la ventana de congesti$n aumenta <parte superior del gr'fico=. 0speramos que el rendimiento observado tambi%n aumenta, pero en cambio se mantiene plana <gr'fico central=. 0sto es porque el rendimiento no puede aumentar m's all' del ancho de banda disponible. 's all' de este punto, cualquier aumento en el tama5o de la ventana s$lo resulta en paquetes que ocupan espacio b1fer en el router cuello de botella <gr'fico inferior=. 6na met'fora 1til que describe el fen$meno se ilustra en la figura >.?[ est' conduciendo sobre hielo. 0l veloc#metro <ventana de congesti$n= puede decir que usted va EM millas por hora, pero al asomarse por la ventanilla del coche y ver a las personas que pasan a pie <medido tasa de env#o= usted sabe que usted va no m's de ; millas por hora. &a energ#a e*tra est' siendo absorbida por los neum'ticos del coche <buffers del router=.

+ useful metaphor that describes the phenomenon illustrated in .igure >.?[ is driving on ice. The speedometer <congestion window= may say that you are going EM miles an hour, but by looking out the car window and seeing people pass you on foot <measured sending rate= you know that you are going no more than ; miles an hour. The e*tra energy is being absorbed by the car3s tires <router buffers=.

.ig. >.?[. Gentana de congesti$n frente a la tasa de rendimiento observado <los tres gr'ficos est'n sincroni-ados=. +rriba, la ventana de congesti$n, medio, el rendimiento observado, inferior, espacio de b1fer ocupado en el router. &#nea de color O (ongestionWindow, vi5eta s$lida O tiempo de espera, marcas de control O tiempo en que se transmite cada paquete, barras verticalesOmomento en el que un paquete que finalmente se retransmiti$ se transmite primero.

Tahoe, 4eno, and Gegas The name AT(P GegasB is a takeoff on earlier implementations of T(P that were distributed in releases of L.E B27 6ni*. These releases were known as Tahoe and 4eno <which, like &as Gegas, are places in @evada=, and the versions of T(P became known by the names of the B27 release. T(P Tahoe, which is also known as B27 @etwork 4elease ?.M <B@4?=, corresponds to the original implementation of Sacobson3s congestion!control mechanism and includes all of the mechanisms described in 2ection >.E e*cept fast recovery. T(P 4eno, which is also known as B27 @etwork 4elease :.M <B@4:=, adds the fast recovery mechanism, along with an optimi-ation known as header predictionoptimi-ing for the common case that segments arrive in order. T(P 4eno also supports delayed +(\sacknowledging every other segment rather than every segmentalthough this is a selectable option that is sometimes turned off. + version of T(P distributed in L.L B27 6ni* added the Abig windowsB e*tensions described in 2ection ;.:. 0l nombre de CT(P GegasC es un despegue en With the rising popularity of the &inu* operating system, and an increase in the number of researchers looking at T(P congestion control, the situation has grown considerably more comple*. &inu* today offers a range of settings for T(P congestion control, with Gegas being one option and a newer variant called T(P (6B/( being the default. The whole idea of using place names to refer to T(P variants has been taken up enthusiastically <see T(P!/llinois and T(P!Westwood,

implementaciones anteriores de T(P que se distribuyeron en las versiones de L.E B27 6ni*. 0stas versiones fueron conocidos como Tahoe y 4eno <que, como &as Gegas, son lugares en @evada=, y las versiones de T(P se hicieron conocidos por los nombres de la versi$n B27. T(P Tahoe, que tambi%n se conoce como B27 4ed 4elease ?.M <B@4?=, corresponde a la implementaci$n original de mecanismo de control de congesti$n de Sacobson, e incluye todos los mecanismos descritos en la 2ecci$n >.E, e*cepto recuperaci$n r'pida. 4eno T(P, que tambi%n se conoce como B27 4ed 4elease :.M <B@4:=, a5ade el mecanismo de recuperaci$n r'pida, "unto con una optimi-aci$n conocida como predicci$n de cabecera! la optimi-aci$n para el caso com1n de que los segmentos llegan en orden. T(P 4eno tambi%n soporta retrasos en +(\s !reconociendo cada dos segmentos en lugar de todos los segmentos! aunque esto es una opci$n seleccionable que a veces se apaga. 6na versi$n de T(P distribuidos en L.L B27 6ni* a5ade las e*tensiones Cgrandes ventanasC que se describen en la secci$n ;.:. for e*ample=. (on la creciente popularidad del sistema operativo &inu*, y un aumento en el n1mero de investigadores que buscan en el control de congesti$n de T(P, la situaci$n ha crecido considerablemente m's comple"a. &inu* hoy en d#a ofrece un rango de a"ustes para el control de congesti$n de T(P, con Gegas siendo una opci$n y una nueva variante llamada T(P (6B/(

siendo el valor predeterminado. &a idea de utili-ar los nombres de lugares para hacer referencia a las )ne point you should take away from this discussion of T(P3s lineage is that T(P has been a rather fluid protocol over the last several years, especially in its congestion!control mechanism. /n fact, you would not even find universal agreement about which technique was introduced in which release, due to the availability of intermediate versions and the fact that patch has been layered on top of patch. +ll that can be said with any certainty is that any two implementations of T(P that follow the original specification, although they should interoperate, will not necessarily perform well. 4ecogni-ing the performance implications of interactions among T(P variants is a tricky business. /n other words, you could argue that T(P is no longer defined by a specification but rather by an implementation. The only question is, which implementationR T(P Gegas uses this idea to measure and control the amount of e*tra data this connection has in transit, where by Ae*tra dataB we mean data that the source would not have transmitted had it been trying to match e*actly the available bandwidth of the network. The goal of T(P Gegas is to maintain the ArightB amount of e*tra data in the network. )bviously, if a source is sending too much e*tra data, it will cause long delays and possibly lead to congestion. &ess obviously, if a connection is sending too little e*tra data, it cannot respond rapidly enough to transient increases in the available network bandwidth. T(P Gegas3s congestion! avoidance actions are based on changes in the estimated amount of e*tra data in the network, not only on dropped packets. We now describe the algorithm in detail.

variantes de T(P, se ha incorporado con entusiasmo <ver T(P!/llinois y T(P!Westwood, por e"=. 6no de los puntos que usted debe tomar distancia de esta discusi$n sobre el lina"e de T(P es que T(P ha sido m's bien un protocolo fluido en los 1ltimos a5os, especialmente en su mecanismo de control de congesti$n. 7e hecho, usted ni siquiera se encontrar#a un acuerdo universal acerca de qu% t%cnica se introdu"o en qu% versi$n, debido a la disponibilidad de las versiones intermedias y el hecho de que el parche se ha acodada encima del parche Todo lo que se puede decir con certe-a es que las dos implementaciones de T(P que siguen la especificaci$n original, aunque deber#an interoperar, no son necesariamente un buen desempe5o. 4econociendo las implicaciones de rendimiento de las interacciones entre las variantes T(P es un negocio dif#cil. 0n otras palabras, se podr#a argumentar que T(P ya no est' definido por una especificaci$n, pero m's bien por una aplicaci$n. &a 1nica pregunta es, Yqu% aplicaci$nR T(P Gegas utili-a esta idea para medir y controlar la cantidad de datos adicionales esta cone*i$n tiene en tr'nsito, donde por Cdatos adicionalesC nos referimos a los datos de que la fuente no habr#a transmitido ten#a su estado tratando de coincidir e*actamente con el ancho de banda disponible de la red. 0l ob"etivo de T(P Gegas es mantener la cantidad CcorrectaC de los datos adicionales en la red. )bviamente, si una fuente est' enviando demasiados datos adicionales, que causar' grandes retrasos y posiblemente provocar una congesti$n. 7e manera menos obvia, si una cone*i$n est' enviando muy pocos datos adicionales, no puede responder con suficiente rapide- a los aumentos transitorios en el ancho de banda de red disponible. +cciones de evitaci$n de la congesti$n de T(P Gegas se basan en los cambios en la cantidad estimada de datos adicionales en la red, no s$lo en la p%rdida de paquetes. 7escribimos ahora el algoritmo en detalle. Primero definir Base4TT de un flu"o determinado para ser el 4TT de un paquete cuando no est' congestionado el flu"o. 0n la pr'ctica, T(P Gegas establece Base4TT al m#nimo de todos los tiempos de ida y vuelta medidos, es com1nmente el 4TT del primer paquete enviado por la cone*i$n, antes de que la cola de router aumente debido al tr'fico generado por este flu"o. 2i asumimos que no estamos desbordando la cone*i$n, entonces el rendimiento esperado se indica por donde (ongestionWindow es la ventana de congesti$n T(P, que se asume <para los fines de esta discusi$n= sea igual al n1mero de bytes en tr'nsito. acknowledgment arrives, and dividing the number of bytes transmitted by the sample 4TT. This calculation is done once per round!trip time. 2econd, T(P Gegas calculates the current sending rate, +ctual4ate. This is done by recording the sending time

.irst, define a given flow3s Base4TT to be the 4TT of a packet when the flow is not congested. /n practice, T(P Gegas sets Base4TT to the minimum of all measured round!trip times, it is commonly the 4TT of the first packet sent by the connection, before the router queues increase due to traffic generated by this flow. /f we assume that we are not overflowing the connection, then the e*pected throughput is given by where (ongestionWindow is the T(P congestion window, which we assume <for the purpose of this discussion= to be equal to the number of bytes in transit. 2econd, T(P Gegas calculates the current sending rate, +ctual4ate. This is done by recording the sending time for a distinguished packet, recording how many bytes are transmitted between the time that packet is sent and when its acknowledgment is received, computing the sample 4TT for the distinguished packet when its

for a distinguished packet, recording how many bytes are transmitted between the time that packet is sent and when its acknowledgment is received, computing the sample 4TT for the distinguished packet when its Third, T(P Gegas compares +ctual4ate to 0*pected4ate and ad"usts the window accordingly. We let 7iff O 0*pected4ateX+ctual4ate. @ote that 7iff is positive or M by definition, since +ctual4ate_0*pected4ate implies that we need to change Base4TT to the latest sampled 4TT. We also define two thresholds, PQc, roughly corresponding to having too little and too much e*tra data in the network, respectively. When 7iff QP, T(P Gegas increases the congestion window linearly during the ne*t 4TT, and when 7iff _c, T(P Gegas decreases the congestion window linearly during the ne*t 4TT. T(P Gegas leaves the congestion window unchanged when PQ 7iff Qc /ntuitively, we can see that the farther away the actual throughput gets from the e*pected throughput, the more congestion there is in the network, which implies that the sending rate should be reduced. The c threshold triggers this decrease. )n the other hand, when the actual throughput rate gets too close to the e*pected throughput, the connection is in danger of not utili-ing the available bandwidth. TheP threshold triggers this increase. The overall goal is to keep between P and c e*tra bytes in the network. .igure >.?Z traces the T(P Gegas congestion!avoidance algorithm. The top graph traces the congestion window, showing the same information as the other traces given throughout this chapter. The bottom graph traces the e*pected and actual throughput rates that govern how the congestion window is set. /t is this bottom graph that best illustrates how the algorithm works. The colored line tracks the 0*pected4ate, while the black line tracks the +ctual4ate.

acknowledgment arrives, and dividing the number of bytes transmitted by the sample 4TT. This calculation is done once per round!trip time. 0n tercer lugar, T(P Gegas compara +ctual4ate a 0*pected4ate y a"usta la ventana correspondiente. 7e"amos 7iff O 0*pected4ate!+ctual4ate. Tenga en cuenta que 7iff es positivo o M, por definici$n, ya que +ctual4ate_ 0*pected4ate implica que necesitamos cambiar Base4TT a la 1ltima 4TT muestra. Tambi%n definimos dos umbrales, P Qc, que corresponde apro*imadamente a tener muy pocos y demasiados datos adicionales en la red, respectivamente. (uando 7if QP, T(P Gegas incrementa la ventana de congesti$n linealmente durante el pr$*imo 4TT, y cuando 7if._ c, T(P Gegas disminuye la ventana de congesti$n linealmente durante el pr$*imo 4TT. T(P Gegas de"a la ventana de congesti$n sin cambios cuando PQ 7iff Qc. /ntuitivamente, podemos ver que mientras m's le"os el rendimiento real obtiene del rendimiento esperado, m's congesti$n hay en la red, lo que implica que la tasa de env#o se debe reducir. 0l umbral c provoca esta disminuci$n. Por otro lado, cuando la tasa de rendimiento real se acerca demasiado al rendimiento esperado, la cone*i$n est' en peligro de no utili-ar el ancho de banda disponible. 0l umbral P provoca este aumento. 0l ob"etivo general es mantener entre P y c bytes adicionales en la red.

.igura >.?Z tra-as el T(P Gegas algoritmo de congesti$n de evitaci$n. 0l gr'fico superior tra-a la ventana de congesti$n, que muestra la misma informaci$n que las otras tra-as dados a lo largo de este cap#tulo. 0l gr'fico inferior tra-a las tasas esperadas y las reales de rendimiento que determinan c$mo se establece la ventana de congesti$n. 0ste es el gr'fico inferior que me"or ilustra c$mo funciona el algoritmo. &a l#nea de color rastrea el 0*pected4ate, mientras que la l#nea negro sigue el +ctual4ate. .ig. ?>.?Z Tra-a de T(P Gegas mecanismo de congesti$n de evitaci$n. +rriba, la ventana de congesti$n, parte inferior, que se espera <l#nea de color= y actual <l#nea de color negro= el rendimiento. 0l 'rea sombreada es la regi$n entre la P y c umbrales.

The wide shaded strip gives the region between the P and c thresholds, the top of the shaded strip is P \Bps away from 0*pected4ate, and the bottom of the shaded strip is c \Bps away from 0*pected4ate. The goal is to keep the +ctual4ate between these two thresholds, within the shaded region. Whenever +ctual4ate falls below the shaded region <i.e., gets too far from 0*pected4ate=, T(P Gegas decreases the congestion window because it fears that too many packets are being buffered in the network. &ikewise, whenever +ctual4ate goes above the shaded region <i.e., gets too close to the 0*pected4ate=, T(P Gegas increases the congestion window because it fears that it is underutili-ing the network.

&a banda ancha sombreada da la regi$n entre los umbrales de P y c, la parte superior de la banda sombreada es P \bps le"os de 0*pected4ate, y la parte inferior de la tira sombreada es c \BP2 le"os de 0*pected4ate. 0l ob"etivo es mantener el +ctual4ate entre estos dos umbrales, dentro de la regi$n sombreada. 2iempre que +ctual4ate cae por deba"o de la regi$n sombreada <es decir, se pone demasiado le"os de 0*pected4ate=, T(P Gegas disminuye la ventana de congesti$n, ya que teme que demasiados paquetes se est'n buffer en la red. 7el mismo modo, cada ve- que +ctual4ate pasa por encima de la regi$n sombreada <es decir, se acerca demasiado a el 0*pected4ate=, T(P Gegas aumenta la ventana de congesti$n porque teme de que se subutili-ar la red. 7ebido a que el algoritmo, como se acaba de presentar, compara la diferencia entre las tasas de rendimientos reales y esperados a los umbrales de P y c, estos dos umbrales se definen en t%rminos de kbps. 2in embargo, tal ve- sea m's e*acto pensar en t%rminos de cu'ntos buffers adicionales la cone*i$n est' ocupando en la red. Por e"emplo, en una cone*i$n con un Base4TT de ?MM ms y un tama5o de paquete de ? \B, si P O EM \Bps y c O >M \Bps, entonces podemos pensar en P como especificar que la cone*i$n se debe ocupar por lo menos E e*tra buffers en la red y c como se especifica que la cone*i$n debe ocupar no m's de > buffers e*tra en la red. 0n la pr'ctica, un valor de P a ? b1fer y c a E buffers funciona bien. linear decrease "ust described is an early decrease in the congestion window that should happen before congestion occurs and packets start being dropped.

Because the algorithm, as "ust presented, compares the difference between the actual and e*pected throughput rates to the P and c thresholds, these two thresholds are defined in terms of \Bps. 9owever, it is perhaps more accurate to think in terms of how many e*tra buffers the connection is occupying in the network. .or e*ample, on a connection with a Base4TT of ?MM ms and a packet si-e of ? \B, if P O EM \Bps and cO>M \Bps, then we can think of P as specifying that the connection needs to be occupying at least E e*tra buffers in the network and c as specifying that the connection should occupy no more than > e*tra buffers in the network. /n practice, a setting of P to ? buffer and c to E buffers works well. .inally, you will notice that T(P Gegas decreases the congestion window linearly, seemingly in conflict with the rule that multiplicative decrease is needed to ensure stability. The e*planation is that T(P Gegas does use multiplicative decrease when a timeout occurs, the

.inalmente, te dar's cuenta de que T(P Gegas disminuye la ventana de congesti$n linealmente, aparentemente en conflicto con la norma de que se requiere disminuci$n multiplicativa para asegurar la estabilidad. &a e*plicaci$n es que T(P Gegas hace uso ,valuatin+ a New Con+estion-Control Mechanism 2uppose you develop a new congestion!control mechanism and want to evaluate its performance. .or e*ample, you might want to compare it to the current mechanism running on the /nternet. 9ow do you go about measuring and evaluating your mechanismR +lthough at one time the /nternet3s primary purpose in life was to support networking research, today it is a large production network and therefore completely inappropriate for running a controlled e*periment. /f your approach is purely end to endthat is, if it assumes only ./.) routers within the /nternetthen it is possible to run your congestion!control mechanism on a small set of hosts and to measure the throughput your connections are able to achieve. We need to add a word of caution here, however. /t is surprisingly easy to invent a congestion!control mechanism that achieves five times the throughput of T(P across the /nternet. Jou simply blast packets into the /nternet at a high rate, thereby causing congestion. +ll the other hosts running T(P detect this congestion and reduce the rate at which they are sending packets. Jour mechanism then happily consumes all the bandwidth. This strategy is fast but hardly fair. 2i su enfoque es puramente de e*tremo a e*tremo! es 0*perimenting directly on the /nternet, even when done carefully, will not work when your congestion! control mechanism involves changes to the routers. /t is simply not practical to change the software running on thousands of routers for the sake of evaluating a new congestion!control algorithm. /n this case, network designers are forced to test their systems on simulated networks or private testbed networks. .or e*ample, the T(P traces presented in this chapter were generated by an implementation of T(P that was running on a network simulator. The challenge in either a simulation or a testbed is coming up with a topology and a traffic workload that are representative of the real /nternet.

de disminuci$n multiplicativo cuando se produce un tiempo de espera, los disminuci$n lineal se acaba de describir es una disminuci$n temprana en la ventana de congesti$n que debe ocurrir antes de que ocurra la congesti$n y los paquetes de inicio siendo descartado. ,valuacin de un nuevo mecanismo de Control de con+estin 2uponga que usted desarrolla un nuevo mecanismo de control de congesti$n y desea evaluar su rendimiento. Por e"emplo, es posible que desee comparar con el mecanismo actual que se e"ecuta en /nternet. Y($mo hace usted para medir y evaluar su mecanismoR +unque en un momento el ob"etivo principal del /nternet en la vida consist#a en apoyar la creaci$n de redes de investigaci$n, hoy en d#a es una red de producci$n grande y, por tanto, totalmente inadecuado para e"ecutar un e*perimento controlado. decir, si se asume s$lo los routers ./.) dentro de la /nternet! entonces es posible hacer funcionar su mecanismo de control de congesti$n en un peque5o con"unto de hosts y medir el rendimiento de las cone*iones pueden lograr. Tenemos que a5adir una palabra de precauci$n aqu#, sin embargo. 0s sorprendentemente f'cil inventar un mecanismo de control de congesti$n que logra cinco veces el rendimiento de T(P a trav%s de /nternet. 6sted simplemente e*plosi$n paquetes en /nternet a un ritmo elevado, lo que provoca la congesti$n. Todos los dem's hosts que e"ecutan T(P detectan esta congesti$n y reducen la velocidad a la que est'n enviando paquetes. 2u mecanismo entonces feli-mente consume todo el ancho de banda. 0sta estrategia es r'pida, pero no es "usta. 0*perimentar directamente en /nternet, incluso cuando se hace con cuidado, no traba"ar' cuando el mecanismo de control de la congesti$n implica cambios en los routers. 2implemente no es pr'ctico cambiar el software que se e"ecuta en miles de enrutadores por el bien de la evaluaci$n de un nuevo algoritmo de control de congesti$n. 0n este caso, los dise5adores de la red se ven obligados a probar sus sistemas en las redes de bancos de pruebas simuladas o redes privadas. Por e"emplo, las tra-as T(P presentadas en este cap#tulo fueron generados por una implementaci$n de T(P que se estaba e"ecutando en un simulador de red. 0l desaf#o, ya sea en una simulaci$n o un banco de pruebas es dar con una topolog#a y una carga de tr'fico que son representativos de la /nternet real.

6.6 Su##ary
+s we have "ust seen, the issue of resource allocation is not only central to computer networking, it is also a very hard problem. This chapter has e*amined two aspects of resource allocation. The first, congestion control, is concerned with preventing overall degradation of service when the demand for resources by hosts e*ceeds the supply available in the network. The second aspect is the provision of different qualities of service to applications that need more assurances than those provided by the best!effort model. (omo acabamos de ver, la cuesti$n de la asignaci$n de recursos no s$lo es esencial para las redes de computadoras, sino que tambi%n es un problema muy dif#cil. 0n este cap#tulo se ha e*aminado dos aspectos de la asignaci$n de recursos. 0l primero, el control de la congesti$n, se ocupa de la prevenci$n de la degradaci$n del servicio en general, cuando la demanda de recursos por parte de hosts supera la oferta disponible en la red. 0l segundo aspecto es la provisi$n de diferentes calidades de servicio para las aplicaciones que necesitan m's garant#as que las previstas por el

modelo de me"or esfuer-o ost congestion!control mechanisms are targeted at the best!effort service model of today3s /nternet, where the primary responsibility for congestion control falls on the end nodes of the network. Typically, the source uses feedbackeither implicitly learned from the network or e*plicitly sent by a routerto ad"ust the load it places on the network, this is precisely what T(P3s congestion!control mechanism does. &a mayor#a de los mecanismos de control de /ndependent of e*actly what the end nodes are doing, the routers implement a queuing discipline that governs which packets get transmitted and which packets get dropped. 2ometimes this queuing algorithm is sophisticated enough to segregate traffic <e.g., W.H=, in other cases, the router attempts to monitor its queue length and then signals the source host when congestion is about to occur <e.g., 407 gateways and 70(bit=. /ndependiente de lo que e*actamente los nodos finales est'n haciendo, los routers implementan una disciplina de colas que gobierna qu% paquetes son transmitidos y qu% paquetes se caen. + veces, este algoritmo de cola es suficientemente sofisticado como para segregar el tr'fico <por e"emplo, W.H=, en otros casos, el router intenta controlar su longitud de la cola y, a continuaci$n las se5ales de la fuente de acogida cuando la congesti$n est' a punto de producirse <por e"emplo, puertas de enlace 407 y 70(bit=. congesti$n est'n dirigidos al modelo de servicio de me"or esfuer-o de la actual /nternet, en donde la responsabilidad principal de control de la congesti$n cae en los nodos finales de la red. @ormalmente, la fuente utili-a la retroalimentaci$n! ya sea impl#cita aprendido de la red o enviadas e*pl#citamente por un router! para a"ustar la carga que impone a la red, esto es precisamente lo que hace mecanismo de control de congesti$n de T(P.

0merging quality of service approaches aim to do substantially more than "ust control congestion. Their goal is to enable applications with widely varying requirements for delay, loss, and throughput to have those requirements met through new mechanisms inside the network. The /ntegrated 2ervices </nt2erv= approach allows individual application flows to specify their needs to the routers using an e*plicit signalling mechanism <42GP=, while 7ifferentiated 2ervices <7iff2erv= assigns packets into a small number of classes that receive differentiated treatment in the routers. 7ifferentiated 2ervices is by far the more widely deployed approach, and yet neither 7iff2erv nor /nt2erv has seen much deployment in the public /nternet. 0mergentes enfoques de calidad de servicios tienen como ob"etivo hacer mucho m's que un simple control de la congesti$n. 2u ob"etivo es permitir a las aplicaciones con muy diversas necesidades de retraso, p%rdida, y el rendimiento para tener esos requisitos cumplidos a trav%s de nuevos mecanismos dentro de la red. 0l enfoque de 2ervicios /ntegrados </nt2erv= permite la aplicaci$n individual fluye para especificar sus necesidades a los routers utili-ando un mecanismo de se5ali-aci$n e*pl#cita <42GP=, mientras que los 2ervicios 7iferenciados <7iff2erv= asigna los paquetes en un peque5o n1mero de clases que reciben tratamiento diferenciado en los enrutadores. 2ervicios diferenciados es, con mucho, el m%todo m's ampliamente desplegado, y sin embargo ni 7iff2erv ni /nt2erv ha visto mucho en el despliegue de la /nternet p1blica.

You might also like