AbsrracCChere är ett ökande behov av Internetvärdar för att snabbt och effektivt kunna lära sig avståndet, i termer av metria såsom latency eller bandbredd, mellan Internet värdar. Till exempel, för att välja närmaste av flera lika innehåll webbservrar. I detta dokument undersöks tekniska frågor som rör inrättandet av en offentlig infrastrukturtjänst för att tillhandahålla sådan information. På så sätt föreslår vi en arkitektur, kallad IDMaps, där Internet distansinformation distribueras över Internet, med IP multicast p u p s, i form av en virtuell distanskarta. System som lyssnar på grupperna kan uppskatta avståndet mellan ett par IP-adresser genom att köra en spanning trädalgoritm över den mottagna distanskartan. Vi a h presenterar resultaten av experiment som ger preliminära bevis för arkitekturen. Detta arbete lägger därmed den första grunden för det framtida arbetet på detta nya område. Det är i allt högre grad så att en viss Intemet-interaktion kan tillfredsställas av en av ett antal Internet-värdar. Exempel sträcker sig från kortvariga interaktioner såsom en enda webbsida åtkomst till någon av flera lika innehåll webbservrar till en långsiktig peering relation mellan två nyheter (NNTP) servrar [I]. I alla sådana interaktioner, alla andra saker är lika, är det fördelaktigt att få tillgång till "glänsande" valet. Med nära menar vi i termer av Internet prestandamått, såsom låg latency eller hög bandbredd. Även när alla andra saker inte är lika, såsom fallet där olika webbservrar har olika svarstider, är det fortfarande användbart att inkludera avstånd till varje kandidat värd som ett av flera kriterier för att göra ett urval [2]. En metod för att få denna distansinformation är att den initierande värden mäter den själv med hjälp av antingen unicast (ping, track route [3]) eller multicast (expanderande ringsökning [4] ) verktyg. Även om dessa verktyg har ett brett spektrum av användningsområden, är deras användbarhet i allmänhet begränsad av deras overhead. Till exempel, kostnaden för att köra en enda spårväg kan överstiga kostnaden för själva webbsidan åtkomst. Ännu viktigare är att ett stort antal värdar som gör oberoende och frekventa mätningar kan ha en allvarlig inverkan på prestanda totalt sett. Helst bör mätningar som görs av ett system (värd eller rquter) göras tillgängliga, till låg kostnad, för andra värdar. En användbar allmän tjänst för Internet skulle vara en tjänst där en värd snabbt och effektivt skulle kunna hålla avståndet mellan två värdar. För att vara till stor nytta bör en sådan tjänst ge ett svar med en fördröjning och en övre gräns som är mindre än de vinster som uppnås genom att använda tjänsten. Ett enkelt protokoll för en sådan tjänst (SONAR) diskuterades i stiftelsen redan i februari 1996 [SI] och i april 1997 som en mer allmän tjänst kallad HOPS (Host Proximity Service) [6]. Båda dessa ansträngningar föreslog lättviktsklienterver quishheply protokoll i linje med en DNS queskply. Båda krävde också att servern skulle kunna producera ett svar på mycket kort tid, helst, men inte nödvändigtvis, genom att använda information som redan lagrats lokalt. Detta dokument handlar om problemet med hur servrar i en sådan SONAIUHOPS-tjänst kan få den distansinformation som behövs för att svara på frågor. Vi undersöker särskilt följande frågor: 1. Vilka system producerar ursprungligen distansinformationen, och hur produceras den? 2. Utgångspunkten är följande: Hur når distansinformationen från dessa producerande system till servrarna? Detta dokument tar därför ett första hugg i att utforska en global, i motsats till endhost baserad, arkitektur för Internet värd avstånd uppskattning och distribution. Vi diskuterar grundläggande aspekter av de frågor som beskrivs ovan, och baserat på detta föreslår en allmän arkitektur för en underliggande tjänst som ger den grundläggande information som används av en SONAIUHOPS-tjänst. T h s underliggande tjänst kallas IDMaps, för Internet Avstånd Karta Service. I avsnitt I1 beskrivs bland annat vilka tillämpningar som behövs, men mer av grundläggande tekniska begränsningar. Avsnitt 111 s t m med en bred diskussion om de grundläggande egenskaperna hos problemet och lösningens art. Den presenterar och utvecklar två varianter av lösningen, "Hop-by-Hop" och "End-to-End", varav den senare är mer elegant men mindre välförståelig och slutar med en diskussion om deras för- och nackdelar. I avsnitt IV beskrivs resultaten av en preliminär analys som testar några av de grundläggande antagandena i End-to-End-lösningen. Dessa resultat tyder på att det har lovat, och uppmuntrar oss att gå vidare med en mer detaljerad utformning och genomförande. Slutligen diskuteras några av de många olösta frågorna i avsnitt V. Det är svårt att ange exakta mål för även en SONAIUHOPS-tjänst. Mycket mindre IDMaps-tjänsten. Detta beror på att SONAFUHOPS kan uppmanas att stödja ett brett spektrum av applikationer, från webbklienter som vill ha en webbserver från vilken man kan hämta en liten mängd data en gång, till Network Tine Protocol-servrar (NTP) som vill etablera en långsiktig koppling till ett peer-system. Vi skulle kunna gå igenom övningen att göra en lista över potentiella tillämpningar och extrahera ut de mest krävande kraven (och i viss utsträckning, åtminstone informellt, vi har gjort detta), men i själva verket denna övning visar snabbt att vi inte ens kan komma nära att uppfylla alla tänkbara krav. Till exempel kan vi inte hoppas på en allmän IDMaps-tjänst för att ge nära-instantan information om aktuella förseningar och bandbredd som ses mellan två Internet-värdar. Även om sådan information kan vara mycket användbar för en värd som vill välja en server som tillhandahåller ett live videoflöde, till exempel. Snarare har vi tagit något motsatt takt-vi bestämde ungefär den bästa servicen vi kan erbjuda med tanke på tekniska begränsningar och behovet av global skalbarhet av tjänsten, och sedan överväga om det finns tillämpningar för vilka denna nivå av tjänst skulle vara användbar. Här följer en diskussion om de mål som blir resultatet. Vårt mål är att tillhandahålla distansinformation i form av latens (t.ex. fördröjning av tur och retur) och, om möjligt, bandbredd. Latency är den enklaste typen av information att ge, och lyckligtvis den mest allmänt användbara. Det finns två skäl till att det är lätt att tillhandahålla. Först är det lätt att mäta. Ett litet antal paket kan ge en bra grov uppskattning. Andra. Det är relativt oberoende av den exakta vägen mellan de två värdarna, men på intet sätt helt oberoende.
I IDmaps-projektet REF producerar latencykartor över Internet från vilka latenser av godtyckliga sökvägar kan erhållas.
An architecture for a global Internet host distance estimation service
{'venue': "IEEE INFOCOM '99. Conference on Computer Communications. Proceedings. Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies. The Future is Now (Cat. No.99CH36320)", 'journal': "IEEE INFOCOM '99. Conference on Computer Communications. Proceedings. Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies. The Future is Now (Cat. No.99CH36320)", 'mag_field_of_study': ['Computer Science']}