Problemes de "El protocol TCP a fons"

1. Quants números de seqüència en total s’utilitzen per a enviar 1024 bytes d’informació?

(DavidSánchez) [23/10]

• Si comptem 1 nº de seq. per byte: 1024 ACKs, +1 si contem la connexió, +2 si comptem la desconnexió.
  

index

2. La pèrdua de confirmacions en TCP força la retransmissió de segments? Per què?
(DanielMartín) [20/10]
Si arriba una confirmació d'un segment posterior llavors es suposa que tots els segments fins el que ha generat la conirmació s'han rebut be, per tant no es retransmetran els segments anteriors encara que les seves confirmacions s'hagin perdut.
Afegit: Aquest mecanisme es diu ACK acumulatiu.

index

3. L’emissor E envia al receptor R 6144 bytesa través d’una connexió TCP ja establerta. L’aplicació en el receptor llegirà les dades del buffer d’arribada de 256 en 256 bytes, realitzant la primera lectura als 4 segons i la resta cada 2 segons. L’emissor envia les dades en segment plens (1024 bytes de dades), sempre que pot. Mostra els segments intercanviats (números de seqüència i número de bytes en els segments de dades, número de seqüència i anunci de finestra en els segments de confirmació, mida del buffer de lectura i de la finestra del receptor) a llarg de la transmissió.
() [22/10]

En aquest cas, a menys que s'apliquin heurístiques en l'emissor o en el receptor es patirà el Síndrome de la Finestra Tonta (SWS):

index

4. Un llamp deixa sense subministrament elèctric a una xarxa. Què passarà amb la connexió TCP que teniem establerta amb una de les seves màquines?

• () [23/10]
  La funcionalitat de keepalive pot ser implementada por l'aplicació directament o per la implementació de TCP que utilitzi el sistema operatiu.
  

(DavidSánchez)
Correcció:Hi han dues possibilitats. Una d'elles és que no hagin arribat tots els ACK's o falti informació per transmetre i per tan es tallaria la conexió. Si per aquesta conexió no s'enviés res, restaria activa fins el Keepalive (2 hores + 9 reintentis cada 75 segons)
M'agradaria dir que aquest problema te tots els números per haber patit un contratemps, es a dir, , a la hora de editar, va pegar el contingut de la resposta malament, deixant a mitjes el problema, sense donar-se compte. Peró pel que es pot arribar a enendre la resposta podria arribar a ser correcta en la seva totalitat
Gracies a la coevaluació per advertir el fet.

()
Correcció:Ja ho ha deixat clar el meu company, només afegir que si no hi ha keepalive i no es transmeten dades, la conexió NO es tancarà.
La respota que haurià de haber possat:
Depen de si es disposa d'un mètode de keepalive. Si ho porta es tancarà la connexió passat aquest temps, sinó la connexió continuarà establerta sempre que no s'enviïn dades. La funcionalitat de keepalive pot ser implementada por l'aplicació directament o per la implementació de TCP que utilitzi el sistema operatiu.
Que ja consta a la revisió 2 de la pàgina personal, (), amb data 20-10-2006. Em sap molt de greu aquest error tonto.

index

5. Cóm argumentarieu que tancar automàticament connexions inactives és bo? Com implementaríeu aquest mecanisme de keep alive sense afegir nous bits de control a les capçaleres TCP?

()

• El echo de cerrar automáticamente conexiones inactivas no es bueno de por si solo. Para que lo sea, el tiempo que se espera para cerrar la conexión ha de ser prudente. Si el keepalive (tiempo máximo que se espera sin recibir contestación) es bueno, el cierre automático de conexiones inactivas resultará útil para liberar recursos de conexiones que han dejado de ser operativas, ya sea por fallos del cliente-servidor o por fallos de la red.

  Según el RFC 1122, si una conexión se mantiene sin intercambio de datos durante 120 minutos, se pasará a hacer una comprobación de keepalive para ver si la conexión sigue siendo activa. Si se recibe señal, la conexión se puede mantener activa durante al menos 2 hora más. Si por el contrario no se recibe la confirmación, se volverá a intentar 9 veces más, repitiendo el procedimiento de keepalive cada 75 segundos. Si después de estos 10 intentos no se ha conseguido recibir confirmación, la conexión se cerrará y se liberaran esos recursos.

  Para implementar el keepalive sin añadir nuevos bits de control, lo que se hace es reenviar el último byte del último segmento del que se ha recibido confirmación (ACK). Si la comunicación tiene éxito, se recibirá el ACK de ese segmento, pero como ya se disponía de él, no se tendrá en cuenta y no alterará para nada a la recomposición de los segmentos.

index

6. Podem canviar el MSS de TCP de manera dinàmica al llarg d’una connexió? Poden existir diferents MSS de manera simultània en un mateix router?

()

• Sí se puede cambiar el MSS de TCP dinámicamente a lo largo de una conexión. El MSS (tamaño máximo de segmento) se “negocia” entre los dos extremos de la comunicación con el objetivo de evitar la fragmentación de los segmentos. Pero esta no fragmentación durante todo su recorrido, no se puede garantizar sólo con eso, ya que durante su recorrido sí que puede sufrir fragmentaciones. Para evitar estas fragmentaciones existen algoritmos, como el “path MTU Discovery”, que se basa en enviar inicialmente datagramas IP grandes con la opción de no-fragmentación, para que así los routers que necesite fragmentarlos se vea obligado a retornarlos via ICMP, añadiendo la MTU del router que requería fragmentarlo. Con esta información el extremo que inicia la comunicación puede “ajustar” el MSS a un valor adecuado para evitar la fragmentación.
  
  Sí pueden existir diferentes MSS de manera simultánea en un mismo router, estos MSS dependerán del valor “negociado y ajustado” para cada comunicación individual que “pasa” por el router y son independientes unas de otras. Aunque en el mismo router no haya diferencia en el MTU, sí que la puede haber en el recorrido anterior o posterior, y estas diferentes MTU que se pueden dar entre diferentes comunicaciones son las que hacen que puedan haber diferentes MSS a la vez en un mismo router.
  
  

Para más información sobre “Path MTU Discovery” : ftp://ftp.rediris.es/pub/docs/rfc/rfc1191.txt

index

7. Quina és la base de l’algorisme de Jacobson? Per què penses que millora de manera tan espectacular els resultats prèvis?

()

• El algoritmo de Jacobson esta basado en el uso de una estimación de la variancia del RTT, y así poder calcular y adaptar el timeout según las condiciones de carga de la red durante toda la comunicación.
  
  Mejora espectacularmente los resultados previos gracias al uso de la estimación de la variancia, ya que esto le permite reaccionar rápidamente (RTO) a cambios reales y adaptar la velocidad de adaptación a dichos cambios producidos en la red.
  
  

index

8. Si enviem dades de byte en byte en TCP, amb un byte per segment de dades, quin tant per cent de xarxa podriem utilitzar? Com variarà en aquest cas el utilitzar una finestra d’1 byte a utilitzar una de 64 KBytes?

()

• Para hacer los cálculos de Throughput tomaremos como datos enviados útiles 1 byte, y como datos enviados 40 bytes de cabecera TCP más los datos útiles. En cuanto a la ventana TCP calcularemos que está con 65535 posiciones, y por ultimo, aceptaremos 45 confirmaciones. Así pues, utilizando la fórmula del Throughput:

  • Throughput = Ancho de banda * Datos útiles / Datos enviados
    

    Throughput = Ancho de banda * (65535 * 1 byte / 65535 * (1 byte + 40 bytes)) + (45 * 40 bytes (ACKs))
    

    Throughput = Ancho de banda * 0.025
    

index

9. És proporcional la probabilitat de que un datagrama sigui descartat al percentatge de tràfic que genera la connexió?

() [23/10]

• Depen de la política de gestió de cues. Els datagrames de una connexió amb un percentatge alt de tràfic tindrien mes probabilitats de ser descartats que els d'altre connexió si, per exemple, la política fos SFQ.
  

(DavidSánchez) [23/10]

• Anotació:
  Com bé diu el meu company depen de la gestió de cues, pero també pot generar descart de datagrames, la mida dels paquets i la congestió de la xarxa, però sempre tenint en compte primer la política de gestió de les cues.
  

()
Correcció: Si, sempre serà propocional ja a que independentment de la política de gestió de cues escollida, aumentant el percentatge de tràfic sempre aumenta la probabilitat de que datagrames de la connexió siguin descartats degut a que el recursos sempre son limitats.

10. Posa algun exempleper al que l’algorismede Nagle sigui desaconsellable. () [22/10]
L'algorismes de Neagle així com molts dels algorismes dels que s'ha parlat en aquest tema estan basats en una assunció bàsica. Aquesta assunció suposa que les pèrdues de paquets SEMPRE són degudes a la congestió. En el cas de les xarxes wireless la pèrdua de paquets no és deguda a la congestió en molts casos sinó a les interferències. Aquest fet provoca que en moments determinats les xarxes wireless tinguin una gran pèrdua de paquets mentre que la recuperació pot ser molt ràpida. Per altra banda, en el cas d'una xarxa cablejada la pèrdua de paquets es normalment deguda a la congestió i per tant la recuperació ha de ser més lenta.
És per aquest motiu que l'algorisme de Nagle no és adequat per a les xarxes wireless ja que suposa un temps d'adaptació molt gran. index

index

11. Podem saber des d'un extrem que els segments enviats han arribat fora d'ordre a l’altre?
(DanielMartín) [20/10]

No, degut a que les confirmacions poden no enviar-se totes, s'envien en ordre (no s'envia una confirmació si els segments anteriors tambè s'han rebut bé) i a més poden arribar en diferent ordre que l'enviat.

Correcció: Depèn de la implementació, ja que si un segment arriba fora d'ordre es pot no fe res, amb el que no es podría saber, o enviar un ACK de l'anterior o no enviar un ACK del que ha arribat tard, i llavors es podría saber.

index

12. Quins inconvenients veus en l’ús generalitzat de la política de gestió de cues Tail Drop? En quins casos estaria indicada?

(DavidSánchez) [19/10]

• Un inconvenient seria la sincronització global, com bé diu DanielMartín en el seus apunts de classe, es a dir, cada cop que es descarten paquets aquests fan que l'emissor redueixi tamany de la finestra de congestió a un segment entrant en Slow Start, fet que implica una disminució del tràfic per l'emissor. Aquest succés s'expandeix a altres emissors prvocant la perdúa d'una gran quantitat de paquets en les conexions extrem a extrem aplicades provocant una caiguda significativa del tràfic en tots els emissors que comparteixin protocol amb reflex a la cua gestionada amb la política Tail Drop on s'observarà una disminució considerable en el nombre de paquets. Un cop ens trobem en aquesta situació tormarem a patir un creixiement de la finestra i posteriorment una altra vegada el descart de paquets.

  Estaria indicada per a la gestió de cues de datagrames petits amb tràfic escàs de dades per qüestió d'evidencies físiques, es a dir, una situació sense congestió. Una cua amb capacitat limitada s'ompla abans amb elements grans que no pas amb petits,per tant, amb Tail Drop trigaria més en descartar els últims datagrames si aquests son de mida més petita i n'acceptaria més.

Fonts:
Apunts de l'assignatura
http://www.tdx.cesca.es/TESIS_UPC/AVAILABLE/TDX-1204101-085733//07capitol4.pdf
http://www.acm.org/crossroads/espanol/xrds7-5/july2001.html

index

13. Tenim dos routers en seqüència (tots els datagrames que surten d’un entren en l’altre), un funcionant amb PFIFO i l’altre amb RED. Quin posaríeu primer? Per què?

(DavidSánchez)[19/10]

• Primer posaria el router que funcionés amb RED ja que treballa millor sobre la congestió fent que tinguin més probabilitat de perdua els paquets grans que els petits. Així probocariem un camí sense congestió en la trasmisió.
  A la sortida del router RED posaria llavors el PFIFO que, com bé hem dit en l'exercici anterior, treballa millor sense congestió i amb una cua adecuada. Així aprofitariem el camí sense congestió que generem amb el RED.
  

Fonts:
Apunts de l'assignatura

index

14. Té sentit tenir més d'una política de gestió de cues en un únic router?
(DanielMartín) [20/10]
Si, per diferenciar, per exemple, subxarxes segons l'entrada. Es mes flexible si permitim escollir la cua i així podem definir regles per cada subxarxa física.
index

15. Imagina que en el router de l’Autònoma volem utilitzar cues diferents per a cada connexió per a que el tràfic d’excés sigui descartat de manera justa. Veus algun problema? En cas afirmatiu, com ho podries solucionar?() [22/10]

El principal problema que hi veig en aquesta aproximació és que cal mantenir un gran nombre de cues en memòria per tal de poder implementar aquesta política. Si tenim en conte el nombre de professors i estudiants que hi ha a l'Autònoma això seria pràcticament impossible.

Una solució pràcticament equivalent seria classificar els datagrames en diferents cues segons una funció hash. Això limitaria el nombre de cues a utilitzar i a més si s'utilitza una estratègia de Round Robin es donaria igual prioritat a totes les cues, aconseguint així una aproximació a la solució anterior.

index

16. Quin és el motiu d’afegir una finestra de congestió en TCP? Aquesta finestra necessitarà un nou buffer de dades?

() [23/10]

• Per poder tenir un mitjà per actuar en front de la congestió de la xarxa.

  El seu valor serà un màxim pel valor final que s'accepti com a finestra d'enviament:
  

  • finestra_permesa = min (finestra_receptor, finestra_congestió)
• No fa falta cap buffer nou perque només influeix en la quantitat final de dades enviades cap a la capa inferior.

index

17. Assumint que tant la capacitat de l’enllaç com la finestra de recepció són infinits, quants RTTs calen per a enviar els primers 10 segments de TCP si s’utilitza slow start? Podries generalitzar per cas dels k primers segments?

()

• A continuación haremos la prueba para comprobar cuantos RTTs se necesitan para enviar 10 segmentos según las características dadas: Emisor:
  • VC=1 ;
  Receptor:

  • Tiene el segmento 1
    ACK=2;

  Emisor:
  • VC=2;
  Receptor:

  • Tiene los segmentos 1,2,3
    ACK=4;

  Emisor:
  • VC=4;
  Receptor:

  • Tiene los segmentos 1,2,3,4,5,6,7
    ACK=8;

  Emisor:
  • VC=8;
  Receptor:

  • Tiene los segmentos 1,2,3,4,5,6,7,8,9,10
    ACK=11;

  Emisor:
  • VC=11;
  Con lo que obtenemos que el número de RTTs necesarios para enviar 10 segmentos en TCP es 4. Para generalizar el ejemplo anterior, buscaríamos una fórmula que nos permitiese saber el número de RTTs que se necesitan para enviar n segmentos en TCP. Mirando el ejemplo que ya hemos calculado (para 10 segmentos), podríamos deducir la siguiente formula:

  • Nº RTTs = round (log (n+1))

  En donde n es el número de segmentos a enviar y round(x) es una función que devuelve el entero superior más cercano a x.

index

18.Justifica si té sentit utilitzar el mecanisme de començament lent per a les connexions establertes dintre d’una mateixa xarxa LAN.

()

• Se puede justificar el uso del mecanismo de comienzo lento (“slow start”) para las conexiones establecidas dentro de una misma red LAN porque también se puede producir congestión dentro de la red, y el comienzo lento no es más que un mecanismo para “evitar” esta congestión. Aunque la posibilidad de congestión dentro de una misma red LAN es mucho menor y con menos repercusión que en la red global, sí que puede ser interesante utilizar mecanismos para evitar o reaccionar ante la posible congestión, y uno de ellos es el “slow start”.
  

index

19.Explica el que pots veure en la següent connexió. Els temps entre parèntesis són els increments respecte l’anterior. Entre quins segments creus que pot haver hagut desconnexió de cable?

()

• En esta conexión pueden 6 retransmisiones, que indica que debe haber habido una desconexión. La desconexión del cable puede haberse producido entre los segmentos 2y 3, ya que es cuando el incremento de tiempo es mayor. A partir de aquí comienzan unas retransmisiones con incrementos de tiempos regulares debidos a una política de respuesta a la congestión, hasta que se hubiera producido la reconexión del cable, que podría haber sido entre los segmentos 8 y 9, que es cuando el incremento de tiempo es menor, y vuelva a unos valores muy bajos propios de una buena comunicación entre los extremos.
  

index

20. Si disposéssim d’una xarxa que permetés uns transmissió a velocitat infinita, i una potència de processament també il.limitada, hi hauria un throughput màxim de TCP, o seria també infinit? Justifica la teva resposta.

()

• Para intentar contestar a esta pregunta nos miraremos la fórmula del Throughput:

  Throughput = Ancho de banda * Datos útiles / Datos enviados Así pues, estaríamos en un medio en el que la velocidad de transmisión y la capacidad de proceso serían infinitos, con lo que no existiría congestión alguna. Esto nos puede hacer pensar que el Throughput podría ser infinito, pero el hecho de que tengamos una diferencia en la fórmula de cálculo del Throughput de los datos útiles por los enviados y debido a que los enviados siempre serán mas que los útiles, podríamos llegar a la conclusión de que el Throughput en un medio como el descrito, sería muy grande, pero nunca infinito.

index

21. Quin és el throughput màxim de TCP si el RTT promig és de 10ms, les capçaleres de la xarxa física són sempre 62 bytes, i el MTU és 128 KBytes?

() [23/10]

• La finestra es la màxima permesa (65535 Bytes) i s'envien 65535/130 970=0.5 -> Un únic segment amb la mida determinada per la màxima finestra
  S'envia un únic ACK.
  L'amplada de banda.
  

  • RTT/2 = 5ms -> 128Kbytes/0.005 = 209 715 200 bits/seg = 25Mbits/seg
    
    

  Throughtput = 3 276 800 Bytes/seg * 1*65535Bytes / (1*65535Bytes+1*102Bytes) = 3 271 707 Bytes/seg = 3.12Mbytes/seg = 24.96Mbits/seg
  

index

22. Calcula el throughput màxim de TCP per xarxes Ethernet de 100Mbps, 1 Gbps i 10Gbps.() [22/10]

Suposant que el tamany màxim de finestra per a una ethernet és de 65535 bytes tenim que d'quests:

• - 16 (8+8) són del preamble Ethernet
  - 24 (12 + 12) són de les adreces Ethernet
  - 4 ( 2+2) són del camp de tipus Ethernet
  - 80 (40 + 40) són de les capcelesr IP i TCP
  - 65447 són dades útils
  - Suposarem 0 bytes de padding ethernet
  - 8 (4+4) de CRC Ethernet
  - Suposarem 0 d'espai entre paquets.
  

D'aquesta manera tenim que el màxim throughput per a:

• - Ethernet a 100Mbps = 100Mb/s * (65447/65601) = 99,76 bits
  - Ethernet a 1GBps = 1024Mb/s * (65447/65601) = 1021,59 bits
  - Ethernet a 10GBps = 10240Mb/s * (65447/65601) = 10215,96 bits
  

index

23. Seria possible tenir TCP per sobre d’Ethernet directament, sense utilitzar IP? Raona els motius i les limitacions que trobis.
(DanielMartín) [20/10]
Si, però tinría els següents inconvenients:

• No es podría interconnectar amb altres xarxes.
• En lloc d'IP s'hauría d'utilitzar la MAC, que s'hauríen d'incloure a la capçalera TCP.
  

(DavidSánchez) [23/10]

• Anotació:
  Es podria conectar amb les xarxes ethernet veïnes mitjançants repetidors o bridges però no deixaria de estar aïllada, es a dir, pasaria a ser una xarxa ethernet commutada de més tamany, fiable y amb un throughput més gran provocat per l'ausencia del checksum.
  

index

24. Quines penses que són les avantatges/inconvenients d’utilitzar una cua TBF en comptes d’una RED? Se t’acudeix com combinar les idees bàsiques de totes dues cues en una de nova?

(DavidSánchez)[23/10]

• En principi en RED, els datagrames grans tenen més probabilitat de ser eliminats pel comportament de la política. En canvi en TBF l'arribada de datagrames grans es possible que arribin en una freqüencia inferior a la arribada dels tockens i per tant tindran menor probabilitat de ser descartats.