Pregunta 47

ebnz · Mensaje por **ebnz** » 22 Jul 2009, 16:57

danii escribió:
En las wireless hay muchos errores de transmision comparado con las wired. Esto no lo maneja bien TCP porque esta pensado para entornos de baja tasa de errores y entornos de alta congestion. Por lo que cuando se pierden paquetes tiende a "pensar" que son problemas de congestion.

Precisamente por eso TCP ha evolucionado, y si tienes un sistema que debe comunicarse mediante redes no cableadas, debes habilitar las opciones que te 'mejoran' el rendimiento.

RFC 2018 - SACK escribió: La pérdida de múltiples paquetes de una ventana de datos puede tener
efectos catastróficos en el rendimiento del protocolo TCP. TCP [12]
emplea un esquema de notificación de recepción en el cual, los
segmentos recibidos que no están en el borde izquierdo de la ventana
a la que pertenecen, no se notifican. Esto fuerza al remitente que o
bien espere que se agote el tiempo de espera de la notificación para
detectar los paquetes perdidos, o reenvíe segmentos que han sido
correctamente recibidos [3]. Con el esquema de la notificación de
recepción acumulativa, los múltiples segmentos descartados causan,
generalmente, que el protocolo TCP pierda su reloj basado en las
notificaciones (ACK), reduciendo el rendimiento global.

La notificación de recepción selectiva (SACK) es una estrategia que
corrige este comportamiento en el escenario de múltiples segmentos
descartados. Con la notificación de recepción selectiva, el receptor
de los datos puede informar al remitente de todos los segmentos que
han llegado correctamente, por lo que el remitente solo tiene que
retransmitir los segmentos que han sido perdidos.

RFC 1106 - NAK escribió: Abstract

Two extensions to the TCP protocol are described in this RFC in order
to provide a more efficient operation over a network with a high
bandwidth*delay product. The main issue that still needs to be
solved is congestion versus noise. This issue is touched on in this
memo, but further research is still needed on the applicability of
the extensions in the Internet as a whole infrastructure and not just
high bandwidth*delay product networks. Even with this outstanding
issue, this document does describe the use of these options in the
isolated satellite network environment to help facilitate more
efficient use of this special medium to help off load bulk data
transfers from links needed for interactive use

¿TCP distingue entre pérdidas por errores de transmisión y pérdidas por congestión, aplicando procedimientos de recuperación diferentes?

Definitivamente SI

Un saludo

ReBelaBk · Mensaje por **ReBelaBk** » 22 Jul 2009, 18:36

ebnz escribió:
danii escribió:
En las wireless hay muchos errores de transmision comparado con las wired. Esto no lo maneja bien TCP porque esta pensado para entornos de baja tasa de errores y entornos de alta congestion. Por lo que cuando se pierden paquetes tiende a "pensar" que son problemas de congestion.
Precisamente por eso TCP ha evolucionado, y si tienes un sistema que debe comunicarse mediante redes no cableadas, debes habilitar las opciones que te 'mejoran' el rendimiento.

RFC 2018 - SACK escribió: La pérdida de múltiples paquetes de una ventana de datos puede tener
efectos catastróficos en el rendimiento del protocolo TCP. TCP [12]
emplea un esquema de notificación de recepción en el cual, los
segmentos recibidos que no están en el borde izquierdo de la ventana
a la que pertenecen, no se notifican. Esto fuerza al remitente que o
bien espere que se agote el tiempo de espera de la notificación para
detectar los paquetes perdidos, o reenvíe segmentos que han sido
correctamente recibidos [3]. Con el esquema de la notificación de
recepción acumulativa, los múltiples segmentos descartados causan,
generalmente, que el protocolo TCP pierda su reloj basado en las
notificaciones (ACK), reduciendo el rendimiento global.

La notificación de recepción selectiva (SACK) es una estrategia que
corrige este comportamiento en el escenario de múltiples segmentos
descartados. Con la notificación de recepción selectiva, el receptor
de los datos puede informar al remitente de todos los segmentos que
han llegado correctamente, por lo que el remitente solo tiene que
retransmitir los segmentos que han sido perdidos.

RFC 1106 - NAK escribió: Abstract

Two extensions to the TCP protocol are described in this RFC in order
to provide a more efficient operation over a network with a high
bandwidth*delay product. The main issue that still needs to be
solved is congestion versus noise. This issue is touched on in this
memo, but further research is still needed on the applicability of
the extensions in the Internet as a whole infrastructure and not just
high bandwidth*delay product networks. Even with this outstanding
issue, this document does describe the use of these options in the
isolated satellite network environment to help facilitate more
efficient use of this special medium to help off load bulk data
transfers from links needed for interactive use
¿TCP distingue entre pérdidas por errores de transmisión y pérdidas por congestión, aplicando procedimientos de recuperación diferentes?

Definitivamente SI

Un saludo

Si aludes a la RFC 1106 en la argumentación de la impugnación, ten en cuenta que, además de su abstract, se leerán (porque viene antes) el Status of this Memo

This memo discusses two extensions to the TCP protocol to provide a
more efficient operation over a network with a high bandwidth*delay
product. The extensions described in this document have been
implemented and shown to work using resources at NASA. This memo
describes an Experimental Protocol, these extensions are not proposed
as an Internet standard, but as a starting point for further
research.

Por otro lado, las soluciones que sugiere la 1106, si la he entendido bien, van enfocadas a optimizar TCP en enlaces con mucho retardo. Alude al tema de la diferenciación entre congestión y ruido para decir que es una cuestión que aún se tiene que investigar, no que se le esté dando una solución en dicha RFC.

Vamos, que yo la 1106 no la mentaría (me da que es más bien contraproducente).

ReBelaBk · Mensaje por **ReBelaBk** » 22 Jul 2009, 18:36

(Lo siento. Se duplicó el mensaje anterior)

ebnz · Mensaje por **ebnz** » 22 Jul 2009, 18:59

ReBelaBk, tienes razon respecto a la 1106, debido a que está más bien orientada a transmisión satélite

Pero la 2018 sirve precisamente para diferenciar los errores de congestión de las pérdidas en redes no cableadas

http://www.iana.org/assignments/tcp-parameters/
http://www.speedguide.net/read_articles.php?id=2009

saludos

ReBelaBk · Mensaje por **ReBelaBk** » 22 Jul 2009, 19:11

ebnz escribió:ReBelaBk, tienes razon respecto a la 1106, debido a que está más bien orientada a transmisión satélite

Pero la 2018 sirve precisamente para diferenciar los errores de congestión de las pérdidas en redes no cableadas

http://www.iana.org/assignments/tcp-parameters/
http://www.speedguide.net/read_articles.php?id=2009

saludos

Hasta donde yo sé, el mecanismo de SACK (ACK selectivo) optimiza el proceso de confirmación, permitiendo que el receptor pueda confirmar segmentos no secuencialmente. De esta manera, el emisor puede retransmitir sólo las tramas que se han perdido. Pero SACK no permite diferenciar si las tramas que no han sido confirmadas no lo han sido por llegar con errores o por no llegar.

No sé si voy a decir una burrada, pero es que, además, diferenciar esas dos situaciones no siempre es posible. Imaginemos una trama que llega con errores en la cabecera. ¿A quién tendría que mandar una notificación de tal cosa el receptor, si es posible que la IP origen sea la dañada? Una trama así lo más probable es que sea simplemente descartada por el receptor. Bien, ¿en qué se diferencia tal descarte del descarte que haga un nodo intermedio por estar congestionado?

ebnz · Mensaje por **ebnz** » 22 Jul 2009, 19:36

ReBelaBk escribió: No sé si voy a decir una burrada, pero es que, además, diferenciar esas dos situaciones no siempre es posible. Imaginemos una trama que llega con errores en la cabecera. ¿A quién tendría que mandar una notificación de tal cosa el receptor, si es posible que la IP origen sea la dañada? Una trama así lo más probable es que sea simplemente descartada por el receptor. Bien, ¿en qué se diferencia tal descarte del descarte que haga un nodo intermedio por estar congestionado?

Si la cabera IP está dañada, la trama no llega a tcp , se descarta en IP. La trama está perdida.

Un router avisa al emisor que reduzca la tasa de transmisión debido a congestión mediante ICMP (source quench)

saludos

ebnz · Mensaje por **ebnz** » 22 Jul 2009, 19:37

-- repe al intentar editar --

ReBelaBk · Mensaje por **ReBelaBk** » 22 Jul 2009, 22:40

En http://www.tcpipguide.com/free/t_TCPCon ... lgorit.htm creo que se puede encontrar la explicación de la respuesta a esta pregunta.

El párrafo clave es el que dice

The first issue is that we need to know when congestion is taking place. By definition, congestion means intermediate devices—routers—are overloaded. Routers respond to overloading by dropping datagrams. When these datagrams contain TCP segments, the segments don't reach their destination, and they are therefore left unacknowledged and will eventually expire and be retransmitted. This means that when a device sends TCP segments and does not receive acknowledgments for them, it can be assumed that in most cases, they have been dropped by intermediate devices due to congestion. By detecting the rate at which segments are sent and not acknowledged, a TCP device can infer the level of congestion on the network between itself and its TCP connection peer.

No lo puedo afirmar tajantemente, pero entre los mecanismos de control de congestión o tratamiento de errores contemplados por TCP no creo que esté ningún mecanismo de comunicación con el nivel IP. Es decir, la capa IP podrá recibir los mensajes ICMP que sea y actuar en consecuencia, pero no está contemplado que los pase, a su vez, (tal cual o mediante otras notificaciones) al nivel TCP.

danii · Mensaje por **danii** » 23 Jul 2009, 08:35

Muy interesante.
Le voy a dar una pensanda y esta noche intento decir algo con sentido, que ahora voy con prisa.
Chao.

jfuentes · Mensaje por **jfuentes** » 23 Jul 2009, 10:09

Buenas,

Yo no quiero decir que la respuesta d no sea correcta, sino que no es menos correcta la a. Cada implementación de TCP es diferente y no se puede afirmar categóricamente que se disminuye la tasa de envío porque se interpreta congestión en la red. Existen diferentes enfoques para la utilización de TCP sobre redes inalámbricas, como se ve en http://www.gcr.tsc.upc.edu/publications ... ciones.pdf

Es decir, no siempre se van a interpretar las pérdidas como congestión en la red, ni siempre el emisor va a utilizar SACK y va a poder distinguir entre los dos tipos de errores.

Podríamos redactar entre todos los que vamos a impugnarla un "escrito plantilla" y que cada uno le dé luego su toque personal. ¿Os parece bien?

ebnz · Mensaje por **ebnz** » 23 Jul 2009, 17:22

ReBelaBk escribió: No lo puedo afirmar tajantemente, pero entre los mecanismos de control de congestión o tratamiento de errores contemplados por TCP no creo que esté ningún mecanismo de comunicación con el nivel IP. Es decir, la capa IP podrá recibir los mensajes ICMP que sea y actuar en consecuencia, pero no está contemplado que los pase, a su vez, (tal cual o mediante otras notificaciones) al nivel TCP.

RFC 1122 - Requirements for Internet Hosts -- Communication Layers escribió: 3.2.2.3 Source Quench:
A host MAY send a Source Quench message if it is approaching, or has reached, the point at which it is forced to discard incoming datagrams due to a shortage of reassembly buffers or other resources. See Section 2.2.3 of [INTRO:2] for suggestions on when to send Source Quench.

If a Source Quench message is received, the IP layer MUST report it to the transport layer (or ICMP processing). In general, the transport or application layer SHOULD implement a mechanism to respond to Source Quench for any protocol that can send a sequence of datagrams to the same destination and which can reasonably be expected to maintain enough state information to make this feasible. See 4 for the handling of Source Quench by TCP and UDP.

.
.
.
[...]
.
.
.

4.2.3.9 ICMP Messages

TCP MUST act on an ICMP error message passed up from the IP layer, directing it to the connection that created the error. The necessary demultiplexing information can be found in the IP header contained within the ICMP message.

o Source Quench

TCP MUST react to a Source Quench by slowing transmission on the connection. The RECOMMENDED procedure is for a Source Quench to trigger a "slow start," as if a retransmission timeout had occurred.

parece ser que si.

saludos

ebnz · Mensaje por **ebnz** » 23 Jul 2009, 19:12

jfuentes, ¿que te parece este texto para la impungación?

- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -

**IDENTIFICACIÓN**

EXPONE:
que en relación con la pregunta número 47 del Primer Ejercicio de las XVIII Pruebas selectivas para el ingreso en el Cuerpo Superior de Sistemas y Tecnologías de la Información de la Administración del Estado, celebradas el pasado 18 de Julio, ruega se tengan por presentadas y se tomen en consideración las siguientes

ALEGACIONES:

1º.- que en dicha pregunta número 47 se pedía indicar la afirmación cierta
2º.- que la opción A “[El emisor TCP] Distingue entre pérdidas por errores de transmisión y pérdidas por congestión, aplicando procedimientos de recuperación diferentes” es una afirmación totalmente cierta.
3º.- que en la plantilla de corrección facilitada en la sede electrónica del INAP se indica que la respuesta con afirmación cierta sería la opción D ”[El emisor TCP] Interpreta las pérdidas debidas a errores de transmisión como congestión en la red, disminuyendo su tasa de envío.”
4º- que existe una opción TCP, RFC 2018 (TCP Selective Acknowledgment Options - SACK), opciones de cabecera 4 y 5, diseñadas para salvar la condición de “pérdidas frecuentes por errores de transmisión debidos a las características del acceso radio”.
5º- que la opción SACK previamente mencionada consiste en que el receptor pueda informar al emisor de los datos que han sido recibidos de modo que el emisor retransmita únicamente los segmentos de datos perdidos, y por lo tanto la afirmación de la opción D no es cierta
6º- que también son erróneas, o no del todo ciertas, las afirmaciones de las opciones B y C

SOLICITA:

que se considere que hay un error en la plantilla de solución de la pregunta 47 y sea considerada como correctamente respondida la opción A “[El emisor TCP] Distingue entre pérdidas por errores de transmisión y pérdidas por congestión, aplicando procedimientos de recuperación”.

**FECHA Y FIRMA**

A la atención de la Ilma. Sra. Presidenta del Tribunal de las XVIII Pruebas selectivas para el ingreso en el Cuerpo Superior de Sistemas y Tecnologías de la Información de la Administración del Estado.

- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -

saludos

jfuentes · Mensaje por **jfuentes** » 23 Jul 2009, 19:36

Creo que habría que añadir por algún sitio que al tratarse de una red móvil celular como se indicaba en el enunciado de la pregunta, es habitual el uso de la opción SACK, y no me gusta mucho lo de decirles que la afirmación de la opción D es errónea así de tajantes, sino recalcar el hecho de que la red es móvil y es sabido el hecho de las pérdidas frecuentes, por lo que no se encuentran redes móviles que no usen la opción SACK.

¿Qué te parece esta modificación sobre lo tuyo? (solo tocaría los puntos 5 y 6, el resto me parece perfecto, pero no presento nada hasta que estemos de acuerdo):

5º- que la opción SACK previamente mencionada consiste en que el receptor pueda informar al emisor de los datos que han sido recibidos de modo que el emisor retransmita únicamente los segmentos de datos perdidos, y por lo tanto en este caso (el habitual en las redes móviles celulares por el conocimiento previo que se tiene del comportamiento del medio de transmisión utilizado) la afirmación de la opción D no es cierta
6º- que también son erróneas, o no del todo ciertas, las afirmaciones de las opciones B y C como bien indica la plantilla

jfuentes · Mensaje por **jfuentes** » 23 Jul 2009, 19:42

Perdón, duplicado

ebnz · Mensaje por **ebnz** » 23 Jul 2009, 20:01

sobre la modificación de la alegación 6º parece peloteo

Con relación a la alegación 5º

5º- que la opción SACK previamente mencionada consiste en que el receptor pueda informar al emisor de los datos que han sido recibidos de modo que el emisor retransmita únicamente los segmentos de datos perdidos, y por lo tanto, en el caso mencionado en el enunciado de la pregunta (red móvil celular que sufre pérdidas frecuentes por errores de transmisión) la afirmación de la opción D no es cierta

¿que tal?

un saludo