Løsningsforslag uke 10

1. Transportlaget

1. Hvorfor sier vi at transportlaget danner et skille i OSI modellen? Hva er den fundamentale forskjellen på lagene over og under transportlaget?

   Transportlaget er det første laget med ende til ende kontroll. Lagene fra transportlaget og over finnes typisk bare i endesystemene og ikke i rutere og svitsjer. Over transportlaget finner vi protokoller som understøtter samvirke mellom distribuerte applikasjoner; disse protokollene beskjeftiger seg ikke med selve overføringen av data, men forutsetter at dette ivaretas av underliggende lag. Under transportlaget har vi det fysiske nettet med rammer og ruting. Disse lagene (fysisk, link, nett, transport ) har det kollektive ansvaret for overføring av data mellom sender og mottaker, og sørger for at overføringskvaliteten tilsvarer applikasjonenes behov.

2. Hvilke hovedkrav må transportlaget oppfylle dersom det har det fulle ansvaret for påliteligheten i kommunikasjonen mellom to transport-bruker entiteter?

   Hvis vi ønsker å oppnå/garantere full pålitelighet i transportlaget kreves følgende: Pålitelig oppkobling av forbindelser, pålitelig overføring av data, dvs at alle meldinger kommer frem, at ingen meldinger dupliseres, at meldinger ikke bytter rekkefølge og at meldingene ikke inneholder feil (ende-til-ende feilsjekk), pålitielig nedkobling av forbindelser uten tap av datapakker (graceful close ).

3. På hvilket grunnlag velges transportprotokoll (eks TCP eller UDP i TCP/IP) for en applikasjon? Når gjøres valget?

   Valget foretas når man skal implementere en applikasjon, dvs at man velger når det opprettes feks en socket som kan ha parameter UDP eller TCP. Man bør velge den protokollen man tror best kan oppfylle kravene til nettverkskommunikasjon hhv. effektivitet, hastighet, sikkerhet. Ofte ender man med et kompromiss hvor en bruker den protokollen som har flest av de ønskede egenskapene. UDP vil typisk være egnet til å sende mange små pakker, lyd/bilde og interaktiv bruk hvor det ikke er vesentlig at alle pakker kommer frem. TCP er derimot velegnet til feks store filoverføringer.

4. Beskriv feltene i henholdsvis UDP og TCP headeren. Hvorfor er de så ulike?

   Se figur side 526 og 537 i Tanenbaum for header layout hhv UDP og TCP. TCP headeren er mer omfattende fordi man trenger å skille mellom ulike typer TPDUer (feks for op- og nedkobling), det trengs sekvensnummer for å sikre at alle bytene leveres i riktig rekkefølge , og det trengs et felt for å gi melding om mottakervinduet.

5. Transportprotokollen UDP er som IP forbindelsesløs, hvorfor har vi en forbindelsesløs transportprotokoll?

   Det er behov for valgmuligheter: i noen situasjoner er det bedre/mer effektivt/raskere med en forbindelsesløs transport protokoll. Feilhåndtering etc må da håndteres på laget over (applikasjonen). Ofte skreddersyr man applikasjoner for å få bedre ytelse vha. UDP i situasjoner hvor det sendes mange små pakker, eller tale/video hvor npen pakker kan bli borte uten å ødelegge for resutatet.

6. Beskriv prinsippet for pålitelig etablering av en transportforbindelse ved hjelp av tre-veis håndtrykk.

   Se figur side 540 i Tanenbaum. Algoritmen treveis håndtrykk brukes av TCP for å etablere og terminere forbindelser. Håndtryket involverer utveksling av tre beskjeder mellom klient og tjener. Ideen er at de to partene skal enes om et sett parameter for forbindelsen. Ved åpning av forbindelse er det særlig viktig å avtale hvilket sekvensnummer man starter med. I tillegg kan det være QoS-parametre samt andre opsjoner. Først sender klienten en transport protokoll enhet (TPDU) til tjeneren og angir sitt initielle sekvensnummer (>YN) . Tjeneren svarer med en ACK på klientens sekvensnummer samtidig som den angir eget initielle sekvensnummer (SYN+ACK). Til sist svarer klienten med en tredje TPDU aom bekrefter tjenerens sekvensnummer (ACK). Grunnen til at det ikke brukes forhåndsdefinerte initielle sekvensnummer er at TCP krever at hver side av forbindelsen selv velger disse tilveldig, for å hindre at to instanser av samme forbindelse gjenbruker de samme sekvensnummer for raskt.

7. Fragmentering og reassemblering blir tatt hånd om av IP. Betyr det at TCP ikke trenger å bekymre seg om at data kan komme frem feil rekkefølge?

   Det er kun de separate pakkene som blir satt tilbake til opprinnelig tilstand av IP etter fragmentering. Dvs at IP ikke besørger annet enn å ikke levere fragmenterte pakker fra IP og opp til transportlaget. Rekkefølgen av pakkene er likegyldig for IP, og TCP må håndtere situasjoner hvor pakker kommer frem i en annen rekkefølge enn de ble sendt i. Eksempelvis TCP sin sliding window algoritme tar seg av å stokke pakkene tilbake i rekkefølge.

2. Oppgaver basert på Computer Networks 4th edition

1. Hva om vi kun hadde et to-veis håndtrykk. Hvorfor bruker vi ikke dette?
   
   Tenk på dette scenarioet: Host 1 sender en SYNpakke til Host 2. Host 2 setter opp tilkoblingen sin og sender deretter en ACK tilbake på denne SYNpakken? Hva skjer om denne ACKpakken forsvinner på veien tilbake? I dette tilfellet har Host 2 allerede satt opp en tilkobling, mens Host 1 fortsatt venter på svar fra Host 2. En timeout vil forekomme hos Host 1 etter en stund og en ny SYNpakke vil sendes til Host 2. Problemet her er at Host 2 vil se på denne SYNpakken som en ny tilkobling mellom de to nodene, ikke som en resending av den første SYNpakken, og dermed heller sette opp 2 tilkoblinger til Host 1.
    
2. Hva med et tre-veis håndtrykk? Løser dette problemene med to-veis håndtrykket?
   
   Et tre-veis håndtrykk vil løse problemene som beskrevet over ved at begge partene i kommunikasjonen vil gå inn i en mellomliggende fase før den faktiske tilkoblingen settes opp. Hvis vi tenker oss samme scenario som i oppgave 1 så vil Host 2 sende en SYN/ACK pakke etter å ha mottatt den første SYNpakken fra Host 1. Etter at denne pakken er sendt vil Host 2 gå inn i en mellomliggende fase kalt SYN-SENT i stedet for å sette opp tilkoblingen direkte. Host 2 vil være i denne mellomliggende fasen helt til den mottar en ACK på SYN/ACK pakken som den sendte tilbake til Host 1. Hvis SYN/ACK pakken forsvinner i dette tilfellet, og Host 2 mottar en ny SYN pakke fra Host 1 så vil Host 2 forstå at SYN/ACK pakken må ha forsvunnet ettersom en ACK aldri har kommet fram på denne pakken.
    
3. Hva er "The two army's problem" og hvordan relaterer det seg til nedkobling av en connection i TCP?
   
   Viser til side 537 i Computer Networks 5th edition (eller side 503 i 4th edition) for en forklaring av The two army's problem. Poenget her er at det vil være umulig å synkronisere de to armeene til blå. Det samme gjelder nedkobling av en connection i TCP. Det finnes ingen protokoller som garanterer at begge partene i en samtale tar ned tilkoblingen samtidig.
    
4. Trenger man egentlig UDP protokollen? Kunne man ikke like godt bare sende rene IP pakker?
   
   UDP implementerer ikke mye funksjonalitet, men protokollen har allikevel en viktig oppgave, nemlig å identifisere hvilken applikasjon pakken segmentet tilhører. IP protokollen har mulighet til å identifisere (og å finne) en viss maskin på Internett, men når denne pakken kommer fram trenger man en protokoll som sier noe om hvilken applikasjon pakken skal leveres til, og det er altså dette UDP gjør.
    
5. Både UDP og TCP bruker portnumre for å identifisere en prosess. Hvorfor oppfant man en ny type ID for prosesser (portnummer) i stedet for å bruke prosessIDen som allerede var i bruk da man designet disse protokollene?
   
   Det er tre grunner til at man bruker portnumre i stedet for prosessIDen som man finner i operativsystemet:
   1. En prosessID er spesifikk for hvert operativsystem, ved bruk av en slik prosessID måtte protokollen også vært skreddersydd for operativsystemet.
   2. I enkelte tilfeller vil man ha muligheten til å sette opp flere tilkoblinger mellom to prosesser, da må man ha en måte å skille disse på.
   3. Enkelte portnumre er såkalte "godt kjente" portnumre. Dette gjelder for eksempel HTTP som alltid bruker port nummer 80. Dette ville vært umulig å gjennomføre med prosessIDer.
    
6. Hvorfor er maksimum nyttelast (payload) for et TCP segment 65.495 bytes? 65536
   
   Grunnen til at et TCP segment kun kan være på 65.495 bytes er fordi et IP datagram max kan være på 65.515 bytes. Hvis man da har nyttelast på 65.495 bytes + en TCP header + 20 bytes er man på 65.515 bytes.
   
   Dette lar det være igjen 20 bytes med IP header som gir 65.535 bytes (som er resultatet av 2^16 - 1).