---------- Forwarded Message ---------- Subject: Congestion control considered harmful?! (Jacobson paper) was Re: Submitted Freenet paper Date: Tuesday 09 Mar 2010 From: Matthew Toseland <[email protected]> To: Vilhelm Verendel <[email protected]>
On Friday 19 February 2010 12:42:58 Vilhelm Verendel wrote: > Interesting paper: http://portal.acm.org/citation.cfm?id=1658941 Section 3.1 seems to say that any request/response system doesn't need congestion control. CCN is quite close to Freenet in various ways so this is a very interesting finding. I am not sure I understand why though. Here is what they say about it. ======================================= 3.1 Reliability and Flow Control One Interest retrieves at most one Data packet. This basic rule ensures that flow balance is maintained in the network and allows efficient communication between varied machines over networks of widely different speeds. Just as in TCP, however, it is possible to overlap data and requests. Multiple Interests may be issued at once, before Data arrives to consume the first. The Interests serve the role of window advertisements in TCP. A recipient can dynamically vary the window size by varying the Interests that it issues. We show the effect of such pipelining later in Section 6.2. Since CCN packets are independently named, the pipeline does not stall on a loss the equivalent of TCP SACK is intrinsic. In a large network, the end-to-end nature of TCP conversations means there are many points between sender and receiver where congestion can occur from conversation aggregation even though each conversation is operating in flow balance. The effect of this congestion is delay and packet loss. The TCP solution is for end- points to dynamically adjust their window sizes to keep the aggre- gate traffic volume below the level where congestion occurs [20]. The need for this congestion control is a result of TCP's flow bal- ance being end-to-end. In CCN, by contrast, all communication is local so there are no points between sender and receiver that are not involved in their balance. Since CCN flow balance is maintained at each hop, there is no need for additional techniques to control congestion in the middle of a path. This is not the same as hop- by-hop flow control, where backpressure between adjacent nodes is used to adjust resource sharing among continuous flows. CCN does not have FIFO queues between links but rather an LRU mem- ory (the cache) which decouples the hop-by-hop feedback control loops and damps oscillations. (We will cover this topic in detail in a future paper.) ========================================= Does this mean that Freenet can operate perfectly happily without congestion control? I believe there is a later section relating to strategy i.e. how often the clients should send requests... An important side-note is that delayed responses (ULPRs and passive requests, see the other reply) may undermine this conclusion. But then delayed responses can generally be sacrificed if absolutely necessary and can certainly be queued for a long time... I guess the fundamental issue here is that Freenet can and does misroute in response to nodes being temporarily unavailable due to limited capacity. IP and CCN can do this too but they have the advantage of being certain whether they are actually making progress; we don't because Freenet is messy. And in fact, CCN can fork stuff. Security vs flooding (5.4): =========================================== CCN incorporates a number of mechanisms to prevent excessive forwarding of unwanted traffic. Flow balance between Interests and Data prevents brute force denial of service by Data flooding over anything beyond the local link. Flow balance operates in a hop-by- hop fashion. Only the number of Data packets requested by down- stream Interests will ever be forwarded across a given link, no mat- ter how many are provided. Even if an Interest is forwarded across many networks in search of matching Data (unlikely, but dependent on routing), at each aggregation point only a single Data packet will be forwarded towards the content consumer. Data-based distributed denial of service (DDoS) attacks are simply not possible. As Interests can be generated by consumers at a rate of their choosing, it is theoretically possible to mount an Interest flood- ing attack distributed generation of huge numbers of Interests in hopes of overwhelming the available bandwidth to the node(s) or networks CCN routers believe are the most likely sources of matching content. Multiple Interests requesting the same Data will be combined by CCN routers, and only a single copy will be for- warded upstream. So to attempt an Interest flood, an attacker must generate Interests for names that begin with a prefix supplied by the target, but which contain unique name components (to prevent In- terest combining). As CCN routing allows transmission of Interests for content that does not yet exist, such Interests would normally be forwarded to their intended target. Two features of CCN routing make it easy to mitigate such at- tacks: first, as Data packets follow the Interests they satisfy back to the consumer, every CCN intermediary node is able to see, for each Interest it forwards, whether or not that Interest successfully re- trieves Data. (This is not the case in IP networking, where forward and return paths through the network are frequently disjoint.) Such randomly generated Interest flood packets will in general never re- sult in Data responses. A simple adaptive algorithm allows inter- mediary routers to limit the number of Interests they will forward under a certain prefix as a function of how many previous Interests for that prefix have been successful (resulted in Data). Second, the attacked domain can ask downstream routers to throttle the number of Interests they forward by name prefix, much as an IP network might ask its upstream IP to throttle or block attempts to access un- used addresses. However, CCN's ability to attach policy to content namespaces allows semantically selective control. ===================================
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/devl
