Implications of the topological properties of Internet traffic on traffic engineering

Implications of the topological properties of Internet traffic on traffic engineering
of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
  Implications of the Topological Properties of InternetTraffic on Traffic Engineering Steve Uhlig    , OlivierBonaventure Computer Science andEngineering DepartmentUniversité catholique deLouvain, Vincent Magnin Laboratory for ComputerCommunications andApplicationsEPFL, Chris Rapier PittsburghSupercomputing Center, Luca Deri Centro SerraUniversity of Pisa, ABSTRACT In this paper we study the behavior of Internet traffic on the AS-level topology and discuss its implications on interdomain trafficengineering. We rely on two notable interdomain traffic traces, thefirst is one month long and the other is one day long. This studyshows that interdomain paths are stable for a large majority of thetraffic from a routing viewpoint. We show that the aggregation of the traffic occurring on the AS-level graph is essentially limited todirect peers, with almost no aggregation occurring at larger AS hopdistances. Furthermore, only part of the AS paths of the AS-leveltopology that see a lot of traffic are stable, when considering theirpresence among the largest AS paths on a hourly basis. Relyingon the largest AS paths in traffic over a time window to capture thetraffic over the next time interval discloses the important variabilityof the traffic seen by the largest AS paths in traffic. Interdomaintraffic engineering is hence due to be difficult because of the lim-ited traffic aggregation on the AS-level topology and the importanttopological variability of the traffic for a significant percentage of the total traffic. Categories and Subject Descriptors C.2.5 [ Computer-communication Networks ]: Local and Wide-AreaNetworks—  Internet traffic ; C.2.1[ NetworkArchitectureandDesign ]: Network topology General Terms Measurement Keywords Internet traffic, topological traffic properties, traffic engineering   Corresponding author (URL:    suh/).This work was carried while Vincent Magnin was a visiting stu-dent at UCL. Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee. SAC   ’04, March 14-17, 2004, Nicosia, CyprusCopyright 2004 ACM 1-58113-812-1/03/04 ...$5.00. 1. INTRODUCTION The global Internet is made of two types of ASes: transits andstubs. Transit ASes provide Internet connectivity to stub ASes, byforwarding IP packets across their network. Stub ASes on the otherhand only produce or receive IP packets, they do not allow IP pack-ets to transit their network.The topological distribution of the Internet traffic has been rarelystudied in the literature. [12] is among the early papers that ana-lyzed the traffic distribution on the ARPANET in 1974. An impor-tant finding from this paper was that a few sites were responsiblefor the majority of the traffic. Similar results were obtained in 1993on the NSFNet backbone [7] on the basis of packet-level traces andSNMP statistics from backbone routers. More recently, [8] ana-lyzed several one hour packet level traces from universities and acommercial backbone to evaluate the impact of aggregating flowsat the Autonomous System level. Similar results are reported for alarge transit ISP in [9] and stub ASes in [22, 15].Thecommon threadinallof thesepapersisthatalimitednumberof ASes are responsible for a large fraction of the interdomain traf-fic. The limitation of these studies concerns the fact that they allconsider the traffic distribution for a given time period, assumingthat the timescale over which the studies are carried is representa-tive of the behavior of the interdomain traffic, as if the way trafficcrosses the AS-level topology does not vary with time. However,the recent proliferation of content distribution networks and peer-to-peer systems may be responsible for large variations of the topo-logical characteristics of interdomain traffic.Moreand moreISPsareconcerned withhow tocontrol thetrafficat multiple interdomain access points. Recent studies [20, 2] haveshown that a large number of today’s ASes are multi-homed. Morethan 60 %of all ASeshaveat least two BGPpeers [20]. Anincreas-ing trend towards multi-homing was shown in [2] and is likely tocontinue as ISPs become aware of interdomain traffic engineeringtools and techniques [15, 5, 3]. Examples of traffic engineeringtools include the solutions commonly referred as “route optimiza-tion” techniques [3]. These route optimization techniques work on relatively short timescales and target multi-homed ASes. Theirprinciple is to find, based on active and passive measurements, the“best” route to attain a destination or/and to be attained by externalhosts. These techniques work on timescales in the order of a round-trip time or more and adapt the traffic flow to the current condi-tions of the network, i.e. they try to find the best upstream providerto send or receive traffic. Their objective is often to optimize the“instantaneous” QoS experienced by the traffic, by measuring the  “quality” of the routes available from the upstream providers andtrying to choose the best upstream in real time. From our knowl-edge, no paper in the literature has evaluated nor described howthese techniques exactly achieve their goals. We are only awareof [23] that proposes a method to engineer the outbound interdo-main traffic for stub-ASes by tweaking the local-pref attributeof BGP routes and [9] that discusses the predictability of the BGProutes for outbound traffic engineering. Interdomain traffic engi-neering is still in its infancy. Understanding the dynamics of theinterdomain traffic and the relationships between the topology of the traffic and BGP peering relationships is absolutely necessary todo it properly [4].The control of the outgoing traffic with BGP is based on the se-lection of the best route among the available ones. This selectioncan be performed on the basis of various parameters, but it is lim-ited by the diversity of the routes received from upstream providerswhich depends on the connectivity and the policy of these ASes.The control of the incoming traffic is based on a careful tuning of the advertisements sent by an AS. This tuning has however severaldrawbacks. First, an AS that advertises more specific prefixes ordivides its address space in distinct prefixes to announce them se-lectively will advertise a number of prefixes larger than required.All these prefixes will be propagated throughout the global Internetand will increase the size of the BGP routing tables of potentiallyall ASes in the Internet. [6] reports that more specific routes con-stitute more than half of the entries in a BGP table. Faced withthis increase of their BGP routing tables, several large ISPs havestarted to install filters to ignore BGP advertisements correspond-ing to more specific prefixes. The deployment of those filters im-plies that the more specific prefixes will not be announced by thoselarge ISPs and thus the technique will become much less effective.Details concerning interdomain traffic engineering with BGP canbe found in [15].Fromaninterdomaintrafficperspective, not muchisknown abouthow the traffic that leaves or enters a stub AS, nor how the topolog-ical distribution of this traffic varies with time. The implications of traffic engineering on the trafficpattern on the Internet topology arelargely unknown, mostly because the topological properties of thetrafficpattern arethemselves not known. In this paper, we study theaggregation of the traffic on the AS-level topology and its dynam-ics, to understand its implications on the feasibility of interdomaintraffic engineering. Contrary to [16, 18, 17, 13] that focus on asubset of the applications in the whole traffic, our goal is to studythe dynamics of all traffic sent by stub ASes, independently of theunderlying applications. This paper focuses on stub ASes becausethey constitute the vast majority of all ASes [20, 2].The structure of the paper is the following. In section 2 we ex-plain the context of the paper. In section 3 we present the traffictraces on which we rely. Section 4 then studies the stability of the BGP routing for the interdomain traffic. Section 5 analyzesthe topological properties of the interdomain traffic over the wholetraces while section 6 looks at the hourly dynamics of the traffic onthe interdomain topology. Finally, section 7 discusses the implica-tions of our study on traffic engineering. 2. STUDYINGTHEINTERDOMAINTOPOL-OGY Inorder tounderstand thetopological distributionof interdomaintraffic we rely on an AS-level graph. This graph is built from theAS path information contained in the BGP advertisements receivedby the studied stub ASes. More precisely, each AS is one node of the interdomain graph and an edge correspond to the peerings be-tween two ASes. A node of our AS-level graph may correspondto several distinct prefixes. For example, the node correspondingto a large provider will correspond to the domain of this providerand to several of its smaller clients that do not have an AS number.Furthermore, an edge in the interdomain graph may correspond toseveral distinct physical links or peerings. Since BGP only adver-tisesone pathtoeach destination, theconsidered interdomain graphdoes not show all interconnections between domains.On this interdomain graph, we are interested in the paths fol-lowed by IP packets sent by the monitored stub AS to the globalInternet. Those paths are the one selected by the BGP decisionprocess [19] based on the advertisements received from each of itsBGP peers. Since BGP is a dynamic routing protocol, these pathsmay change with time. Furthermore, since an AS may advertiseseveral prefixes and the AS Path information is associated with oneprefix, there might be several distinct paths between the studiedstub AS and a given destination AS.In this paper, we call an “edge” an AS pair appearing as twoconsecutive and distinct ASes in the AS path of the  best BGP route for some traffic destination. With the BGP routes, we know howthe interdomain traffic gets forwarded across the AS-level topologywithout respect tophysical linksor multiplepeering points betweentwo ASes. With the AS path information of the BGP routes, only“edges” of the AS-level topology are known. An example will bet-ter illustrate this notion of an “edge”. In the left part of Figure 1,the stub AS (AS A) has two BGP peers (AS B and AS C) and eachBGP peer announces one route towards each of the two destinationASes (AS F and AS G). In this topology, the stub AS receives tworoutes towards destination AS F from its two peers. The route ad-vertised by peer 1 has AS path  B-F   while the route advertised bypeer 2 has AS path  C-B-F  . Assuming that the stub chooses as itsbest route towards AS F the route advertised by AS B having theshortest AS path, we have two edges in the interdomain topologyfor this AS path, namely edge    A,B   and edge    B,F   . Our stubAS receives two routes for destination AS 2 having the same ASpath length of 3 from its two peers,  B-D-G  for peer 1 and  C-E-G from peer 2. If we also assume that our stub chooses the route ad-vertised by peer 2 we have three new edges;    A,C   ,    C,E   and   E,G   . Figure 1: Example AS-level topology. In the AS-level graph, we are interested in studying and under-standing the topological distribution of the interdomain traffic. Forthis, we need to associate each “edge” with the amount of traffic it  carries. We thus count all network traffic that transits between twoASes connected by that edge. An edge does not represent a physi-cal link or a single peering between two ASes, but all peerings be-tween two ASes. From a topological characterization perspective,“edges” represent an aggregate of links or peerings. From a traf-fic engineering perspective on the other hand, “edges” represent ameaningful traffic aggregate that could be controlled through BGPtweaking like AS path prepending, MED, or redistribution commu-nities [15]. 3. DATA In this paper, we rely on two traffic traces along with the as-sociated BGP routing information. The first trace is a one entiremonth trace of the outbound traffic from the University of Louvain.The BGP data was gathered from a session established with the as-sociated network provider, BELNET. A literature review indicatesthat the length of this trace and its continuous nature make it no-table. The second trace, mainly used for validation purposes, wasgathered from the PittsburghSupercomputing Center and covers 24hours of the outbound commodity traffic. Its BGP information wasgathered from an on-site route server.Given that the aim of this paper is to study macroscopic proper-ties of interdomain traffic the decision was made to use a granular-ity of one hour for the timescale. This also has a practical consid-eration in that for a trace of one month duration a finer granularitywould prove to be unworkably cumbersome. 3.1 The UCL trace The primary data set used is a month long trace of all the out-bound traffic from the University of Louvain, Belgium, betweenMarch    2003 0:00 and April    2003 23:59 CET. Duringthis period 8.4 terabytes of traffic were observed with an averagebit rate of 25.1 Mbps. The University’s connectivity is a heavilyloaded full duplex fast Ethernet linkto thenetwork service providerBELNET. We are not aware of analyses of such long and detailedtraffic traces in the literature.ThemajorityoftheUniversity’suser baseconsistsofabout 25,000students and 5000 staff and faculty members using theinternal Uni-versity network of 10 Mbps and 100 Mbps Ethernet links. The Uni-versity also provides ADSL and cable modem access to some stu-dents and staff. The University’s Internet connectivity is providedby the Belgian research network, BELNET which is connected totwo tier-1 providers and the European research network GEANT,in addition to more than 100 peers at several interconnection points(BNIX, AMS-IX, SFINX). The internal network of BELNET con-sists of all Belgian universities and research institutions, linked bya 2.5 Gbps star configuration between its main routers in Brus-sels and at each University. BELNET did not perform any kindof traffic engineering on its commercial providers but relied on theshortest AS path towards each destination during the time periodof the trace. All academic traffic was sent and received through theGEANT network. A limit of 45 Mbps was enforced by BELNETfor commodity traffic in the incoming direction only, and no trafficlimitation was applied for traffic among the BELNET sites nor fortraffic exchanged through the GEANT network. 3.2 The PSC trace The Pittsburgh Supercomputing Center (PSC) is a regional ag-gregation point of presence located in western Pennsylvania, USA.PSC provides commodity and Internet2 access to local universitiesand organizations including Carnegie Mellon University, The Uni-versity of Pittsburgh, Pennsylvania State University, West VirginiaUniversity, The City of Pittsburgh, etc. Currently PSC has a maxi-mum capacity of 395 Mbps of commodity access though AT&T at145 Mbps and Verio with 250 Mbps via an OC-12. Furthermore,PSC has a full OC-48 of Internet2 connectivity through the Abilenenetwork. The user community consists of approximately 100,000students and an additional 25,000 faculty and staff members.The PSC trace used in this study is composed of all outboundcommodity traffic from 8:47 AM 18 April 2003 to 8:45 AM 19April 2003. During this period 1.7 terabytes of traffic were ob-served for an average rate of 164 Mbps. 4. STABILITY OF THE INTERDOMAINPATHS Any study of the topological properties of Internet traffic de-pends on the premise that the interdomain topology advertised byBGP itself be stable. Therefore we first need to explore the stabilityof the AS paths of the BGP routes. To do this we rely exclusivelyon the traces and BGP data collected from UCL. The month longtrace provides the necessary depth of information which the PSCtrace of 24 hours simply cannot.First we look at how long AS paths were seen in the BGP table.The top part of Figure 2 compares the number of days distinct ASpaths were seen, for all AS paths as well as AS paths that saw atleast one byte of data over that month. During this period 103,853distinct AS paths were seen in the BGP advertisements but only31,151 carried any traffic at all. Due to BGP dynamics more thanfifty percent of the distinct AS paths were present in the BGP rout-ing table for less than nine minutes. On the other hand, more than42 percent of the AS paths over which traffic was sent were foundintheBGProutingtablefor99 percent of thedurationof themonth.These stable AS paths having traffic represented slightly more than13 percent of all AS paths seen over the month. These results aresimilar to [16] where it was shown that most BGP update eventsoccur for a small fraction of the prefixes. [24] also showed thatthe primary AS path for a DNS A root server lasted for long timeperiods.The top part of Figure 2 provides an overview of the stability of theASpathsbut withoutrespect tothetraffictheysee. Whenstudy-ing the traffic, we are interested in whether the AS paths whichcarry the majority of the traffic are stable or not, AS paths that donot carry traffic are irrelevant. The bottom part of Figure 2 com-pares the longevity in presence of the AS paths and their associatedtraffic over time. We define “presence” as the number of secondsduring which an AS path was found among the BGP best routesover the one month of the trace. The curve labeled “AS paths” onthe right part of Figure 2 gives the percentage of the total time ASpaths were present in the BGP routing table. The curve labeled“traffic” shows the percentage of traffic for AS paths present formore than some percentage of the one month trace period. The lat-ter curve shows that more than 95 percent of the total traffic wascarried by AS paths that were present in the BGP routing tablemore than 99 percent of the time. In contrast, only 42 percent of the AS paths having traffic were present for more than 99 percentof the time in the BGP routing table. The prefixes for the largestfraction of the traffic of our stub AS have a single AS path that lastsfor more than 99 percent of the one month period of our trace. Ourresults are similar to those of [16] that showed that the prefixes as-sociated with popular web sites for AT&T traffic had stable BGProutes. Our results however are more precise and detailed than [16]since we consider the routing stability of all the interdomain traffic,not a subset of the prefixes.BGP hence does not significantly interfere with the traffic dy-namics. The interdomain topology used to carry outbound traffic  050001000015000200002500030000350004000045000500000.010.1110    #   d   i  s   t   i  n  c   t   A   S  p  a   t   h  s   h  a  v   i  n  g   l   i   f  e   t   i  m  e  >  x AS paths lifetime [days]AS path stability over 1 monthAll AS pathsAS paths with traffic020406080100051015202530020406080100    %   o   f   A   S  p  a   t   h   h  a  v   i  n  g   t  r  a   f   f   i  c   T  r  a   f   f   i  c  p  e  r  c  e  n   t  a  g  e AS path lifetime [days]AS path stability for traffic over 1 monthtrafficAS paths Figure 2: Stability of AS paths: without traffic (top) and withtraffic (bottom). can thus be considered as stable even over a long time period asone month. 5. TOPOLOGICAL TRAFFIC AGGREGA-TION Before looking at the dynamics of the traffic on the AS-leveltopology, it is good to build an understanding of how the trafficgets aggregated on the AS-level topology, given that the whole AS-level graph visible from BGP routing tables contains about 15,000ASes and more than 30,000 edges. The definition of an “edge”serves this particular purpose. In interdomain traffic engineering,a primary concern is the size of the interdomain topology for themajority of the traffic. Note that the AS-level topology where onlyedges that saw traffic are considered can be seen as a tree rooted atthe traffic capture point and whose leaves are the destination ASesof the traffic.We begin with how much traffic edges see for each AS hop dis-tance. This viewpoint will show us how many edges we need ateach AS hop distance to influence some percentage of the total traf-fic. Figure 3 provides the cumulative traffic percentage carried byedges at each AS hop distance. So we take all edges at some AShop distance and count how many bytes have been carried by theseedges. We then sort the edges at thisAS hop distance by decreasingbyte count and plot the cumulative percentage of traffic carried bythe largest    edges at this AS hop distance from the local AS. Thecurves for an AS hop distance of one on Figure 3 illustrate the main 1020304050607080901001101001000    P  e  r  c  e  n   t  a  g  e  o   f   t  o   t  a   l   t  r  a   f   f   i  c Number of edgesCumulative traffic percentage for edges (UCL)AS hop distance = 1AS hop distance = 2AS hop distance = 301020304050607080901001101001000    P  e  r  c  e  n   t  a  g  e  o   f   t  o   t  a   l   t  r  a   f   f   i  c Number of edgesCumulative traffic percentage for edges (PSC)AS hop distance = 1AS hop distance = 2AS hop distance = 3 Figure 3: Cumulative traffic captured by edges : UCL (top)PSC (bottom)). difference between UCL and PSC. The largest direct peer of UCL’sprovider sees only a littlemore than forty percent of thetotal traffic,while the largest peer of PSC sees a little less than eighty percent of the total traffic. UCL’s provider has many direct peers with whomit exchanges traffic at local interconnection points. The PSC traceon the other hand shows that the two largest direct peers see allthe traffic, simply because the PSC trace contains only commoditytraffic that is sent through its commercial providers.The curves for an AS hop distance of two and three provide uswith the interesting information about traffic aggregation on theAS-level topology. Obviously, traffic aggregation occurs on theedges with the direct peers. However, traffic aggregation on edgesis desirable farther in the topology because trafficengineering tech-niques are due to perform finer operations than moving all the traf-fic from one direct peer to another. Traffic engineering will haveto work on traffic aggregates to allow an AS to control the amountof traffic that crosses the links with its direct peers. This is whyit is important to know how traffic is split a few AS hops away inthe AS-level topology. Figure 3 tells us that if we were to influ-ence the largest ten edges at two AS hops, then we would be ableto control about 35 percent of the total traffic for UCL and a lit-tle less than 60 percent for PSC. This information is relevant fortraffic engineering since we would be able to influence a large frac-tion of the total traffic by tweaking a few edges. If one wants toperform fine-grained inbound traffic engineering, relying on edgesat two AS hops or more will be necessary to control sufficientlysmall traffic aggregates because traffic aggregation is too important  on the links with the direct peers. This means that we would thenneed to tweak a larger number of edges due to the lack of trafficaggregation beyond direct peers. Although a few edges at two orthree AS hops may allow to influence a large fraction of the traf-fic, we know that inbound traffic engineering will not always work due to local policies applied by other ASes. The topological anal-ysis of the traffic hence provides an overly optimistic view of thefeasibility of interdomain traffic engineering. 6. SHORT-TERM STABILITY OF INTER-DOMAIN TRAFFIC Theprevious sectionsexamined thepropertiesof thetraffic-awareinterdomain topology over the entire temporal length of the mea-surements. Another important issue is the stability of the trafficover smaller timescales. If its distribution is stable, then it shouldbe possible to engineer it. Otherwise, this will be more difficult.Therefore in this section we outline the connection between thelarge timescale features of the traffic-aware interdomain topologypreviously discussed and a smaller timescale of one hour granular-ity. The analysis in this section is based solely on the UCL datasetwhileusing the PSCdataset for confirmation of our results. Inaddi-tion, we rely solely on traffic carried by AS paths in the remainderof the paper because of the limited traffic aggregation occurringfor the edges of the AS-level topology. Given that few distinct ASpaths get aggregated on a given edge, the dynamics of the AS pathsissimilar tothe one of the edges (wedo not show thecorrespondingfigures due to space limitations). 6.1 Short-term evolution of top AS paths In this section, we analyze the evolution with time of what wecall thetop ASpaths. The“top ASpaths” arenothing more than theASpathsweightedbythetraffictheycarryandsortedbydecreasingamount of traffic over the considered time period (month or hour inour case). For instance, thetop fiftypercent ASpaths for some hourarethetop ASpathsthat capture fiftypercent of thetotal trafficoverthat particular hour.Figure 4 shows the hourly evolution of the number of AS pathspresent in the top    percent AS paths for 4 different values of     . Tocreate this graph we computed the amount of traffic seen by eachAS path for each hour, sorted them by decreasing amount of the to-tal traffic, computed the cumulative traffic distribution and finallyplotted the hourly evolution of the number of AS paths for variousvalues of the trafficpercentage every hour. Each point of the curvesshows how many AS paths are necessary to carry an arbitrary per-centage of the total traffic during a given hour. The hourly evolu-tion of the number of AS paths for the traffic percentage followsa daily periodicity similar to the one of the total traffic evolution.The larger number of AS paths seen during the busiest hours of theday is likely to be due to a larger number of IP addresses. Note thatfor fifty percent of the hourly traffic, this daily periodicity is lessevident because the number of AS paths is small.The use of a logarithmic scale for the y-axis on Figure 4 reducesthe visual importance of the dramatic increase in the number of AS paths needed as the percentage of traffic increases. Capturingfifty percent of the traffic every hour requires between five and tenAS paths, while ninety percent requires one hundred AS paths, andcapturing all thetrafficdemands asmany asfivethousand ASpaths.These numbers are to be compared with the number of AS pathsthat capture the same percentages of traffic over the whole month:17 for fifty percent, 332 for ninety percent, 1923 for ninety-ninepercent, and 31,150 for one hundred percent. The largest hourlyAS paths thus are fewer in number than monthly ones, indicating 110100100010000100000051015202530    N  u  m   b  e  r  o   f   A   S  p  a   t   h  s Time [days]Number of hourly AS paths for traffic percentage100%99%90%50% Figure 4: Hourly evolution of the number of top AS paths. that it should be easier to engineer some percentage of the totaltraffic on a hourly basis. This statement however does not takeinto account whether the important AS paths change a lot from onehour to another. If the important AS paths are stable in time, thenperforming traffic engineering on small timescales is feasible. If they are not stable, traffic engineering can be difficult. 6.2 Presence of short-term top AS paths Thissectionstudiesfor how much timemost ASpathsareamongthe hourly top AS paths. For this, we compute for each hour the topninety percent AS paths and count how many times the AS pathsreappear in the top ninety percent over the length of the trace.Figure 5 counts the number of hours over the month that eachAS path appears in the hourly top 90 % (top of Figure 5) and top50 % AS paths (bottom of Figure 5). We also compute for eachof these AS paths the amount of traffic it captures during the hoursit is among these top AS paths. The curve labeled “AS paths per-centage” gives the cumulative percentage of the AS paths whichhave ever appeared among the top AS paths in terms of the num-ber of hours it was present, hence the name “presence”. The othercurve labeled “traffic percentage”, gives the corresponding cumula-tive percentage of the total traffic carried by the previous AS pathsduring a given number of hours over the month.A total of 2139 AS paths were seen among the hourly top 90 %AS paths. This is much more than the 332 AS paths capturing 90% of the traffic over the one month, indicating that there is muchturnover among the hourly AS paths. 626 of them were seen onlyonce while just six were seen during all time periods. The curvelabeled “AS paths percentage” shows that most AS paths were seenfor a small fraction of the time. More than 96 percent of these ASpaths were seen for less than one third of the time and representabout twenty percent of the total traffic during the whole month.Additionally, 50 % of the total traffic appears for AS paths seenamong the hourly top 90 % for about 80 % of the time. The six ASpaths that are present during all time periods carry about 36 % of the total traffic which is a significant portion. However, more than20 % of the traffic appears for AS paths that are seen in less thanone third of the time periods during the month. This leaves about25 % of the traffic being carried by AS paths that are not entirelystable.The relatively limited presence of the top 90 % AS paths mightbe due to the fact that most of them carry too limited an amount of traffic. The presence of larger AS paths might be better than what


Apr 29, 2018

Indra knooyi

Apr 29, 2018
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!