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