Demora en cola aplicada al control de congestión TCP

Autores
Rigotti, Guillermo
Año de publicación
2015
Idioma
español castellano
Tipo de recurso
documento de conferencia
Estado
versión publicada
Descripción
Los métodos de control de congestión utilizados por TCP se basan en modificar la tasa de envío en función de la carga de la red. Tradicionalmente la estimación se hacía sólo en base a las pérdidas de paquetes. Dos problemas conocidos de este mecanismo son la necesaria producci´on de pérdidas de paquetes para estimar la carga y la sincronización de flujos. En 1989 surge la idea de utilizar la demora ida y vuelta experimentada por los paquetes (RTT) para detectar la congestión anticipadamente. El emisor disminuye entonces su tasa de envío antes de que se produzca una pérdida, mejorando la eficiencia del protocolo y el throughput de la red (p. ej. TCP Vegas y FAST). Si bien medir el RTT es sencillo, el valor obtenido no basta para una correcta estimación de la carga, ya que se debe tener en cuenta, entre otros factores, la asimetría en los caminos de ida y de vuelta. Por eso se ha intentado estimar la carga en la red de manera más precisa a partir de la demora emisor-receptor (OWD: one way delay). Sin embargo, medir esta demora no es inmediato, ya que los relojes del emisor y del receptor deben estar sincronizados, para lo que se recurre a servidores NTP o uso de GPS. Esto es adecuado para algunas aplicaciones (p.ej.VoIP), pero no para el caso de flujos TCP, ya que por su número y ubicación pueden generar un overhead considerable (NTP) o no tener capacidad de GPS.
Sociedad Argentina de Informática e Investigación Operativa (SADIO)
Materia
Ciencias Informáticas
control de congestión
TCP
Nivel de accesibilidad
acceso abierto
Condiciones de uso
http://creativecommons.org/licenses/by-sa/3.0/
Repositorio
SEDICI (UNLP)
Institución
Universidad Nacional de La Plata
OAI Identificador
oai:sedici.unlp.edu.ar:10915/54843
Acceder
id SEDICI_5e5180b390502c6dc3c317c442e4f725
oai_identifier_str oai:sedici.unlp.edu.ar:10915/54843
network_acronym_str SEDICI
repository_id_str 1329
network_name_str SEDICI (UNLP)
spelling Demora en cola aplicada al control de congestión TCPRigotti, GuillermoCiencias Informáticascontrol de congestiónTCPLos métodos de control de congestión utilizados por TCP se basan en modificar la tasa de envío en función de la carga de la red. Tradicionalmente la estimación se hacía sólo en base a las pérdidas de paquetes. Dos problemas conocidos de este mecanismo son la necesaria producci´on de pérdidas de paquetes para estimar la carga y la sincronización de flujos. En 1989 surge la idea de utilizar la demora ida y vuelta experimentada por los paquetes (RTT) para detectar la congestión anticipadamente. El emisor disminuye entonces su tasa de envío antes de que se produzca una pérdida, mejorando la eficiencia del protocolo y el throughput de la red (p. ej. TCP Vegas y FAST). Si bien medir el RTT es sencillo, el valor obtenido no basta para una correcta estimación de la carga, ya que se debe tener en cuenta, entre otros factores, la asimetría en los caminos de ida y de vuelta. Por eso se ha intentado estimar la carga en la red de manera más precisa a partir de la demora emisor-receptor (OWD: one way delay). Sin embargo, medir esta demora no es inmediato, ya que los relojes del emisor y del receptor deben estar sincronizados, para lo que se recurre a servidores NTP o uso de GPS. Esto es adecuado para algunas aplicaciones (p.ej.VoIP), pero no para el caso de flujos TCP, ya que por su número y ubicación pueden generar un overhead considerable (NTP) o no tener capacidad de GPS.Sociedad Argentina de Informática e Investigación Operativa (SADIO)2015-09info:eu-repo/semantics/conferenceObjectinfo:eu-repo/semantics/publishedVersionObjeto de conferenciahttp://purl.org/coar/resource_type/c_5794info:ar-repo/semantics/documentoDeConferenciaapplication/pdf1-3http://sedici.unlp.edu.ar/handle/10915/54843spainfo:eu-repo/semantics/altIdentifier/url/http://44jaiio.sadio.org.ar/sites/default/files/ietfday1-3.pdfinfo:eu-repo/semantics/altIdentifier/issn/2451-7623info:eu-repo/semantics/openAccesshttp://creativecommons.org/licenses/by-sa/3.0/Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)reponame:SEDICI (UNLP)instname:Universidad Nacional de La Platainstacron:UNLP2025-09-29T11:05:29Zoai:sedici.unlp.edu.ar:10915/54843Institucionalhttp://sedici.unlp.edu.ar/Universidad públicaNo correspondehttp://sedici.unlp.edu.ar/oai/snrdalira@sedici.unlp.edu.arArgentinaNo correspondeNo correspondeNo correspondeopendoar:13292025-09-29 11:05:29.665SEDICI (UNLP) - Universidad Nacional de La Platafalse
dc.title.none.fl_str_mv Demora en cola aplicada al control de congestión TCP
title Demora en cola aplicada al control de congestión TCP
spellingShingle Demora en cola aplicada al control de congestión TCP
Rigotti, Guillermo
Ciencias Informáticas
control de congestión
TCP
title_short Demora en cola aplicada al control de congestión TCP
title_full Demora en cola aplicada al control de congestión TCP
title_fullStr Demora en cola aplicada al control de congestión TCP
title_full_unstemmed Demora en cola aplicada al control de congestión TCP
title_sort Demora en cola aplicada al control de congestión TCP
dc.creator.none.fl_str_mv Rigotti, Guillermo
author Rigotti, Guillermo
author_facet Rigotti, Guillermo
author_role author
dc.subject.none.fl_str_mv Ciencias Informáticas
control de congestión
TCP
topic Ciencias Informáticas
control de congestión
TCP
dc.description.none.fl_txt_mv Los métodos de control de congestión utilizados por TCP se basan en modificar la tasa de envío en función de la carga de la red. Tradicionalmente la estimación se hacía sólo en base a las pérdidas de paquetes. Dos problemas conocidos de este mecanismo son la necesaria producci´on de pérdidas de paquetes para estimar la carga y la sincronización de flujos. En 1989 surge la idea de utilizar la demora ida y vuelta experimentada por los paquetes (RTT) para detectar la congestión anticipadamente. El emisor disminuye entonces su tasa de envío antes de que se produzca una pérdida, mejorando la eficiencia del protocolo y el throughput de la red (p. ej. TCP Vegas y FAST). Si bien medir el RTT es sencillo, el valor obtenido no basta para una correcta estimación de la carga, ya que se debe tener en cuenta, entre otros factores, la asimetría en los caminos de ida y de vuelta. Por eso se ha intentado estimar la carga en la red de manera más precisa a partir de la demora emisor-receptor (OWD: one way delay). Sin embargo, medir esta demora no es inmediato, ya que los relojes del emisor y del receptor deben estar sincronizados, para lo que se recurre a servidores NTP o uso de GPS. Esto es adecuado para algunas aplicaciones (p.ej.VoIP), pero no para el caso de flujos TCP, ya que por su número y ubicación pueden generar un overhead considerable (NTP) o no tener capacidad de GPS.
Sociedad Argentina de Informática e Investigación Operativa (SADIO)
description Los métodos de control de congestión utilizados por TCP se basan en modificar la tasa de envío en función de la carga de la red. Tradicionalmente la estimación se hacía sólo en base a las pérdidas de paquetes. Dos problemas conocidos de este mecanismo son la necesaria producci´on de pérdidas de paquetes para estimar la carga y la sincronización de flujos. En 1989 surge la idea de utilizar la demora ida y vuelta experimentada por los paquetes (RTT) para detectar la congestión anticipadamente. El emisor disminuye entonces su tasa de envío antes de que se produzca una pérdida, mejorando la eficiencia del protocolo y el throughput de la red (p. ej. TCP Vegas y FAST). Si bien medir el RTT es sencillo, el valor obtenido no basta para una correcta estimación de la carga, ya que se debe tener en cuenta, entre otros factores, la asimetría en los caminos de ida y de vuelta. Por eso se ha intentado estimar la carga en la red de manera más precisa a partir de la demora emisor-receptor (OWD: one way delay). Sin embargo, medir esta demora no es inmediato, ya que los relojes del emisor y del receptor deben estar sincronizados, para lo que se recurre a servidores NTP o uso de GPS. Esto es adecuado para algunas aplicaciones (p.ej.VoIP), pero no para el caso de flujos TCP, ya que por su número y ubicación pueden generar un overhead considerable (NTP) o no tener capacidad de GPS.
publishDate 2015
dc.date.none.fl_str_mv 2015-09
dc.type.none.fl_str_mv info:eu-repo/semantics/conferenceObject
info:eu-repo/semantics/publishedVersion
Objeto de conferencia
http://purl.org/coar/resource_type/c_5794
info:ar-repo/semantics/documentoDeConferencia
format conferenceObject
status_str publishedVersion
dc.identifier.none.fl_str_mv http://sedici.unlp.edu.ar/handle/10915/54843
url http://sedici.unlp.edu.ar/handle/10915/54843
dc.language.none.fl_str_mv spa
language spa
dc.relation.none.fl_str_mv info:eu-repo/semantics/altIdentifier/url/http://44jaiio.sadio.org.ar/sites/default/files/ietfday1-3.pdf
info:eu-repo/semantics/altIdentifier/issn/2451-7623
dc.rights.none.fl_str_mv info:eu-repo/semantics/openAccess
http://creativecommons.org/licenses/by-sa/3.0/
Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)
eu_rights_str_mv openAccess
rights_invalid_str_mv http://creativecommons.org/licenses/by-sa/3.0/
Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)
dc.format.none.fl_str_mv application/pdf
1-3
dc.source.none.fl_str_mv reponame:SEDICI (UNLP)
instname:Universidad Nacional de La Plata
instacron:UNLP
reponame_str SEDICI (UNLP)
collection SEDICI (UNLP)
instname_str Universidad Nacional de La Plata
instacron_str UNLP
institution UNLP
repository.name.fl_str_mv SEDICI (UNLP) - Universidad Nacional de La Plata
repository.mail.fl_str_mv alira@sedici.unlp.edu.ar
_version_ 1844615925365473280
score 13.069144

Publicaciones similares