Løsningsforslag Gruppeoppgaver, 28. april 2. mai. 1. Metningskontroll ( Congestion control ) og ressursallokering.

Transkript

1 Løsningsforslag Gruppeoppgaver, 28. april 2. mai 1. Metningskontroll ( Congestion control ) og ressursallokering. a) Hva menes med metning og metningskontroll i et nettverk? Metning er overbelastning i et nettverk, som bl.a. kan komme av at mange maskiner forsøker å sende over samme link samtidig. Det kan også være at alle pakker ut fra en ruter skal ut på samme linje samtidig, eller at det ikke er bufferkapasitet nok. Metningskontroll blir da de mekanismer en har for å hindre eller kontrollere metningen. b) Hvor og hvordan oppstår metning i et nettverk? Metning oppstår i rutere når disse blir overbelastet. For mye trafikk inn til en ruter vil først føre til opphoping av pakker som den ikke klarer å ta unna; disse vil gradvis fylle opp ruterens buffere til disse er fulle, og når køene er fulle, må pakker kastes. c) Er det noen forskjell på metningskontroll i forhold til forbindelsesløse og forbindelsesorienterte nett? I forbindelsesorienterte nett allokeres ofte ressursene ved oppstarten av hver forbindelse. Da unngås metning, men det er potensiale for sløsing med ressursbruken hvis ikke nodene tilknyttet forbindelsen utnytter den fulle båndbredden som er allokert til enhver tid. I forbindelsesløse pakkesvitsjede nettverk (Internet) pre-allokeres det ikke noen ressurser, og man må da håndtere det at det kan oppstå metning i rutere. d) Redegjør for de to hovedprinsippene for metningskontroll. 1. Unngå at nettet går i metning ved design av nettverk og påtrykk 2. Lette påtrykket når nettet er i ferd med å mettes: Info om trafikkproblemet må sendes tilbake til avsendere av pakkene (øker trafikken), eller også sendes til nabonodene (sprer opphopningen noe). Tiltakene vil være å øke kapasiteten, rute andre veier og/eller redusere senderaten. Viktig å unngå svingende oppførsel. e) Begrepsforklaring: back pressure: tilbaketrykk for å la pakker vente i nettverket, dvs. at de holdes tilbake i buffre i noder oppstrøms for den ruteren som har metningsproblemer istedenfor at denne ruteren må kaste pakker. soft state: i et forbindelsesløst pakkesvitsjet nettverk blir i prinsippet alle pakkene svitsjet uavhengig av hverandre. I praksis er pakkeflyten aldri uavhengig siden to noder som kommuniserer vil sende en strøm av meldinger mellom seg. En softstate-basert ruter tar vare på info om slike dataflyter for å kunne ta mer velbegrunnede avgjørelser om ressursallokering (dynamisk oppbygget), i motsetning til hard state rutere hvor denne info-en er hardkodet 1

2 på forhånd. f) Metningskontroll innbefatter flere lag i OSI-modellen. Redegjør for hvilke lag dette er og hvordan de er involvert. Transportlaget: Retransmisjonspolitikk, cachingpolitikk når pakker ankommer out-of-order, kvitteringspolitikk, flytkontrollpolitikk og bestemme timeout-verdier. Nettverkslaget: Virtuelle kanaler mot forbindelsesløs overføring, køpolitikk og betjeningsrekkefølge, kastepolitikk, rute-algoritme og pakkelivssykluspolitikk. Datalinklaget: Retransmisjonspolitikk, cachingpolitikk når pakker ankommer out-of-order, kvitteringspolitikk og flytkontrollpolitikk. g) Redegjør for forskjellige typer for kødisiplin, og diskuter fordeler/ulemper med de forskjellige. FIFO: kun en kø; tar ikke hensyn til hvilken flyt en pakke tilhører. Implementeres vanligvis slik at pakker kastes når køen er full (tail drop). DECbit og RED bruker mer kompliserte algoritmer for å avgjøre hvilke pakker som skal kastes. Fair queuing: Ulike køer for hver flyt; disse behandles round robin. Hvis det her sendes data for raskt til at det kan tas unna i en flyt, så vil metningsproblemet være isolert til den ene køen, og ikke ramme de andre flytene. Weighted fair: queuing variant av FQ hvor hver enkelt kø kan tillegges vekt avhengig av prioriteten på de dataene som er i køen. h) Redegjør for hvordan metningskontroll er implementert i TCP. Implementert som kontroll av avsendervinduet (congestionwindow) ved hjelp av additiv increase / multiplicative decrease, slow start, fast retransmission, fast recovery osv. i) Begrepsforklaring: Slow start: Brukes for å øke metningsvinduet raskt fra en kald start. Økningen er eksponensiell istedenfor lineær, og metningsvinduet dobles da for hver RTT inntil pakketap, hvorpå det da halveres og man går over til å bruke additiv increase videre. Brukes både på begynnelsen av en oppkobling og når metning dør ut og man starter å sende på nytt. Fast retransmitt: I stedet for å vente hele RTT før pakker som ikke har blitt ACK'et sendes på ny, kan man sende pakken med en gang man vet at den ikke har kommet frem. Hvis mottaker ikke har mottatt pakke n, sender den ACK for pakke (n-1) ved mottak av hver nye pakke frem til den får pakke n. Mottaker vil da altså sende ACK for det høyeste pakkenummeret som til enhver tid har ankommet korrekt. Fast recovery: Slår til når det eksisterer metning. Metningsvinduet halveres da, og additiv increase benyttes videre. j) Redegjør for ulike strategier for å unngå metning. DECbit: En ruter som benytter dette gir tilbakemelding til noder før metning inntreffer, ved at ruteren setter et bit i pakkene som sendes gjennom ruteren. Mottaker kopierer så dette bitet inn i ACK'en slik at sender får beskjeden. Bitet settes hvis gjennomsnittlig kølengde er større enn 1 når pakken passerer 2

3 ruteren. Random Early Detection (RED): har samme prinsipp som over, men istedenfor å sette et bit, gis det her kun implisitt tilbakemelding i form av pakketap. Pakketapet skjer før det strengt tatt er behov for det i denne ruteren, slik at sender vil justere sin datarate raskere enn om pakker bare hadde blitt kastet når det var fullt. Brukes sammen med TCP. Andre endemaskiner kan også detektere at metning snart vil inntreffe ved å holde et øye med RTT og ta økning her som en indikasjon pâ at en eller flere rutere er i ferd med  bli overbelastet. En mulig algoritme er å sjekke nåværende RTT mot gjennomsnittet av max og min RTT, hvis større så reduseres metningsvinduet med 1/8. Alternativt kan en sammenligne throughput for hver RTT. 2. RPC (Remote Procedure Call). a) Beskriv hvordan RPC fungerer. RPC er en teknikk som gjør det mulig å kalle en prosedyre i et annetadresserom (f.eks. i en annen maskin). Meningen er at et fjernprosedyrekall skal minne mest mulig om et vanlig prosedyrekall (dvs. med parametre, returverdi og mulige exceptions). Det er et poeng at et fjernprosedyrekall skal være så enkelt som mulig for programmerer. Mest mulig av kommunikasjonsdetaljene skal være skjult (transparens). De prosedyrekallene som skal være tilgjengelig som fjernprosedyrekall, må spesifiseres ved hjelp av et interface definition language (IDL). IDL språket består bare av grensesnittet til prosedyrene (dvs. prosedyrenavn, inn og ut parametre, returverdi osv.). IDL'en inneholder ikke implementasjonsdetaljer (IDL språket er deklarativt). Bak kulissene vil en IDL kompilator lage stubs for klient og tjener. NÂr en klient kaller en fjernprosedyre, vil kallet gå til klientstubben (dette vil se ut som et vanlig lokalt prosedyrekall siden vi er i samme adresserom). I klientstubben vil kallet bli endret til et passende nettverksformat. En passende protokoll (f.eks. TCP/IP) vil bli brukt til å overføre kallet til tjenerstubben. Tjenerstubben transformerer meldingen fra nettverksformatet til et lokal prosedyrekall som igjen blir eksekvert på tjeneren. Alle kommunikasjon går igjennom stubbene, men dette er skjult for de som programmerer. Her er stegene for å lage en RPC applikasjon: (1) Lag IDL'en. Definisjonene som er i IDL'en er tilgjengelig for klienter. (2) Kompiler IDL'en. Dette vil produsere en del headerfiler samt stubs for klient og tjener. (3) Programmer tjenerprogrammet. De prosedyrene som ble spesifisert i IDL'en må nå implementeres. Kompileres sammen med headerfiler og tjener- stubben. (4) Programmér klientprogrammet. Her kan man invokere fjernprosedyrekallene. Kompileres sammen med headerfiler samt klient- stubben. Se man rpc for mer informasjon om hvordan RPC brukes med C. b) Gjør rede for de fire mulige kall-semantikkene som RPC kan operere med. En RPC implementasjon kan ha forskjellige leveringsgarantier. Dette kalles 3

4 ofte for RPC-kallsemantikk. Det som skiller de forskjellige semantikkene er: (1) om vi prøver å retransmittere meldinger til vi enten har fått et svar eller at vi antar at tjeneren er død (2) om vi filtrerer ut duplikate meldinger ved retransmisjon (3) om vi holder en oversikt over svarene tjeneren har sendt slik at vi kan retransmittere svar som har blitt bort uten å utføre det originale prosedyrekallet på nytt Det er viktig å vite hvilken form for semantikk RPC implementasjonen støtter. Den vanligste er at-most-once. exactly-once: betyr at et prosedyrekall fra klient til tjener blir utført nøyaktig 1 gang. Denne semantikken er vanskelig (hvis ikke umulig) å garantere for. Problemet er at en klient ikke ser forskjell på en feil i nettverket (f.eks. at metning oppstår og pakker blir kastet) eller en feil i tjeneren (core dumped). Man kan garantere at et kall ble utført nøyaktig 1 gang hvis tjeneren ikke kræsjer og klienten mottar resultatet av kallet. at-most-once: vil si at et prosedyrekall fra klient til tjener enten blir utført eller ikke utført (0 eller 1 gang). Her vil tjeneren filtrere ut duplikate meldinger fra klienten. at-least-once: vil si at en prosedyrekall fra klient til tjener blir utf ørt en eller flere ganger. Her vil meldinger bli retransmittert uten at tjeneren filtrerer ut duplikate meldinger. maybe: vil si at en prosedyrekall fra klient til tjener kanskje blir utført. Dette vil si at klienten prøver ikke å retransmittere meldinger den får timeout på. Det er usikkert om prosedyrekallet ble utført. Hvis meldingen ble borte eller tjeneren kræsjet ble prosedyren ikke utført, men hvis svar-meldingen forsvant kan det være at prosedyren ble utført. 3.Oppgaver i Tanenbaum, kap.6: Oppgave 23: Nei. En forbindelse er identifisert ved dets sockets. Således er (1, p) (2, q) den eneste mulige forbindelse mellom disse to portene. Oppgave 25: Hele TCP segmented må passe inn i det bytes store payload feltet i en IPpakke. Siden TCP-hodet er på minimum 20 bytes, er det bare bytes tilgjengelig for TCP data. Oppgave 27: Selv om brukeren skriver med jevn hastighet, vil tegnene bli ekkoet i bursts. Brukeren kan trykke på flere taster uten at noe synes på skjermen, og så vil plutselig skjermen ta igjen tastingen. Folk kan oppleve dette som irriterende. Oppgave 28: 4

5 De første burst-ene inneholder hhv. 2K, 4K, 8K, and 16K bytes. Det neste er 24 KB og inntreffer etter 40 ms. Oppgave 29: Den neste overføringen vil være 1 maksimum segment størrelse (MSS). Så 2, 4, og 8, slik at etter fire suksesser vil den være 8 KB. Oppgave 30: De suksessive estimatene er 29.6, 29.84,