<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: [e2e] GRID Network Research</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Hi Jon</FONT>
</P>
<P><FONT SIZE=2> What GRID stands for and what is its web site ?</FONT>
</P>
<P><FONT SIZE=2> Hesham</FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Jon Crowcroft [<A HREF="mailto:Jon.Crowcroft@cl.cam.ac.uk">mailto:Jon.Crowcroft@cl.cam.ac.uk</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, May 08, 2002 9:11 AM</FONT>
<BR><FONT SIZE=2>To: end2end-interest@postel.org</FONT>
<BR><FONT SIZE=2>Subject: [e2e] GRID Network Research</FONT>
</P>
<BR>
<BR>
<BR>
<P><FONT SIZE=2>the GGF (see usal web site) are interested in inpout on this:</FONT>
<BR><FONT SIZE=2>(we will also generate a doc about the 10 things grid people wish</FONT>
<BR><FONT SIZE=2>network people knew!)</FONT>
</P>
<P><FONT SIZE=2>comments to me!</FONT>
</P>
<P><FONT SIZE=2> cheers</FONT>
</P>
<P><FONT SIZE=2> jon</FONT>
</P>
<BR>
<P><FONT SIZE=2>Outline Draft for:</FONT>
<BR><FONT SIZE=2>Top ten things network engineers wish grid programmers knew</FONT>
</P>
<P><FONT SIZE=2>TBA:</FONT>
<BR><FONT SIZE=2>Top ten things grid programmers wish network engineers knew </FONT>
</P>
<P><FONT SIZE=2>Jon Crowcroft et al...26/4/2002</FONT>
</P>
<P><FONT SIZE=2>Abstract </FONT>
</P>
<P><FONT SIZE=2>This is a draft contribution for a document for the GHPNRG </FONT>
<BR><FONT SIZE=2>(see <A HREF="http://www.cs.wm.edu/~lowekamp/ghpnrg.html" TARGET="_blank">http://www.cs.wm.edu/~lowekamp/ghpnrg.html</A></FONT>
<BR><FONT SIZE=2>amongst other places)</FONT>
<BR><FONT SIZE=2>which is meant to list topics that the network community is</FONT>
<BR><FONT SIZE=2>working on and is sometimes asked alarming questions about by</FONT>
<BR><FONT SIZE=2>folks who make intensive (and quite well educated) use of</FONT>
<BR><FONT SIZE=2>networks, such as Global GRID Forum people.</FONT>
</P>
<P><FONT SIZE=2>It is currently a list of topics and references. I might expand</FONT>
<BR><FONT SIZE=2>the list, and it certainly needs lots of explanatory text. It</FONT>
<BR><FONT SIZE=2>might be neat of this was from the GNT!.</FONT>
</P>
<BR>
<P><FONT SIZE=2>1/ Congestion Control (contrariwise: see QoS)</FONT>
</P>
<P><FONT SIZE=2>Slow Start</FONT>
<BR> <FONT SIZE=2>is this always necessary? no, but beware of ISPs who</FONT>
<BR><FONT SIZE=2>mandate it, and if you think you can use less than recent history rather</FONT>
<BR><FONT SIZE=2>than recent measurements, look at the Congestion Manager and TCP</FONT>
<BR><FONT SIZE=2>PCB state shearing work first!</FONT>
</P>
<P><FONT SIZE=2>Congestion Control</FONT>
</P>
<P> <FONT SIZE=2>This is not optional in a non QoS network (which is just</FONT>
<BR><FONT SIZE=2>about any network) - adaption is mandatory</FONT>
</P>
<P><FONT SIZE=2>AIMD and Equation Based</FONT>
</P>
<P> <FONT SIZE=2>AIMD is not the only solution to a fair, convergent</FONT>
<BR> <FONT SIZE=2>control rule for congestion avoidance and control. Other</FONT>
<BR> <FONT SIZE=2>solution are around - Rate based, using loss, or ECN feedback,</FONT>
<BR> <FONT SIZE=2>can work to be TCP fair, but not generate the characteristic Saw</FONT>
<BR> <FONT SIZE=2>Tooth.</FONT>
</P>
<P> <FONT SIZE=2>Assumptions and errors</FONT>
<BR> <FONT SIZE=2>Most _connections_ do not behave like the Padhye</FONT>
<BR> <FONT SIZE=2>equation, but most bytes are shipped on a small number of</FONT>
<BR> <FONT SIZE=2>connections , and do - c.f. Mice and Elephants.</FONT>
</P>
<P> <FONT SIZE=2>The jury is still out on whether there are non greedy TCP flows</FONT>
<BR> <FONT SIZE=2>(ones who do not have infinite sources of data at any moment)</FONT>
</P>
<P><FONT SIZE=2>RMT and Unicast</FONT>
</P>
<P> <FONT SIZE=2>Reliable Multicast Transport protocols (PGM, ALC) use</FONT>
<BR> <FONT SIZE=2>a variety of techniques to mimic TCP mainly.</FONT>
</P>
<P><FONT SIZE=2>Mobile and Congestion Control</FONT>
<BR> <FONT SIZE=2>Mobile nodes experience temporary indications of </FONT>
<BR> <FONT SIZE=2>loss AND congestion</FONT>
<BR> <FONT SIZE=2>during a hand-off. People have proposed mechanisms for</FONT>
<BR> <FONT SIZE=2>indicating whether these are "true" or chimera.</FONT>
</P>
<P><FONT SIZE=2>Economics, Fairness etc</FONT>
</P>
<P> <FONT SIZE=2>Congestion control results in an approximately fair</FONT>
<BR> <FONT SIZE=2>distribution of bottleneck bandwidth - this may not be</FONT>
<BR> <FONT SIZE=2>great if you paid more to get a fat pipe to the net.</FONT>
<BR> <FONT SIZE=2>But, you are probably nearer the core and have </FONT>
<BR> <FONT SIZE=2>every right to ask the ISP to upgrade their bottlenecks anyhow</FONT>
<BR> <FONT SIZE=2>and the people that paid less should be bottlenecked at THEIR</FONT>
<BR> <FONT SIZE=2>access links in that case. So?</FONT>
</P>
<BR>
<P><FONT SIZE=2><A HREF="http://www.psc.edu/networking/tcp_friendly.html" TARGET="_blank">http://www.psc.edu/networking/tcp_friendly.html</A></FONT>
</P>
<P><FONT SIZE=2>2/ Routing</FONT>
</P>
<P><FONT SIZE=2>Priorities for good routing system design are:</FONT>
</P>
<P><FONT SIZE=2>Fast Forwarding</FONT>
<BR> <FONT SIZE=2>Packet classification and switched routers have come a</FONT>
<BR><FONT SIZE=2>long way recently - we are unlikely in the software world to beat</FONT>
<BR><FONT SIZE=2>the h/w in core routers, but we can compete nicely in access</FONT>
<BR><FONT SIZE=2>devices - certainly, there is no reason why a small cluster</FONT>
<BR><FONT SIZE=2>couldn;t make a good 10Gbps router - but there's every reason why</FONT>
<BR><FONT SIZE=2>a PCI bus machine maxes out at 1Gbps!</FONT>
</P>
<P><FONT SIZE=2>Faster Convergence</FONT>
</P>
<P> <FONT SIZE=2>Routers and links fail. the job of OSPF/ISIS and BGP is</FONT>
<BR><FONT SIZE=2>to find the alternate paths quickly - in reality they take a</FONT>
<BR><FONT SIZE=2>whole to converge - IGPs take a while (despite being mainly link</FONT>
<BR><FONT SIZE=2>state nowadays) because link failure detection is NOT obvious -</FONT>
<BR><FONT SIZE=2>sometimes you have to count missed HELLO packets (since some</FONT>
<BR><FONT SIZE=2>links don't generate an explicit clock). BGP convergence is a</FONT>
<BR><FONT SIZE=2>joke. But there are smart people on the case.</FONT>
</P>
<P><FONT SIZE=2>theory and practice</FONT>
</P>
<P><FONT SIZE=2>Most the problems with implementing routing protocols are those</FONT>
<BR><FONT SIZE=2>of classic distributed (p2p/autonomous) algorithms: dealing with</FONT>
<BR><FONT SIZE=2>bugs in other peoples implementations - it takes a good</FONT>
<BR><FONT SIZE=2>programmer about 3 months to do a full OSPF. It then takes around</FONT>
<BR><FONT SIZE=2>3 years to put in all the defences.</FONT>
</P>
<P><FONT SIZE=2>Better (multi-path, multi-metric) routing</FONT>
</P>
<P><FONT SIZE=2>equal cost Multipath OSPF and QOSPF </FONT>
<BR><FONT SIZE=2>have been dreamt up - are they used a lot? multipath in limited</FONT>
<BR><FONT SIZE=2>cases appears to work quite well. Multimetric relies on good</FONT>
<BR><FONT SIZE=2>understanding of traffic engineering and economics, and to date,</FONT>
<BR><FONT SIZE=2>hasn't seen the light of day. Note that also, in terrestrial tier</FONT>
<BR><FONT SIZE=2>one networks, end-to-end delays are approaching transmission</FONT>
<BR><FONT SIZE=2>delays, so asking for a delay (or jitter) bound is getting fairly</FONT>
<BR><FONT SIZE=2>pointless - asking for a throughput guarantee is a good idea, but</FONT>
<BR><FONT SIZE=2>doesn't need clever routing!</FONT>
</P>
<P><FONT SIZE=2>Does MPLS Help? No, not one bit. </FONT>
</P>
<P><FONT SIZE=2>Policies are hard - BGP allows one to express unilateral</FONT>
<BR><FONT SIZE=2>policies to the planet. this is cute (the same idea could be used</FONT>
<BR><FONT SIZE=2>for policy management of other resources like CPUs in the GRID)</FONT>
<BR><FONT SIZE=2>however, it results in difficulties in computing global choices</FONT>
<BR><FONT SIZE=2>(esp Multihoming) - there are fixes. </FONT>
</P>
<BR>
<P><FONT SIZE=2><A HREF="http://www.potaroo.net/" TARGET="_blank">http://www.potaroo.net/</A></FONT>
<BR><FONT SIZE=2><A HREF="http://www.telstra.net/gih" TARGET="_blank">http://www.telstra.net/gih</A></FONT>
<BR><FONT SIZE=2>NANOG</FONT>
</P>
<BR>
<P><FONT SIZE=2>3/ Packet Sizes</FONT>
</P>
<P><FONT SIZE=2>Go faster LANs have always pushed the MTU up - since ATM LANs</FONT>
<BR><FONT SIZE=2>(remember the fore asx100) we tried 9280 byte packets, and</FONT>
<BR><FONT SIZE=2>enjoyed things. But the GRID is global, so the MTU is that of the</FONT>
<BR><FONT SIZE=2>weakest link. Most stuff is on 100BaseT somewhere on the path</FONT>
<BR><FONT SIZE=2>so we aren't likely to see more than the occasional special case</FONT>
<BR><FONT SIZE=2>non 1500 byte path. However, with path MTU discovery, we get that</FONT>
<BR><FONT SIZE=2>auto-magically</FONT>
</P>
<P><FONT SIZE=2>Multicast MSS is a real problem:)</FONT>
</P>
<P><FONT SIZE=2>Sub-IP packet size is a consideration - some systems (ATM) break</FONT>
<BR><FONT SIZE=2>packets into tiny little pieces, then apply various level2</FONT>
<BR><FONT SIZE=2>schemes to these pieces (e.g. rate/congestion control) - most</FONT>
<BR><FONT SIZE=2>these are anathema to good performance.</FONT>
</P>
<BR>
<P><FONT SIZE=2><A HREF="http://www.nlanr.net/NA/Learn/packetsizes.html" TARGET="_blank">http://www.nlanr.net/NA/Learn/packetsizes.html</A></FONT>
<BR><FONT SIZE=2><A HREF="http://www.faqs.org/rfcs/rfc1191.html" TARGET="_blank">http://www.faqs.org/rfcs/rfc1191.html</A></FONT>
<BR><FONT SIZE=2>etc</FONT>
</P>
<P><FONT SIZE=2>4/ Overlays</FONT>
</P>
<P><FONT SIZE=2>Overlays and P2p (e.g. Pastry, CAN, Tapastry)</FONT>
<BR><FONT SIZE=2>are becoming commonplace - the routing overlay du jour is</FONT>
<BR><FONT SIZE=2>probably RON from MIT - these (at best) are an auto-magic way of</FONT>
<BR><FONT SIZE=2>configuring a set of Tunnels (IPinIP, GRE etc). I.e. they build</FONT>
<BR><FONT SIZE=2>you VPNs</FONT>
</P>
<P><FONT SIZE=2>P2P: are slightly different - they do content sharing and have</FONT>
<BR><FONT SIZE=2>cute index/search/replication strategies varying from</FONT>
<BR><FONT SIZE=2>mind-numbingly stupid (napster, gnutella) to very cute (CAN,</FONT>
<BR><FONT SIZE=2>Pastry). They have problems with</FONT>
<BR><FONT SIZE=2>Locality and Metrics so are not the tool for the job for low</FONT>
<BR><FONT SIZE=2>latency file access....in trying to mitigate this , they (and</FONT>
<BR><FONT SIZE=2>overlay routing substrates) use ping and pathchar to try to find</FONT>
<BR><FONT SIZE=2>proximal nodes:</FONT>
</P>
<P> <FONT SIZE=2>limitations of Ping/Pathchar</FONT>
<BR> <FONT SIZE=2>Convergence when not native (errors/confidence)</FONT>
</P>
<P><FONT SIZE=2>Peer-to-Peer Harnessing the Power of Disruptive Technologies</FONT>
<BR><FONT SIZE=2>Edited by Andy Oram, March 2001, 0-596-00110-X</FONT>
</P>
<P><FONT SIZE=2>5/ QoS (contrariwise: see Congestion Control)</FONT>
</P>
<P><FONT SIZE=2>QoS - would be a nice thing</FONT>
</P>
<P><FONT SIZE=2>Parameters typically include</FONT>
<BR> <FONT SIZE=2>Throughout</FONT>
<BR> <FONT SIZE=2>Delay</FONT>
<BR> <FONT SIZE=2>Availability</FONT>
<BR> <FONT SIZE=2>Some people add security/integrity</FONT>
<BR> <FONT SIZE=2>Some people also mention loss...</FONT>
</P>
<P><FONT SIZE=2>Threats</FONT>
<BR> <FONT SIZE=2>Theft and Denial of Service</FONT>
</P>
<P><FONT SIZE=2>Protection is really what people want - If I send x bps</FONT>
<BR><FONT SIZE=2>to site S, what y bps will be received, how much d later?</FONT>
</P>
<P> <FONT SIZE=2>to guarantee y=x, and d is minimised, you need</FONT>
<BR> <FONT SIZE=2>Admission Control (so we are not sharing as we would if</FONT>
<BR> <FONT SIZE=2>we adapted under congestion control)</FONT>
<BR> <FONT SIZE=2>Scheduling (so we do not experience arbitrary queueing</FONT>
<BR> <FONT SIZE=2>delays) </FONT>
<BR><FONT SIZE=2>Re-routing may also need to be controlled and pre-empted</FONT>
<BR><FONT SIZE=2>alternate routes (also known, unfortunately as protection paths)</FONT>
<BR><FONT SIZE=2>may be needed if we want QoS to include availability as well as</FONT>
<BR><FONT SIZE=2>throughput guarantees and delay bounds.</FONT>
</P>
<P><FONT SIZE=2>Network Structure</FONT>
<BR> <FONT SIZE=2>"edge", "core", etc is a myth 0- in the global net the</FONT>
<BR><FONT SIZE=2>average traffic path includes 7 ASs - most inter-domain traffic</FONT>
<BR><FONT SIZE=2>traverses heavily used Internet Exchange points (e.g. London)</FONT>
<BR><FONT SIZE=2>where capacity only just about matches demand, whereas core</FONT>
<BR><FONT SIZE=2>networks are often "over-provisioned" (UK academic net now runs at</FONT>
<BR><FONT SIZE=2><5% utilisation).</FONT>
</P>
<P><FONT SIZE=2>Aggregation is a technique to scale traffic management for QoS -</FONT>
<BR><FONT SIZE=2>by only managing classes of aggregates of flows, we get to reduce</FONT>
<BR><FONT SIZE=2>the state and signaling/management overhead for it. VPNs/tunnels</FONT>
<BR><FONT SIZE=2>of course are aggregation techniques, as are things that treat</FONT>
<BR><FONT SIZE=2>packet differently on subfields like DSCP, port etc etc</FONT>
</P>
<P><FONT SIZE=2>SLAs are around already despite non widespread QoS - however,</FONT>
<BR><FONT SIZE=2>SLAs are only intra-ISP to my knowledge (some Internet Exchanges</FONT>
<BR><FONT SIZE=2>offer SLAs but end 2 end SLAs are as scarce as dragons).</FONT>
</P>
<P><FONT SIZE=2>Economics - are important here again as you can imagine!</FONT>
</P>
<BR>
<P><FONT SIZE=2>An Engineering Approach to Computer Networking</FONT>
<BR><FONT SIZE=2>Keshav, 1997, Addison-Wesley Pub Co; ISBN: 0201634422 </FONT>
<BR><FONT SIZE=2>or</FONT>
<BR><FONT SIZE=2>Internet QoS: Architectures and Mechanisms for Quality of Service</FONT>
<BR><FONT SIZE=2>by Zheng Wang, 2001, Morgan Kaufmann Publishers; ISBN: 1558606084</FONT>
</P>
<P><FONT SIZE=2>6/ Multicast</FONT>
</P>
<P><FONT SIZE=2>Tier 1 routing works. Most ISPs run core native multicast</FONT>
</P>
<P><FONT SIZE=2>Interdomain only just limps (its getting better...</FONT>
<BR> <FONT SIZE=2>MSDP Problems</FONT>
<BR> <FONT SIZE=2>App Relay Solutions</FONT>
</P>
<P><FONT SIZE=2>RMT - we have some candidate protocols for reliable multicast -</FONT>
<BR><FONT SIZE=2>nothing as solid as 1988 TCP quite yet tho.</FONT>
</P>
<P><FONT SIZE=2>Address Allocation and Directories are not great yet, hence</FONT>
<BR><FONT SIZE=2>beacons and so on.</FONT>
</P>
<P><FONT SIZE=2>Access Network are in bad shape...e.g.</FONT>
<BR> <FONT SIZE=2>DSLAMs dont do IGMP snooping</FONT>
<BR> <FONT SIZE=2>Cable dont do IGMP snooping</FONT>
<BR> <FONT SIZE=2>Dialup cant hack it at all</FONT>
</P>
<P><FONT SIZE=2>Does IPv6 Help (don't laugh!) - yes it might!</FONT>
</P>
<P><FONT SIZE=2>Developing IP Multicast Networks: The Definitive Guide to</FONT>
<BR><FONT SIZE=2>Designing and Deploying CISCO IP Multicast Networks</FONT>
<BR><FONT SIZE=2>by Beau Williamson, 2000, Cisco Press; ISBN: 157870077</FONT>
<BR><FONT SIZE=2>and</FONT>
<BR><FONT SIZE=2>Multicast Communication: Protocols, Programming, and Applications</FONT>
<BR><FONT SIZE=2>by Ralph Wittmann, Martina Zitterbart</FONT>
<BR><FONT SIZE=2>Morgan Kaufmann Publishers; ISBN: 1558606459 </FONT>
</P>
<P><FONT SIZE=2>7/ Operating Systems</FONT>
</P>
<P><FONT SIZE=2>Linux, Solaris etc...there's a lot we could say here - lots of</FONT>
<BR><FONT SIZE=2>things can and should be configured</FONT>
</P>
<P><FONT SIZE=2>zero copy stack - we'd all like this - zero copy receive is hard;</FONT>
<BR><FONT SIZE=2>RDMA is not obviously the answer</FONT>
</P>
<P><FONT SIZE=2>Interrupts (self selecting NICs) we should minimises these if we</FONT>
<BR><FONT SIZE=2>want TCP to go to 10Gbps on a reasonable processor - there are</FONT>
<BR><FONT SIZE=2>nice techniques</FONT>
</P>
<P><FONT SIZE=2>socket buffer considerations -there are lots!</FONT>
</P>
<P><FONT SIZE=2>protection and scheduling domains - if we could get away from OSs</FONT>
<BR><FONT SIZE=2>that confused these , life would be easier!</FONT>
</P>
<P><FONT SIZE=2>W Richard Stevens, TCP/IP Illustrated, All Volumes.</FONT>
<BR><FONT SIZE=2>AND</FONT>
<BR><FONT SIZE=2>Understanding the Linux Kernel,</FONT>
<BR><FONT SIZE=2>D.P. Bovet and M. Cesati, O'Reilly, 2001, </FONT>
<BR><FONT SIZE=2>ISBN 0-596-00002-2</FONT>
</P>
<P><FONT SIZE=2>8/ Layer 2 Considerations</FONT>
</P>
<P><FONT SIZE=2>layer 2 NBMA nets - lots - a pain</FONT>
</P>
<P><FONT SIZE=2>layer 2 shared media nets - was decreasing due to switched ether,</FONT>
<BR><FONT SIZE=2>now increasing due to wireless.</FONT>
</P>
<P><FONT SIZE=2>switching and routing re-cursed - layer 2 switching and routing</FONT>
<BR><FONT SIZE=2>usually makes life HARDER for the IP engineer.</FONT>
</P>
<P><FONT SIZE=2>flow and congestion control re-cursed - layer 2 reliability and</FONT>
<BR><FONT SIZE=2>flow control almost ALWAYS make life worse for the IP and TCP</FONT>
<BR><FONT SIZE=2>engineer.</FONT>
</P>
<P><FONT SIZE=2>signaling (implicit, explicit) is just painful.</FONT>
</P>
<P><FONT SIZE=2>802.11 - in its glory:</FONT>
<BR><FONT SIZE=2><A HREF="http://www.apple.com/ibook/wireless.html" TARGET="_blank">http://www.apple.com/ibook/wireless.html</A></FONT>
</P>
<P><FONT SIZE=2>General discussion of slow lossy links:</FONT>
<BR><FONT SIZE=2><A HREF="http://www.ietf.org/html.charters/pilc-charter.html" TARGET="_blank">http://www.ietf.org/html.charters/pilc-charter.html</A></FONT>
</P>
<P><FONT SIZE=2>WAP horrors - see web for many stories</FONT>
</P>
<P><FONT SIZE=2>GPRS - see:</FONT>
<BR><FONT SIZE=2><A HREF="http://www.cl.cam.ac.uk/Research/SRG/netos/coms/index.html" TARGET="_blank">http://www.cl.cam.ac.uk/Research/SRG/netos/coms/index.html</A></FONT>
</P>
<P><FONT SIZE=2>Other end of "Spectrum", see</FONT>
<BR><FONT SIZE=2><A HREF="http://www.cis.ohio-state.edu/~jain/refs/opt_refs.htm" TARGET="_blank">http://www.cis.ohio-state.edu/~jain/refs/opt_refs.htm</A></FONT>
<BR><FONT SIZE=2>(includes Raj Jain's own list of hot topics!)</FONT>
</P>
<BR>
<P><FONT SIZE=2>9/ Light v. Heavyweight Protocols</FONT>
</P>
<P><FONT SIZE=2>Header prediction, Packet templates make</FONT>
<BR><FONT SIZE=2>Code complexity a lot lower in the common case even for a big</FONT>
<BR><FONT SIZE=2>protocol like TCP or SCTP.</FONT>
</P>
<P><FONT SIZE=2>"User space" v. kernel myths - in this authors experience it is</FONT>
<BR><FONT SIZE=2>really worth getting people to put transports into the kernel -</FONT>
<BR><FONT SIZE=2>reasons include independent failure of application and protocol</FONT>
<BR><FONT SIZE=2>as well as good control of end system resources. It ain't that</FONT>
<BR><FONT SIZE=2>hard and user space will just almost never be as fast.</FONT>
</P>
<P><FONT SIZE=2>Computer Networks, A Systems Approach</FONT>
<BR><FONT SIZE=2>Peterson and Davie, </FONT>
<BR><FONT SIZE=2>Morgan Kaufmann, 1996, ISBN 1-55860-368-9</FONT>
<BR><FONT SIZE=2>(2nd ed. too)</FONT>
</P>
<P><FONT SIZE=2>10/ Macroscopic Traffic and System Considerations</FONT>
</P>
<P><FONT SIZE=2>Self similarity, so?</FONT>
<BR> <FONT SIZE=2>traffic is self similar (i.e. arrivals are not i.i.d) -</FONT>
<BR> <FONT SIZE=2>this doesn't actually matter much (there is a horizon effect)</FONT>
</P>
<P><FONT SIZE=2>traffic phase effects</FONT>
<BR> <FONT SIZE=2>p2p (IP router, multiparty applications etc)</FONT>
<BR> <FONT SIZE=2>have a tendency (like clocks on a wooden door, or</FONT>
<BR> <FONT SIZE=2>fireflies in the mekong delta) to synchronise 0- this is</FONT>
<BR> <FONT SIZE=2>a bad thing </FONT>
</P>
<P><FONT SIZE=2>flash crowds</FONT>
<BR> <FONT SIZE=2>e.g. genome publication of new result followed </FONT>
<BR> <FONT SIZE=2>by simultaneous dbase search with similar queries from</FONT>
<BR> <FONT SIZE=2>lots of different places...</FONT>
</P>
<P><FONT SIZE=2>Asymmetry</FONT>
</P>
<P> <FONT SIZE=2>Many things in the net are asymmetric - see ADSL lines,</FONT>
<BR><FONT SIZE=2>see client-server, master-slave, see most NAT boxes. See BGP</FONT>
<BR><FONT SIZE=2>paths. beware - assumptions about symmetry (e.g. deriving 1 way</FONT>
<BR><FONT SIZE=2>delay from RTT) are often wildly wrong. Asymmetry also breaks all</FONT>
<BR><FONT SIZE=2>kinds of middle box snooping behaviour.</FONT>
</P>
<BR>
<P><FONT SIZE=2>The Art of Computer Systems Performance Analysis</FONT>
<BR><FONT SIZE=2>Raj Jain, 1991, Wiley, ISBN 0-471-50336-3</FONT>
</P>
<P><FONT SIZE=2>Web Protocols and Practice</FONT>
<BR><FONT SIZE=2>B. Krishnamurthy & J. Rexford,</FONT>
<BR><FONT SIZE=2>Addison Wesley, 2001, ISBN 0-201-710885</FONT>
</P>
<P><FONT SIZE=2>Security Engineering, </FONT>
<BR><FONT SIZE=2>Ross Anderson, 2001 Wiley & Sons; ISBN: 0471389226 </FONT>
</P>
<P><FONT SIZE=2>------------------------------------</FONT>
<BR><FONT SIZE=2>Global Reference:</FONT>
<BR><FONT SIZE=2>ACM CCR 25th Anniversary Edition, </FONT>
<BR><FONT SIZE=2>ACM SIGCOMM CCR, Volume 25, No.1 January 1995, </FONT>
<BR><FONT SIZE=2>ISSN #: 0146-4833</FONT>
<BR><FONT SIZE=2><A HREF="http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-95.html" TARGET="_blank">http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-95.html</A></FONT>
</P>
</BODY>
</HTML>