Pregunta 47

Temas relacionados con el examen de test.
Avatar de Usuario
jfuentes
Usuario registrado
Mensajes: 453
Registrado: 30 May 2009, 17:34
Agradecido: 0
Agradecimiento recibido: 0

Mensaje por jfuentes »

ebnz escribió:sobre la modificación de la alegación 6º parece peloteo :mrgreen:

Es que ES peloteo :lol: Más que nada porque estarán hartos de que les lleven la contraria, jeje
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


Esta modificación me gusta bastante.

Bueno, solo queda enviarlo. Voy a madurarlo esta tarde, lo consulto con la almohada esta noche y a ver si mañana lo envío y nos quitamos esto de encima cuanto antes.

Saludos desde debajo de un flexo! (manda narices, a mediados de verano y que lo más parecido al sol que veo sea la bombilla E27 ...)

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

Mensaje por ebnz »

Yo en vista que parece que no existe un registro electrónico, creo que me acercaré a María de Molina a presentarlo mañana o la próxima semana, porque no tengo muy claro que valga mandarlo por correo electrónico.
jfuentes escribió:Saludos desde debajo de un flexo! (manda narices, a mediados de verano y que lo más parecido al sol que veo sea la bombilla E27 ...)
ánimo

un saludo

atm
Usuario registrado
Mensajes: 27
Registrado: 03 Jun 2008, 13:57
Agradecido: 0
Agradecimiento recibido: 0

Mensaje por atm »

Te entiendo danii.
La has acertado y no quieres que la impugnemos, pero no sabes explicar porqué no es impugnable y encima nos acusas de haberla fallado por no estudiar lo suficiente. ;-)

Avatar de Usuario
jfuentes
Usuario registrado
Mensajes: 453
Registrado: 30 May 2009, 17:34
Agradecido: 0
Agradecimiento recibido: 0

Mensaje por jfuentes »

Hola atm,
Al final ¿tú también la impugnarás?

Avatar de Usuario
capelo8
PreparaTIC25
Mensajes: 19
Registrado: 18 Ene 2005, 15:59
Agradecido: 0
Agradecimiento recibido: 0

Mensaje por capelo8 »

Te entiendo danii.
La has acertado y no quieres que la impugnemos, pero no sabes explicar porqué no es impugnable y encima nos acusas de haberla fallado por no estudiar lo suficiente.
Como se está poniendo el tema... Entiendo que esto no pasa de ser un comentario irónico y dentro del buen rollo, pero los espectadores morbosos estamos deseosos de que danii publique una respuesta!!! :twisted: :twisted:

Avatar de Usuario
jfuentes
Usuario registrado
Mensajes: 453
Registrado: 30 May 2009, 17:34
Agradecido: 0
Agradecimiento recibido: 0

Mensaje por jfuentes »

ebnz, te puedes ahorrar la visita a María de Molina. Les he escrito a la dirección de correo que tienen en la página y me han contestado lo siguiente:
Buenos días:


Para presentar alegaciones basta con un fax o correo electrónico en el que se indique claramente lo que se desea comentar acerca de la o las preguntas que considera incorrectas, especificando los motivos y aportando la mayor información posible que justifique dichos motivos. No se necesita un formato particular.


Por otro lado, no es posible consultar las solicitudes de impugnación. Puede usted realizar todas las que estime convenientes; si se enviaron dentro del plazo serán tenidas en cuenta.


Un saludo.

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

Mensaje por ReBelaBk »

ebnz escribió:
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
Se aprende casi más después del examen que antes :) .

No sabía que TCP recibía notificación de ICMP. No obstante, ten en cuenta lo que he marcado en negrita: vale, recibe el Source Quench, pero reacciona como si hubiera expirado un tiempo de espera para la retransmisión (vamos, como si la trama se hubiera descartado por tener errores).

No puedo desearte suerte con la reclamación porque eso puede ser mi desgracia, pero te agradezco tu argumentación.

Un saludo.

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

Mensaje por ebnz »

ReBelaBk, ese el objetivo del examen: hacer la alegaciones para aprender para el próximo año :mrgreen:


Como bien dices y remarcas, al recibir un source quench TCP se comporta como un fin del timeout ... pero te recuerdo que el source quench se envía cuando un gateway intermedio (o el host destino) no puede procesar todos los datagramas que le llegan: congestión -> comportamiento 1

jfuentes y yo mismo alegamos que cuando se pierden paquetes, en TCP existe un mecanismo (SACK) que permite reenviar sólo los perdidos: comportamiento 2

Y por lo tanto SOLICITO, que sea tenida en cuenta como válida la respuesta A de la pregunta 47 ...


gracias por la info jfuentes (aunque no me fio ... habrá que estudiar los temas 7 y 8 para corroborarlo :mrgreen: )

saludos

Avatar de Usuario
jfuentes
Usuario registrado
Mensajes: 453
Registrado: 30 May 2009, 17:34
Agradecido: 0
Agradecimiento recibido: 0

Mensaje por jfuentes »

ebnz escribió: gracias por la info jfuentes (aunque no me fio ... habrá que estudiar los temas 7 y 8 para corroborarlo :mrgreen: )


:lol: todo esto de los procedimientos administrativos es infumable a más no poder. Me ha extrañado mucho que no me dijeran que tenía que rellenar el formulario A43, llevarlo a la tercera planta, y preguntar por el formulario A62BIS que se modificó en el Real Decreto 456/2009 :shock:

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

Re: Pregunta 47

Mensaje por danii »

Chicos no me estreseis que estoy de fin de semana, por eso no he contestado.

De verdad que si quereis impugnarla, adelante. Yo he suspendido y de largo así que me da igual.

De todas formas, yo sigo pensando que la mia es correcta. Otra cosa es que vosotros impugneis porque hay otra que tambien es cierta. Pero eso yo nunca lo he negado, yo solo hablaba de que la mia es correcta.

Entiendo que los que impugnais estais en el filo de la navaja y eso crea tensiones que yo no tengo. Así que os perdono. :mrgreen: :mrgreen:

De todas formas el lunes me empollo los links que habeis puesto y comento algo.

Chao.

arf
PreparaTIC XIX
Mensajes: 6
Registrado: 26 May 2008, 12:33
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por arf »

Hola,

La verdad q me he perdido con tanto mensaje y reconozco q no me lo he leido en detalle.

He de confesar q yo conteste la d sin tenerlo del todo claro. Os cuento mi razonamiento:
En una red de telefonia movil de paquetes, al menos como yo lo entiendo, TCP solo lo implementa el emisor (q sera un servidor fuera de la red) y el usuario movil. En el resto del camino el paquete TCP q ha enviado el servidor esta encapsulado para poderse enviar por las pilas propias de los distintos interfaces por los que circulan los datos. Asi q la unica confirmacion (ACK) q le llega al servidor es la q le envia el usuario movil. Por tanto, el servidor no tiene forma de saber si el paquete se ha perdido en el camino GGSN-SGSN-RNC porq se lo ha tragado algun equipo o porque en algun cable hay congestion, o si se ha perdido en el enlace radio. Solo sabe q no le llega al usuario, y entonces aplica los controles propios de congestion.
Vamos, q yo no veo claro como puede saber en q tramo de la red se esta perdiendo el paquete, si el unico q entiende TCP y el unico q confirma es el usuario movil...

Yo al menos es lo q entiendo de esta pregunta; no se si he aclarado algo o ya teneis todos muy clarito q la respuesta es incorrecta.

Saludos

atm
Usuario registrado
Mensajes: 27
Registrado: 03 Jun 2008, 13:57
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 47

Mensaje por atm »

Sí, ya la he impugnado basádome en el campo ventana.
Según la RFC 793 (la de TCP), el emisor sólo reduce la tasa de envío cuando el campo ventana de los ACKs recibidos disminuye.

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

Re: Pregunta 47

Mensaje por ebnz »

Yo también lo he presentado ya, como la oficina de Maria de Molina no me queda lejos me he acercado y he tardado menos de 5 minutos.


Como dijo Jack el destripador, vayamos por partes
arf escribió: 1/ TCP solo lo implementa el emisor (q sera un servidor fuera de la red) y el usuario movil.
2/ En el resto del camino el paquete TCP q ha enviado el servidor esta encapsulado para poderse enviar por las pilas propias de los distintos interfaces por los que circulan los datos.
3/ Asi q la unica confirmacion (ACK) q le llega al servidor es la q le envia el usuario movil.
4/ Por tanto, el servidor no tiene forma de saber si el paquete se ha perdido en el camino GGSN-SGSN-RNC porq se lo ha tragado algun equipo o porque en algun cable hay congestion, o si se ha perdido en el enlace radio.
5/ Solo sabe q no le llega al usuario, y entonces aplica los controles propios de congestion.
6/ Vamos, q yo no veo claro como puede saber en q tramo de la red se esta perdiendo el paquete, si el unico q entiende TCP y el unico q confirma es el usuario movil...
1/ ... y supongo que algún otro interfaz de la red, pero no viene al caso
2/ ... no digo que no. De hecho en cierto casos es más convenientes usar un protocolo diseñado para redes no alámbricas y engañar a los extremos mediante ip spoofing
3/ ... En TCP el emisor sólo se comunica con el receptor, no con ningún otro 'elemento intermedio'. Si ocurre "algo" a nivel de red (IP) se comunica por ICMP.
4/ ... a nadie le importa en qué tramo se pierden los datagramas, lo que nos importa es que como la tasa de pérdidas es mayor el receptor y el emisor pueden implementar SACK para informar qué datagramas le han llegado y reenviar los perdidos
5/ ... sabe qué datagramas le han llegado al receptor
6/ ... La escalabilidad de las redes IP se debe a que no existe una topología conocida de red, sino que la red es un 'ente' que se conoce a si misma.

saludos

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

Re: Pregunta 47

Mensaje por danii »

Bueno, aqui va mi respuesta para los morbosos como capelo. :lol:

Ademas, como ya habeis hecho las impugnaciones, este debate queda en un ambito mas didactico que "guerrillero" por lo que espero que se relajen las tensiones. :roll:

Me he centrado basicamente en ver si la respuesta A es correcta o no, ya que parece que estamos mas o menos de acuerdo en que la D lo es. (Realmente creo que da igual, porque la A y la D son excluyentes, pero bueno).

He leido todas las RFC que habeis puesto y alguna mas.

Mi argumento va un poco en la linea de lo que hablabais Ebnz y RebelaBK el miercoles:

Tenemos las RFC 1072 y la 1185 que ya estan obsoletas.
Y nos quedan la 2018 y la 1323 (esta explicitamente dice: "SACK has been deferred to a later memo." asi que nos olvidamos de ella).

En todas las RFC se habla de SACK como un sistema de control de paquetes perdidos y como mejorar la retransmision para que no se envien mas de los necesarios o menos. Es decir, ayuda a mejorar la eficiencia en la transmision.
Muy bien.

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.

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.).


Chao.

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 »

Madre mía. ¿El tribunal se tiene que leer todas las RFC's que indicáis? Se van a volver locos. Casi me están empezando a dar pena :wink:

Cerrado

Volver a “PRIMER EXAMEN 2009”