Internet Simulations:Issues in Defining the Model

Sally FloydNetwork Research Group, Lawrence Berkeley National Laboratoryhttp://www-nrg.ee.lbl.gov/floyd/

DIMACS Workshop on End-to-End Network Modeling and Simulations

October 23-24, 1997

Credits are due to many other people, most notably to Deborah Estrin...

1

Overview of the talk:

� What are the problems in defining models in Internet research/simulations?

� Examples from my own research.

� Interspersed suggestions of (and requests for) tools that would help.

2

Defining the model: what is the problem?

� What level of detail or abstraction is appropriate?

� How to model a rapidly-changing world (that is changing in ways thatare hard to predict)?

� What to model in a world of great heterogeneity (of underlying tech-nologies, link bandwidth and propogation delay, levels of congestion, pro-tocols, router scheduling and queue management mechanisms, etc.)

� How to handle issues of scale?

� Sensitivity to small changes in parameters of the model.

3

Propositions:

� Choosing the appropriate model is one of the key steps in a networkresearch project.Corollary: One of the criteria for evaluating work is the appropriateness ofthe problem definition and of the models chosen.Corollary: The relationship between defining the model and simulating/analysisis two-way.

� Better tools can make this easier: richer tools and models for topol-ogy generation and traffic generation, tools for visualization of research-in-progress, tools for more explicitly varying the level of detail or abstraction,discussion in the network research community, etc.

� There are plenty of challenging and important questions of scale to ad-dress in network research. These will stress our modeling and simulationtools. (There are presumably also challenging and important questionsthat are not about issues of scale?)

4

Level of detail: TCP's retransmit timers

� The issue:The dynamics of TCP over ATM in an environment with non-negligablecell losses. [Romanow 1995].

� The question:Do we mostly care about the behavior of current implementations of TCP,including the limitations imposed by the coarse clock granularities? Or dowe mostly care about the fundamental properties of the underlying algo-rithms?

� Answer:It depends on the goal of that particular research.

5

Modeling a changing world: Reno TCP's unnecessary retransmit time-outs

� The issue:Reno TCP has a problem with unnecessary retransmit timeouts when mul-tiple packets are dropped from a window of data.SACK TCP and NewReno TCP do not have this problem. [Fall 1996].

� The question:Are we in danger of designing future networks (e.g., rate control algo-rithms for ABR service in ATM networks) tuned to the performance detailsof 1990 implementations of Reno TCP?

6

Modeling a changing world: traffic modeling

� The issue:Measurement-based admissions control algorithms for realtime traffic withQoS requirements.

� The question of traffic mix:Is the realtime traffic all MPEG video?All two-way audio?Or a mix that includes reliable multicast, n-way audio, multi-player games,distributed simulations, etc.

7

Traffic modeling: small audioconferences have different traffic pat-terns than two-way audio:

July 16, 1995Time (in Seconds)

Pac

kets

per

10-

seco

nd B

in

0 5000 10000 15000

050

010

0015

0020

0025

0030

00

Six members, each with a peak rate of 64 Kbps. [Floyd 1996].

8

Measurement-based admissions control: more questions

� The mix between realtime and non-realtime traffic:Is the realtime traffic allocated 100% or only 10% of the link bandwidth?

� Network questions:What is the context: IETF's guaranteed service, controlled-load service,or predictive service (which is no longer standards-track)?Another proposed Internet service? ATM?

� Application-level questions:Does the realtime traffic have adaptive playback times, coding to maximizeloss tolerance, and adaptive congestion control, or not?

9

Measurement-based admissions control: better tools can help.

� Libraries and models of traffic generators for a wide range of traffic types.

� Higher-level procedures for generating a rich traffic mix in a simulation.

� A simulator that includes new models for realtime services, new pro-posals for admissions control algorithms, and new models for adaptivecongestion control for realtime traffic, so that researchers can explore howthese various proposals interact with each other (and with other proposalsfor new multicast routing algorithms, new queue management algorithms,etc.)

10

Modeling a changing world: general questions.

� Topologies:Single backbone? Multiple ISPs? Congested transoceanic links?

� Underlying technologies:Multiaccess links? Wireless? Satellite? ATM clouds?

� Router functionality:Scheduling mechanisms? Queue management? Multicast routing algo-rithms?

� Pricing structures?

11

Issues of topology and of scale: Scalable Reliable Multicast.

� Session members in SRM use randomized algorithms for multicasting“requests” for missing data, and for multicasting “repairs” if they have therequested data. [Floyd 1995].

� But the results are very different for topologies of random labeled treesthat only include session members, and for sessions embedded in topolo-gies that are bounded-degree trees of degree four, with 1000 nodes.

12

SRM: results for the request/repair algorithms with fixed parameters.

� Random labeled graphs, all nodes are session members:

Session Size

Num

ber

of R

epai

rs

20 40 60 80 100

05

1015

20

.................... .................... .................... ....................

.................... .................... .................... .................... ...................

. ....................

� Bounded-degree trees of degree four, 1000 nodes:

Session Size

Num

ber

of R

epai

rs

20 40 60 80 100

05

1015

20

......

.

.

...

.........

......

...

..........

.

......

..

..

..

...

..

..

.

.....

.....

....

.

.

...

.

........

...........

.

......

...

...

.

.

....

.

.

.....

......

..

.

..

...

.

.........

......

.

.

.

..

.......

.............

....................

(The request/repair algorithms with adaptive parameters perform muchbetter in this environment than the algorithms with fixed parameters.)

13

Issues of topology and of scale: Scalable Session Messages in SRM.

Local Member

Global Member

Local Session Message

Global Session Message

Local Session Message

� Instead of all members sending periodic session messages with globalscope, only “global representatives” send global session messages, andall members send local session messages. [Sharma 1997].

14

67

63 59

60

61

6264

65

6668

69

7071

72

73

7475

76

54

76

17

20

23

25

2426

16

18

22

2119

30

33

32

31 3428

27

35

29

80

7778

79

81

82 83

84

85

86

88

87

8990

91

95

949392

969798

99 3

1 2

0

47

42

43

45

48

46

44

53

49

51

50

52

5455

56

57

58

8

12

9

11

10

13

14

15

38

39

36

41

37

40

12 12

12

9393

93

93

40

40

40

45

45

45

51

51

51

58

61

61

61

6161

73

73

73

85

85

89

30

30

30

30

30

22

16

SESSION MEMBER

REPRESENTATIVE

2316

23

16

Scalable Session Messages:

� Issues of scale.

� Topology generation.� Visualization tools?

15

Issues of topology and of scale: Reliable Multicast.

� Analysis of a complex scenario is generally intractable.

� Simulations need to include moderate-to-large multicast groups in aconsiderably-larger topology.

� Simulation results can be very sensitive to the underlying topology, sotopology generation is an increasingly-important issue.

� We need visualization tools for large topologies that help us to developintuition and understand the dynamics of the simulations.

16

Issues of topology and of scale: Adaptive Web Caching.

� A global data dissemination architecture: Web caches organize them-selves into overlapping multicast groups. Web caches exchange informa-tion among themselves, and determine the most appropriate forwardingpath for each request. [Zhang 1997].

user−1

user−2

origin−server

G1

G2

G3

G4

G5

G6G7

C1

C2

C3

C4C5

C6

C7

17

Issues of topology and of scale: Adaptive Web Caching.

� Topology:Probably the critical element of the underlying topology is that it consist ofcontinents separated by congested high-delay inter-continental links. (Inaddition, the web servers are not evenly distributed among the continents.)

� Scale:One question for a proposed mechanism should be at what scale doesthat mechanism begin to break down.But how does one investigate in simulations a proposal for a global datadissemination architecture?

18

References (all available from http://www-nrg.ee.lbl.gov/floyd/):

[Fall 1996]: Fall, K., and Floyd, S., Simulation-based Comparisons ofTahoe, Reno, and SACK TCP, Computer Communication Review, V. 26N. 3, July 1996.

[Floyd 1996]: Floyd, S., Comments on Measurement-based AdmissionsControl for Controlled-Load Services, July 1996.

[Floyd 1995]: Floyd, S., Jacobson, V., Liu, C., McCanne, S., and Zhang, L.,A Reliable Multicast Framework for Light-weight Sessions and ApplicationLevel Framing. SIGCOMM '95. To appear in Transactions on Networking.

[Romanow 1995]: Romanow, A., and Floyd, S., Dynamics of TCP Trafficover ATM Networks. IEEE JSAC, V. 13 N. 4, May 1995.

[Sharma 1997]: Sharma, P., Estrin, D., Floyd, S., and Zhang, L., ScalableSession Messages in SRM, August 1997, in submission.

19

References (continued):

[Zhang 1997]: Zhang, L,. Floyd, S., and Jacobson, V., Adaptive WebCaching, February 1997 proposal.

20

Wish list:

� Vint/ns and similar projects.

� Topology generators based on continents.

� Visualization tools.

21