130 likes | 227 Vues
Explore open challenges in network tomography for internet infrastructure analysis, focusing on loss and delay measurements, inference methodologies, and application complexities. Delve into the unique characteristics and problems of end-to-end network analysis.
E N D
Network Tomography for the Internet: Open Problems D. Towsley U. Massachusetts
LOSS % Delay LOSS% 1 2 3 4 5 6 1 2 3 4 5 6 4 5 6 Avg. Delay 4 5 6 Infrastructure (NIMI) 6 6 1 1 cross section view composition of views cross section view ? 2 2 4 4 3 3 5 5 Avg. Delay LOSS % 1 2 3 1 2 3 Network Tomography: I Goal: obtain spatio-temporal picture of a network/internet from end-to-end views ?
Rationale Why? • network management: bottlenecks/faults • agreement verification • adaptive applications: loss, delay, shared point of congestion Why not query routers? • 1000s of autonomous systems • 100,000s routers • need special privileges • router info not always complete
a1 a2 a3 1 0 1 1 1 0 loss rates ^ ^ ^ a1, a2, a3 Example: MINC source Uses end-end observations to peer inside network • multicast probes • correlated performance observed by receivers • exploit correlation to estimate link behavior • loss rates • delay statistics receivers
Inference Methodology (Losses) • model • known multicast tree topology • independent Bernoulli processes across all links with unknown loss prob. {ak } • methodology • maximum likelihood estimates for {ak} • extensions • link delays • topology inference
Open Problems • data massaging • delay measurements exhibit many artifacts • scalability • robustness to missing data • layout/composition of views • use (partial) information from network Characteristic of any approach
The Real Internet • most traffic is point-point • point-to-point behavior verydifferent frommulticast behavior Q: how to infer internal network behavior from point-to-point measurements? • introduce correlation • exploit correlation
Network Tomography: II Goal: obtain detailed picture of end-end behavior from internal views • network design From internal observations, infer • end-end application-level behavior • traffic flows • workload characterization
Traffic Analysis Many applications have well known protocol/port (in packet header) 21 - ftp, 23 - telnet, 80 - http Some dynamically select ports napster games denial of service attack
Ftp Traffic courtesy of kc claffy@CAIDA
Napster: until recently courtesy of kc claffy@CAIDA
user 1 napster server trace collector user 2 Challenges • application signatures • napster • signaling/data transfer pattern? • games • denial of service attack signatures
observations internal end-end views internal end-end Summary • theory needed to make this happen • correlation, correlation! • scalability, scalability! • robustness, robustness! Work with a networking specialist