Pregunta 47

Temas relacionados con el examen de test.
eszer
PreparaTIC XIX
Mensajes: 283
Registrado: 10 Dic 2006, 11:33
Ubicación: Madrid
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por eszer »

Las preguntas, se impugnan y se anulan. Nunca se cambia una respuesta, ni se tienen dos respuestas como válidas.

ebnz
Usuario registrado
Mensajes: 41
Registrado: 28 Mar 2009, 12:13
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por ebnz »

danii escribió: Creo que os habeis centrado mucho en SACK, que me parece un sistema muy bueno para controlar los errores de congestion. Pero no os habeis dado cuenta de que en ningun lado dice que distinga cuando se han perdido paquetes porque un router los ha descartado por congestion o cuando se han perdido porque han chocado contra una pared (p.e.).
SACK NO es un sistema para controlar errores de congestión.

En castellano: http://www.rfc-es.org/rfc/rfc2018-es.txt
1. Introducción

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.
danii escribió: Pero es que, explicitamente en la RFC 2018 dice:
5.1 Congestion Control Issues
Future research into congestion control algorithms may take advantage
of the additional information provided by SACK. One such area for
future research concerns modifications to TCP for a wireless or
satellite environment where packet loss is not necessarily an
indication of congestion.
Si dice "Investigacion futura" esta claro que todavia no se ha encontrado la solucion.
SACK pone la base y la implementacion para controlar la congestion, pero dice claramente que todavia no hay forma de saber si son errores de congestion o de perdidas en la transmision: "where packet loss is not necessarily an indication of congestion" . Y dice "necesariamente" porque podria ser que sí fuesen errores de congestion, pero no lo sabemos.
Dice "investigación futura" para que el mecanismo de control de congestión se aproveche de SACK, pero vuelvo a repetir, SACK no es para control de congestión sino para cuando se pierden datagramas.

Future research into congestion control algorithms may take advantage of the additional information provided by SACK


eszer escribió:Las preguntas, se impugnan y se anulan. Nunca se cambia una respuesta, ni se tienen dos respuestas como válidas.
¿por qué no se puede cambiar una respuesta si la publicada no es correcta? ¿existe alguna norma escrita al respecto?

saludos

Avatar de Usuario
peper_2009
PreparaTIC XX
Mensajes: 306
Registrado: 31 Mar 2009, 19:31
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por peper_2009 »

ebnz escribió: ¿por qué no se puede cambiar una respuesta si la publicada no es correcta? ¿existe alguna norma escrita al respecto?
saludos
Imagino que será para no hacer un bucle de impugnaciones. Alguien que la tuviera bien podría volverla a impugnar si se le cambia la respuesta y así hasta el infinito. Ahora, escrito escrito no se si está

danii
Usuario registrado
Mensajes: 74
Registrado: 13 Nov 2005, 23:38
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por danii »

Ebnz, lo que has dicho es correcto, pero no ha contestado a lo que yo te planteaba.

La clave es la palabra "Distingue".
SACK NO es un sistema para controlar errores de congestión.

En castellano: http://www.rfc-es.org/rfc/rfc2018-es.txt

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.
Muy bien, SACK no es para control de congestion. Es para retransmitir segmentos descartados.
Pero un segmento que choca con una pared (error de transmision), no es descartado por nadie, simplemente desaparece. Pero ese segmento se vuelve a retransmitir. Y esto es asi porque SACK no distingue entre errores de transmision y congestion de la red.
Dice "investigación futura" para que el mecanismo de control de congestión se aproveche de SACK
pero vuelvo a repetir, SACK no es para control de congestión sino para cuando se pierden datagramas.
Tu mismo lo estas diciendo: SACK no se centra en la congestion. Mira todas las perdidas de datos en general. Con lo cual no puede distinguir los errores de TX de la congestion.

Como dije antes, te estas centrando en lo bueno que es SACK porque retransmite todo muy bien. Y es cierto, pero la pregunta del test se centraba simplemente en darse cuenta de que los algoritmos de congestion/flujo/transmision "matan moscas a cañonazos". Les da igual porque se pierdan/descarten paquetes, ellos lo retransmiten sin saber el origen del problema.

ebnz
Usuario registrado
Mensajes: 41
Registrado: 28 Mar 2009, 12:13
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por ebnz »

danii escribió:Y es cierto, pero la pregunta del test se centraba simplemente en darse cuenta de que los algoritmos de congestion/flujo/transmision "matan moscas a cañonazos". Les da igual porque se pierdan/descarten paquetes, ellos lo retransmiten sin saber el origen del problema.
1-. congestión -> ICMP-Source Quench -> Disminución de tasa de envío -> disminución de la ventana
------------ pasado el time out -> reenvío de la ventana completa no reconocida

2-. pérdidas -> TCP-SACK -> reenvio de paquetes perdidos

saludos

danii
Usuario registrado
Mensajes: 74
Registrado: 13 Nov 2005, 23:38
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por danii »

Buenas,

estaba mirando todo el tema este centrandome en tu ultima respuesta para intentar discernir si realmente 1 y 2 son distintos o iguales, pero he encontrado algo que me ha dejado un poco frio.

En la rfc 2026: "The Internet Standards Process " he encontrado esto:
4.1.1 Proposed Standard

The entry-level maturity for the standards track is "Proposed
Standard". A specific action by the IESG is required to move a
specification onto the standards track at the "Proposed Standard"
level.

A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.

Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed Standard
designation.

The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet.

A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it. However, the IESG may
waive this requirement in order to allow a specification to advance
to the Proposed Standard state when it is considered to be useful and
necessary (and timely) even with known technical omissions.

Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive
environment is not recommended.
Y la RFC que habla de SACK es de este tipo.
Entonces la verdad, yo ya no se si realmente un "proposed standard" se puede usar como base de estudio o no. ¿¿Como lo veis?? ¿sabeis si esto se usa en la actualidad o es solo una propuesta teorica sin validar por el IETF?

ReBelaBk
Usuario registrado
Mensajes: 36
Registrado: 09 Jun 2008, 12:58
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por ReBelaBk »

danii escribió:Entonces la verdad, yo ya no se si realmente un "proposed standard" se puede usar como base de estudio o no. ¿¿Como lo veis?? ¿sabeis si esto se usa en la actualidad o es solo una propuesta teorica sin validar por el IETF?
Yo he hecho capturas de tráfico en comunicaciones reales en las que SACK se utiliza.

Lo que sigo sin ver es que dicho mecanismo tenga que ver con procesar de manera distinta tramas perdidas por congestión o por errores. SACK optimiza el uso del canal cuando la pérdida es principalmente por ráfagas de errores, porque en este caso se puede suponer que sólo se pierde una trama (o unas pocas) tramas de vez en cuando; mientras que con congestión, es más probable que se pierdan bloques consecutivos de tramas, con lo que SACK dará poca ganancia en comparación con el mecanismo básico de confirmación. En otras palabras, SACK es una mejora del mecanismo de confirmación, no tiene nada que ver con cambiar el comportamiento de TCP en función de que las tramas se hayan perdido por errores o por congestión. Lógicamente, es de suponer que la ralentización en el envío de tramas estará convenientemente adaptado para el caso en el que se usa SACK (quiero decir, tal vez la decisión "ojo, canal congestionado" sea algo más compleja de tomar).

En definitiva, TCP se comporta de manera distinta según se haya negociado el uso de SACK o no en el momento del establecimiento de la conexión, de acuerdo. Pero si se ha negociado usar SACK en una conexión y tenemos que x% de tramas se pierden por errores y z% de tramas se pierden por congestión, TCP actúa exactamente igual en uno u otro caso (hasta donde yo sé). Es decir, si mi ordenador ha estimado que el canal, más que congestionado, es ruidosillo, a lo mejor decide utilizar SACK; y si durante la descarga de un ISO de 650 MB resulta que a ratos hay un nodo intermedio congestionado que descarta bloques de tramas, pues mala suerte: seguirá aplicando SACK de todas formas.

(Por cierto, desconozco de qué manera la pila TCP/IP decide utilizar SACK o no; no sé si es por configuración, si lo hace inteligentemente, por defecto o qué).

danii
Usuario registrado
Mensajes: 74
Registrado: 13 Nov 2005, 23:38
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por danii »

Ok. Lo que dices de SACK, pues totalmente de acuerdo.

Al respecto de los estandares del IETF, por lo que dices parece que son bastante cautos en cuanto a pasar a estandar algo hasta que no ha sido probado hasta la saciedad.

Pero bueno, entonces consideramos las "proposed standards" y demas como validos.
Mañana pongo lo que pienso del tema que ahora tengo lio domestico. :)

Chao.

Avatar de Usuario
Julio
PreparaTIC XVIII
Mensajes: 381
Registrado: 28 May 2007, 12:42
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por Julio »

peper_2009 escribió:
ebnz escribió: ¿por qué no se puede cambiar una respuesta si la publicada no es correcta? ¿existe alguna norma escrita al respecto?
saludos
Imagino que será para no hacer un bucle de impugnaciones. Alguien que la tuviera bien podría volverla a impugnar si se le cambia la respuesta y así hasta el infinito. Ahora, escrito escrito no se si está
En A1 no lo sé, en A2 me consta que el año pasado cambiaron la respuesta a una pregunta (la primera de reserva del Bloque III), por lo que dudo mucho que haya normas escritas en contra.

danii
Usuario registrado
Mensajes: 74
Registrado: 13 Nov 2005, 23:38
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por danii »

- Source Quench: esto es algo que desde que lo comento ebnz me ha chocado bastante.
Segun el "end to end principle" de OSI, las comunicaciones e interacciones es mejor hacerlas entre capas "en horizontal" que entre una capa y la superior o inferior. El hecho de que icmp pase datos a la capa tcp siempre me ha parecido raro.
La solucion es que realmente es raro porque es una excepcion, y como tal al final ha terminado por desaparecer.

En un foro del IETF se habla de que este tipo de mensaje de icmp ha cambiado su condicion respecto a su uso por los routers. En un principio se podia usar, pero en la ultima actualizacion se recomienda que los routers no lo utilicen.
Espero que con esto quede claro que los mensajes "Source Quench" de ICMP ya no los utilizan los routers.
http://www.ietf.org/mail-archive/web/tr ... 00044.html

ICMP Source Quench
------------------
RFC 792 describes the Internet Control Management Protocol (ICMP). ICMP includes a message type called "Source Quench" (Type 4). Source Quench was intended to provide "back pressure" when a gateway discards an incoming IP datagram because no buffers are available. The message is sent to the Source IP Address carried in the discarded IP datagram. Conceptually, a host receiving an ICMP Source Quench message would slow down its sending rate until it stopped receiving ICMP Source Quench messages, and then gradually increase its sending rate.

The original specification did not provide quantitative guidance on HOW MUCH to slow down. RFC 1016 proposed a formula Source Quench Induced Delay ("SQuID"), but this RFC was published six years after RFC 792, and defined itself as a "crazy idea". A better characterization might have been "embryonic", reflecting an unsophisticated awareness of congestion - TCP didn't include Slow Start/Congestion Avoidance until a couple of years later.

The original specification allowed gateways to generate an ICMP Source Quench for every datagram dropped, but did not require gateways to send them at all. RFC 1009 ("Requirements for Internet Gateways") required gateways to include the capability to send rate-limited ICMP Source Quench messages, but when it was updated as RFC 1812 ("Requirements for IP Version 4 Routers"), this requirement was dropped in favor of deprecating ICMP Source Quench ("Gateways SHOULD NOT"). The reasons given for this about-face included:

- ICMP Source Quench affected only packets sent from the host generating the "over the top" packet, so did not provide a fair mechanism for hosts sharing overcommitted network paths, and

- ICMP Source Quench added (reverse-direction) packets to the network during congestion events, and used router memory and processing power to construct and send ICMP Source Quenches during congestion events.

The overwhelming problem with ICMP Source Quench wasn't that it required gateways to send a "trigger" to hosts - it had problems with unfairness and inefficiency. Since the specifications omitted critical details and didn't require this functionality, hosts were forced to add end-to-end congestion avoidance at the transport layer, anyway.

This experience isn't terrically relevant to TRIGTRAN, because recommendations have shifted from MAY to SHOULD NOT - hardly an overwhelming push to deployment!
------------------------------------ rfc 1812

4.3.3.3 Source Quench

A router SHOULD NOT originate ICMP Source Quench messages. As
specified in Section [4.3.2], a router that does originate Source
Quench messages MUST be able to limit the rate at which they are
generated.

DISCUSSION
Research seems to suggest that Source Quench consumes network
bandwidth but is an ineffective (and unfair) antidote to
congestion. See, for example, [INTERNET:9] and [INTERNET:10].
Section [5.3.6] discusses the current thinking on how routers
ought to deal with overload and network congestion.

A router MAY ignore any ICMP Source Quench messages it receives.

DISCUSSION
A router itself may receive a Source Quench as the result of
originating a packet sent to another router or host. Such
datagrams might be, e.g., an EGP update sent to another router, or
a telnet stream sent to a host. A mechanism has been proposed
([INTERNET:11], [INTERNET:12]) to make the IP layer respond
directly to Source Quench by controlling the rate at which packets
are sent, however, this proposal is currently experimental and not
currently recommended.

-----------
As described in Section [4.3.3.3], this document recommends that a
router SHOULD NOT send a Source Quench to the sender of the packet
that it is discarding. ICMP Source Quench is a very weak mechanism,
so it is not necessary for a router to send it, and host software
should not use it exclusively as an indicator of congestion.
Ahora tenemos SACK.
Sack es un nuevo sistema que mejora los anteriores ack y nack. Pero no es mas que un sistema para que el emisor retransmita lo que no le ha llegado al receptor.
Despues de leerme la rfc de sack y todo lo relacionado con este, no terminaba de entender por que EBNZ no veia algo que yo veia muy claramente.
La solucion la vi cuando me di cuenta que no era un tema de conceptos, sino de gramatica: a lo que se referia EBNZ era a la introduccion de la RFC, donde dice "han sido perdidos" o algo asi. Y él entendia que perdidos es porque ha habido errores de transmision (si no, deberia decir "descartados").
El caso es que esta frase no es muy afortunada o quizas la traduccion al español es confusa. Es decir, para que hubiese quedado claro, deberia decir "have been dropped", aunque realmente si dice "have been lost" quizas tambien se refiera a descartados, porque si no diria "are lost" o "were lost". Es decir, si "han sido perdidos" es por alguien, un router en este caso.

El caso es que incluso olvidandonos del tema gramatical, en esa exacta frase de la introduccion de la RFC de SACK es el unico sitio donde dice "perdidos". En el resto habla de descartados, o claramente cuando dice perdidos esta claro que se refiere al termino general, englobando perdidas por congestion o por transmision.

- Como apoyo a esto, podemos encontrar algun otro texto que apoya mi idea:
--------------------- rfc 3155

3.0 Summary of Recommendations

The Internet does not provide a widely-available loss feedback
mechanism that allows TCP to distinguish between congestion loss and
transmission error. Because congestion affects all traffic on a path
while transmission loss affects only the specific traffic
encountering uncorrected errors, avoiding congestion has to take
precedence over quickly repairing transmission errors. This means
that the best that can be achieved without new feedback mechanisms is
minimizing the amount of time that is spent unnecessarily in
congestion avoidance.

The Fast Retransmit/Fast Recovery mechanism allows quick repair of
loss without giving up the safety of congestion avoidance. In order
for Fast Retransmit/Fast Recovery to work, the window size must be
large enough to force the receiver to send three duplicate
acknowledgments before the retransmission timeout interval expires,
forcing full TCP slow-start.

Selective Acknowledgements (SACK) extend the benefit of Fast
Retransmit/Fast Recovery to situations where multiple segment losses
in the window need to be repaired more quickly than can be
accomplished by executing Fast Retransmit for each segment loss, only
to discover the next segment loss.

These mechanisms are not limited to wireless environments. They are
usable in all environments.
---------------------- http://www.icir.org/floyd/papers/report_Jan01.pdf

2.3 Implications for Corruption Notification
One of the fundamental components of TCP congestion control
is that packet losses are used as indications of congestion.
TCP halves its congestion window after any window of
data in which one or more packets have been lost. With the
addition of ECN to the IP architecture, routers would also be
able to set a bit in the ECN field of the IP header as an indication
of congestion. However, the addition of ECN to the IP
architecture would not eliminate congestion-related packet
losses due to buffer overflow, and therefore would not allow
end nodes to ignore packet losses as indications of congestion.
For wired links, packet losses due to packet corruption
instead of congestion are infrequent, at least in terms of their
effect of congestion control [14]; this is not always the case
for wireless links [6]. While many wireless links use Forward
Error Correction (FEC) and link-level retransmission
to repair packet corruption, it is not always possible to eliminate
all packet corruption in a timely fashion.
One possible response to packet corruption would be for
the TCP sender to “undo” the congestion window reduction
if the TCP sender found out, after the fact, that a single
packet loss had been due to corruption rather than congestion.
This late “undoing” of a congestion window reduction
could use a delayed notification of packet corruption, where
the TCP sender receives the notification of corruption some
time after it has already retransmitted the packet and halved
the congestion window.
Such a mechanism for the late “undoing” of a congestion
window reduction would allow a link-level protocol to
develop a method for the delayed sending of a corruption
4
notification message to the TCP data receiver. That is, the
link-level protocol could determine when the link level is no
longer attempting to retransmit a packet has been lost at the
link level due to corruption. In this case, the link-level protocol
could arrange that the link-level sender send a corruption
notification message to the IP destination of the corrupted
packet. Of course, this short corruption notification message
could itself be corrupted or lost, in which case the transport
end nodes would be left to their earlier inference that the
packet had been lost due to congestion.
With this form of Congestion Notification, a TCP sender
that has halved its congestion window as a result of a single
packet loss could receive information from the link level,
some time later, that this packet was lost due to corruption
rather than due to congestion. If such mechanisms for corruption
notification are developed, a necessary next step will
be to determine the appropriate response of the end nodes to
this corruption. For packet corruption that is not an indication
of congestion from competing traffic, halving the congestion
window in response to a single corrupted packet is
clearly unnecessarily severe. At the same time, maintaining
a persistent high sending rate in the presence of a high packet
corruption rate is also clearly unacceptable; each corrupted
packet could represent wasted bandwidth on the path to the
point of corruption.
The development of corruption notification will also require
the development of accompanying mechanisms for protection
against misbehaving routers or receivers, so that receivers
cannot mislead the sender into treating a congestionrelated
packet loss as a corruption-related loss.
Y bueno, hay muchos mas textos por ahi pero creo que con esto es suficiente para que quede claro que la respuesta correcta es la ultima.

Chao.

Cerrado

Volver a “PRIMER EXAMEN 2009”