From dpreed at reed.com Tue Jan 1 07:50:43 2002 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <200112312248.RAA16596@ginger.lcs.mit.edu> Message-ID: <5.1.0.14.2.20020101103822.02b81908@mail.reed.com> At 05:48 PM 12/31/2001 -0500, J. Noel Chiappa wrote: >In other words, "I do not say you cannot have names which do not reflect >topology; only that the routing calculations cannot use those names." I meant what I said, which does not contradict what you say in the least. Though you apparently read it that way, I was not arguing for some kind of naive "routing based on GUID" scheme. In fact I was merely arguing against the idea that hierarchical assignment of stable topological routing IDs is somehow "the right answer" for the evolution of the future Internet. To amplify my own thoughts in this area: topology is what routing is about, and routing calculations need names that reflect topological information. However it is a deep mistake to assume that the proper model for the ultimate Internet is dominated by a fixed and unchanging graph of links and nodes. That's like saying that when MacAdam around 1815 invented the hard-paved road (read "twisted pair" or "fiber"), that all human transportation could be reduced to graphs of "road-like" links connecting intersections. It was a useful abstraction, but airplanes, helicopters, and off-road-vehicles would be stunted in their capabilities if we forced them to live in that abstraction. Wireless networks, especially densely scaled mobile wireless networks, do not behave like "wires without wires" or "fibers without fibers". Topology is not naturally hierarchical in its interconnection, for example. So "hierarchically derived" topological addresses are just plain wrong. More relevant, though again as naive as GUID-based routing, is geotemporal routing. - David -------------------------------------------- WWW Page: http://www.reed.com/dpr.html From Jon.Crowcroft at cl.cam.ac.uk Wed Jan 2 00:05:57 2002 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: Message from "David P. Reed" of "Tue, 01 Jan 2002 10:50:43 EST." <5.1.0.14.2.20020101103822.02b81908@mail.reed.com> Message-ID: In message <5.1.0.14.2.20020101103822.02b81908@mail.reed.com>, "David P. Reed" typed: >>Wireless networks, especially densely scaled mobile wireless networks, do >>not behave like "wires without wires" or "fibers without fibers". Topology >>is not naturally hierarchical in its interconnection, for example. So >>"hierarchically derived" topological addresses are just plain wrong. More >>relevant, though again as naive as GUID-based routing, is geotemporal routing the similarity of the recent parallel work on smart, ad hoc, self organised, wireless network routing and smart ad hoc, self organised peer2peer systems, has been remarked on a few times... the applicability of the work of both to the internet's lower level shortcomings is also reasoanble... actually, a lot of the constraints are different tho....for example, non-reachability of a node in a wireless system and a p2p system is a _feature_, so is anonymity... fixed networks dont have these luxuries:-) cheers jon From jnc at ginger.lcs.mit.edu Wed Jan 2 07:38:54 2002 From: jnc at ginger.lcs.mit.edu (J. Noel Chiappa) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace Message-ID: <200201021538.KAA19226@ginger.lcs.mit.edu> > From: "David P. Reed" > I meant what I said, which does not contradict what you say in the > least. Though you apparently read it that way, I was not arguing for > some kind of naive "routing based on GUID" scheme. Well, you didn't give any detail, so I was kind of at sea as to how to read it. So, I didn't assume that's what you meant. In fact, even with this follow-up, I'm still kind of confused as to exactly what it is you are saying. (In my reply, I just tried to state what I believed to be the limits - and indicate that I was OK with non-topological names for some purposes.) > To amplify my own thoughts in this area: topology is what routing is > about, and routing calculations need names that reflect topological > information. OK so far. > However it is a deep mistake to assume that the proper model for the > ultimate Internet is dominated by a fixed and unchanging graph of links > and nodes. Nobody's saying it's fixed and unchangeable: if nothing else, new stuff gets put into service, and old stuff removed, all the time - and that's something we already deal with. However, there is a question of the dynamicity/rate. A topology which is too dynamic (in the provisioning sense) is no more tractable than a topology that is too dynamic (in the up/down sense). The latter is a circumstance we've already had a lot of struggling with. Which is not to say that there's no way to handle it - we manage to deal with a very large amount of up/down dynamicity by constraining the scope of the updates. However, if the topology is provisioning-dynamic, since the naming abstraction hierarchy has to be based on the the topology, this could cause problems. > Wireless networks, especially densely scaled mobile wireless networks, > do not behave like "wires without wires" or "fibers without fibers". > Topology is not naturally hierarchical in its interconnection, for > example. Nobody is saying it is. But you have to impose a naming abstraction hierarchy, or the routing will not scale. You can impose such an abstraction hierarchy on *any* graph - it doesn't have to be hierarchically organized. Kleinrock/Kamoun shows that when you do so - in an arbitrary graph - you still get reasonably optimal paths (which asymptote to the optimal as the network gets large). > So "hierarchically derived" topological addresses are just plain wrong. Sorry, I completely disagree - although perhaps I'm just misunderstanding what you mean by ""hierarchically derived topological addresses". > More relevant, though again as naive as GUID-based routing, is > geotemporal routing. Sorry, I don't know what that is - can you elaborate? Noel From dpreed at reed.com Wed Jan 2 08:35:23 2002 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <200201021538.KAA19226@ginger.lcs.mit.edu> Message-ID: <5.1.0.14.2.20020102110229.045ecbc0@mail.reed.com> At 10:38 AM 1/2/2002 -0500, J. Noel Chiappa wrote: >Nobody is saying it is. But you have to impose a naming abstraction >hierarchy, or the routing will not scale. You can impose such an abstraction >hierarchy on *any* graph - it doesn't have to be hierarchically organized. This embodies precisely the problem I have with most routing discussions. Let me try to get at this from my point of view. The problem phrase is "You can impose such an abstraction on *any* graph". While true, it is irrelevant in a deep way, for two reasons: 1. a communications system, from its endpoints perspective, is the graph of capabilities for end-to-end message delivery. The internal structure of the network (links & nodes) is only relevant when it constrains that. Confusing internal structure with external function is not modular. This is like saying that two Pentium IVs are different because they have different cache sizes or are made in different processes. 2. The abstraction being imposed (IP's addressing) is intended to apply to communications systems that are not graphs at all. For example, radio networks have topology, but in space, time, and frequency domain they are continuous manifolds, not graphs. (recognizing this manifold structure has come late to those who keep trying to adapt link-level models to radio networking, though - Procrustes would be extremely proud of Mobile IP). >Kleinrock/Kamoun shows that when you do so - in an arbitrary graph - you >still get reasonably optimal paths (which asymptote to the optimal as the >network gets large). "Optimal" is a red flag to me, meaning "check the assumptions". The realism of these particular assumptions is questionable, IMHO. I'm not criticizing Kleinrock's work at all - such work is extremely useful because it is usually easier to prove something optimal under approximate assumptions than to prove "pretty good" under actual real circumstances. But "optimal" is a word that is often used to trump discussion (especially when not qualified with the assumptions). For example, the techniques used to implement 56K bit modems were thought to be impossible, because 32 kb/s was "optimal" for a 4 KHz voice telephone channel (modeled as an analog channel). That the problem was in the assumptions was hidden by the tools used to argue "optimality". > > So "hierarchically derived" topological addresses are just plain wrong. > >Sorry, I completely disagree - although perhaps I'm just misunderstanding >what you mean by ""hierarchically derived topological addresses". > > > > More relevant, though again as naive as GUID-based routing, is > > geotemporal routing. > >Sorry, I don't know what that is - can you elaborate? I mean approaches that recognize that endpoints are embedded in a spatial and temporal physical world, and which calculate routes in a distributed manner using such information. (a prehistoric ancestor of such things is Landmark Routing, but also included are various radio techniques such as MIT's GRID and low-level routing techniques such as spatial coding, joint and multiuser detection - depending on the topology of the available connectivity manifold and its embedding in 4-space). > Noel - David -------------------------------------------- WWW Page: http://www.reed.com/dpr.html From huitema at windows.microsoft.com Wed Jan 2 09:07:00 2002 From: huitema at windows.microsoft.com (Christian Huitema) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace Message-ID: > >You are possibly working on the assumption that _someone_ knows, but they > >are not telling the rest of us. The alternative explanation is that noone > >knows and there is nothing to tell as yet! > > From my perspective, what's interesting is that it looks like the > mobile ad-hoc networking folks are getting ahead of the wire-line folks. Uh, looking at recent publications, it seems that most ad hoc routing algorithms scale with the number of nodes N in at least O(N), if not O(N^2) -- they also have a scaling dependency on the number of neighbors per node. Not quite what you would want for Internet wide routing... -- Christian Huitema From jnc at ginger.lcs.mit.edu Wed Jan 2 09:24:19 2002 From: jnc at ginger.lcs.mit.edu (J. Noel Chiappa) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace Message-ID: <200201021724.MAA19404@ginger.lcs.mit.edu> > From: "David P. Reed" >> you have to impose a naming abstraction hierarchy, or the routing will >> not scale. You can impose such an abstraction hierarchy on *any* >> graph - it doesn't have to be hierarchically organized. > This embodies precisely the problem I have with most routing > discussions. Let me try to get at this from my point of view. Your note embodies precisely the problem I have with most routing discussions, too! :-) > The problem phrase is "You can impose such an abstraction on *any* > graph". While true, it is irrelevant in a deep way On the contrary, you cannot build a routing architecture (i.e. a system for finding paths between sources and destinations) that will scale to very large sizes without a naming abstraction hierarchy *based on the real topology*. > 1. a communications system, from its endpoints perspective, is the > graph of capabilities for end-to-end message delivery. The internal > structure of the network (links & nodes) is only relevant when it > constrains that. Exactly! It's for the problem of finding a real path (i.e. an ordered set of real links and nodes) from a source to a destination that the routing architecture needs those topology-based names you hate so much. > Confusing internal structure with external function is not modular. One person's hidden internal structure is another person's explicit structure. If you want to treat the network as if if were an N^2 set of direct connections between all possible endpoint pairs, fine. Those of us who actually have to get the packets from A to B don't have that luxury. If what you're saying is you want a namespace for interfaces (or whatever) which doesn't have topology built into it, then fine - but you have to make the case as to why the costs of that extra namespace (and all the mappings to and fro to other namespaces) are worth the benefits - which are...? > 2. The abstraction being imposed (IP's addressing) is intended to apply > to communications systems that are not graphs at all. For example, > radio networks have topology, but in space, time, and frequency domain > they are continuous manifolds, not graphs. True enough. But it's also true that one can represent the connectivity between the radio nodes by a graph, with arcs between all nodes that can directly communicate. One can further enhance that graph by adding attributes to the arcs, showing bandwidth, S/N (aka error rates), etc, etc. (Of course, it may be a very dense graph, but there are ways to deal with that which I'm going to gloss over for the moment.) The question then becomes "which is a more useful way to model the real world radio network". Even for the purposes of routing within the radio network, it's not clear to me that the continuous manifold model is better (since I doubt that the theoretical manifold model will always accurately tell you the real bandwidth and S/N available between any particular pair of nodes, when you take into account buildings, trees, rain, etc, etc, etc). Won't you want to wind up measuring it? Then the question becomes "what's the best way to embed that information in a knowledge schema that other entities which are trying to select paths can use"? At which point we wind up back at the graph model, I suspect. And anyway, even if it is more appropriate to use some other technique for modelling the connectivity in some limited domain, you still face the problem of what the appropriate model is for the system as a whole - remember, to be much use at all, users of that radio network have to be able to get to users anywhere else on the network. And for the larger network, a graph-based knowledge schema still seems like the right thing. >>> More relevant, though again as naive as GUID-based routing, is >>> geotemporal routing. > approaches that recognize that endpoints are embedded in a spatial and > temporal physical world, and which calculate routes in a distributed > manner using such information. The physical location is completely irrelevant. What matters is the ability to communicate. And the most compact model of that communication capability, in most cases, is a graph of the actual connectivity. > a prehistoric ancestor of such things is Landmark Routing Well, landmark routing is just a way of building an abstraction hierarchy (albeit not one with fixed boundaries). It has downsides of its own, too (which I don't feel like yapping about here). > also included are various radio techniques such as MIT's GRID and > low-level routing techniques such as spatial coding, joint and > multiuser detection - depending on the topology of the available > connectivity manifold and its embedding in 4-space). There may well be some use for other techniques in part of the network. A well designed routing architecture should make such things relatively easy. However, the problem remains of what connectivity model to use for the system as a whole - and of a naming system for that model that results in an overall scalable routing system. Noel From nhv at godel.crhc.uiuc.edu Wed Jan 2 10:11:42 2002 From: nhv at godel.crhc.uiuc.edu (Nitin H Vaidya) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <200201021724.MAA19404@ginger.lcs.mit.edu> Message-ID: On Wed, 2 Jan 2002, J. Noel Chiappa wrote: >> > 2. The abstraction being imposed (IP's addressing) is intended to apply >> > to communications systems that are not graphs at all. For example, >> > radio networks have topology, but in space, time, and frequency domain >> > they are continuous manifolds, not graphs. >> >>True enough. >> >>But it's also true that one can represent the connectivity between the radio >>nodes by a graph, with arcs between all nodes that can directly communicate. >>One can further enhance that graph by adding attributes to the arcs, showing >>bandwidth, S/N (aka error rates), etc, etc. (Of course, it may be a very >>dense graph, but there are ways to deal with that which I'm going to gloss >>over for the moment.) The question then becomes "which is a more useful way >>to model the real world radio network". I believe graphs are fine so far as modeling a radio network is concerned, but a couple of issues must be addressed a bit more carefully: * Links in radio networks are not necessarily a "given" -- one can decide which links "exist" and which don't, by controlling parameters such as the transmit power. * I presume you mean bit rate, when you say bandwidth above: Bit rate of a link between a pair of nodes is not always an independent variable, since all the "links" terminating at a given node may share the channel with each other. Thus, bit rates of these links are correlated, not independent (generally, a link's bit rate is correlated with those links one or, possibly, more hops away). Also, the bit rate can be tweaked by changing parameters such as the modulation scheme. Regards. - nitin From jnc at ginger.lcs.mit.edu Wed Jan 2 11:01:32 2002 From: jnc at ginger.lcs.mit.edu (J. Noel Chiappa) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace Message-ID: <200201021901.OAA19575@ginger.lcs.mit.edu> > From: Nitin H Vaidya > Links in radio networks are not necessarily a "given" -- one can decide > which links "exist" and which don't, by controlling parameters such as > the transmit power. Good point. > I presume you mean bit rate, when you say bandwidth above Yes, sorry - I was being (probably too) loose with terminology. Noel From dpreed at reed.com Wed Jan 2 11:23:43 2002 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: References: <200201021724.MAA19404@ginger.lcs.mit.edu> Message-ID: <5.1.0.14.2.20020102140636.045f8908@mail.reed.com> My reading: Chiappa and Vaidya think that graphs are fine for modeling the radio network medium. Chiappa thinks this is best because the "real network" is the fixed fiber/wire network of relatively fixed topology, and radio is a mere peripheral, whose quirks are best unified into the underlying fixed network model. And Huitema thinks that the best measure of promise of some of the ideas in the ad hoc networking community is the computational complexity of the algorithms they have managed to invent so far (by the way, the GRID technique scales as N log(N), as do some other approaches with high dynamicity that I know of). My reaction is that this makes the Internet design abstractions brittle - unable to incorporate its next set of challenges (including mobility and other dynamics, and self-organizing evolution and provisioning) because of excess complexity from stretching the model. (since I'm writing this, I say it reminds me of epicycles - you could model every orbit of a planet using perfect circles if you use enough of them). It was indeed the case that epicycle-based models were *far* more accurate in predicting planetary motions for a long time before Newtonian models were properly fit. (partly because epicycles had the freedom to introduce large numbers of correction terms to fit observation precisely). I'm willing to take the risk that I'm wrong, here. But are there others on this list who are willing to look at the big picture of routing and addressing and consider that there might be a lot of important things we don't understand yet about how to think about communications systems as a whole? - David -------------------------------------------- WWW Page: http://www.reed.com/dpr.html From dpreed at reed.com Wed Jan 2 11:53:51 2002 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: References: <200201021724.MAA19404@ginger.lcs.mit.edu> Message-ID: <5.1.0.14.2.20020102142609.045e6a38@mail.reed.com> At 12:11 PM 1/2/2002 -0600, Nitin H Vaidya wrote: > * I presume you mean bit rate, when you say bandwidth above: Bit rate of > a link between a pair of nodes is not always an independent variable, > since all the "links" terminating at a given node may share the channel > with each other. Thus, bit rates of these links are correlated, not > independent (generally, a link's bit rate is correlated with those > links one or, possibly, more hops away). > Also, the bit rate can be tweaked by changing parameters such as the > modulation scheme. This characterization remains muddy, and still shows evidence of trying to think of electromagnetic propagation as a set of wirelike links. Signals do not interfere with each other in the physical medium - they are superposed on each other (a reversible process). With space-time coding, for one interesting current example, they can in many cases be completely separated again. (in fact, in a band-limited and space-bounded diffusive medium, it's been shown that as the number of transmitter reciever pairs increases with N, the communications capacity of the channel increases linearly with N. The *opposite* of what you'd expect if signals interfere and diffusion/multipath could be viewed as as noise). So the tradeoff of achievable bitrates among a fixed set of transceivers in a medium is not derivable from the fundamental physics. If you arbitrarily draw an fantasy topology on it and limit the computational capacity of the nodes to trivial processing (like memoryless linear filtering only, e.g. early twentieth-century tank circuits), then you come close to the approximation you suggest above. Information theory has hardly started to be able to explain general "network channels" that arise when computational radios cooperatively coexist in a dense space. Instead we use simple rules about point-to-point channels, and lump all other effects into our models as worst-case, assumed-to-be-gaussian noise processes. But with respect to modeling radio networks as graphs, that is circular reasoning, assuming what you want to demonstrate. Instead, I think you have to start modeling radio networks based on physics, and then see if graphs can model the real physics in a useful way. From nhv at godel.crhc.uiuc.edu Wed Jan 2 14:10:42 2002 From: nhv at godel.crhc.uiuc.edu (Nitin H Vaidya) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <5.1.0.14.2.20020102142609.045e6a38@mail.reed.com> Message-ID: David: The objections you raise are reasonable. I should have hedged a bit when I earlier stated that graph models for radio networks are "fine". I did not mean to imply that they are a perfect model, but only that they may suffice for certain purposes. For instance, for routing protocols that rely on "hop-by-hop" packet forwarding, graph models seem adequate. Should we be looking at other kinds of protocols? Certainly. Given that graphs are an approximation of reality, they cannot be expected to serve for all purposes. On Wed, 2 Jan 2002, David P. Reed wrote: . >>Signals do not interfere with each other in the physical medium - they are . >>superposed on each other (a reversible process). With space-time coding, . >>for one interesting current example, they can in many cases be completely . >>separated again. (in fact, in a band-limited and space-bounded diffusive . >>medium, it's been shown that as the number of transmitter reciever pairs . >>increases with N, the communications capacity of the channel increases . >>linearly with N. The *opposite* of what you'd expect if signals interfere . >>and diffusion/multipath could be viewed as as noise). Yes, you are right that channel capacity can grow with N Does that necessarily mean that bit rates of different "links" are independent? I did not think so, but I could be mistaken, particularly, considering that I did not know that the capacity can grow *linearly* with N without imposing some constraints. Does this result require some assumptions about the channel, or receivers? - nitin From Jon.Crowcroft at cl.cam.ac.uk Wed Jan 2 14:10:04 2002 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: Message from "Christian Huitema" of "Wed, 02 Jan 2002 09:07:00 PST." Message-ID: In message , "Christian Huitema" typed: >>> >You are possibly working on the assumption that _someone_ knows, but >>they >>> >are not telling the rest of us. The alternative explanation is that >>noone >>> >knows and there is nothing to tell as yet! >>> >>> From my perspective, what's interesting is that it looks like the >>> mobile ad-hoc networking folks are getting ahead of the wire-line >>folks. >> >>Uh, looking at recent publications, it seems that most ad hoc routing >>algorithms scale with the number of nodes N in at least O(N), if not >>O(N^2) -- they also have a scaling dependency on the number of neighbors >>per node. Not quite what you would want for Internet wide routing... not sure what publications or what definition of "recent" you are using - i've seen self organisign hierarchies (not just spine) based ad hoc protocols which do way way better....depends on the _mobility_ model - a lot of people have naive mobility models - if you use a mix of techniques, and a mix orf appropriate scale mobile/wireless node velocity models, you can do really quite well... esp. if you dont start with ip:-) cheers jon From huitema at windows.microsoft.com Wed Jan 2 14:20:07 2002 From: huitema at windows.microsoft.com (Christian Huitema) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace Message-ID: > >>> From my perspective, what's interesting is that it looks like the > >>> mobile ad-hoc networking folks are getting ahead of the wire-line > >>folks. > >> > >>Uh, looking at recent publications, it seems that most ad hoc routing > >>algorithms scale with the number of nodes N in at least O(N), if not > >>O(N^2) -- they also have a scaling dependency on the number of > neighbors > >>per node. Not quite what you would want for Internet wide routing... > > not sure what publications or what definition of "recent" you are > using - i've seen self organisign hierarchies (not just spine) based > ad hoc protocols which do way way better....depends on the _mobility_ > model - a lot of people have naive mobility models - if you use a mix > of techniques, and a mix orf appropriate scale mobile/wireless node > velocity models, you can do really quite well... I was looking at the MANET drafts. I can see two kinds of protocols, either based on pre-computation of routing tables with one entry per destination, or "flood and trace" variations. The amount of state per node in the pre-computation variant scales as O(N), and so does the number of message per node; the total number of messages in the network scales as O(N^2). In the flood and trace variant, the cost of a given flood scales as O(N) and the number of floods scales as O(P), where P is the number of peers maintained by a given host; you can argue that P scales as O(N), or possibly slightly better (but not O(1)!); in any case, the number of messages in the network grows faster than the number of nodes. This may be perfectly fine for the ad hoc networking application, but I would not take it as a model of the general solution. -- Christian Huitema From dpreed at reed.com Wed Jan 2 14:49:53 2002 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: References: <5.1.0.14.2.20020102142609.045e6a38@mail.reed.com> Message-ID: <5.1.0.14.2.20020102171951.045c6540@mail.reed.com> At 04:10 PM 1/2/2002 -0600, Nitin H Vaidya wrote: >Yes, you are right that channel capacity can grow with N >Does that necessarily mean that bit rates of different "links" >are independent? I did not think so, but I could be >mistaken, particularly, considering that I did not know that the >capacity can grow *linearly* with N without imposing some constraints. >Does this result require some assumptions about the channel, or receivers? This is really not understood completely. One set of approaches involves taking advantage of diffusive media (multipath is your friend!) to make the transmission matrix full-rank. I am not aware that this is the only case that applies. There are folks actively working on more general theories. An interesting pair of articles in Science led me to this area, which has (as far as I know) been pioneered mostly by folks at AT&T Bell Labs (Foschini & Gans). Three online references (the first two may require you to register/have a membership in AAAS): Moustakas, et al. Communication Through a Diffusive Medium: Coherence and Capacity (http://www.sciencemag.org/cgi/content/abstract/287/5451/287) Stuart, Dispersive Multiplexing in Multimode Optical Fiber (http://www.sciencemag.org/cgi/content/full/289/5477/281) Foschini & Gans, On the Limits of Wireless Communications in a Fading Environment when Using Multiple Antennas (http://www.bell-labs.com/project/blast/wpc-v6n3.pdf) Gupta and Kumar have combined some of these ideas with their models of multihop repeater network capacity models, to derive a class of networks that scale faster than the sqrt(N) scaling that they proved was the maximum for networks that treat wireless connections as wires - I can't find their workshop paper from this fall at the moment. - David -------------------------------------------- WWW Page: http://www.reed.com/dpr.html From hofmann at bell-labs.com Wed Jan 2 14:52:13 2002 From: hofmann at bell-labs.com (Markus Hofmann) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] IEEE Global Internet 2002 - Call for Papers! Message-ID: <3C338F1D.1060306@bell-labs.com> *** Apologies if you receive this note more than once *** 7th IEEE Global Internet Symposium in conjunction with IEEE Globecom 2002 Taipei, Taiwan November 17-21, 2002 http://gi2002.planethofmann.com/ ------------------------------------------------------------------ Call for Papers The seventh IEEE Global Internet Symposium will be held simultaneously and co-located with IEEE Globecom 2002. Therefore, all of the relevant dates, location, and travel information are derived from IEEE Globecom 2002 and are available at the conference site (http://www.globecom2002.com/). Symposium Topics IEEE Global Internet 2002 aims to provide a forum for researchers and practitioners to present and discuss advances in Internet-related technologies. The focus of the symposium is on experimental systems and on emerging Internet technologies. The Program Committee encourages original submissions describing promising work in progress, speculations about the future of the Internet, and progressive position papers. Authors are invited to submit papers on any issue related to Internet technology, including but not limited to: * Content networking (caching, content distribution, content routing, content services, load balancing, etc.). * Provisioning, monitoring, and management of IP services (VPNs, traffic engineering, mobility support, etc.). * Distributed Internet applications (file sharing, games, conferencing, etc.). * Novel applications and new paradigms (telephony, streaming media, etc.). * Privacy and/or security issues. * Charging and billing issues. * Handling Internet dynamics/heterogeneity (by applications and/or the network). * Routing (unicast, multicast, anycast, etc.). * Flow management (fairness/sharing, differentiated services, etc.). * The Internet and mobility/mobile devices. * Wireless Access and Internet Gateways. * Traffic measurement, analysis, modeling, and visualization. Important Dates Full Paper due : February 25, 2002 Notification of Acceptance: June 30, 2002 Final Manuscript due : August 15, 2002 Symposium : November 2002 Submission Instructions Please see the Global Internet Symposium WWW site at: http://gi2002.planethofmann.com/ From johnh at ISI.EDU Thu Jan 3 18:06:22 2002 From: johnh at ISI.EDU (John Heidemann) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: Message from Jon Crowcroft of "Wed, 02 Jan 2002 08:05:57 GMT." Message-ID: <200201040206.g0426MO29407@dash.isi.edu> > >In message <5.1.0.14.2.20020101103822.02b81908@mail.reed.com>, "David P. Reed" >typed: > > >>Wireless networks, especially densely scaled mobile wireless networks, do > >>not behave like "wires without wires" or "fibers without fibers". Topology > >>is not naturally hierarchical in its interconnection, for example. So > >>"hierarchically derived" topological addresses are just plain wrong. More > >>relevant, though again as naive as GUID-based routing, is geotemporal routing > > >the similarity of the recent parallel work on >smart, ad hoc, self organised, wireless network routing >and >smart ad hoc, self organised peer2peer systems, >has been remarked on a few times... But the similarity shouldn't be exaggerated. Christian H. just commented that many of the ad hoc protocols scale O(n) or worse (where n is the number of nodes or even number of flows). This approach is quite reasonable for an interesting class of ad hoc net problems, but it's quite a different constraint than the general Internet where scale in numbers of nodes is central. By contrast, many peer-to-peer systems that push scale operate on the assumption that "all nodes are pretty close to each other". For example, FreeNet and Chord both basically hash content to nodes largely irrespective of node's network location. For nodes operating in the Internet, this assumption is quite reasonable. But I think one would not be happy trying to apply this to ad hoc networks. More similar to ad hoc networking are some of the peerish overlay network work. For example, the Resilent Overlay Network paper that appeared at SOSP last year which showed reasonable performance improvement due to link-state routing with frequent updates but explicitly didn't try to scale past 10s of nodes. -John Heidemann From demir at usc.edu Thu Jan 3 19:35:13 2002 From: demir at usc.edu (demir) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <200201040206.g0426MO29407@dash.isi.edu> Message-ID: To me, whatever the system (smart, ad hoc, self organised, wireless, peer2peer) is can not breake the "end2end argument in system design." As a result, Any implementation satisfies the demand/QoS/requirement/complexity in its domain is suffucient because there has to be a universal constant somewhere in any system (We know that QxE=C as a QoS rule). I call this from zero to infinite complexity/choice/constant (C). The system can be called "macro" or "micro" such as macroeconomy, microeconomy. Otherwise, there is always oscillations from truth/right (1) to false/wrong (0) or vice versa... Alper K. Demir, PhD student The University of Southern California > >In message <5.1.0.14.2.20020101103822.02b81908@mail.reed.com>, "David P. Reed" > >typed: > > > > >>Wireless networks, especially densely scaled mobile wireless networks, do > > >>not behave like "wires without wires" or "fibers without fibers". Topology > > >>is not naturally hierarchical in its interconnection, for example. So > > >>"hierarchically derived" topological addresses are just plain wrong. More > > >>relevant, though again as naive as GUID-based routing, is geotemporal routing > > > > > >the similarity of the recent parallel work on > >smart, ad hoc, self organised, wireless network routing > >and > >smart ad hoc, self organised peer2peer systems, > >has been remarked on a few times... > > But the similarity shouldn't be exaggerated. > > Christian H. just commented that many of the ad hoc protocols scale > O(n) or worse (where n is the number of nodes or even number of > flows). This approach is quite reasonable for an interesting class of > ad hoc net problems, but it's quite a different constraint than the > general Internet where scale in numbers of nodes is central. > > By contrast, many peer-to-peer systems that push scale operate on the > assumption that "all nodes are pretty close to each other". For > example, FreeNet and Chord both basically hash content to nodes > largely irrespective of node's network location. For nodes operating > in the Internet, this assumption is quite reasonable. But I think one > would not be happy trying to apply this to ad hoc networks. > > More similar to ad hoc networking are some of the peerish overlay > network work. For example, the Resilent Overlay Network paper that > appeared at SOSP last year which showed reasonable performance > improvement due to link-state routing with frequent updates but > explicitly didn't try to scale past 10s of nodes. > > -John Heidemann > From demir at usc.edu Thu Jan 3 19:38:09 2002 From: demir at usc.edu (demir) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: Message-ID: Sorry to add again. As a result "assumtions" are inevitable cause "facts" might change. Alper K. Demir On Thu, 3 Jan 2002, demir wrote: > To me, whatever the system (smart, ad hoc, self organised, wireless, > peer2peer) is can not breake the "end2end argument in system design." As a > result, Any implementation satisfies the demand/QoS/requirement/complexity > in its domain is suffucient because there has to be a universal constant > somewhere in any system (We know that QxE=C as a QoS rule). I call this > from zero to infinite complexity/choice/constant (C). The system can be > called "macro" or "micro" such as macroeconomy, microeconomy. Otherwise, > there is always oscillations from truth/right (1) to false/wrong (0) or > vice versa... > > Alper K. Demir, PhD student > The University of Southern California > > > >In message <5.1.0.14.2.20020101103822.02b81908@mail.reed.com>, "David P. Reed" > > >typed: > > > > > > >>Wireless networks, especially densely scaled mobile wireless networks, do > > > >>not behave like "wires without wires" or "fibers without fibers". Topology > > > >>is not naturally hierarchical in its interconnection, for example. So > > > >>"hierarchically derived" topological addresses are just plain wrong. More > > > >>relevant, though again as naive as GUID-based routing, is geotemporal routing > > > > > > > > >the similarity of the recent parallel work on > > >smart, ad hoc, self organised, wireless network routing > > >and > > >smart ad hoc, self organised peer2peer systems, > > >has been remarked on a few times... > > > > But the similarity shouldn't be exaggerated. > > > > Christian H. just commented that many of the ad hoc protocols scale > > O(n) or worse (where n is the number of nodes or even number of > > flows). This approach is quite reasonable for an interesting class of > > ad hoc net problems, but it's quite a different constraint than the > > general Internet where scale in numbers of nodes is central. > > > > By contrast, many peer-to-peer systems that push scale operate on the > > assumption that "all nodes are pretty close to each other". For > > example, FreeNet and Chord both basically hash content to nodes > > largely irrespective of node's network location. For nodes operating > > in the Internet, this assumption is quite reasonable. But I think one > > would not be happy trying to apply this to ad hoc networks. > > > > More similar to ad hoc networking are some of the peerish overlay > > network work. For example, the Resilent Overlay Network paper that > > appeared at SOSP last year which showed reasonable performance > > improvement due to link-state routing with frequent updates but > > explicitly didn't try to scale past 10s of nodes. > > > > -John Heidemann > > > > From demir at usc.edu Sat Jan 5 21:18:52 2002 From: demir at usc.edu (demir) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] test Message-ID: test From rbriscoe at jungle.bt.co.uk Mon Jan 7 16:23:26 2002 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <5.1.0.14.2.20020102171951.045c6540@mail.reed.com> References: <5.1.0.14.2.20020102142609.045e6a38@mail.reed.com> Message-ID: <3.0.5.32.20020108002326.01f19cf0@mailhost.jungle.bt.co.uk> David, At 17:49 02/01/02 -0500, David P. Reed wrote: >At 04:10 PM 1/2/2002 -0600, Nitin H Vaidya wrote: >>Does this result require some assumptions about the channel, or receivers? > >This is really not understood completely. One set of approaches involves >taking advantage of diffusive media (multipath is your friend!) to make the >transmission matrix full-rank. I am not aware that this is the only case >that applies. We are talking about whether the address of endpoint E_0 should be hierarchically related to m possible previous hops R_m in order for any of N other end-points E_n in the world (Solar System?) to send to E_0. This breaks down into two issues. 1/ do we need any previous hops at all? or can all N other end-points reach E_0 wirelessly? 2/ if a previous hop is needed, will most of the m possible previous hops tend to be more closely connected to each other than all the other impossible hops? This is where a basic physical assumptions comes in, prompted by Nitin's question: Assumption 1/ In free space, e-m energy propagates by an inverse square law with distance, depending on how directional it is, which depends on frequency. Whereas wireline/fibre networks confine the signal to a much better approximation to 'fully directional', whatever the frequency. So taking each issue above in turn: 1/ For E_0 to be globally reachable wirelessly, the other N senders have to pump up their power by the square of distance. Particularly in order get the signal to go round corners (assumption 2: the world has corners which get in the way between most pairs of points on its surface that want to communicate!) e.g. to bounce the signal off whatever layers of the atmosphere it will bounce off, if at all, or to drive it straight through the earth's core. So we need to answer whether the cost of laying fibre to confine this e-m radiation to a single directional path is always going to be less than the cost of the energy required to pump data over global distances wirelessly. Not to mention the cost in biological life terms of all this intense radiation from N high power transmitters! It might sound as if I'm being sarcastic. But these Gedanken experiments are worth doing to see if someone else can point out an invalid assumption I'm making (I'm sure there are plenty, but I mean one that breaks the argument). But for now, let's assume a global wireless network is infeasible compared to a fixed one. So all that (very interesting) discussion about why non-hierarchical addressing is relevant in a wireless world, is trumped by the inverse square law of energy propagation. Therefore, as someone already said in this thread, let's assume there is a fixed network connecting over the wide area, with wireless at the extremities. So we move on to issue 2/ (will all the m possible previous hops to E_0 be topologically closer to each other than to the impossible hops?) Whether E_0 is wired or wireless, we can certainly say the previous hops are likely to be geographically close to each other (cost per km in the wired case, inverse square law and cost of transmission power again in the wireless case). So the question boils down to whether 'geographically closer' implies a tendency to be 'topologically closer' on the fixed network side. Again, cost per km of glass/wire should tend to imply this (but this could be a bit of a non-sequiteur). So even if the end station E_0 is rapidly switching between the m providers e.g. on some market-driven basis, it still seems to make sense to use some degree of hierarchy in the addressing. QED Can anyone point out an implicit assumption I've made that flaws this argument? Certainly its changes in assumptions that drive innovation. But if no-one can challenge the assumptions, we can't innovate (yet). I suspect there might be some mileage in being more precise in the wording of the assumption about the inverse square law, directionality and frequency. I think the assumption you were hanging on when discussing the multipath stuff was that you can get N to grow unlimited, but only by increasing the density of receivers within the range of the transmitters. Increasing the range wasn't part of the analysis. Bob ____________________________________________________________________________ Bob Briscoe http://www.btexact.com/people/briscorj/ From dpreed at reed.com Mon Jan 7 17:14:26 2002 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:31 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <3.0.5.32.20020108002326.01f19cf0@mailhost.jungle.bt.co.uk> References: <5.1.0.14.2.20020102171951.045c6540@mail.reed.com> <5.1.0.14.2.20020102142609.045e6a38@mail.reed.com> Message-ID: <5.1.0.14.2.20020107194953.045248c8@mail.reed.com> Bob - Considering wired networks, it's not obvious to me that every packet put into a network must take the shortest path through the network. For example, suppose that the load between point A and point B turns out to be heavier than what the links on the shortest path between A&B can support, and the rest of the load is light. In this case, one can get greater performance (either throughput or latency) by using additional paths, even though they are longer. And if you know up front that some packets can be delayed longer than others, you even have a heuristic for picking longer vs. shorter routes. For all A, B pairs, there will be some in the hierachical decomposition that will not be able to use hierarchical addresses to discover a set of routes that do particularly well in spreading the traffic along disjoint, non-interfering routes. Or so I would think. Not a proof. All I mean to point out by this is that hierarchy of addresses is intimately tied with other assumptions about what routing will be used, and what the load looks like (as well as what I really care about, which is that topology changes end up being reflected in application-visible addresses, and thus end up pushing the problem onto the higher levels which have no better way to deal with the problems.) To me, wireless and nomadic networks matter, because at some point, we will likely have many more nodes of that kind than there will be of fixed kind. Thus today's routing problems don't have anywhere near the scaling issues that wireless and nomadic ones do. From jg at pa.dec.com Mon Jan 7 18:00:07 2002 From: jg at pa.dec.com (Jim Gettys) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <5.1.0.14.2.20020107194953.045248c8@mail.reed.com> Message-ID: <200201080200.g08207Y323142@pachyderm.pa.dec.com> > To me, wireless and nomadic networks matter, because at some point, we will > likely have many more nodes of that kind than there will be of fixed > kind. Thus today's routing problems don't have anywhere near the scaling > issues that wireless and nomadic ones do. Dave, I don't challenge the claim that wireless routing is going to be challenging. I do question the claim that there will be many more nodes of the wireless/nomadic kind than fixed, unless I'm missing something. Even if wireless becomes ubiquitous to replace alot of short cables, there is no reason I can see that this needs to contribute to the global routing problem... Am I missing something? - Jim -- Jim Gettys Cambridge Research Laboratory Compaq Computer Corporation jg@pa.dec.com From rbriscoe at jungle.bt.co.uk Tue Jan 8 08:26:09 2002 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <5.1.0.14.2.20020107194953.045248c8@mail.reed.com> References: <3.0.5.32.20020108002326.01f19cf0@mailhost.jungle.bt.co.uk> <5.1.0.14.2.20020102171951.045c6540@mail.reed.com> <5.1.0.14.2.20020102142609.045e6a38@mail.reed.com> Message-ID: <3.0.5.32.20020108162609.01c84aa0@mailhost.jungle.bt.co.uk> David, At 20:14 07/01/02 -0500, David P. Reed wrote: >Bob - > >Considering wired networks, it's not obvious to me that every packet put >into a network must take the shortest path through the network. > >For all A, B pairs, there will be some in the hierachical decomposition >that will not be able to use hierarchical addresses to discover a set of >routes that do particularly well in spreading the traffic along disjoint, >non-interfering routes. Or so I would think. Not a proof. But we're not talking about using the address alone as the way to route the data. The routing alogorithm does that, but it needs to /use/ addresses to describe routes. We're merely talking about ensuring there is an extremely succinct and efficient way to represent a large set of addresses in some distant, far-off land where we don't care about whether there are disjoint routes 99.9% of the time. But when we /do/ want to discriminate between routes to different addresses in that far-off land, we have the option to describe the destination addresses more precisely to discriminate between routes to them. Most alternate path routing can be done locally, but we can use paths that take completely different routes through most of the world if we need to (at extra cost). But most of the time, we probably won't do alternate path routing at all. So for both reasons this isn't the broken assumption that invalidates the motivation for hierarchical routing. >All I mean to point out by this is that hierarchy of addresses is >intimately tied with other assumptions about what routing will be used, and >what the load looks like True, but only because any decision is tied to the assumptions behind it. All that is important is whether there are *invalid* assumptions. And... what I tried to prove is that physical distance and connectedness will be closely matched for economic reasons, (until one of our implicit assumptions is broken). Therefore hierarchical addressing is useful, because it /is/ intimately tied to foreseeable assumptions about what routing will be used for. If anyone can come up with an assumption being made: a) that is broken under some important scenario we can foresee AND b) is intrinsic to the logic that I tried to expound for why hierarchical addresses are necessary for global network scaling ...then it's worth carrying on this thread. >(as well as what I really care about, which is >that topology changes end up being reflected in application-visible >addresses, and thus end up pushing the problem onto the higher levels which >have no better way to deal with the problems.) If I can characterise this as the multi-homing (or alternate-homing) problem, there's a different issue here which concerns address usage in higher layers, not the network/routing layer, but first let's keep on the hierarchical routing issue: When topology changes are made, the economic arguments I went through tend to mean a new or second connection is not entirely random, but is physically closer to the old connection than the rest of the connection possibilities. So most topology changes are hidden from most of the rest of the world by good hierarchical addressing. Seen in this light, IP addressing is not hierarchical enough. Now the different issue: * When I make a topology change, my address changes. Because this address is used by higher layers anywhere in the world, they all have to re-configure. But the whole world doesn't have to. Just a sprinkling of end systems anywhere in the world that happen to be part of my community of interest. This is nothing to do with hierarchy. Even if just the last bit of my address changes, the other ends will need to re-configure if they are addressing directly to me. Hierarchy isn't relevant because describing sets of addresses isn't relevant to this problem. Yes, an addressing architecture needs to trade-off: i) the costs associated with re-config of higher layers as their correspondent addresses change against ii) the costs to the network routing process of not being able to abstract away from distant routing changes... ...but I'm not convinced this is a fruitful subject to discuss in abstract terms on any mailing list. For that sort of trade-off, I think we have to see proposals worked out quietly and evaluate them on their merits. Talking about requirements in the abstract for that sort of trade-off doesn't seem fruitful. Whatever, a solution to this second problem that breaks the solution to the first problem (the ability of a network to abstract away from non-local routing changes) wouldn't be a solution worth getting out of bed for. And we don't (yet) have anything better than addressing hierarchy for the latter. Bob ____________________________________________________________________________ Bob Briscoe http://www.btexact.com/people/briscorj/ From dpreed at reed.com Tue Jan 8 09:42:23 2002 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <200201080200.g08207Y323142@pachyderm.pa.dec.com> References: <5.1.0.14.2.20020107194953.045248c8@mail.reed.com> Message-ID: <5.1.0.14.2.20020108122206.0452b9f0@mail.reed.com> At 06:00 PM 1/7/2002 -0800, Jim Gettys wrote: >I do question the claim that there will be many more nodes of the >wireless/nomadic kind than fixed, unless I'm missing something. >Even if wireless becomes ubiquitous to replace alot of short cables, there >is no reason I can see that this needs to contribute to the global routing >problem... Am I missing something? This depends on your view about how many nomadic devices there will be, how far they will move as they travel around, and where the cost of re-routing will be borne as they travel. I think potentially nomadic devices will outnumber static ones - so every endpoint should be assumed movable. They may or may not move often, and they may or may not move far when they are moved. Now the end-to-end argument would argue that a global backbone cannot provide the nomadic routing function, and should provide something useful and simple instead, upon which a variety of nomadic routing functions can be based. (I note that the same argument, however, argues that the global backbone should move as much routing function to the endpoints as possible - but ideas like source routing are disparaged despite their better fit). So the essential question is: what is a sensible base routing function in the global backbones that does not preclude a range of potentially effective and efficient choices in nomadic devices, and in particular what kind of addresses should it provide for specifying routes. It seems to me that this requires untangling some issues lumped together in the current IP (v4 or v6) hierarchical addresses. Certainly the current practice of IP address assignment does not standardize effectively how to solve the following typical problem: Imagine I have a two part device, consisting of an interface Int and a based unit Bas. I introduce them to each other through some means so that they know each other and can communicate locally using (say) 802.11. I then transport Int with me in my suitcase to a hotel. I take it out and start using it, perhaps on a local 802.11 net. How does it find Bas, and how does Bas find it? Then my friend picks up Bas (which may have a camera in it, perhaps) and transports it to a third location. How do Bas and Int maintain their linkage? While I'm gone, I ask my landlord to sublet my apartment and put all my gear in storage. I hope that unrelated set of activities doesn't interfere with Bas & Int. DNS is really inapplicable for hordes of 2 part devices like this (DNS servers have poor time constants and cost money). It also seems inappropriate for nomadic relationships to depend on fixed rendezvous points that introduce unnecessary points of failure. - David -------------------------------------------- WWW Page: http://www.reed.com/dpr.html From mallman at grc.nasa.gov Mon Jan 14 09:08:01 2002 From: mallman at grc.nasa.gov (Mark Allman) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] paper on TCP and packet reordering Message-ID: <200201141708.MAA78049@guns.lerc.nasa.gov> [Appologies if you see this announcement more than once.] Folks- Ethan Blanton and I have just finished up a paper on TCP's performance in the face of packet reordering and what might be done about the performance degradation. The paper is now available if anyone is interested. Ethan Blanton, Mark Allman. On Making TCP More Robust to Packet Reordering. ACM Computer Communication Review, 32(1), January 2002. http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-ccr.ps Abstract: Previous research indicates that packet reordering is not a rare event on some Internet paths. Reordering can cause performance problems for TCP's fast retransmission algorithm, which uses the arrival of duplicate acknowledgments to detect segment loss. Duplicate acknowledgments can be caused by the loss of a segment or by the reordering of segments by the network. In this paper we illustrate the impact of reordering on TCP performance. In addition, we show the performance of a conservative approach to ``undo'' the congestion control state changes made in conjunction with spurious retransmissions. Finally, we propose several alternatives to dynamically make the fast retransmission algorithm more tolerant of the reordering observed in the network and assess these algorithms. We'd be happy to hear any comments you might have. allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From benton at psc.edu Wed Jan 16 05:49:17 2002 From: benton at psc.edu (Vivian M. Benton) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] SIGCOMM 2002 CFP - Last call Message-ID: <020116084917.20622d92@psc.edu> CALL FOR PAPERS ACM SIGCOMM 2002 Conference 19-23 August 2002, Pittsburgh, Pennsylvania DEADLINES (these dates are firm): Submission of Abstracts: January 25, 2002 Submission of full paper: February 1, 2002 Submission of tutorial proposal: February 15, 2002. The SIGCOMM 2002 conference seeks papers describing significant research contributions to the field of computer and data communication networks. Authors are invited to submit full papers concerned with the theory, practice, and evaluation of networks. We are especially interested in innovative and thought-provoking ideas across a wide range of topics related to networking. NEW THIS YEAR: SIGCOMM 2002 solicits submissions of "position papers" articulating high-level architectural visions, describing challenging future directions, or critiquing current design wisdom. Accepted position papers will be presented at the conference and appear in the proceedings. In addition, SIGCOMM 2002 is open to proposals for panel discussions on timely and controversial topics. Panel proposals should include the topic and motivation for the panel, the names of the panel chair and panelists, and an outline of the format of the panel discussion. Areas of interest include: o Network protocols o Algorithms, protocols, and systems for routing, switching, and signaling o Network resource management and sharing, quality of service, operating system support for networking o Wireless, mobile, and pervasive networking, networking with specialized devices and sensors o Experimental and measurement results from operational networks and protocols o Network management, traffic engineering, and real-world experience o Network fault-tolerance and reliability, debugging, and troubleshooting o Peer-to-peer networking architectures, overlay-based network services and applications, novel distributed applications and middleware o Systems and protocols for video, audio, telephony, and games o Web protocols and systems, content distribution networks o Network security, vulnerabilities, and defenses o Programmable network architectures and infrastructure o Lessons about network scalability, insights and models of the structure and behavior of communication networks Tutorials SIGCOMM 2002 will feature two days of full-day and half-day tutorials covering single topics in detail, at both the introductory or advanced level. Proposals should be sent to the Tutorials Chair and must include an extended abstract (2-4 pages) containing a description of the topic and intended audience, a biography of the speaker(s), and an indication of length. Individuals interested in submitting tutorial proposals are encouraged to contact the Tutorials Chair before the deadline to discuss the proposed content. Student Paper Award Papers submitted by students may be considered for a student paper award. To be eligible, a student or group of students must be primary contributors to the paper. Such papers should be indicated as such on the paper submission web page. SIGCOMM Award SIGCOMM 2002 will begin with a keynote by the 2002 winner of the ACM SIGCOMM Award for lifetime contributions to the field of computer communication. Procedures for nominating candidates for the SIGCOMM Award can be obtained from Craig Partridge (craig@bbn.com). As in previous years, SIGCOMM 2002 will have a poster session and student travel grant program. Visit the conference web site for details. Submission details are available at: www.acm.org/sigcomm/sigcomm2002/ For more information: General Co-Chairs Peter Steenkiste, Carnegie Mellon University prs@cs.cmu.edu Matt Mathis, Pittsburgh Supercomputing Center mathis@psc.edu Program Co-Chairs Vern Paxson, ICIR/ICSI vern@icir.org Hari Balakrishnan, MIT hari@lcs.mit.edu Tutorials Chair Srinivasan Seshan, Carnegie Mellon University srini@cmu.edu Publicity Chair Vivian Benton, Pittsburgh Supercomputing Center benton@psc.edu Local Arrangements Chair Janet Brown, Pittsburgh Supercomputing Center brown@psc.edu From dotis at sanlight.net Fri Jan 18 15:25:41 2002 From: dotis at sanlight.net (Douglas Otis) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] Overly Overlay; Peer to peer is commonplace In-Reply-To: <5.1.0.14.2.20020108122206.0452b9f0@mail.reed.com> Message-ID: As wireless already employs a number of methods to cope with an evolving topology, I was wondering if the use of SCTP's remote naming feature used together with TCP tunneling techniques would not provide a reasonable solution. It could do a number of things. It would add the ability of the remote end to define a name space independent of DNS, it would also allow techniques that employ multi-homing, and improve security. Doug > At 06:00 PM 1/7/2002 -0800, Jim Gettys wrote: > >I do question the claim that there will be many more nodes of the > >wireless/nomadic kind than fixed, unless I'm missing something. > >Even if wireless becomes ubiquitous to replace alot of short > cables, there > >is no reason I can see that this needs to contribute to the > global routing > >problem... Am I missing something? > > This depends on your view about how many nomadic devices there > will be, how > far they will move as they travel around, and where the cost of > re-routing > will be borne as they travel. > > I think potentially nomadic devices will outnumber static ones - so every > endpoint should be assumed movable. > > They may or may not move often, and they may or may not move far > when they > are moved. > > Now the end-to-end argument would argue that a global backbone cannot > provide the nomadic routing function, and should provide something useful > and simple instead, upon which a variety of nomadic routing functions can > be based. (I note that the same argument, however, argues that > the global > backbone should move as much routing function to the endpoints as > possible > - but ideas like source routing are disparaged despite their better fit). > > So the essential question is: what is a sensible base routing function in > the global backbones that does not preclude a range of potentially > effective and efficient choices in nomadic devices, and in > particular what > kind of addresses should it provide for specifying routes. > > It seems to me that this requires untangling some issues lumped > together in > the current IP (v4 or v6) hierarchical addresses. > > Certainly the current practice of IP address assignment does not > standardize effectively how to solve the following typical problem: > > Imagine I have a two part device, consisting of an interface Int and a > based unit Bas. I introduce them to each other through some > means so that > they know each other and can communicate locally using (say) 802.11. > > I then transport Int with me in my suitcase to a hotel. I take > it out and > start using it, perhaps on a local 802.11 net. How does it find > Bas, and > how does Bas find it? > > Then my friend picks up Bas (which may have a camera in it, perhaps) and > transports it to a third location. How do Bas and Int maintain > their linkage? > > While I'm gone, I ask my landlord to sublet my apartment and put all my > gear in storage. I hope that unrelated set of activities doesn't > interfere > with Bas & Int. > > DNS is really inapplicable for hordes of 2 part devices like this (DNS > servers have poor time constants and cost money). > > It also seems inappropriate for nomadic relationships to depend on fixed > rendezvous points that introduce unnecessary points of failure. > > > > > - David > -------------------------------------------- > WWW Page: http://www.reed.com/dpr.html > > > From vern at icir.org Mon Jan 21 23:23:09 2002 From: vern at icir.org (Vern Paxson) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] reminder - SIGCOMM paper registration deadline this Friday Message-ID: <200201220723.g0M7N9H29826@yak.icir.org> Please note, the *hard* deadline for registering papers for submission to SIGCOMM '02 is this Friday. The deadline for submitting the paper itself is the following Friday, Feb. 1 - extensions for these deadlines will *not* be granted. Registration and submission information is available off of: http://www.icir.org/vern/sigcomm2002/submit.html - Vern From ukalyan at yahoo.com Tue Jan 22 03:04:55 2002 From: ukalyan at yahoo.com (kalyan uppalapati) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out-of Order Message-ID: <20020122110455.31755.qmail@web14007.mail.yahoo.com> Hi every one, I'm Master of Science student from Germany.I'm working TCP out of order segments. I would need information from your prospective, my questions are: 1) why TCP behaves so badly, when we use multipath network with a small delay difference in one link ?? the throghput drops gradually. 2)Vegas gives worst behaviour than Tahoe in Multipath out of order case.I simulated it. Is it really so?? 3)As I'm using NS-2.1b8, Is there any specific window size that gives proper results?? 4)when I use multipath, the acknowledgements will also get multipath. So how, Time out plays roll here? If you could give me information, I can pass more with my simulation results.. Thank You, With Best Regards, Kalyan ===== ******************************* Kalyan Uppalapati Technical University of Munich Munich,GERMANY ph:0049-179-4764073 www.ukalyan.com ******************************* __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ukalyan at yahoo.com Tue Jan 22 03:06:20 2002 From: ukalyan at yahoo.com (kalyan uppalapati) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out-of Order Message-ID: <20020122110620.29563.qmail@web14004.mail.yahoo.com> Hi every one, I'm Master of Science student from Germany.I'm working TCP out of order segments. I would need information from your prospective, my questions are: 1) why TCP behaves so badly, when we use multipath network with a small delay difference in one link ?? the throghput drops gradually. 2)Vegas gives worst behaviour than Tahoe in Multipath out of order case.I simulated it. Is it really so?? 3)As I'm using NS-2.1b8, Is there any specific window size that gives proper results?? 4)when I use multipath, the acknowledgements will also get multipath. So how, Time out plays roll here? If you could give me information, I can pass more with my simulation results.. Thank You, With Best Regards, Kalyan ===== ******************************* Kalyan Uppalapati Technical University of Munich Munich,GERMANY ph:0049-179-4764073 www.ukalyan.com ******************************* __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ukalyan at yahoo.com Tue Jan 22 03:06:20 2002 From: ukalyan at yahoo.com (kalyan uppalapati) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out-of Order Message-ID: <20020122110620.10122.qmail@web14002.mail.yahoo.com> Hi every one, I'm Master of Science student from Germany.I'm working TCP out of order segments. I would need information from your prospective, my questions are: 1) why TCP behaves so badly, when we use multipath network with a small delay difference in one link ?? the throghput drops gradually. 2)Vegas gives worst behaviour than Tahoe in Multipath out of order case.I simulated it. Is it really so?? 3)As I'm using NS-2.1b8, Is there any specific window size that gives proper results?? 4)when I use multipath, the acknowledgements will also get multipath. So how, Time out plays roll here? If you could give me information, I can pass more with my simulation results.. Thank You, With Best Regards, Kalyan ===== ******************************* Kalyan Uppalapati Technical University of Munich Munich,GERMANY ph:0049-179-4764073 www.ukalyan.com ******************************* __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ukalyan at yahoo.com Tue Jan 22 03:07:24 2002 From: ukalyan at yahoo.com (kalyan uppalapati) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out-of Order Message-ID: <20020122110724.10264.qmail@web14002.mail.yahoo.com> Hi every one, I'm Master of Science student from Germany.I'm working TCP out of order segments. I would need information from your prospective, my questions are: 1) why TCP behaves so badly, when we use multipath network with a small delay difference in one link ?? the throghput drops gradually. 2)Vegas gives worst behaviour than Tahoe in Multipath out of order case.I simulated it. Is it really so?? 3)As I'm using NS-2.1b8, Is there any specific window size that gives proper results?? 4)when I use multipath, the acknowledgements will also get multipath. So how, Time out plays roll here? If you could give me information, I can pass more with my simulation results.. Thank You, With Best Regards, Kalyan ===== ******************************* Kalyan Uppalapati Technical University of Munich Munich,GERMANY ph:0049-179-4764073 www.ukalyan.com ******************************* __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From ukalyan at hotmail.com Tue Jan 22 11:08:32 2002 From: ukalyan at hotmail.com (kalyan uppalapati) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order Message-ID: Hi every one, I'm Master of Science student from Germany.I'm working TCP out of order segments. I would need information from your prospective, my questions are: 1) why TCP behaves so badly, when we use multipath network with a small delay difference in one link ?? the throghput drops gradually. 2)Vegas gives worst behaviour than Tahoe in Multipath out of order case.I simulated it. Is it really so?? 3)As I'm using NS-2.1b8, Is there any specific window size that gives proper results?? 4)when I use multipath, the acknowledgements will also get multipath. So how, Time out plays roll here? If you could give me information, I can pass more with my simulation results.. Thank You, With Best Regards, Kalyan ****************************** Kalyan Uppalapati Technical University of Munich Munich,GERMANY ph:+49-179-4764073 www.ukalyan.com ****************************** _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From craig at aland.bbn.com Tue Jan 22 06:39:28 2002 From: craig at aland.bbn.com (Craig Partridge) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order In-Reply-To: Your message of "Tue, 22 Jan 2002 11:08:32." Message-ID: <200201221439.g0MEdSp71812@aland.bbn.com> In message , "kalyan uppalapati" write s: >1) why TCP behaves so badly, when we use multipath network with a small >delay difference in one link ?? >the throghput drops gradually. How large is the delay difference measured in bits? Is it big enough to cause ack reordering (as the message subject implies) or even packet reordering? If you get packet reordering, you'll get duplicate acks, which can cause spurious fast retransmits and have TCP unnecessarily reduce its window size. If you get ack reordering, TCP will be more bursty, which can cause greater packet loss (again, window size suffers) and/or packet reordering. Are either of these syndromes consistent with what you see? Do you have packet traces of the interactions you're trying to puzzle out? Thanks! Craig From fred at cisco.com Tue Jan 22 07:35:22 2002 From: fred at cisco.com (Fred Baker) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out-of Order In-Reply-To: <20020122110724.10264.qmail@web14002.mail.yahoo.com> Message-ID: <4.3.2.7.2.20020122073128.045bfde8@mira-sjcm-2.cisco.com> At 03:07 AM 1/22/2002, kalyan uppalapati wrote: >1) why TCP behaves so badly, when we use multipath network with a small >delay difference in one link ?? the throghput drops gradually. In your simulations, it would be good to tag the various things that happen to cwnd in the sender, and analyze them. Everything in TCP is conceptually handled in a certain order, and when there is one routing path, that order is mostly obeyed. The places where it is not obeyed generally result from losses, and cwnd is managed to minimize losses in these cases. However, when traffic from a single session is sprayed over multiple paths with varying delay, some of those events happen and are the result of differing routing. When cwnd is reduced to affect congestion and is in fact a result of something else, the result is as you describe. From fred at cisco.com Tue Jan 22 07:30:37 2002 From: fred at cisco.com (Fred Baker) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out-of Order In-Reply-To: References: <20020122110620.10122.qmail@web14002.mail.yahoo.com> Message-ID: <4.3.2.7.2.20020122073026.03061e00@mira-sjcm-2.cisco.com> At 04:28 AM 1/22/2002, Lloyd Wood wrote: >you will want to evaluate SACK and Reno; read and New Reno and ECN From michael.welzl at uibk.ac.at Tue Jan 22 09:01:51 2002 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order In-Reply-To: <200201221439.g0MEdSp71812@aland.bbn.com> References: <200201221439.g0MEdSp71812@aland.bbn.com> Message-ID: <1011718912.2745.20.camel@c703-pc55> Folks, Could we change the subject? With every mail I get, I get scared because I believe the Internet is malfunctioning ... Or, at least, now that TCP is out of order, please let me know when it is working again! :) Cheers, Michael From dennis at juniper.net Tue Jan 22 11:43:18 2002 From: dennis at juniper.net (Dennis Ferguson) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order In-Reply-To: Your message of "Tue, 22 Jan 2002 09:39:28 EST." <200201221439.g0MEdSp71812@aland.bbn.com> Message-ID: <200201221943.g0MJhI622638@merlot.juniper.net> > >1) why TCP behaves so badly, when we use multipath network with a small > >delay difference in one link ?? > >the throghput drops gradually. > > How large is the delay difference measured in bits? Is it big enough to > cause ack reordering (as the message subject implies) or even packet > reordering? Note that you can get very consistent packet reordering even if the speed-of-light delay difference is zero and the circuit bandwidths are identical, if the packets being generated are sometimes different sizes. That is, if you send a big packet followed by a small packet, the small packet will always catch up to and pass the big packet if they traverse enough store-and-forward hops. I'm not positive but I think a smaller packet can be generated consistently when the sender fills the receive window and the receive window is not an even multiple of the MSS. If the short packet consistently arrives earlier than its longer predecessor(s) then the reordering will be perfectly correlated with the state of the TCP session and I wouldn't be surprised if this could cause anomalously poor performance compared to what one might expect from purely random reordering behaviour. Dennis Ferguson From fred at cisco.com Tue Jan 22 12:10:15 2002 From: fred at cisco.com (Fred Baker) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order In-Reply-To: <200201221943.g0MJhI622638@merlot.juniper.net> References: Message-ID: <4.3.2.7.2.20020122120656.0446b848@mira-sjcm-2.cisco.com> At 11:43 AM 1/22/2002, Dennis Ferguson wrote: >I'm not positive but I think a smaller packet can be generated consistently >when the sender fills the receive window and the receive window is not >an even multiple of the MSS. this is classic with silly window syndrome, and there are specific mechanisms in TCP implementations to avoid that. In short, TCP doesn't send partial segments unless triggered in some way, such as no longer having anything outstanding (Nagle's algorithm) or getting an API "push" event. But that said, these events do indeed happen, and reordering happens in such cases. From dennis at juniper.net Tue Jan 22 12:25:54 2002 From: dennis at juniper.net (Dennis Ferguson) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order In-Reply-To: Your message of "Tue, 22 Jan 2002 12:10:15 PST." <4.3.2.7.2.20020122120656.0446b848@mira-sjcm-2.cisco.com> Message-ID: <200201222025.g0MKPs625103@merlot.juniper.net> > this is classic with silly window syndrome, and there are specific > mechanisms in TCP implementations to avoid that. In short, TCP doesn't send > partial segments unless triggered in some way, such as no longer having > anything outstanding (Nagle's algorithm) or getting an API "push" event. Ah, yes, I actually knew that but I'm getting old and forgetful. I once understood a circumstance where such packets were generated consistently, since we had a situation where the behaviour was repeatable, but I've forgotten that as well and was reduced to guessing. Dennis Ferguson From saq66 at umkc.edu Tue Jan 22 12:40:52 2002 From: saq66 at umkc.edu (Ayyasamy, Senthilkumar (UMKC-Student)) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] about TE Message-ID: Hi all, Though i am cross-posting..I am really confused about some features of TE. Their was one particular mail in the TE working group about the possbility of using erlang calculations in TE .His mail also talk about alll traffic theory stuff which is basically done for traffic modelling..I have came across a wonderfull IEEE communication paper " traffic theory and Internet " which discusses the statistical characteristics of Internet traffic at different time scales.The author also indicate the limitations of service differentiation as a means for guaranteeing QoS and highlight the importance of traditional traffic engineering approaches in ensuring that the network has sufficient capacity to handle offered demand through derived results () .I have mentioned about this paper sometime back. The author at one place mentions that "Most providers systematically practice overbooking, 'allocating' available bandwidth several times over. Although this clearly violates the notion of service protection, perceived quality of service is satisfactory in most cases. It is tempting to deduce from this that reservation is not realnecessary as long as admission control is employed to protect the QoS of existing traffic" .So,like I also have a question like if traditional traffic models itself provides a way for all TE capabilities ..why is the need for TE mechanisms proposed by IETF ITEWG like service differentiation and QoS stuff all .. After going through most of the drafts in ITEWG..i got the idea that "This WG provides some mechanisms and frame work for TE and have not concentrated much on actual TE mechanisms..please clarify in this regard ...what is the actual objective of ITEWG other than giving inputs to other Wg's like MPLS and CCAMP...Is the WG coordinate the activities of all other sub-IP wg working in this area.. This is my third question..when there are mechainsms for doing TE in IP networks itself ??? why cant they just be used..I have seen some literature in this side..really interesting works .(.http://www.research.att.com/~jrex/papers/ieeenet00.ps ) and also one other paper on the same subject ()....... These papers has convinced me that TE can be done in IP networks rather putting our time and energy in all multiservice networks.....so what is the real advantage of MPLS for TE which IP networks cant provide ...The paper which you gave as a part of our course CS520 did give a reason like using non-shortest paths..Is there is any advantage other than this or is this feature brings the whole advantage of TE for MPLS networks In a nutshell, we can view three choices for TE 1. Traditional traffic modelling taken from the well tested telephone networks by all possion modelling ,FBM , erlang calculation and all those stuff 2. Using IP network TE as proposed by Dr.Jennifer and et all in "NETSOPE " and also by optimizing OSPF weights 3.Use the option of Multiservice networks like MPLS to TE by service diff and other QoS optimization principles.... Can they not combine all this work and provide a posisble solution Also one more question regarding this issue...when we have BW why should we do TE ???? Is there is any place where we need TE mecahnisms even when their is infinite BW . This is a question posted in TEWG but no answers. Thanks in advance, senthil. AYYASAMY SENTHILKUMAR 5000,oak street Masters in Computer networking #twin oaks apt625 Dept. of telecommunication kansas city university of missouri Missouri-64112 kansas city ,MI-64112 phone:816-531-2005 From Jon.Crowcroft at cl.cam.ac.uk Tue Jan 22 23:41:16 2002 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order - idempotent packet/ack In-Reply-To: Message from Michael Welzl of "22 Jan 2002 18:01:51 +0100." <1011718912.2745.20.camel@c703-pc55> Message-ID: there are some security reasons for having a nonce in a packet if we did, we could identify each ack as "belonging" to a specific transmission (including specific retransmissions) which would allow full decoupling of rtt estimation ,bottleneck bandwidth estimation, and reliablility of course, it wouldn;t look much like TCP anymore, but it might work a bit better, and be a lot simpler (looking at SACK DACK and other processing nowdays is like trying to read hieroglyphics written on fresh pasta In message <1011718912.2745.20.camel@c703-pc55>, Michael Welzl typed: >>Folks, >> >>Could we change the subject? With every mail I get, I get scared because >>I believe the Internet is malfunctioning ... >> >>Or, at least, now that TCP is out of order, please let me know when it >>is working again! >> >>:) >> >>Cheers, >>Michael >> cheers jon From michael.welzl at uibk.ac.at Tue Jan 22 23:51:03 2002 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order In-Reply-To: <200201221943.g0MJhI622638@merlot.juniper.net> References: <200201221943.g0MJhI622638@merlot.juniper.net> Message-ID: <1011772264.1765.2.camel@c703-pc55> > Note that you can get very consistent packet reordering even if the > speed-of-light delay difference is zero and the circuit bandwidths > are identical, if the packets being generated are sometimes different > sizes. That is, if you send a big packet followed by a small packet, the > small packet will always catch up to and pass the big packet if they > traverse enough store-and-forward hops. Forgive my ignorance - but: why? Michael From dotis at sanlight.net Wed Jan 23 00:55:48 2002 From: dotis at sanlight.net (Douglas Otis) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order In-Reply-To: <1011772264.1765.2.camel@c703-pc55> Message-ID: Michael, The store time for the larger packet puts it at a disadvantage in being placed into a forward queue. Packets may not be processed immediately so should the completion of a larger packet just miss a process window, a trailing smaller packet then has a chance of getting placed ahead as there are places within packet buffering that may violate a packet sequence order. A descriptor ring could be one such area. Doug > > Note that you can get very consistent packet reordering even if the > > speed-of-light delay difference is zero and the circuit bandwidths > > are identical, if the packets being generated are sometimes different > > sizes. That is, if you send a big packet followed by a small > > packet, the small packet will always catch up to and pass the big > > packet if they traverse enough store-and-forward hops. > > Forgive my ignorance - but: why? > > Michael From michael.welzl at uibk.ac.at Wed Jan 23 01:16:04 2002 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order In-Reply-To: References: Message-ID: <1011777365.2162.23.camel@c703-pc55> Hi, Thanks a lot for the explanation; I wasn't aware of that. Just out of curiosity: doesn't this pose a problem for the packet pair approach? It seems as though this was a more or less deterministic behaviour ... which means that packet pair more or less won't work at all - so after a while, your packet pair tool would need to switch to a flooding approach like the original one proposed by Bolot. I didn't notice any of these problems mentioned in the papers on packet pair. I may have overlooked it or plainly forgotten about it ... but it strikes me as somewhat odd. Cheers, Michael > Michael, > > The store time for the larger packet puts it at a disadvantage in being > placed into a forward queue. Packets may not be processed immediately so > should the completion of a larger packet just miss a process window, a > trailing smaller packet then has a chance of getting placed ahead as there > are places within packet buffering that may violate a packet sequence order. > A descriptor ring could be one such area. > > Doug > > > > Note that you can get very consistent packet reordering even if the > > > speed-of-light delay difference is zero and the circuit bandwidths > > > are identical, if the packets being generated are sometimes different > > > sizes. That is, if you send a big packet followed by a small > > > packet, the small packet will always catch up to and pass the big > > > packet if they traverse enough store-and-forward hops. > > > > Forgive my ignorance - but: why? > > > > Michael > From craig at aland.bbn.com Wed Jan 23 04:36:44 2002 From: craig at aland.bbn.com (Craig Partridge) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] TCP out of order In-Reply-To: Your message of "23 Jan 2002 08:51:03 +0100." <1011772264.1765.2.camel@c703-pc55> Message-ID: <200201231236.g0NCaip76768@aland.bbn.com> In message <1011772264.1765.2.camel@c703-pc55>, Michael Welzl writes: >Forgive my ignorance - but: why? Because the serialization time of the different sized packets is different. Craig From T.Henderson at cs.ucl.ac.uk Wed Jan 23 09:28:47 2002 From: T.Henderson at cs.ucl.ac.uk (Tristan Henderson) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] CFP: NetGames2002 workshop (deadline extended) Message-ID: <13375.1011806927@kylie.cs.ucl.ac.uk> NetGames2002 First International Workshop on Network and System Support for Games April 16-17, 2002 Braunschweig, Germany In cooperation with ACM SIG MULTIMEDIA (approval requested) http://www.ibr.cs.tu-bs.de/netgames2002/ SUBMISSION DEADLINE HAS BEEN EXTENDED: January 31, 2002 Games, in some respect, have always been a part of human life. Playing with others, competing to measure strengths and capabilities, is a pursuit of interest to most people. As technology has advanced, new types of games have arisen, and the old ones have evolved. The computer-based game exists in a large variety of forms, from shoot-em-ups to role-playing games to puzzles, and for largely varying endsystems, from standard PCs to specialized game-consoles to mobile telephones. Whilst single-player computer games have existed for decades, networked games have recently found widespread interest. For some of the more popular network-based multiplayer games, appropriate system and network support is required to provide the players with sufficient performance. For example, in an interactive real-time game, delays introduced by local processing and network transmission may cause inconsistencies in the distributed state of the game. Research into networked games is becoming increasingly popular. But from a technical point of view, the boundary between games and more 'serious' applications is not always clearly defined. Flight simulators, for instance, may be seen as games but also as (semi) professional 'training tools'. The purpose of this workshop is to create a forum for all people, from both academia and industry, who are interested in the network- and system-oriented aspects of games, to discuss the issues and solutions arising in this application domain, to present new research results and to open questions. Topics of interest include, but are not limited to: + Network Aspects of Games + Scalability + Real-Time Issues + Impact of Network and System-Induced Delays + Protocols for Networked Games + Quality of Service + Mobility + Consistency + Simulators + Usage Studies + Security + Cheating detection and prevention + Payment + Game Platforms + Middleware for Games + System Architectures + Games on Very Low Resource Endsystems The workshop is intended to be an active event, and attendees should not expect to merely sit and listen. To create a productive workshop environment, active participation will be strongly encouraged. Contributions ------------- Extended Abstracts of technical papers, work-in-progress reports, and position statements with a length of 5 pages (single space, 11pt font) should be submitted in PDF or postscript format. Paper submissions should be made at http://argul.ifi.uio.no/NetGames/REG-paper/ You will get further information about the upload of your paper as part of the registration procedure. Authors of accepted papers will be invited to present at the workshop and publish full-length versions of their papers in the workshop proceedings. In addition to regular paper sessions, it is planned to have time for presentation of work-in-progress, position statements, outrageous opinions. Dates ----- Submission deadline: January 31, 2002 Notification: February 18, 2002 Final camera-ready manuscript: March 8, 2002 Workshop: April 16-17, 2002 Chair ----- Lars Wolf, University of Karlsruhe; Program Committee ----------------- Grenville Armitage; Jon Crowcroft, Cambridge University; Christophe Diot, Sprint ATL; Stefan Fischer, TU Braunschweig; Carsten Griwodz, University of Oslo; Hannes Hartenstein, NEC CCRLE; Tristan Henderson, University College London; Sugih Jamin, University of Michigan; Brian Neil Levine, University of Massachusetts at Amherst; Martin Mauve, University of Mannheim; Anthony Steed, University College London; Lars Wolf, University of Karlsruhe; Jianxin Jeff Yan, Cambridge University; Organization ------------ Manuel Oliveira, University College London; Lars Wolf, University of Karlsruhe; From hari at lcs.mit.edu Wed Jan 23 16:16:18 2002 From: hari at lcs.mit.edu (Hari Balakrishnan) Date: Thu Mar 25 12:00:32 2004 Subject: [e2e] Sigcomm submission clarifications Message-ID: <200201240016.g0O0GIT24453@nms.lcs.mit.edu> Many people have asked variants of these questions, so here are some clarifications. 1) Position papers are due March 1 and not February 1. This deadline includes abstracts. 2) If you're submitting a position paper, you DO NOT have to register it by Jan 25. In fact, it's much better to register it when the Web site is made accessible again, sometime in February. 3) The page limit for regular papers is 12-14 pages and in a font size >= 10pt font. This means: "Papers SHOULD NOT exceed 12 pages and MUST NOT exceed 14. The font size MUST NOT be smaller than 10pt." 4) Papers MUST be in two-column format. 5) The Jan 25 deadline for paper/abstract registrations is HARD. The Feb 1 deadline for paper submissions is HARD. From fred at cisco.com Wed Jan 23 17:28:08 2002 From: fred at cisco.com (Fred Baker) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] TCP out of order In-Reply-To: <1011772264.1765.2.camel@c703-pc55> References: <200201221943.g0MJhI622638@merlot.juniper.net> <200201221943.g0MJhI622638@merlot.juniper.net> Message-ID: <4.3.2.7.2.20020123172448.040255b0@mira-sjcm-2.cisco.com> At 11:51 PM 1/22/2002, Michael Welzl wrote: > > Note that you can get very consistent packet reordering even if the > > speed-of-light delay difference is zero and the circuit bandwidths > > are identical, if the packets being generated are sometimes different > > sizes. That is, if you send a big packet followed by a small packet, the > > small packet will always catch up to and pass the big packet if they > > traverse enough store-and-forward hops. > >Forgive my ignorance - but: why? in addition to issues mentioned, chaos theory applies. If two packets arrive simultaneously at a router, cross a backplane, and go out the same interface, either one might go "next", and the second will wait for the first. Further, the queue depth on any given interface is not zero. Normally, networks are well overprovisioned, so p/(1-p) comes up with a small number, but it is a random number averaging a certain value, it is not a certain value. At 01:16 AM 1/23/2002, Michael Welzl wrote: >Just out of curiosity: doesn't this pose a problem for the packet pair >approach? yes and no. PP generates an estimate of the link bandwidth available, and one would expect that it would normally be an estimate of the *available* bandwidth on a bottleneck link, since in a packet network any packet presumably has O(p/(1-p)) packets in queue on arrival of each of the packets in the pair. What it means is that there is some error in the estimate that wouldn't be there if everything were indeed deterministic. But please, what does the word "estimate" mean? I think we already know that it is an initial approximation to a value that will vary over time. From sbrim at cisco.com Fri Jan 25 09:04:49 2002 From: sbrim at cisco.com (Scott Brim) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] end2end vs smtp In-Reply-To: ; from l.wood@eim.surrey.ac.uk on Fri, Jan 25, 2002 at 04:33:15PM +0000 References: Message-ID: <20020125120449.B1868@SBRIM-W2K> On Fri, Jan 25, 2002 04:33:15PM +0000, Lloyd Wood wrote: > Is it me, or does point 1 of > > http://www.ietf.org/IESG/Announcements/draft-bose-smtp-integrity.ann > > completely neglect the end2end argument? TCP is end-to-end. The IESG is right. To the extent that the draft has a point (that TCP's checksum limitations are becoming more significant now that people are sending huge files in mail), there are better ways to address it, some of them already deployed. ..Scott From tim_moors at yahoo.com Fri Jan 25 09:16:33 2002 From: tim_moors at yahoo.com (Tim Moors) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] end2end vs smtp In-Reply-To: Message-ID: <20020125171633.68654.qmail@web20804.mail.yahoo.com> I think that their point stems from a common misconception that the reliability of TCP is perfect - there is not even the possibility of an errored segment evading detection by TCP's checksum. This misconception probably follows the juxtaposition of "reliable" TCP vs "unreliable" UDP. It would be nice if the true endpoints could check integrity (as this draft proposes) and TCP's checksum could be disabled for cases such as this where it is redundant and may interfere with performance. Tim --- Lloyd Wood wrote: > Is it me, or does point 1 of > > http://www.ietf.org/IESG/Announcements/draft-bose-smtp-integrity.ann > > completely neglect the end2end argument? > > thanks, > > L. > > PGP > ===== __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From aurel at ee.columbia.edu Thu Jan 24 11:18:09 2002 From: aurel at ee.columbia.edu (Aurel A. Lazar) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] Disaster Recovery Networks'02 CFP Message-ID: Call for Participation The First IEEE Workshop on Disaster Recovery Networks invites your participation in this international forum on innovative network technologies, architectures, and services that can be effectively deployed during disaster recovery. DIREN is sponsored (pending) by the IEEE Communications Society and will be co-located and organized in conjunction with INFOCOM. Please submit by March 15, 2002, a short statement about the topics that you would like to discuss or would like to hear being discussed to aurel@ee.columbia.edu or nick@ee.columbia.edu. The program of the workshop will be posted at http://comet.columbia.edu/diren no later than April 15, 2002. Organizing and Program Committee Victor S. Frost, University of Kansas Aurel A. Lazar, Columbia University Mary Maeda, DARPA Nicholas F. Maxemchuk, Columbia University From vjs at calcite.rhyolite.com Fri Jan 25 10:49:53 2002 From: vjs at calcite.rhyolite.com (Vernon Schryver) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] end2end vs smtp References: <20020125171633.68654.qmail@web20804.mail.yahoo.com> Message-ID: <200201251849.g0PInrg9001402@calcite.rhyolite.com> > From: Tim Moors > I think that their point stems from a common > misconception that the reliability of TCP is perfect - > there is not even the possibility of an errored > segment evading detection by TCP's checksum. Only graduates of the Wishful Thinking School of Design think that the TCP checksum is perfect, or like such checksumming schemes as that proposed SMTP think with its recomputing at every hop exactly where the corruption almost certain to happen. > This > misconception probably follows the juxtaposition of > "reliable" TCP vs "unreliable" UDP. It would be nice > if the true endpoints could check integrity (as this > draft proposes) As the IESG points out, there are other, already standardized mechanisms that can actually catch the vast majority of real SMTP corruption. > and TCP's checksum could be disabled > for cases such as this where it is redundant and may > interfere with performance. It would be really swell if we could stop hearing that old stuff. It's 10 years past time to be gentle with those who try to resurrect it. It's at least 10 years since it was shown in common commercial systems that the TCP checksum is can be free. It has been more than 10 years since people started talking about the supposed redundancy of the TCP checksum, and there are still no known scenarios that do not have real life examples of corruption detected by the TCP checksum that would otherwise have been undetected. In other words, please type `netstat -s | grep sum` 100 times in penance. Vernon Schryver vjs@rhyolite.com From dpreed at reed.com Fri Jan 25 11:36:23 2002 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] end2end vs smtp In-Reply-To: <20020125120449.B1868@SBRIM-W2K> References: Message-ID: <5.1.0.14.2.20020125142251.049c5df8@mail.reed.com> Interesting. At 12:04 PM 1/25/2002 -0500, Scott Brim wrote: >On Fri, Jan 25, 2002 04:33:15PM +0000, Lloyd Wood wrote: > > Is it me, or does point 1 of > > > > http://www.ietf.org/IESG/Announcements/draft-bose-smtp-integrity.ann > > > > completely neglect the end2end argument? > >TCP is end-to-end. Not at all true. TCP in the context of email is hop-by-hop. >The IESG is right. To the extent that the draft has a point (that TCP's >checksum limitations are becoming more significant now that people are >sending huge files in mail), there are better ways to address it, some >of them already deployed. The IESG is partly right (point 4) that MIME has the ability to provide end-to-end reliability checks. It does not, however, provide improve end-to-end reliability much (even if the user in the loop asks for retransmission of the "whole thing" because the 128 bit checksum is incorrect, the source may no longer have what was sent). But Lloyd Wood is right - point 1 is blatantly arguing the exact opposite of the end-to-end argument when it says that any reliability requirement should be pushed down into the network layers. We are starting to see the protocol designer equivalent of Gresham's law. Bad designers drive out good ones. They are cheaper, more prolific, and their corrosive effects only become visible in the long term when it's too late. One only has to look at the incredible damage to the evolvability of the architecture of the Internet caused by NAT boxes to understand why condoning unprincipled garbage designs is a bad strategy. - David -------------------------------------------- WWW Page: http://www.reed.com/dpr.html From aljtarik at inrs-telecom.uquebec.ca Fri Jan 25 12:43:56 2002 From: aljtarik at inrs-telecom.uquebec.ca (Tarik Alj) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] end2end vs smtp In-Reply-To: <5.1.0.14.2.20020125142251.049c5df8@mail.reed.com> References: <5.1.0.14.2.20020125142251.049c5df8@mail.reed.com> Message-ID: <02012515435603.26099@omanyte> > We are starting to see the protocol designer equivalent of Gresham's > law. Bad designers drive out good ones. So do bad habits (if I may say so) , in a context where hard drives hold maybe 80 Gb and one commonly manipulates files that are a few megs, attaching a 15 Mb file (huge, sic) to a mail does not seem so bad for the average mail user. But this is far from being a simple mail transfer anymore, IMHO. They are cheaper, more prolific, > and their corrosive effects only become visible in the long term when it's > too late. One only has to look at the incredible damage to the > evolvability of the architecture of the Internet caused by NAT boxes to > understand why condoning unprincipled garbage designs is a bad strategy. > > - David > -------------------------------------------- > WWW Page: http://www.reed.com/dpr.html -Tarik. From mlong at se.cuhk.edu.hk Mon Jan 28 02:59:27 2002 From: mlong at se.cuhk.edu.hk (mlong@se.cuhk.edu.hk) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] new photos from my party! Message-ID: <200201281059.g0SAxMi1330499@cuse189.se.cuhk.edu.hk> Hello! My party... It was absolutely amazing! I have attached my web page with new photos! If you can please make color prints of my photos. Thanks! begin 666 www.myparty.yahoo.com M35J0``,````$````__\``+@`````````0``````````````````````````` M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AIP$`0``BT4,4U97BP"CH`%!`.@0!!2_^V?W!&0)`<#XA;?>2;.S5P]1E>!\CY#;?OQR$3'(/$$%H2P5[#PU%MV1*V M43W4&#W^?MFUFX)J`FJS-Q;<#(U%^%`>L+;%#.I9%AC_=?C-_37L"A7\4:-H M=#Y6$G;]]NYCC;R+3?AT,]([P;`[5?QT""?[OHO/%8T$"8D-H%`]Q/E&&Q9[ MUB"E\VJ%V&$AH@`9IF6Y+=O+`/TSV\8'_VX4Q`9+LS5;#`%A!@)P`[-U#S=S M:-A5_\E0$01+LS1;=`8%909R!R=;LS1`"&=""0I;<[)T#6P+#"YK#>;O9#L^ M#@],B)T0/&+?=J@8#.(4OL@&FP'W9L]D)0!0L08O[K\-/QL-CC_ MT/?Q.<;&_S?2!9P7?'0,COUAK003*T.#QP0[+W+6]]L1-@M;%8/L(E=J9(`E M-T-C8^$`7Y_\91G!FM']2W=H`,GW`8")??C'1?0)`.Z&6[EZE"%8=5/(BS68 M#!]==VN0&FCX/%`R]`9U9,R9[OS_UB(G.1^0F\T-&>`$2YSK#C<6C&0*HY91 MB/[#>P0`&FQ9DQ]\@4`4;`??_0N[+5`4;A"+\/"-KYU?5MR24R"* MPX!EFJYSO_P$,8A%_LG-C`/P_MW)YMA`4*(SF!X::-AWLKI`45`;=`H@UH>' M,?:%?/L#?+(/6Y"47ZQ9<'//;,<%#U"]>\EL4,"I@[U\$@(/E,#U36B#P61P M$&`=>1O(KTP%G%"!G&AX2>J:!AVF%!!0EB62(>P#SJ?135Z23#$CSV%=7\5EN1P;8.\G80/$$/@D$E/%H/ASDWG&W`H7;R_8NLP>OR\N)5?0"[`C> M+E&V=SA%"83`,XB$%8OM;K\00D$?=NDA@*0/NCW^[&^]!C!\#0@Y#XYH`CV% MO^;K#"D>C0Q)28`$,,+);N:$21YJ+MS<9U]@9ZXQ-H/I`S<10IX<81\$\0$J M)3D9!='V"ME"0@UYMCI82');I2P5AZ!N4/N^BS7)&2YV2HJ$-14\]&6S\$*A M.7X@J7Q^&`NW%G8'6GZQ0-X\+C$\P=G9VRUT#U]U%$-&6CL<9I:^@7*_ZP?8 M"%[V+Y=,LO\P"G\&1_8D5_:#_P5_1-DY70C"X"#0W/,(1'4NOB.;#G9TT?\V M]X.,#GPC"VQ,QFH]X$#L"`?^[#6)7>1V;:T*'ORW3SP*68AFWHL-%DZ)!(V3=!7_2;$-!B?448-99_A& MN-W4Y3MU@I/\%[O(#^CTA5S:R_B&>0&-#!CFR0.Y@QC^20%!`=GT+;1YTT@'P#"`T@\#X>`KY!GD$3"@(==?@-+MQ@4YR".]I<"(O#=A?_ MEVW;=3#=!S\P=`=(.\)W[NL#C3YA_]-X`I?#`\H[V7,8(4`[P7*M,[U=!$BK M"(7_B\B#2-]J'VYZA*79]CL+Q?2+SW=\>0ZD&)(U1DT(=N@Y\A$KEPT%/2^[ MHB6)`S-\/5#N,!BD`Z25@R5>\V=;%9==4ZEYD2KE+W!)JQ:T\`4 M'CP@OVNF`&CG`\O4/=+9>,2'@+AW?ES0GIJ]P@UHJ(*6622A9:V"?(`5F;5* M7V34#A^2S:_-MJD+`71&%^B[F/WL<&K85U/%,RHU&]G1Q3KP*2!,"C)4XNPV M+>O0%R'EK$:`(:$B5D5J!M1<2N0Q6K9*#J34Q M+?ZQ52);MA>;4=,Y58$M2I?3""O85`RH-VJ/]0PMV0QT"WM*X3_XMW3K@\$@ M3FI@FA5&B`P00.NVS;45'BT00;VS4(3`QY-LX),_Z]8H'.5BVD>@P,M6^$)-Z<("A1`.04@Z2%\CYG^'6B$ MRI`(3LF!T#KK((>".&LP$!X<4W%E#1O;C##:;'4-"F8$G5M]_6#K4+Z&4_`$ M_.=HD8T:6@Y9!\Q3#]A41FB($[O(LI7@D33_)9@3!9PR,C(RI*B@M#,R,C*\ MN*RP7>@/6,P`5XM\)`CK/8O`<$/AGP*+3"0$5_=,]G0/BO_/.B@H&SL.=?&+ M`;K__OY^`Y=>V.#0@_`"PG$$J0`X@73KYG[WZ(M!_"8CA.1T&JFD.`ZI@''1=BVPD%(7M M="[]@\D<_U]HA!@3\J[WT4F%THOQ=$'[_B4^]A,1.\YV%7T6/74/5E52F7AG M^D>L]U,1BU,$%'O[0KLP==$ILUU;PXO_1`8!"FBX-1<$%`:0D`X(/F4H&#\) MAU1IBHG?W95=WT^+]QD4B@=&.-`BAR@0<*W^4C,"..!UQ(H.,5OJ"K>@9O\W$'1\L2^;>\==-(K"Z;_B MC4?_#(W'HY=V?P56BW2`@\\/1@RH;'_[Q78-QP8`+LC_HL.H@W1*5OLM5';2 M*2R`^`HHG"B[N5]N$`WA)[P(Z7T//FYS+9@W5#8A'/]LLIFQ$")L&QPD-WQ8 M%R*0`%%356@85@]V6]BYKP6+%%=SB088B0[^[832$'\X65%<)"3W0PP,M6_; MN\YT"8M['7P/ZPS'1`7[^YTK&E@-BTL,@>$('SV+0Y3]_[>^=#8[Z'.CQ8L[ MB\B+T2OHP>D"\Z6+RL8-VV\]`_.DBW/,$UX8*_!A_07S]@/(B0Z)$XG9ZW<[ M[W)(!\,66L>\4_81;-6ZW(NTS`Q.TO<3W+8OF/TK^NM:_6<05[_W;9/A*USQ M]W1+9P/P.\>_]C7=_W(_ZRL/O@Y344_[Q_",*VU]9> ME_1E-;8/(.T7W,'R4PP,:LH@*\6)"];>;'-X-AP:%P\6V9'LLA&0`,@O3/A; M^K$!PUF+5,U0+E!14NDM,YL)+7PL`!5G=NW3\VI`(LH4;"$-7PF$GRP8GWP3 MLEPD)4=H6>*N0GD$$(XWZ?P.:-ATP M/X]$M_4\*WFX%/3_`71NW06V!00"3B3O"XD==156!=/]MCXL5!366>W[6[@D_"OK%*@^$*@(;Z%"7;7V%6!&S5_/A^HM.ZZ8]0)IZ MP_;WV!O``T@!7\<%Z'X6=!H(L[D1`?YCT.`))V`\BP(Z`74N"OX"MS%I=NK&101`QUM;H%M"Y8$&G7KP.WPT-JWD&71X$##"T.= M=,_6[2Z5`D)$Z4$PX!,"J'F:K[5F6#-;TLK)'TALH,&`ZXQO@^P@/]?5=
$R##C:P-J]#A4LEG&!7HX!=&7SX`?00"P_\+7QK`2@8]@/0-?F8]?PO\ M?WU?^UYCJ2L+["M:>U!R[EGNLE%\H004_X29]_UHL`^J36P0B+H-"&#=R],V MBU0KP5)!##PX'!"!].=96\">'T!1?/!#A'3<[8VU!GA!#7X_N3PNK_TE_H69 M]_DTB19]#@/1!5_M]L-K&Q;%N(F(`/?I&+7PC1H)A+9J)%A!]32UJS24+V`@'+RQ0#?LK MF_A_'X/`'S5L`3U&%$@-1`+`!3@PT]B4JV6\5Q0#^_:63K@B,P+\MKP MUVP%AUE^"NQF8G-[-WT*9CL5XBIU/V9$#07@^9[+RS%,)`8-WB,I`OMIGJ?: M%0#8!Z'0!AXP3;?K9E<@Z%DF#;F_U`1"'6:#O"2Z?YB+'ALPQ(0D0)$'N`A, MC1JM>(``G?V](^!:$(D53_6)#=S;:Z_K"6^C6QB2%.3X@P=G'AP+Q!Z!XF=S MWRV2`"4$4A@/X;"!=6,:420@'QM3[J5I44!2C"3L@KC@<*L)V@+1@<0DJS]& M3Y_T&P$"_]!H$+`0?)M-K@@$2QR\:`01`&NHAX!Y!-10$;-72.(,+&\?,!N$ MD`$/,"Q\%Y%3,0%6=0Y50_PF3J;!K?CH3$>X+1TNX=*`EU/BCP MJ\$BBS7LE:[T=PF#[@0[\7(52;X(@7P?FQX4<^MH',L4WB@@WR01(.1U$54C MLP799C"`])SJB93!G_<0-\7AW09S#VLJ^?=R\72;P8Q?B=X_!"+-P&Q?)`@) M`+,>F$T;45#T4\PU#8&0T!(/#T++(;!"*`^-+%<-@1:O5+0'%P@TT0<4HW\/ M1,L)-"W&O\8/3%&M^DLA*Z.PRPYX@R\(CPN-2XT4B+_42@W&T@3NT(V$D,,? MMGWLGB8`)\'X$"5W`"^-0O\=)`$*("T?BL&AMW*#5=C!X&V#A?^#9W03B@I" M.-ETT82M47K6X(4'[0O81\/!X_0(Z%)C]8L*O^'!YC/+./BKWS(#^8/Q_^K/ M,\9Y?EN]:KOKG24&=-,OU5UX`56!YD6`W5Y?6YLJ]`U%BT+\.-A&Y^\XFLYL M\-QT)X3'YQ(5W+98NVD&U.N6+;$$_@_.2>"P) MD,C@M"14^$(%Z`^!&]3WV1O)J".6.\X0(\@.HXQK6,M]`D8$G(,/^AJ(-=H3 MG0^?C2?<`Y8=/`\;V,,7V`$6*_G2$(U6%.(8%<[HB_K?R/[AV[9AAGN#C2_( M<`/(9C.?!X4``P$#6@@+>0*0+V=".'EU#%DK-R"$Y,A8,4@Q*I)!N[)BT@$37(A,]W#ZT@8=&)Y7%(3%(^Z1R=.M[$2 MA0`9::O]N>4VZD\$6DQ90(1B9KLZ"'QM0AE+BO5-=`!@_!J^X*Q:VC5=9 M=06+?0AV&_1O!-$#QCO^=@@[^WCZ]\>_%(:1C!08;H/Y"'(I;T,;"B#4:#,Y MQ[H<*VRP4;5R3.`#5==]N%7,@#+SC7@>D`>_Z;IF_#*0!+P#X"/1B@:(![(U MM_V*1@&(1P$%`E8(6<:9*\G8QUS,W2MYEF4L)0$"`J;DZ\XFD"-&(4<_C)JF MZPY?!DP#1#PT@;^F:2PD'+]$CN3!TS1-=X_D!^CH[.Q-TS1-\/#T]/CXX-78 M-/S\C5B:Z;Y#:#?X"<#P@`.,O<+&KZ`110@]R6*=N&"S@0OY$:-]F"$A#0HK MC70Q>\D@O&=\.?Q_)`W]X[R5SF[\=P`U!^^-L#2?DT.(C_DK"#1,U_TB+)`8 M"S@#8+[N5MAM`SIO`TY83U:V)0Q[2TL?HVQ`OMON`N\"*8R0)\J6A+3W-)<<'$W3-$T8&!04$!`T3=,T M#`P("`2Z$Q;2!!\0!1CGEK#I`R@\-9>WM0MAM@2'#X,`"6%@$[C8J`&SR"`3U%P`-G*F)I#(HB!D M_'&V!FW!X=\*^#<+X2Y#H_0'1C,*:ASMWD]7OB;'1?Q3#EVL^-C-]@2<5!RC MZ!LN66RC-(NQ=ZQ,":$2//_[^.UVIQL'5KP$510.NLA\@\Q.D9?<0J)3>#,5#R%X&QL:](7X"+L MFO\^4FR[P4WP^`UA6XOE7?T@NK]@@ST\6`):87P4F*9X_;EA>("%X.^)R^?# MZC%B$C\,/@U,"H&VV4Z>40I04%*EW#O7K]';AV.>CA$!+L%&_&'6[#%P]C%M$,R$*XS5=D%HQ>6>T04JYL8E"D(1*O/?YW#N`;51!7._`/@V#$++#'9#SO#=!XQ4-(LUU2;G`HI2ML?^$^PT6KZ59/;QD0Z!`!% M2%*OI5L+M->H1E"7W M^_L*5Y5MPL2)!LG@7L,_E!_1B+FK*:QP$R@2\3OVMDMTAH],]LET$ET0S#7$ M>VNRO5ZP4(YH$2Y3O^Y2`UTX%@>`^39&J=E&?./=/YR+/BOX*WXTBU8*Q.X@ MT%)\.\!+$KLHL)AW;VF_$,((/+_Q+'P`C9X;!M&5\: M7@N$MRR`><+#[\`:@@B^%8(O\U'$7K&545'K$?V%)P$!EU`@OX66@KW(U&0GRS.,("G3$2 MFBM=CVH4\R[@C_YN$*B"#X08J$`/A<"]%`47&A6H$.+0+7"-I,C')/X&^FZL M@-P,%23O#`*I:"T!WQ1S)H'^:/!B"",+<;,'B'4-57]M=8S0'MX)5@SC]RI> M;$(++8B;88WH0F3A_TD[^XD6B4X$?AAG57*IAJZV'MCM('"(YUFZ-7U3@_W_ M3M7*P?H*X+=O5:25"P6XH.]O]D""%*WQ!"!T#/'2L3Z"7>=!/Q0\%K^R3*[P M-^OI45T>V#O?-\B^AN$*L+[2="5H;HN]J@T:7QL)999>P\K1O."7&C8L%1S; M.\%!5Z:1`484C3R-;^BB(^8#0(EGBDP6!!I]"PNM`4QA+YR> M=`ZZX$+U.]W>`R#[&DTJ,U&'7,,J%9KD6-%54`>N/.#/UN>`0%&L)#0$K(C? M*$=/18O]#X:#VL;_1X\HB\\KS3O+MU[H!WRNQRO%6W*!48Y'#8^Y]FV?Q2SK]8TYE05U M':,9*5L2+#MR[+@6%5IC`WP1YSC-0L(OT!.`?0`:(TYECB5#\0PK+1K8PG(O M:126(=:5.ROQB:-E++@BT_#5$$)55SB$5TK6B_(%[FEU84\W,!"%/X6AQ(Y( M7Q&*`?S76[_I4E4]>,<\870=/'*-/%RK0>!W=`UU*+U/NA:-^`L,&Q#KOK65MQ1%$'4-"0H= M=00,0"=KB@XD]BI!KX50T#W&%Q1,%11HI#A1K9J!(S)MG%D]^]3;\+!]_J%T M%D"C!3`"#S<&B7@,H$`KQQWA;(NC#`@&'&]($--UAC9]]SUP[$T#0$W3-$U: M"AXO%&S8$%8P\0`!#R\[(4\"`P0%!@L'">#`"3P('S5).+#$3YS)._5^S16= M(=R7%U:+`CL9A%@,QT;H?P)_.\Y\[>LSN3R(ZREJ((TT`]Y9Q*!U#1BT;J!] MM@0Q0(LT,DV6_CO];5"V-UV);P0"#$0O!")THP1G1Q!@L1=8%JW_JM4`LC9X M)\T'`@O'`I/`UK;5U[(^O- M^P[I$U=!H_6`2^J`EE*E@:VT`ZCC(.#B2]/+TH`_"G$$)/N(`0>-I;J^`X[W M>S`]X]U"&`WU:HH'/!H./`W[C;N^+H@&1D>.,K5-67,;@'\!/=N^EV`+2<8& M"A6T!PT?=A4>!.H0\A!5;-%0!>-6,)Y2$RC9"^@+4D??7+;@0->+Z`M8TYU0 M@U+!?0'VI3?Z:_WO;JX\GW7K.EJ+"4:(1`L%ZR\[=5O[5NMU#(!\'1P%>^LQ MN!5\%B#E_U+-`-[-=3?%60W MM)<+0(U^^CU$P`1V'P0Z<+5KZ"3_U[\']%:`R&<9$.(8 MP'O@B8S/O_U;]]JIM[NA!LOV"0-]D.7LH=02)]3K&\=%;^O7B@B5$HE-?"T( M'_C?RXM5*HV&=8U-&(V5F'M%%%$'6^V)=1`B.%6OO](O1>D%R/,/G<)*@^,= MB[_T(]=*SE'XB7G\/4?CN?3^EL$\"-;SJXM%$`6G[H"V:(2&N>.P_XWBA0RU M>.3IB(;X\-CO!^D0@<;.@<(G\G+?FB*WC<_#WH#JET`XG'!6W'1J5318-44' M-'M=7[-3P08]_4!LKMOP.37PZQT)BWH-"E'^"^!JC2#JD(:)T`#<`H8."WK! MQ0&&SI5!OW@PZ\"+C@]%!3Z8U2N#?Z/M#9MBJ$*W$*V[`/`_6>YA@;\^Z'5' MB\)H"0/+"/PQ<^"(:2W'!ML!+;;C%4AY2HD&+'&C$M0K!!4I=PSJ]UWT[D5K M%'0-@>L]@^Y;P8T7/7VDBP=_!",N2QVC\(-Z&/_K:HU*'SE[)QAN#`M`BX'P M!NP;,Q>@4NXT_*]T5X:!VQ$OCT)^6-LE'C[VN`L[8G8%!!0+/$+I<@N+G!PZ MZ^O##U`-6_%U,XO160^C^KNYI]JWJ#3!6K] MD`$(.%K`0TL?$U:JK56WUF$?,W3(C`-DX!=P%&X1`_*),(%DP6&BW/Q9/?D% M[^UP&J$5TO@@HP@RP#2UV1"T-0\\P*$5M\]!#"_B)J#DBT$0[\+=6\N%`'G6 MJ1@@"/<:3U.@9>961`1E=!7OMM1I;&Q_4)H:,[ MR)T_%MOP=#)J-88%E"L(#<6B7$\_EK1;LTY34-B M;1&+;<5#6Y`;[>#TXS]:"`S?;OB1*_UH6;:%BPCO\O_G_H6W@`6'T6O^$'WA M;WV[Q%`(:0A&#W3PB\90P>`,-AO=&:-7-B"H1#O'$;2')1K+0%1(*/%2\&G) M!\I^,A7]0RM1X5;:IHE0_,:`O!%^?Y/_QP$/QT'#!4MH'7YWC4YUU3V-A7]? M-]<<3P)S#JV_'@MR]%RWEV@#]B/!B;2(7UXMU?878`HKRXD*BV(K51\PX?&M M$0B)#XV'=0([N/$@-ENQFVTL7A&#P$ MC8$]A3%"++=9/^<(3H_&TTIXXMT1P&V;23=%R1_`H!10J2M<$$(3+W"77:`MC7T@#@` MW_`:%D#;2\0;97-UB@90/(!^E(W^N\'I1@&YOQ5`02?Y.\IS.6BIX2(#,;J) M<5=;55ATS=#9.]H!VSLL$\*(E>P'X%_A]IH#4RP6&:$[Z'*JW7>7),<1:D MMDS/'+W`;T,0M@2V+Q$/(B"T6X@@%(!9#X"449,W7X8O&3Z>$(-?B]4KUXK0 MC=;P','Z##`@+P?1&*/_0"Q'%Y'R._-V&XB'(O#!>`$K\VL#QHD!!MLC;\=A MCVPK?C-51YDK\!O*#]$=NF^HEKC(\2OWJ`-'$%VQG2U% M.Q?3,>*`QD+G'XL$K-"@Z$*%W\3'.\%S#^22`48_`[R&M?4RKMD+T#FLL%$7 MQFUX]@[QT50]UGQ%PFM+/0/V/21K`6%?1<**FW2+^Y)1M:]HHY4/;:X$R9*J M],KV:KAN5'$I.QE]0+I+/Q&+0L@,!I8+O7XI6A3`('1$ZT%"5<+-3GA!/;I* MD`-^8G<7.`!KO$,@M[X6K6.U=QN;%G$K5?(7!`1T4('3'R(YN,Z#V`#<'.N= M,-!?#U[;FTK"1D834'B%ZI:D*D"PRAE21H:&D%V1/2/:`2,/4U:X"*#)`'*- M`!P56')9KS)K4)0$KG@9K`O`0&47[L%6E%'X.$@B"PMX013J-Q4+JQ!'\(I, M,`$O0!.!,);]B`@()-#)/G::96.LV*\(`ABO1D5JDI->1E.K:W#XH-#>R3P] M;#7(\A&:"$8/)2L!6TE.9!@\S1L+36Z4T2O55!B,7/*<^^?XQ:,))Y-"5)S' M9_EPP"B."$8\1GB>P$85V-"4P\;##*0EC3R:RWS(":T#_?-F?2P>W0B&CH`& MHE%!D=@[D$#X2EHN+(%3.@C<0V3$1**A#F\>PS<`V],7+&\)&0*\+L+E5#M MB8"*'T>$VXAX`_#$7Q[6P^$P1"@BY^J0;RA!V`\#X>]/*9K:+=? M7%@6GD0#-"-3')HH)*X9UENX7=T++")(%E-CX#?W]U4S(!BT!NV7VNVP MCQA-TXVB>4K07)9+>"8`MRZ!!F6'G)R\J!#$7J,E^#\V=2"I-/H902A%":VY MR3?"NV0DGSRAX/*`+-7*C=)40)<`T5`!N<(L-+P"8,".QA'">MI);!:HX!98 ML$=)(B`)+2&79B"$9R>796S/O367!#"]>)"16>RI,`A$0-AU@S3W`Q`0=#F< MO`UZU'%D8'L6W%1=7^AA[7TN?.]U*'_KVQI>\ORB\8?>YV*TY%1$`Q#9/HUB:IRB^D:KGI(V>/ZOI!(V"$#QNFP")]S.07#D%NI"J]'N]HZE-$- M_+.\"Q08]M9.A=*30=!F<&RAH8-^"F8"&77P.8L5+E#1^")\.?BS#W4#,0VO M"$`N!B/AE?,L$A/PVD6QA4L59JL+LQ:'9V;$UWL@QL9^V>>$,O6E0F:?[YHB0WKL.`.2/BZ M\E!(0**AE>E0@W/+9)?C@ZZ%6.K(W:WP4+P+)12!YH#8A9S9=FSV#K%<41W4 MR;(LS?9J%O944LPS9WP+;5PM=1.W`;9"!$/D7_;."=K-Q"W#5ME`#5>.,8/(C!U!2[H@,%1@?2(9B>' MO1,CZQLI"`N9M@U'L=?+W\:?"N^55U@'7F"/`D`&1; MJO\C5W1LM-=_!HO."\_A&[M"P_8PF9A255=6]/%WQZYHAW,\5%B+V!*#PS!I M^[MTQ7+[.71^!`-<.#@3?(C?=H@8!NNK%?$0?VR-K&,KZ$#VQ0(=$OU=-KK] M,'69[4A%$,8`,!U<4]0Y-$(.K&3[8:'VZRK)<@>C+>L6$/>\/%@+*^L*`G0- M(,?LJ!.B"BC\*_H$&MA:/QT,C;0R`K:`Y410*2`W,V$61DG>&2V80/>!4%%6 M(RI2B^9RA71X=@0.NB';;!$=.S"C+'>DJ"FWEHB.CGAW+.V@MEW_GP;42%!2 M`1%H!?P@#`0$?H!^(KFV75LDZVE4:.U+&\:6L"UF[&48*K%E$2P"+R=(]1$] MA=[WC!PXO3O0BUYPAQQ25E4MU`:39^MZ47]0:99-LP.)\CQ118K3=,VV6E(3 MQ=0#MJ>??0=-XQH;``4%`04``@4#:[I+;00$-?^W,SNH!S>1#;9*4B<$``$. M/=M]20(#D'@W1U0#7%/M.G.YCU!5\U(#*@M25'1=TYP'!HQ(`VXG/B_[9M=: M`P!7$`$0`A```Q!W>9`W!!`%$`8'"!`)"F#`\O8*"PP$#1`.#[]LC49T"*NF M`W@3M%]MLA$.B`(',P+UJ_A"B1'K+%%0E=K#7UUUH@R)`60,)FH2A(3@"V`` M7E@23?97?B6TQ(:+3`_]0E-M`M6(KR+^2`3V@+?-) M;0;(A9S=05!&0P?C:+#%:L^FP;3)0K:+'$#\GA\VL@V:"$&;42`_J'!E$V9` MH4U`O;^^5PN.O/\%#J,;@H'_!O9HR'UMJ'>`FHDU4`=3J.Q`D"T"A0F8T16M M`[95WNZ"W":HPU]H6"IQMDO#(5Y7`A.A[%C<+3:L!3/_OCH$0%0#\2_$L,'@ M`F8Y/9X;VPTZ(A-T4!1)`I+XIHMM&9`/&_)T(J$`"$0+T:81=!F9-=3:D'.G M1.[!X8;4WL)'E.O./18%`?/N1V`5D#QJ0&A%5]K*29J`X6D8J0H52-GO[=$+`VF0'1"(SR[(SP`0`+2O;LA70NBD'`S#N.$6S=_,Z M=6-%,Z79EAUV9SF!-C(,D+';K0@*`44+??0W*Z2P`Y7R,%J:O4"M"/?9'A1% M88L.AM2]#161\"0/V_Y5M73&0`,S9D^8E;'&`0W/=Z(V?3E6:W4%&_5`*7JT M)J1%%34\;E,,.[M?IZ-UU>/">'Y<#5X*I89Y@SWP":V-I,)L/Z#)9B#^R"*V MQ]@/^D,?^(PHR6:M'?1PIS._[FHFTB@5]B_R&VN7B%$TZTD,5=(&O9(MVQ:3RRRG%.AJ%M;K,(X1]R;;&!,4!BU84'S:`,NH)FM4<-HH/'B_9:6D9UJ MP3L-L!'L"7@!E`^*'M#8W!_@()@L(& M)9PO&(-:4[XD_C,7^C=%*>@[UGT/P>4#=ROJP,F^Q0/N5BGYZPL.`\T[@!<= M^4`^+(N_XK_;OO!R!@Q3M-J7`R"8#(V3HGV?8@OX#)6- M`Q<]VC)5&:#'1RFNUJ'4&32:@'(LZ\:Z45L=F`F*&3@3)+3@!0W/3P81"K31 MF$O&E2VY+$:L0-<+^\`5K`/"2`3!#3VS_%VP?7T5!?];)@6H$?;>6IQ;/6D4 M?`HM&Q6((#$+(H)16@J>RE89"^:%_Y?B#X"X>2T#$5?WZ<'Z%]'M_I.H5?@#B)5&P;[_1_>`,^$!?"R!Z0=`#IYM>9(=`(7B"0CIZWT#1ZJVHR2X MN`=%+L*MZ`BM6U!Y`\$^BMS="]+!ZA_7T*,L(-L/2MUE*]#;UA32#`?`$4S5 M`\KWGXMOM*XHL5IW/D3N[\7M1BV3;K8$0@]\]5N[5;U#E_Q*<14@06<<&`O' M-HLS:5WW\M8B"I19MLT07]&.0F/E'P1$GCF+,EO[N,6SHI'W/"C\J&91FRH+ MP%KCS78/&!AITO#Q;8TG;D'.(`4;%`B:%HW=HE(\N!"^`EXXC$3?#0K#7R1B MX;+)72CK;(4$^T:,O4).:@/Q^XHFC['&/(\Q;AC7ES2]8O&!/:JWJ@8A?@%& MDZ5<=;%AVUXLR+QMH2WU#,.-0P#1USL"#-1>=86*0SE$P(-;Q\'0M]%.0E1( M#9"J`NTE3$\?_J[BFS[*?&"L`H"!5?!B\-"F4)=T'^@@'*J&8`N.%V)1"WA\ M,HQT!@,M?+LCA:$&)!OP)')11T)/5+G!NUL&M2:XN#,[$'1%>/NW+U-!/2#N M#'+Q@_H3U-9BW806W%PI<<3OR6W)V*]8$C2@%M^IU$<=. M.PQ*+[LF&B\NI!,]CL"+\9V[`VY=N8-_4CV0#PV!)S\G/T0]D80V/9.%)S\G M/R@]C8(:/8^&Q#X^/PP]D@NY,XEG5\C4&S<(_].BX0T7;+#8B;_04>T?!29* MV`09I9OP2K2!3)0.K[XJ/"<^PUT%>?E"[X\6_8W;7,$.1!U M]101=`*@PH55H%$J)<)%F.92;T5;1(N$9TH]@2\KP-01BD0*S;2Q5&U4`\_C MHK74)=JX8I4'>?K5IVA;D2\ M20JC!0Z:`#CBXD&B"@H1+X\(45,-&YUH.&9JT%"9S05U_CWC-""@YRKU%X`G MQ`E(T(F3=@CWNX<(]^!77%V;>9)T`^$,@E$+QPC]6`?E-E-20Q2.4%)6:A;. M@C\[2#0(7[Q(U#4=!5Z,\H"'"@)C-'P\JMB&T<<'R=>$^T,3.[N#=`F)=?N_ M1.$-I8`X(G7`@EUO#EYD8M="59:1O]^-=-1,]5@M0-3!6/;]RT%*0-P M\1?K5D\$[+KAW?^/C@-=JDN`^Z-KJ_AVVXI8N$$.=/:L)?>-]P=Q=1[.>`$B M2M#M:J:`[%2\UAZ M=2>!!N5L]FL:)/\'''(`KT7H"BS00<,=&@"S`+A&:<0`;D?[I+:+"%LZ$*%` M2B`3CAT0+6"E]Q`C1+M)/3Q/)6@P`"*WD!'$YH&-AMA$%[@"9@$'[\$\+AJ7 MJR40'9P,Z1\JP(6H/OET$MUO?-@.%W7W".XKQNG1^$#:>FP%X>CT&VH;T:M& M*"0GV3[2A^B,5_+8NW0O&:D)!C93)H%3BYZM$`WL/%S#)"!8+.,-ZEM0$\!H M:&4('@WM9[YT7(H+)XP0E\`-FMP'=?BLPT!L?[Y#+4W&A3$BX>",X"44H5Q3# MX@>L@7KN=0\L;!32N`FSL(&P7SDH5?,[MY%H?C!"/:#O[955?V@B:T0S"(6Q MN1.O\AW=L+](FO.KJID0`79QBMU=6]46?S-WG^"%^ZO`[A^+]=HPBD[=NTFZ`=H(PAO+_BPD-/UBD9J MT]!'@W8%O-#%"%$$ MQL"CQ_"EX5Z!)>_FT0`+(&9N:OC^#C+(A8WP)7"J_11L+',+Q?R*F!,9UJ`. M1L\%7*X@[9X=]1)W)[1<;4@&N!%Q]MT%`[@$"`42"P0T73="]RT>,P,Y/P=D MK-A%;9\!`@,[&$+&D%\$Q.8L+ M`:W@C:!\SFJ@HV;+1KORQ4BK2[R'VN8+!'@$8A/=1*X(8V8L#WS7$-D"7A`0 MWA!&R]P;]FF^Y%ZJRP318G9)'R3=Q3NV)HD*C8@BT!S&0+;2,M*=`%@6>YG" M$QV@1\)RY-G7WNR;*W0K?*CK"DB#&L$#]78(2=[>BNZ`@S2*!XDNJ`@(Q4:U MM@=X20,K*O`?B]8?#+T`+P3UB13!Q(H/B('J^!IT14:F!`05^EI@MZ%DB-M/ MH?74CR@$VHTTVJ14TD/0SMVH@1BX]J:$PT@8`MGKD&Y4W'0BM4CAC:I1 M)4\RZ(IH%-,5;U0+0:C^J5VI'P(F4B]!!`9K<`HH#>PHD6"]P6O[(+&P;H"Z3="CY=B^SN'!;,F>(2!=\ MLZ-U$NW?]HB2+;-]8(+_5`B3&Z/ZZ\-DCP75#(P41;R_0F2@#X%Y!&CW%KZT M9E'L4@PY490%FXH(5C!P4;NH640(]DO;5KQA2P)#^6L,65O"9SQ#[O_,S%9# M,C!80S`P]^KZ!6+O:O$S10CW0.2$T4P4AX)@&N%E:ZU!]P@^(7.B-E/?>PC! M83"QC]#=VM^+1595C6L0J`M=7D$+S!+5O9LS>#PE4U]?VQD:ZQU6#.ZY-FH! MWG7;PF2/_8]5##L(D_C]SC`:BS2/ZZ&XV^LH;'PAT"_-%/>86WLU(\#L,[1LJFB9P)IU; M&LM.#70-NKV2Z1`]UWD+;P'%2+FGI+0,75!:?'CR"5`6N>>^I(Y@+Q'9(KR= M9J6D"[V*':GKC9P+'QVK92^./'8M&S)J`_=OJPJ#E[@2Z3MHH$E\.PYT`]E3 M1#VY!EZ$=J\5XN=,73F+^U;M%8-FHCY!G<6NOA+Z5,M/'\NB$.WB&")H$`>Y MWL7A]. M]>L&@<.A*FC`-!FH/Q"3](AME5DT9*D47$"``KU")(TL!M5J444T2#Y<%@7_ M>@2\T]!.*_#8($8`8$2)VYUH=P;J M`SAU!M."0[$U$V!B(_M<2A:C1O>1[#V>`]FV)GX1`?X#F-Q00)D445,KNF&N M5Q?52RLU+!>V`G,OBAK)&E`#RD(6'M&C_X6BI=`8.LMR!#K*=FFBA'5D:@(\ MI.(V"^2PA@9;3@$UJ(>3(1H/BN9+V"2#41??.>D&P%8)"%B+3M%V83]J"<[7 M1>!1&\G,J"T>D2L$D6,2Z08]W)+,'E50H5:Y:7`%N#DGDD#@J\FO/%!14EY) M)MV`W>\V4$:\%,69&'B@?K+H7JU$9 M/E%2)A8,*S%KFI\J3H`"/!@7NRJ:^*VU/5?'>^*K9WG<",J8[_X'T04Z8)!* M5H0-%*H05#C/5(5OH5Q@S)8G#L$8U/">:*,1"G=43P:!XG0;-!)T6`KP@D?; M+Y=)]S`B$VH$014L1J=I%AU(0SG(@!UU'248]P#HUNHE..3H*\?7P[XG"QB3 M?,F,W]XY$M#`.TS6N(3&P"#<1$F-/+,Q!Z$7XI_8$XO'BU`$!8D71EV%V"A` MDB;OF%AWFIH`4W%X)P6I3M9@ASWK9T9!49*]`P'"3B0SW26^=9_C MZGT"]]X6M0BO4;'1=B#0)K`9L`!CL4<Z4E:MU@R* MV%?WJA"U$;>H!`0XQR&%SD%W>!V+1G<6VG@H5*!G/"O&BH5S#>^CTA40D<(2 M$*@U=]DC7Q$0)F#C,1`QBQ+)@GY[K33L+1=6A=)3"PP7VK1TV!!!D4$D12M@ M]C(O>X0>U$1K]N%"#QRUZC-O9QXA&9Z7I(;);7B7X*VI?#X/-__AT MM_'!_[DML^`!.T2-D$RTX&?G+K5][$4U5/,786[E]@7P/@E56_[.#D5OG4AMQ()%F;N%@Q0F0H%]>L$G!%V6$C] M,$F@JG6U+)__'IRP03#GFYV:5\(N=,,$_7W"=#``P]T5%L)03S_LT#1R"3K6 M#(W1+BG@!DXG4,PHJ`:0(!426$9`RIM_K\)5`[__M>"=?HD*W!1]"K@4X1JJ MFET%.@!ZW*.]=GODM-43:A1*'6^DC^PF'@]J&D:A#[$??1!ON;;K!1!T0#3@ MB0P0)W3Y!'?;1.M\ZIZZ6![&&F";!=D&\?@$]]OA!CL&QP*'-"!`@?JX+,3= MD&A\T2-J*9R@Y*XN%[!*!8][?,,K>@`,:=W4I`?`;DZ]$1SIOE*)0<4,=!EJ M:Q5;R0A1"MH#&!T%>4%((IPWR"0$Q#K#1C^]H7W MT0[GQ8!U%01`=0R!/:C;!1?EQN`;"%0:BT:+AH+!^L;WRQ^<6^@12'+MK#F8 MP.L`!GFP$@E`ZPB``'^K91L0\_@P#X?!`KC;SE]'F""!6D`.ZQ.[AX[1!P$, MNW8%NS"O#3)1Z.(]1>\-V])_$C0[;SQK<.V]!"0_-FJV51@#%;`]1'1`6K,\ M9QL".044V+[-]J*6H4N]`QH>/)NA6`;A&` M".L+V$6]UPP7#$UI;"$G/=5QU!Z&&*1H2#$+1QPR013H*$&'@VR(%C!3DM@A M&=A#B"**"\\U,6- M/XH=6Q%M5I4\`+Y4G*0&=2I],!IU(SNY0337ZGOL%$%1I!8VZQ!T*2P(0R79 M*+H%WU9F%JX(]0N-K:A`*U-`5V]&K8#)O8LGVTJ(WHDUKSH:/[%INHU^T$,# M2E'Q@#)D4Q9C`0\"A)"B0P.0[Y:BI1:^\E;QM`H#.4`\;SA2="CDUQQ0%1F@ MA7L,0BV!QH`%%7.?1CGJ0/YQHXIV$544+ MEPT]%S$R;(R8;!`R.@P<6@*#PVR"/9,*DL4?[Y]X8.&!B-_)K68^9E"LVA>_ M_P!W1%/^)@!'T*9<6$,=KLAL*)BY*QA6X2HV:""N*;G2L&A_ED9E<-8$I`V# M*OSM0G1V]'J MT=@+J/3W\]5DOO`$&7*(]XK1<@X[4+2[[R=W"'('.RMV`4Y,=QA!+Z];PA"C M4RKN\&:S;E!N-P7V#F.WP@OK4&X0115N!NLV0\@4D000:PPZ`Y%I#@^[&X`V MT[E,!PB]VE&]@5UXV@!\?VU1'YZ+@SU0`7Z3:JUE.FX8!U`I?<5ZU`8YHA4" MR0_:GRJP0TK[EP-'Z\\G%13ZVB5'T2W?P/9*-/PKT2,2\O*#F44IVY*PW6'7Q;BAH^&5[5Z5E--=+49 M0!M6Q@-"<$;0C5R+R^LA*7O6Q-N(BTET)9(I'W7K+;M9X5\=48/C`_$@'2]+ M%\2IPW7STTKY9Y:>@PTZ+HH1VN9.NCKN;!@N^BI.09&"6+=!1@K:8Z^Z!D>6 MY>06@\;>+!YT#!"W!3)?QCGK&$6DZ6)<"0X`$K1"S*A32%6&PK#=[XD'7W7X ML'6%HY\>$"R@G_,%:&8+^_\O-\H2S(`&D@=;(S9@DB\W*88%EBA+DS8<.7F, MT5:0"0ME`M;JI0:`3E'^9I8U!&'VS81`.\5RVTBTL+DH!7490W8U%Z(!WLIW M3.A2G2HF9';_;4B3VE<:9%Q,?[>(LRIP$&R%'FU,./]#"&JZA`L?2$2M.,O8 M'*%&5%+P>&<+8D<2)/<^4+DM81%1]HU&8((W"7@0,\!L@Q7]>@ZX229K"1M: M"A`/K`MVIR12R&JBAP"BPO\A=7^-%#`[U7<>@K_Q!ZT. MH15K4Q'0#(H#3%NKUP)3HQ]0WY:#`S!XU8*XR(%C"/XPI+(/;R(D0 M+"O`:2Y$TCV>V%I25LFQLU*)4%=1,"*@W2GH=2*MRAE56M66I&2`SWUF!=H0 M4`>#"83M=#Q-+TPE5IL,,,)#&PP4'8*X*1X8QIC&9@^V,(+VYFA99K,$I6RI MV(H_'HI*`4+909$Y^+?9&M4("\$[\'0R%=>Z7?4M_SQT*D1"*T;ZVZ1B=;N^ M(P^5P4DCRE6X1[40$03?-YDK[@4>7A];(,/4<0D17U?+/V1`CVBWP($D6M9@ M)QFFG&@2/8O'H,KW+(AEH*\/K^-TM*\@QA%:;<:MP^>RY@6^BQVR2FS5CW<> M=T([-4AW*"CHI6".!\HJ=@C-8T"WSE&+Z>"KB\VJ-4@139LMG`@A=*6BK!\1 M&ZI%'P>=24&"2+0%+%P/L=)B#C4-C;-[F$OHEOS;[@$\A"Q(G8P?MPY M2`5W6U,,$54S[2M1,P+`/G?+X3XZ`<"<=\J2(IVSNH&N`553`?C/9J)4P,D: M$0(/6Y(ZIA3\7(R@!>`:]E]O`9J(CJ>.:+G71&"H@DG;X(-?X7A+-GY"'`<-]/YF'@DN(4P^\7ECVU?;WW1OM`TWB%5\I[!`SOAM9 MV`1:4B(M%_-`,2%_8"8"#X(S$%'L[1R$/L$!*W<5KQVE*A@ M/TG;D7\,N5>O61@#6Z!H(!1M(Y%>;EE_^U6`&&8Z=0DNQJ!U]/?A@U,%'@A& M2[./P@,)$-.>\8`%0\SO5G-@GVX7&.!4!G1$^(K!UPD3:D+ M+02%`1=S["O7Q$*%K6T,B\OE0/VP\@G"]%&AL$?%-")(M>.FD\=U(X424'0@ M)A5\5__61HXZJ4Z6L`4J_7"B7G0O!7'I!G`1#8Y27H\^U2R:(-8N$X<`(-5F M>BA#-M\-*O3%B2Z65Z8:Y!*&M=Y8(DNI3J?88P(^?#%<"7AQ=#K1$YLC'7S- M)W0E3R105',7@E?*M"'&/MD'+2&5@,!7%!M6;1@G$E$X.W'V>#'^2>;I@)9$ MT#U%&1/((3(?B)&@UWTCGY"8D1P'L!/<`[P``V@`D1^(D19"#H"(D3\T3=<- M?P9L`V1<5`R@3=-,1#R1'_>-$`()P/"@`X`,H$VLP)$?CY"''""3T)(HDJ!= M]SLLD#@+6`.`DA#(*PP?(),W6"CD()-;U']-TS1=W`/D[/3\!`@P@'8>%Y,? M-EUW0A\P!3@#2%R3:RHP@!__[Y$&1E3Q3[]:2Z=34$V-_UAX"):*V@N_.[#_ M8[DN"_Q_"0J*)TBM0A(.9DP0]NYX'[QGTL03$6/.0!4PNA0%AG+5RT M7`%!9S<5,*,S!MW#>K`5@W3=2A"X$73@DG3=$F7=$:JQSX0#'%"L4L"RIGL& M4-*%'&@=B%/U^>`2_041VX$[225!H;A2'M"="WJP(4U)(A."V`P+ M:GP'9+"S!Z`E'L`5N`3<"14&PP]+:FD(W%9W(!<*'(+V[%I9IT4'.,1P+0.& M@(,>M4[30M">@K]1+5\=F#,(2-(V+%@`LQ0T(&T,&FU%)$PY++/)!C&`MTQ5 MQQJ8BO2D/HT4!`L8P#]2.19S`2T>5]],,CQ@]@6][V40/)B=52)1VYWA?>A) M$/?%W71)LQ21[>VJ)`"/MS>[)`#N$KI2-5`1FQN%0?=B;N&"49/ELH"WH`PV M4:P@A#5%H6H$=59*W,60D<&:1%`,H&Y9=4((8X<4\';25[&-2O]B^<`MN(9)9/,, M4BO*@`#;&IG",@``KD6;H?]!-A0#_?+V?0`&`@$'$``#!@(0!$7^5^JS``4U M,%,@("@X4%@'N];]K9(W,#!74``@'%0<+_7.N M`!H!#@`H`&X,`"?TQ[IL`2EK*&YU;&PI$%-_\___=6Y-;VY4=6579614:'5& M0IS=&0UVUK[[7!U M%PO6`;)?,3GW M;W!E8-ONYE@QZ[/4QI8K1R>2<*+18`9]O# M10XA$5#4.KDV[-;*+@``/.7@)?QE];8L:VQW;CY(1V5T3&&Q"W=L.D$*=F50 MMG5P$_^M;6 M[`WL;$`0!P8`@4K@MT]T`1>;$B9SVY`"7^`GY,K.+@#_%"=`E(W-#A#3(Q8G MV_]_R,`A#`D""+6'`2N?)C1^Y"4M0RWB\H82#"@``";!PX`=`2\%,.@B0I8H M_Q]`M$`X?3!0:!@+[=_:__]"H_@D(05(V&O1$`YT#FH0:/!_J?Z$%PK_]E_W MO(PUH1M>PVH!6`3_%Z(&^=J-V[:UVT44!1!0IP+^[4X%#'$FT+M]_Y+"CB:%PC M(,U]M_)%R6A82E#G\F^VSIEX-Q\45\SHOO___V__N+N%AO\E&D3\#KN($YW" M]\\N-^BG%@-3Z_(Y7_C__SUC5SEW^X>U0TAJ`^L$5U>F:$@1+R\V5?#GP?__ M__`[]P^$:`*]X$+[[KN_0*](55"#%'J+'60?_[^P0#33ELXBN*Y5&53'@8X4 MR\_____VMOLL5_)62_3H.^\OQ@ZM,QDDP!3<5>5R.Q==_.#_"_\B'?(!BUPS M=%A4D"WX%(E!`^_=[:;B_W^I8]5)U8L,,_:`H#C?N_]M2(`&____C;*^0/\A M*`^.%T#&_]_^_6ICF5V-CAOW_3+_-Z+^5!_____W2`I#13$>_LZ0Y6'$@XW1CV?WNW M;:M925%KC7X!Z08#[?___T6+[BOOCO;K&C!)AT.+O-\0,-Z[V%!72T.`9/K_ M____*QPA4W;WZVF`('4Q-E2%W(P<(#(<=2R#O&S#4$\\4#/_____+#,;C`A;C0=MKUI"'!IP.CN(O[_`QM9-U#O=@&;1B`PHQ1%(%W)/0O_MR@W M4WQ;1C08M`ON2``YCT3\_Q!.S_RC^MU6:(":`XL9P&VCV?___\9X5HWX5V96 M`JQD.F"LZ\BT<=9;XS/:3I5]#/__QO]9':;_A6=O^WXL.E_RM,`;@%D(](4# M^UE]#____^UHL!(=]WS96_WL+[?."&\$N!S,ZXR-A>1V;ZZQ^!>"^)G_O00M MAD,`J=D-[5___YN`:^AU!Z;V!\"WT`MEKW<;\ MC/+=QUKD)^/]"-LI#+[H50R*C#T17(7___]\H?U8!H@,$T.#8Q4C@#@J'VO[ M+0JI,4O^G$L%-/Y)3?2+36;9\\,'__^-_^QTIB(LAC?;;I_L@V4T*_A%!:QF M&.\P2OO"_____ST,P@/V";,6DHOX62:&S98-=[#D5U8.!"!6$L+L6ZMN^___ M__Y<]%8#P4K0`F^W[C_\1BLI`]@7\$@Y)MW;;^!]6__"!D`I+,OJ1SM]]/PR M@O]?^MR5&V?"KCT3W;8X%,I!L=I![CQ^9FP-^^^\?_K M<6C(%/-<:,29D)\`1VC`]@?Y,FB\______@=:+BPG?"9]0A6;UG^P_WH%G@: MB^0-OZZ]_'6!"-PN__]+!#/2EXO8HYVLM,)7B`]J9!'C`K\0_/\'N@?F:.`J M:KT_MO%9^S0+&QE7Z_C_E_[E^M`;?QU_GT%U*:'<0ML%!3@=,/"6>___%R!O M+(6X!F>)+2AG-_S;0\8%%`'K_?___R)310;*64!3VMKL8#]T"Q8)PN5N@W1P M?M8,:M`U&/]_@2^%LQER>Q?6K:;KV*TD6ZZ)7&J;QF]0_?^>C5N`K!.)P(O% M1-@N\,8\9$S^____A=1!O#A;*POQ!$LIA`=).'&[W#>*Z<0#0AA%#8D=Q?__ M_[=\8V]]U4K30S___^%@&BU'"CF>QT$S1PX#^"D`7<(UPP+=Q3-/;3_ M?^N/YE\XF2H4;9R0G`1E,PPP/KT9C,.!____@#TXZW0*F6NSK_'K[6<2`08A MHV`M`E@C;"__T@M\C]*&:Z8;GQ,4&AYI604/"8HWN/T-!3MIO@Z%7U:-^PC9 M____!K]>6#S;)<[8,NQ0T+C7C=31:T`'(3DOB=W_A:C__[MOT7X\OKP27D;\ M=!^-3=Q1-_C__U`F1;9^@=O<.S5_$!'@.TWP?_0>MQ_=*?\"___LB0G_+X/] M'?P[TNS$8SY\Q0A]Z*$//<[_;_S_B!!-`0)\*\PZ&E?*`@I\RB9/!UO)8P'% M7##_____6YM93+U$?]!!30,'\\S M(-3`N^^+\W=[2)0$K'X:ZHO++-N?1&D8.4;P__\O`:3_3`]U=/0=B>ZB=#A< MQH2`A?'`_O___S`)F_\VG&'66KP/=R>-->UD&YR!'D([CWR'_AB"8V7?_O\% M`PD_`4+GL.R=/31;`[57RQ5Z"U@)>12DP+_$(&C%[N.1W_ M____/!=:F$/:=1@8R.^3;"/T%$T2%R")5V[WGAV(4EVA/+______ZRXTB%7D M7O$\UJ%F'MJ=<0L5:D_@$7HUQAL=]E&KDJY^Z?__=KA04A1!40+JY:+%,C4: M975"P1'\-\U4A/#__Q<2,"N[%YF-=U8OR52)C(M7EC!.JM0GM;_]_V^TB[)T M_EFB#&Z'E(E0X=P0&7CT%^Y6:O#_V__"#.`M7FRS8ZV1)'7XT*PQ&XMOL$1; M4_____]70KPPJZ];,JL_M!IHTE!M8/;NK2`,\%90!(E=K%!O)___QO\TW.Y0 M==AF6]P%!AA>@O!T5LF_95=[!]:O#O____^V'8)J")73CC6`M5<7$0-G@SV4 M!;APJG0'Z0&:"J8@YO_____(\XV#"^"Z6E-Y]&K+VZE"#]QH<-+KX$ZK$>K> MZP#)HY:3?PAE"C:\"-C())Z#4H+_/\;@N5?3=Q*3O;OG@:RN#PPP,XZ'" M7O9T=*P'+?[__[3D#`^X(NAA+FD@R'*QV_#O*E-(5DA7.___E_@;4RT1!/0- M$IB@E:IWJ'1KJ\$J%A%/?;7__V_\=2@"FZ6&H_%J`A_4>I,25"T)-4IP:Y\J M.5W_"VS_K8`3;W^RL:S=C021.L?(1/$E*Q> MO:/4RX7>X@4XD6*W"ML.%_7V+_3_YC5J$J7.GKT="A!3V@_K6A@5WOT`P/]+ MT2E1A>L3HF:<%MG3!3.,5!;UQ;X4L'5W2D#COP)0%F(X/\7 M,0O:?/SHV0#N&^\2&_$^)]W_\G_9V?(;\RGT&S?UG9WV;_=H=_AA,RP" M-O_[^7+Z9?L]<_PM_7CE_F/___\M0$.SL2.79P%#`D,;`Q3/4Y>:!&DN!4/2 M^,7_!?X"E`R%0@BRUL+YR1NX%$1`#5/__Q>X\L#:2&D%#G+^A+R""=QX@"@, MJ%/A;[W5X@:!541/IL<4"/T-_@LJL(NW!`BLXA]$S-:X1@@-____"]K86D7$ M,_24_]M<&Z:@YE>`+L^UN5"!;I`\7_HO_5:]1Y@BOM3'_!D,HQR)UKU#DR,) M_[_Q_P\DG%Q7L_%3E-#68!)[V9GI7J`)I"#KW:KIXB]!_['2L@^HV%,)@E%& M-O>FR=!?Z(WE;"@%O-AN1D9<6`DJ\4N2(P!CO^]DD^@)^O\++02%`1=SW3=Z M^XT,_YN@)8PBBTU42IF2-8ISE$EHC5E0!O_/^%UYMDZO"G0PAE;,BO]7__W7R%K;?3[9U!!(* M/"!W!@WK\+G;FNUV:*#___^D4D4$]A`!(-@1[4*GU"7MC[@*PSRP<2X:%G^+ MMZ]S$,_?$3M,F%"=4H(;_/_Y7JJA#7P)G(A049)\*;VP_O]_H=:+58A40/5@ M9V&I@T#.\'H-,??M#?W__SL@6YD@#X9F&8\$863A\9"0^SPPQ?;___\]G\EU MGP/N%UO2D%M8@8$`F0\-@XQ\"T]T%``S0X/___]@`/\HH=91,J]'`RD%2"0` M!*BA&%6[//^52_#_?V\C0V%B:6YE=%=#;&%SMO*_;=L*P`\QEO\`LEA;#X71TC;]JRQ"\#__WE3 M97)V`@M%;E5L0U-ON^W_`W>U\0+P87)E7!$6`%YB,$$/ M]L/NGM'[_R_]5&@:9$EDI:IFVTUU`W@A._W8[3M%#E.TP']I>W`53;5UP__/ M@FTG4W1A.X#_6TAP26YF;Q#9WEK[1D5=V_^_\80-4F7W5;T!F*GV5P>-M[8;)LO]?]O*=O#:]88 MZ!027V/SMKMMIP)L9J-^X7_A7W,)]&WVVK^U"C!?88Y?='EM#QK]_YN?L/9? M9FW`"S5M#0ORVX4":H[?Z-;?#V1I=@[0M=)G$(K&7ZU\_]O__VZA355T$!QG M&(4VV`V!HW'#71N:X;= M:6UN_____W-R/@8*;6C6QA9B(B5N!V-Q!UXL67EP>24-%;="[/;5_U_@_R%O M:5W+;%]H++3NVG(S'W#V!&91-=DL+HT%_O_S@!((PH0(#N3^_H@J=^O53OMO M&___MRL4'L10>]<:86<-V82H^M-UOCY86+_Q+_!(QG-5[LE)QIC[\&>E<^A' M03[?6/C_9>\P&S"U8U.MF[G=5*YL53]$/7^)_@]FL M=VF'#D&QV*PM\0XC[T7B+VWU.8(055XFX:]?11%L4NW__U_TESV:#DR99T&+ M!-$.2U@!%%+` M\U^>U8QE4OQ3_$]014P!!#RB:OO/`#B_U?\_"!BS+$+0)!`PLV#+S0L" M!#,'(U[H_^S,+7L?%`DT$`>_M`T&2GA_JUM\C,CM58`A5QR#?5U7+GF#;[7P M=.L6D)];C<2:`F#IO_#_?QLLLI5AVPS4'"=S][H+0`(N)LO7`<^>DO[?;O&S M)Q[`NBC,296]9_L`"`@^X.V`GZ_!';Y8/6$'=HG%+\D,=2!!!)"PD!Q,U;<(OGR!_0#S5M$! MC13O"D#<2?QV#VB4277WZ08@MA*B`)!B;D4O@`0'TG?QN'7?W?GI3!9>B?>Y M1:F**2SH^`:E7CEW]X#@(XL'BE_[[__?>L'H",'`$(;$*?B`Z^@!\#L%B=CB MV?_>?C-%YR,)P'0\BR>-A#!UW;;=!*P7)K#YUI!!88BQ`,`%%GP5$@UD$U`"MZ9AN#`@&R M="MEVE:P;!535`=R"9IH!060T(E/`J1:(()!A`KMEPYH1'`Z+R]W``2#<+^U M^:)Y+F-O;:$L<#L&GZA<4B!-#75<8%!B5L?H9MN6:-M<"G,)=2[N92LNE?C# M6%!23T9X'T58HL3[UP,60T]-`%%HA4^X78134R-A8T!C.EQ6=Z';X&-Y8_UD M"&]INS!;L`M%Y.G)<#\]X+]S9,``Q7P[+;K!HL0U'#W3[ M%JTYB&4.SY]UV%G[]D-90^)$7$8ME0(`%[6(A`Q2C,A>PM]`@241'7T6X4?N^5T%"`S0$&B!&TH.)5D1^%[Q(0+?V M%OI/($A/+0JQ&B]M.KM%H;<\B3X*4E_E5&\,,5Z:/T1!5$$*(`I3=>S7+G5C M"PH#+KY523Y+J,+)-H%D#0IBS5'B8UOZ-@`@8VV[V4=[PSID>6%HS&H*>[?M MA476=R!P2G3=(&8E(K9U-B!?(&!U!.L*A4BP,`=-$H5"H41Y("@0%0I%:RK[ M`T]6(FZM(!K]87KU)QNEUOA)(&AA0`\/HFBMX?X:E$EW96(Z*0AV`6L1Y6HL M9B`K-$$20U':6MM:(D9K!,]Q`X#!\H`=L M`X!P,A00"U-<6Z#DKC=04U0_1`BV%R40[)-0(QO8A+(7#X,-TGVS%@,"`P<$ M-$W3-!@%#08)R"!-TP<,"`F]@`PV"AL+5QMLL.\[!P]7$!,1`S;(%Z02%R$U M#]@@@PQ!0U`S8(,--E(74P=77],--MA9>VP7;:L@]X(T37`<"'X--,]@@A(^1*9X,-L@@H:1OIS#88(.WG\X?U[:JDX,+&`<%`PM`!NE. M'0L$E@9DD&:-"(Z/0`9D0)"1;D`&9)*3`^/F^V&0!XSO`@0(&*2J9P?[8()Y M@B$GIM\'H:7-]_.QNX&?X/Q^@/POJ,$Y.X3QH]JC(&^!_@=`08;`!K4O0:^0 M_[NV7\^BY*(:`.6BZ*);?J');W>?_E$%`]I>VE]?VFK:,AZ3VU_3V-[@^3DQ M?O=W'-@?!"`%DQDG`K,PHT!FV70C!`<)V*(*FJ9IFK00B!%8$FR:IFDT$P@8 MT*'3-$VS&:@:&P'>31-LVSPH'K@_-Q2`$W3_\S`@7)9P&\' M`0&]$'*%+%,"`0+"1E7(`@,#2/DB<(U`ZF3*3)/R00$H2!X`F2!(`!`F9`"9 MA!"!9`AD0`$0"&1`!H("!(!T6#L@3TVW?"!/'@`[`UIX-DW3-)>UU/,1`6?9 MIEDP3FT!-P,G!HDZLW<#:UUWFJ[JT_(K+P--"*_/-&PZ+NM[`!!"``8!(2.H M`BJ005$U!(Q;I-L7(+CP`4C`1G)E90E7ELU`]')I=&7K%%)D:F^WSPE,0TT? M4W0:;F=!#83]]R*_"U1Y<&57';O9+\M74T5N9$]F.2M69=W<)JARXT5X.@1P M8;,D0+`<18`V@IK=NG,:4RYE<(G>Y>Q6G!9O>99#871)-YL0BF$!%V6])12Y M/(Q*/HL$]:!D+D1!;&RVAZ+7.D-C6GME!P0[H/5R;3,:>[>ST7ES96T=#DRA M:.:"UPW*+R1!+9P1F-N"`ZOO4?1)PH1?HLM&]A4;Y@5GPZO=9\-A&]M;?%,0TH5OF$)=])I9&5# M:!I_-T&P-4V#0GET2FQU<^$9W+]H0$)U9F8I4'DTPA(*`_\V\#D@3%A?PE9A MPLP%035UVU@0+%=75K%[LV2/80Q;2X5N:(+@4$=E+55N:#LL;,2")'A,<)X> MX07UGAEW'@_+F/='8U`V[CW6Q@I! M"P=/14T)QL0<16RF/\6`A`3699E670#%W,$`2F`930);">`*?D$`)(B4H@] MP)-/`>A@-:``)CN1%&PP`0P#;0"D`&P@+^^KP`H@`)0A`8K;F4YA`"YTD0=P MAY"[9,L&B,2:]BYRLT-'!)$`/OL>20%\(XQ$0"Z:IKG%)B?X:[!&D+-"5$HC M*"MIMM@L!_LG"-8T@-I^&\0B`QV#````````$@#_`````&"^%>!``(V^ZR__ M_U>#S?_K$)"0D)"0D(H&1H@'1P';=0>+'H/N_!';+'H/N M_!';$<`!VW/O=0F+'H/N_!';<^0QR8/H`W(-P>`(B@9&@_#_='2)Q0';=0>+ M'H/N_!';$@^[\$=L1R0';<^]U"8L> M@^[\$=MSY(/!`H']`//__X/1`8T4+X/]_'8/B@)"B`='277WZ6/___^0BP*# MP@2)!X/'!(/I!'?Q`<_I3/___UZ)][FZ`0``B@='+.@\`7?W@#\!=?*+!XI? M!&;!Z`C!P!"&Q"GX@.OH`?")!X/'!8G8XMF-O@`@`0"+!PG`=$6+7P2-A#`` M0`$``?-0@\<(_Y9D0`$`E8H'1PC`=-R)^7D'#[<'1U!'N5=(\JY5_Y9H0`$` M"0```%-H96QL17AE8W5T94$````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` I``````````````````````````````````````````````````````"Y end From Administrator at ISI.EDU Mon Jan 28 03:31:28 2002 From: Administrator at ISI.EDU (Administrator@ISI.EDU) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] ScanMail Message: To Recipient virus found and action taken. Message-ID: <000801c1a7ef$53be3040$650210ac@staff.win.be> ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = mlong@se.cuhk.edu.hk Recipient(s) = end2end-interest@postel.org Subject = [e2e] new photos from my party! Scanning Time = 01/28/2002 12:31:26 Engine/Pattern = 5.630-1025/211 Action on virus found: The attachment www.myparty.yahoo.com contains WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to d:\Virus\www.myparty.yahoo3c55368e12.com_. Warning to recipient. ScanMail has detected a virus. From Administrator at ISI.EDU Mon Jan 28 03:48:17 2002 From: Administrator at ISI.EDU (Administrator@ISI.EDU) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] ScanMail Message: To Recipient file blocking settings matched and action taken. Message-ID: <000201c1a7f1$acfdb6b0$0401a8c0@pivosystems.com> ScanMail for Microsoft Exchange has blocked an attachment. Sender = end2end-interest-request@postel.org Recipient(s) = end2end-interest@postel.org Subject = end2end-interest digest, Vol 1 #324 - 1 msg Scanning Time = 01/28/2002 06:48:11 Action on file blocking: The attachment www.myparty.yahoo.com matches the file blocking settings. ScanMail has Deleted it. From koenig at Informatik.TU-Cottbus.DE Thu Jan 31 08:30:05 2002 From: koenig at Informatik.TU-Cottbus.DE (Hartmut =?iso-8859-1?Q?K=F6nig?=) Date: Thu Mar 25 12:00:33 2004 Subject: [e2e] Call for Paper IEEE ICNP 2002 Message-ID: <3C59710D.BD217084@informatik.tu-cottbus.de> Please accept our apologies if you have already received this CfP recently. Also please feel free to redistribute it to your colleagues. ___________________________________________________________________________ CALL FOR PAPERS 1Oth International Conference on Network Protocols ICNP 2002 Telecom Paris Paris, France November 12-15, 2002 http://protocols.netlab.uky.edu/icnp/ http://www-lor.int-evry.fr/platonis/icnp2002/ ICNP is a highly selective conference dealing with all aspects of communication protocols including design, specification, analysis and verification, implementation, application, and performance. The program consists of a full day of tutorials followed by a single 3-day track of peer-reviewed papers, including a limited number of invited talks and panels. This year marks the 10th time the conference has been held. High-quality papers dealing with any aspect of network protocols are solicited for submission to the conference. Topics of particular interest include, but are not limited to: routing protocols, peer-to-peer and overlay protocols and applications, wireless and mobile networks, security, multimedia, web, electronic commerce, home networking, distributed gaming, QoS, signaling, network management, flow and congestion control, and active/programmable networks. Selected top papers from ICNP 2002 will be forwarded to IEEE/ACM Transactions on Networking for possible publication. In addition, this year for the first time a "Best Paper Award" will be given to the outstanding paper presented at the conference. Please refer to the conference web pages above for further information. Important Dates --------------- Paper Submission Deadline: May 15, 2002 Tutorial Submission Deadline: May 10, 2002 Notification of Acceptance: July 24, 2002 Camera Ready Due: August 26, 2002 Tutorials: November 12, 2002 Conference: November 13 - 15, 2002 ICNP 2002 Sponsors ------------------ IEEE Computer Society France Telecom R&D Institut Eurecom Institut National des Telecommunications (INT) L'Ecole Nationale Sup?rieure des T?l?communications (ENST) Organizing Committee -------------------- General Co-Chairs: Ana Cavalli, Institut National des Telecommunications (ana.cavalli@int-evry.fr) Teruo Higashino, Osaka University (higashino@ics.es.osaka-u.ac.jp) Technical Program Co-Chairs: Ernst Biersack, Institut Eurecom (ernst.biersack@eurecom.fr) Ken Calvert, University of Kentucky (calvert@netlab.uky.edu) Tutorial Co-Chairs: C. Jacquenet, France Telecom R&D (christian.jacquenet@francetelecom.com) Osamu Takahashi, NTT DoCoMo (osamu@mml.yrp.nttdocomo.co.jp) Local Arrangements: Fatiha Zaidi, INT, France (fatiha.zaidi@int-evry.fr) Publicity: Harmut Koenig, Brandenburg University of Technology Cottbus (koenig@informatik.tu-cottbus.de) Kenji Suzuki, ADCOM, Japan (suzuki@adcom.co.jp) Steering Committee: Mostafa Ammar, Georgia Institute of Technology Mohamed Gouda, University of Texas at Austin Simon Lam, University of Texas at Austin David Lee, Bell Labs Ming T. (Mike) Liu, Ohio State University Raymond Miller, University of Maryland Krishan Sabnani, Bell Labs Teruo Higashino, Osaka University --