From: Dennis Y Chi Sent: Monday, September 27, 2004 3:49 PM To: Indranil Gupta The End-to-End Approach End-To-End Arguments in System Design In the design of a system, certain functions can be implemented at the application level or the low-level communication system. The end-to-end argument is a design principle that suggests that these functions need the knowledge and help of the application to be implemented completely and correctly. The key is to consider the tradeoff between performance and the cost of putting the functions in a lower level. Implementing a function at a low level can increase efficiency and reliability for certain applications, but it can also be less efficient than implementing it at higher levels, and all applications, even the ones that do not need the function, will have to pay the cost for it. This paper provides various examples to support the end-to-end argument. Applications should provide delivery guarantees, such as acks, because the data communication network can not guarantee that the application received the data, and the application may have specific types of acks. Applications should perform encryption because it can check authentication, manage keys, and keep the data from being exposed. Applications should manage duplicate suppression because duplicates may look different to the network. The paper also points out that the type of application and its end points should be taken into design consideration. End-to-end system design is definitely important because it helps keep the network simple and allows it to operate faster, but the paper tends to go a bit overboard in its support for it. Routing, for instance, is better suited to be handled by the network, rather than the source. Also, there are always going to be arguments about where to implement the functionality. For example, IP multicast requires help from routers, but application-level multicast does not. As the paper stated, security is usually performed at the application level, but IPv6 has proposed adding authentication and encryption to the IP layer. Also, the paper states that applications should supply end-to-end guarantees, but many applications simply depend on TCP. Lampson’s argument, that functions may be provided at lower-levels but should always be replaceable by an application’s special version, seems to be the most logical and applicable to today’s design philosophy. ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks In wireless sensor networks (WSN), a sink is typically interested in the collective information of a group of sensor nodes, rather than their individual reports. Therefore, end-to-end reliability, as provided by mechanisms such as TCP, is not applicable. This paper describes ESRT, an event-to-sink reliable transport protocol that achieves reliable event detection with minimal energy expenditure and congestion resolution. The paper uses ns2 simulations to show that the network can reside in five different states characterized by the congestion and reliability levels. The protocol itself is fairly straightforward: at the end of each decision interval, the sink sends an updated reporting frequency (rf) to the source nodes depending on its current state. If there is low reliability, the sink will aggressively increase the rf if there is congestion, and decrease it otherwise. If there is high reliability, the sink will slowly decrease rf to conserve energy but maintain required reliability levels if there is no congestion, and aggressively decrease rf if congestion is present. The paper also provides both analytical and simulation results to show that ESRT will always converge to the optimal operating region. The paper does a good job of defining the five states and the basic transport protocol, but it does not address many important issues. First, the paper assumes that the sink is powerful enough to reach all source nodes by broadcast, but this usually is not the case. The sink needs to ensure that the update message is received by the entire group of source nodes and that it is received in a timely fashion, before the decision interval has expired, otherwise the convergence of the protocol may be affected. Some other mechanisms, such as gossiping or directed diffusion, could be used to propagate the information quickly. Also, the protocol assumes that the nodes can easily adjust their reporting frequency, but in some cases, the nodes may not be able to increase it any further. Third, the protocol’s goals were to handle dynamic topology changes and to conserve energy, but the simulations do not test any node failures and the paper presents only one power consumption graph. Future work involves addressing the above issues, and possibly testing different congestion detection mechanisms. RFC 3234 – Middleboxes: Taxonomy and Issues Middleboxes are virtual or physical boxes that perform functions apart from the standard functions of an IP router on the data path between a source and destination. Based on the end-to-end principle, the network itself should only contain IP routers that perform routing and forwarding, but middleboxes violate this principle. The main contribution of this RFC is to describe and analyze middleboxes and how they affect the Internet architecture. The paper provides a catalogue of different types of middleboxes. NAT, NAT-PT, and IP firewalls are examples of middleboxes that perform necessary processing and routing functions at the IP layer. SOCKS gateways, IP tunnel endpoints, packet classifiers, load balancers, and anonymizers work at multiple layers to provide functionality and optimizations. Multicast, interceptors, firewalls, proxies, caches, and ALGS are examples of application-level middleboxes. Based on this cataloguing, the RFC determined that a majority of middleboxes are implemented in the application layer and perform required functions that were not designed as part of the protocol. Therefore, to aid applications, middlebox design must clearly define mechanisms for dealing with failure and security, and expectations from its environment. Even though middleboxes violate the end-to-end principle and the Internet’s architecture principles (every entity has a unique IP address and network layering is not violated), they provide necessary functions, such has enhancing performance and allowing heterogeneous networks and protocols to communicate. Also, users and applications generally feel that placing certain functionality into the network is worth the cost and effort because they don’t have to deal with it. Ultimately, applications and middleboxes must be designed with each other in mind. Future work could include analyzing what types of applications benefit and hurt most from the use of middleboxes, and whether workarounds adversely affect application performance. From: Jin Liang [jinliang@cs.uiuc.edu] Sent: Tuesday, September 28, 2004 11:05 AM To: Indranil Gupta Subject: 598ig review 09/28 End-to-end arguments in system design This paper presents the end-to-end design principle. The basic idea is that if some functionality is needed between the communication end points, then implementing it at lower level may be redundant and costly, while still cannot provide the functionality correctly. Thus the end points must implement the desired functionality by themselves, even though the lower layer may provide similar functionality for performance enhancement. One example is the reliable file transfer. Since error might occur any where between the two application process, a reliable communication system doesn't provide the necessary guarantee. Therefore it might be better if the communication system simply provides unreliable packet transport, because the file transfer application needs to implement its reliable tranport mechanism such as checksum anyway. The end-to-end argument can be applied to many other scenarios, such as delivery guarantees, secure transmission of data, duplicate message surpression, etc. In many cases, the lower layer is not equipped with enough knowledge to provide the desired functionality at the higher layer, therefore the higher layer must implement its own version of the functionality, even though it might be tempting to "share" these functionality at the lower layer. Of course, sometimes it is desirable to implement some functionality at the lower layer, however, this is for performance reasons, and cannot guarantee the necessary functionalities. ESRT: Event-to-Sink Rerliable Transport in Wireless Sensor Networks This paper presents a reliable event transport mechanism in sensor networks. In sensor networks, since most communication is data-oriented, it is not important and not necessary to identify each individual sensors. Therefore traditional reliable transport protocols are not directly applicable to the sensor networks. Also, since sensor networks focus on the identification and transport of events, instead of individual data packets, there needs to be a new reliability definition and corresponding algorithms. This paper defines reliability as the received data packets versus the desired number of data packets, the sink will compute the reliability for each interval, and infer its status, and broadcast a message to all sensor nodes asking them to either increase or decrease event report frequency, thus achieve both reliability requirements energy savings. Middleboxes: taxonomy and issues This document describes the different middleboxes in today's Internet and provides a rough classification of the boxes. Existing middleboxes such as NAT, NAPT, firewalls, application gateways, each exists for some compelling reason. The paper does not attempt to classify them as good or bad, instead discusses their impact on the Internet reachability, fault-tolerance, etc. Many middleboxes work on different layers, may or may not be transparent to end points, and may or may not worsen the fault-tolerance of the Internet. From: Yookyung Jo Sent: Tuesday, September 28, 2004 11:00 AM To: Indranil Gupta Subject: 598ig review 09/28 End to end arguments in system design : Summary : End-to-End argument is a rationale for moving function implementation upward in a layered system, closer to the application layer. The supporting argument is that only the ultimate application can perform the function perfectly, thus often the function provided by lower layer must be implemented at the application level again, resulting in redundancy. However, providing a function at system layer can serve the purpose of enhancing performance. For example, in the application of reliable file transfer, providing a reliable packet delivery at system layer is not enough to guarantee that the file transfer is ultimately done correct, and this should be checked and guaranteed by the application level. But, if the application checks the correctness by checksum and retry and if the reliable transfer is not provided by the system layer, it will result in many retries and adversely affect the performance. Thus, in general, providing a function at system level should be done not to guarantee the perfectness (which can only be done at application), but to provide performance (the function is needed by many applications, and it helps application's performance). Comments : ESRT : Summary : In the typical setting of sensor networks where a sink(with high computing resource) collects events from numerous sensor nodes, the reliable event detection at sink is based on the collective information from sensors, not on the individual report. Thus, they introduce event-to-sink reliability instead of end-to-end reliability. To achieve reliable event detection and minimum energy expenditure (another requirement for sensor network), they mainly use congestion control. Reliability is measured by a single metric which is the ratio of the # of data packets in decision interval to the # of data packets required for reliable event detection. And they control reporting rate f to achieve reliability. They observe a universal curve between f and reliability metric, where as f increases from small value, reliability metric continues to increase and starts to achieve reliability (reliability metric >= 1), and at certain point f (=f_max), the reliability metric starts to decrease due to network congestion. They developed a state machine where f is controlled to reach the state of no congestion and reliability metric=1, which is to achieve reliability (reliability >=1), at the same time, minimum energy consumption. For the basic routing protocol, DSR is used. Most of overhead of their algorithm is on the sink with high resource, and sensor nodes only have local congestion detector and they send the congestion information embedded in data packet to the sink. The experiment shows that their mechanism achieves the optimal reliable state starting from various initial conditions. Comments : [C] : It is interesting to make comparison between ESRT and Diffusion protocol we studied last time. Like Diffusion, ESRT is somewhat application-aware network protocol (its reliability metric and acceptable reporting rate are data-specific). However, while Diffusion gains its performance mainly by exploiting in-network aggregation, ESRT gains its performance by avoiding congestion. [C] : Reliability metric is defined in terms of # of data packets per event interval. But, in reality it is more than simply the total number of packets. For example, the data packets from very close sensor nodes might be redundant. Dropping one of the packets will not affect the reliability, yet reduce the # of packets(traffic). [C] : In general, there are many factors other than reporting rate f that affect the reliable detection of events. To depend only on controlling f to get reliable event detection might not be effective, or sometimes ends up in incorrect functioning. As an example of incorrect functioning, if there are major link failures, the sink might not get enough # of packets, but still certain amount of congestion is reported. The sink might think it is in (C, LR) region and lower the value of f for next interval, but in reality, it is (sort of) in (NC, LR) of the graph and its measure of lowering f will not achieve the purpose. [C] : Though they claim that the curve assumption between f and reliability metric is universal, their graph shows, for example, the decreasing part of reliability metric is quite wavy. It is not clear whether the state machine will converge well in that situation. Middleboxes : Summary : The classical Internet architecture can be described with the hourglass model (the neck is IP layer, everything underneath is abstracted in a simple IP layer, and other complicated functions are implemented closer to application layers on top of it) and end-to-end principle. Middlebox is a term to describe any intermediary device (doesn't have to be physical) performing functions apart from normal functions of IP router on datapath. As internet grew and got popular, many form of middlebox service appeared and they are chanllenges to the original design of internet architecture according to the above rationale. RFC3234 enumerates catalogue of middleboxes and provides weak taxonomy of them according to measures such as protocol layer, functioning vs optimizing. Then they conclude with suggestions to the design of application and middlebox - application design should be done recognizing the existence of middlebox and middlebox should be designed with clearer assumption and behavior (e.g.how to deal with failure...). One ultimate goal of these discussions would be how to define architectural principles that guarantee robustness in the presence of middleboxes. Comments : [C] : Middleboxes are challenges to end-to-end principle. Perhaps, it is about time that a new design principle be suggested just as end- to-end principle was suggested 20 years ago. What has essentially changed is that new functionalities and abnormalities introduced after the original system design can no loger be regarded as a nuiance or as a mistake unforseen by the original design. Thus, the remedy can no loger be, to make a new design taking these into account. Internet, due to its popularity, has many different parties voluntarily contributing new functions. Decentralized contribution and self-evolution could be the universal character of many upcoming systems. These will need new design principles, perhaps inspired by nature which itself has coped with decentralized self evolution for many years. From: Thadpong Pongthawornkamol Sent: Tuesday, September 28, 2004 10:22 AM To: Indranil Gupta Cc: Thadpong Pongthawornkamol Subject: 598ig review 09/28 End-to-End Approaches End-To-End Arguments in System Design The classical paper by Saltzer et al. questions the attachments of several services on low-level communication paths along computer network. It claims that although such low-level services as retry, delivery guarantee, message reordering are built only as performance enhancements and they cannot be used to totally replace implementations of such services at end-to-end level. Moreover, some low-level services, although provide redundancies, can incur more overhead on the network. If the same implementations of services are running both at low level and application level, low-level services should give their responsibilities to high-level services, which more information about system are clearer to deal so that high-level services can do better jobs to handle problems. The paper starts by picking up an example of a reliable file transfer program and pointing out that there are some points of possible failures that cannot be handled by network-level mechanism but can only be solved by the application itself. Such failures are disk failure, memory failure. Thus, the paper state that it cannot be avoided to place some mechanisms at application level. The paper then mentions several mechanisms that have been put into low-level network so far. Delivery guarantees can be better achieved at application level because that guarantees that the application does acknowledge upon message delivery. Secure transmission mechanisms should not be built at low-level system because it will need to share the key that is supposed to be known only at two ends of communication. Also duplicate message suppression, message ordering, transaction management can be done at applications where all information are better understood. In conclusion, this paper states that it is not going to nullify conventional low-level mechanisms, but it points out the necessity of application-level mechanisms. Both mechanisms, low-level and application-level, cannot take place of each other, but are supposed to complement each other. Thus, thorough considerations are required to organize the proper layered system, which every component is unique so that the system can achieve high performance and maximum utilization. ESRT: Event-to-sink Reliable Transport in Wireless Sensor Networks The paper by Sankarasubramaniam et al. presents a different perspective on event-based wireless sensor network protocol. It states negative comments toward traditional sensor networks which hop-by-hop reliability is the main consideration. On the other hand, the paper view event-based wireless sensor networks as reliable systems in the sense of collective messages reliability. Thus, it emphasizes on collective end-to-sink reliability than conventional end-to-end reliability. With this assumption, this paper proposes an event-to-sink reliable transport protocol that can achieve both reliability and less power consumption on sensor nodes in the network. The Event-to-Sink Reliable Transport (ESRT) protocol presented in this paper takes place on centralized wireless sensor network, which multiple lightweight sensor nodes observe some events and send all collective data to single sink station. The sink station then acts like a hub to receive and process all data from sensor nodes. It also periodically controls sensor sampling rate adjustment based on current network status in order to achieve the optimal reliability and power-consumption of the network. According to simulation-based studies, the paper makes some observations on reliability (messages received at sink node) and congestion occurring. The paper then proposes ESRT state model, which state behaviors and transitions between states are based on two considerations, reliability (low, high, or optimal) and network congestion (with or without congestion). By counting the number of messages received in a specific period and receiving congestion detection packet from sensor nodes, the sink node can calculate the current state of the network accordingly to the state model. The sink node then calculates new sensor sampling rate and invokes it to sensor nodes in order to change the overall system state to the optimal state (optimal reliability, no congestion). In conclusion, The ESRT protocol proposed in this paper can achieve collective data reliability and power consumption in event-based wireless sensor network, which is suitable for centralized multiple-sources-to-single-sink network. However, the paper is still lacking of security concerns as it states that the ESRT does not require unique source IDs on each sensors, which can make the system error-prone to malicious attacks such as aliasing. Moreover, the assumption on periodical broadcast from central sink to sources may introduce the scalability problem as the network size grows bigger. However, the hierarchical structure (multiple sinks) may be a further approach to solve such problem in the future. Middleboxes: Taxonomy and Issues The document presented in W3C’s RFC3234 presents the recent phenomenon in the Internet, which system is traditionally based on IP routing protocol. However, there have been many devices and systems which inject additional features into conventional TCP/IP protocol stack. The term “middlebox” is set to describe such additional services. Based on the hourglass model and end-to-end approach, although providing some features or achieving better performances, middleboxes cast complexities on traditionally simple IP-based end-to-end network. Thus, this paper describes, categorizes, and analyzes currently presented middleboxes and their impact on Internet architecture and application. The paper introduces a set of services or mechanisms that are likely to be middleboxes. It then gives the categorization on such middleboxes based on their impact on protocol layer, explicitness, hop count affected, their layout in the communication path, their purposes (functional or optimizing), their duties (routing or processing), their states, and their reaction to failures. Middleboxes mentioned in the paper includes IP-layered Network Address Tranlator (NAT), NAT with protocol Translator (NAT-PT), IP Tunnel Endpoints, Packet classifiers. Some middleboxes stand in transport layer, such as Transport relay, TCP proxies. Some have impact on multiple layers, such as Packet classifiers. Some sit in application layer, such as proxy server, DNS server. Some middleboxes are intended to do optimization works, such as URL-diverted load balancers, TCP spoofers. Some middleboxes, on the other hand, are explicitly intended to do some functions or controls, such as firewalls, gatekeepers, proxies, or caches. The paper also characterizes all middleboxes based on considerations mentioned above. Finally, The paper then reports ongoing works to deal with middleboxes and to operate them efficiently so that they can exist in the Internet with minimal side-effects to end-to-end principle. The paper states that middleboxes still have some benefits which are not negligible. Rather it is more reasonable to raise the awareness of middleboxes in the next generation of Internet applications. Middleboxes itself should also give clear definitions of their positions in many aspects, such as failure handling, failure at multiple layers, and securities. From: Pei-Hsi Chen Sent: Tuesday, September 28, 2004 10:03 AM To: Indranil Gupta Subject: 598ig review 09/28 Pei-hsi Chen --ESRT:Event-to-Sink Reliable Transport in Wireless Sensor Networks ESRT aims to configure the reporting rate of source nodes so as to achieve the required event detection reliability at the sink with minimum resource utilization. ESRT protocol operation is determined by the current network state based on the reliability achieved and the congestion condition. Analytical performance evaluation and simulation results show that ESRT converges to state OOR regardless of the initial network state. Some critics to this paper are 1. The assumption that the sink is powerful enough to reach all source nodes by broadcast is not practical, because in a sensor network we should be able to choose a node to be the sink randomly. 2. This paper doesn't take into account the situation where more then two event detections are taking place at the same time. In that case, one event's reporting rate may be less then the desired optimal frequency but congestion still happen. In other words, due to the presence of the traffic produced by other event detection, a sink can hardly achieve its required event detection reliability (or optimal operating point) no matter what the reporting rate of its source nodes is. --End-to-end arguments in system design This paper presented a design principle called end-to-end arguments for the architecture of distributed computer systems. It suggested that some functions placed at low levels of a system may be of little value and cannot completely and correctly be implemented due to lack of the knowledge and help of the application layer. Therefore, the application layer should be the place to ensure the final reliability, and the lower levels need not provide "perfect" reliability, although some effort at the lower levels to improve network reliability may be useful to enhance application performance. But the tradeoff between the amount of effort and the performance should be considered carefully. This paper was published in 1984 when is the very beginning stage of distributed computer systems. At that time, the future applications that would use the underlying communication subsystem were still unknown. Therefore, this paper suggested the designer to keep the lower level subsystem simple by considering the end-to-end arguments. This seems make sense because the lower level subsystems is common to many applications, keeping it simple and providing only basic functions every application will need is intuitive. --Middleboxes A middlebox is defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. The presence of those middleboxes is a challenge to the transparency of the network layer. And in some level, it contradicts with the end-to-end arguments that suggest keeping the lower level simple. However, many middleboexs are invented for performing some functions that are now definitely needed in some places such as NAT, firewall, or for efficiency such as proxy. Because many applications with different purposes are built upon the same underlying communication subsystem, it becomes impossible to both keep the lower level system transparency and simple and also efficiently and sufficiently support all of those applications. Therefore, when midleboxes are surely needed, the issue becomes how we can carefully design them. That is the goal of this document - describe and analyse the current impact of middleboxes on the architecture of the Internet, and try to identify some general conclusions. Those conclusions include 1. middlebox design should include a clear mechanism for dealing with failure. 2 In the future, we should be able to state clearly for each middlebox function what it expects from its environment, and make recommendations about which middlebox functions should be bound together if deployed. 3. New application protocol designs should include explicit mechanisms for the insertion of middleboxes. From: James Richard Newell Sent: Tuesday, September 28, 2004 9:20 AM To: Indranil Gupta Subject: 598ig review 09/28 The End-to-End Approach: End-to-End Arguments, ESRT, Middleboxes James Newell 9/26/2004 The first paper is End-to-End Arguments in System Design by Saltzer, Reed, and Clark. This is an older paper that makes the case for putting more functionality at the end-systems of the network communication path. In the OSI model, this would correlate to the application-layer. The authors argue that while adding the functionality in the lower-layers is nice sometimes for the application writer; the applications tend to end-up repeating the same functionality at the end-points. This is because the internals of the network are incapable of preventing all "failures" of occurring, or the functionality is not quiet with the application is looking for. Furthermore, it could frivolous to the end-user and hence be a burden by degrading and complicating communication. This is usually due to the fact that it costs more to put the functionality on lower system modules. The authors then go on to provide a few common examples where this is the case. This include reliable file transfers (data can be corrupted after it is received, hence another checksum is implemented which is redundant), security (many problems with encryption and trust), transaction management, and soft real-time applications such as VoIP (unneeded). Ultimately, the author propose that there should be a trade-off where easier functionality can be implemented in lower-layers (for better performance), while more complicated aspects should be left to the end-systems. This paper is interesting today because we have 20/20 hindsight of the past, but the future isn't so clear-cut. It is well known back in the early days of the DARPA/Internet, there was conflict as to adding intelligence to the Network layer. Of course, the IP packet design was ultimately chosen, which allowed many different complicated protocols to be built on top of it. Obviously, this allowed the Internet to be as robust and scalable as it is today because it uses this end-to-end paradigm in full. However, the future is more nebulous. New demands on the Internet (such as multicast and QoS) have cause people to debate about the placement of new functionality. The Internet2 provides heavy support for QoS which treats different packet with varying priority. Also, middleboxes such as NATs and firewalls tend to prohibit end-to-end interaction. Furthermore, the rise sensor networks tend to take on a more event-to-sink approach to data gathering (data aggregation). At any rate, for any low-level service to be successful it needs to be useful to a large range of applications, and not break existing applications. The second paper is a RFC memo titled Middleboxes: Taxonomy and Issues by Carpenter and Brim. This RFC gives a general overview of all the different types of "middleboxes": an intermediary device that somehow breaks the end-to-end principle of traditional IP flows. This can range from multiplexing, gateways, relying, policy control, or performance optimizations. The authors give over 24 different examples of middleboxes an how they would classify them. The point being that theses intermediaries were not in-mind with the original design of the protocols and hence add complexity and security/failure concerns to the traditional end-to-end paradigm. Therefore, the authors suggest that future protocols should be designed with the consideration of the likely presence of middleboxes, but still keep the end-to-end principle in mind. Also, they suggest that middlebox should not be catastrophic in the event of a failure to IP sessions. Therefore, they should include features such as discovery and monitoring, configuration, call-out, routing control, failure handling, and security. It is evident from paper that middleboxes are an eclectic but pervasive group of devices. They will probably never go away, and hence should be anticipated for during protocol and application design. This paper reminds me of a project I did as an undergrad that focused on how to accomplish NAT traversal on a multicast overlay network. It was a very difficult goal due to a lack of standards of NAT behavior and no consideration of application-layer control of NAT configuration. The result was a very tedious and long-winded hack to identify and by-pass the NAT using commonly known techniques. Therefore, I think more coordination and standardization of middleboxes is definitely needed in the future. The last paper ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks by Sankarasubramaniam, Akan, and Akyildiz describes a new mechanism for achieving reliable data gathering in WSNs, where the end-to-end approach is not applicable. The authors point that an event-to-sink is more appropriate for WSNs because of their collective data-gathering nature. Thus, per-sink reliability is not needed. Hence the focus of the protocol is to achieve a dictated reliability rate (R) where R percent of the sources ' messages are successfully received. The secondary goal is to reduce congestion and energy consumption on the resource-starved sensor nodes. Therefore, the author's propose a 4-state FSM dependent on the observed behavior of the measured r and congestion. The goal is to get the reliability as close as possible to the R yardstick and minimize congestion using 4 different converging algorithms. The authors notice that a message frequency versus normalize r graph is standard to all event-to-sink networks and hence can be divided into 4 zones. A different algorithm is applied dependent upon which zone the state of the network is in. Congestion is detected by determining if the sensors' buffer is overflowing, and a bit is set with the message to pass along this information. Finally, they show how their protocol performs using a simulator ns-2. It should be noted that this paper makes a few assumptions. For one, the application is knowledgeable of an achievable R for the network to strive for. Second, that the sink is capable of broadcasting to the whole network after each time interval (and the sensors are listening). Also, it assumes that some form of congestion control is implemented on every node. Furthermore, there isn't any consideration for multiple concurrent events in the network. This would surely have an impact on the congestion mechanism that they developed. However, this is an interesting idea and I think the most fundamental idea to take from the paper is the general layout of the f vs. r graph that shows the relationship between reliability and message frequency. From: Jintae Kim Sent: Tuesday, September 28, 2004 9:18 AM To: Indranil Gupta Subject: 598ig review 09/28 CS598IG Review 9/28 Jintae Kim (kim28@uiuc.edu) End-to-end arguments in system design, Saltzer, Reed and Clark, 1984 This paper provides an analysis of function placement and its associated design principle. The problem that this paper tries to solve is where to put functionality in designing systems. The authors argue that end-to-end functionality, which means putting the functionality at the application level is most often the best approach in system design. This argument is based on the following two facts. First, the lower level function is often not aware of the needs of the application level, and so insufficient to achieve the desired functionality. Second, other applications using the same lower level function may have to pay the cost for the unused functionality, which affects the performance negatively. The authors present this argument in a pretty convincing way with some examples showing the advantage of the end-to-end approach. This argument also gives a very general principle, which can apply to various types of system. However, putting everything in the application level may not be very feasible. It may not always lead to the better performance as well. While the authors mention the need for identifying the ends, it does not always seem to be an easy task. A possible future direction can be to define and implement the lower-level common functionality. In this case, applications with different requirements can share some lower- level modules and reduce the design cost by avoiding possible redundancy of functionality. ESRT: Event-to-Sink Reliable Transport in wireless sensor networks, Y. Sankarasubramaniam et al, Mobihoc 2003 While the transport layer should support reliability and congestion control for wireless sensor networks, the existing protocol cannot be used due to the resource constraints such as power. This paper introduces an event-to-sink reliability which is more applicable to WSN than conventional end-to-end reliability. In ESRT, reliability is measured in terms of the number of received packets during a specific interval. The main goal of ESRT is to achieve reliability and minimize the energy consumption by configuring the reporting rate of nodes. To achieve this goal, ESRT handles four undesired states. If congestion and low reliability, it decreases reporting frequency aggressively. If congestion and high reliability, it decreases reporting to relieve congestion. If no congestion and low reliability, it increases reporting frequency aggressively. If no congestion and high reliability, it decreases reporting slowly. While this paper presents a novel solution well tailored to the requirements of WSNs, it assumes that the sink is high- powered, and it broadcasts an update signal to all source nodes when congestion happens. This high-powered signal might disrupt any possible transmission. Also, it might be inefficient to have a requirement that all source nodes must listen to the sink broadcast. A possible future work can be to identify only necessary source nodes to make this protocol more efficient. Middleboxes: taxonomy and issues, RFC 3234, zvon.org Middleboxes are intermediary devices performing functions other than the normal, standard functions between a source host and destination host. This RFC identifies not only current implementation of middleboxes, but also some harmful practices. Most importantly, middleboxes can violate the end- to-end principle, because they can divert or modify the IP packets, or even provide single points of failure. The effect of such changes is unpredictable in general. This paper also deals with some requirements and dependencies for common functions in the middlebox environment. Middleboxes do have some strengths. They not only have already proliferated in the networks, but also they help the Internet scale with growing applications and provide the real services. Yet increased dependencies on the middleboxes result in increased complexity and vulnerability. Thus developing a robust, self-configured, secure and trustworthy middlebox infrastructure is necessary. I think this paper is in that direction to inform the community of such needs. From: Jungmin So [jungmin.so@gmail.com] Sent: Tuesday, September 28, 2004 5:03 AM To: Indranil Gupta Subject: 598ig review 09/28 Paper Review - Sept. 28 - Jungmin So (jso1@uiuc.edu) ------------------------------------------------------------------------------- End-to-end Arguments in System Design ------------------------------------------------------------------------------- The end-to-end argument is a design principle for building general purpose systems. It suggests that a function must be placed at the end point and not in the low level components, because the end points cannot totally rely on low level functions and there is always a possibility that the end points fail to achieve the desired functionality through low level functions. This leads to the need for implementing at the end point anyway, which leads to redundancy of functions in different levels of system. So the general guideline is to make the low level component as simple as possible, and identify the end points where the function should really be implemented. Low level functions can be justified only as a performance optimizer. The end-to-end argument is a very useful guideline, but identifying the end points can be non-trivial. If we go up the protocol stack towards the application, we are more aware of application requirements. However, some functionalities required by some applications (not all) must be built at a lower layer, because it must use low-level information. This function must be built at a lower layer, which leads to an unnecessary redundancy for applications that do not have such requirements. So it might be useful to make the low level components modular, and have applications make decisions on which low-level functionalities they want to use. ------------------------------------------------------------------------------- ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks ------------------------------------------------------------------------------- This paper proposes event-to-sink reliability, a different concept from traditional end-to-end reliability. The motivation is that in sensor networks, the detection at sinks rely on collective information from multiple sensors. So for a detection system, it is "reliable" as long as the sinks can correctly detect an event, using information gathered from the sensor nodes. Ensuring end-to-end reliability is too strong for these systems, and lead to waste of resources, specifically energy. So to support event-to-sink reliability, this paper proposes a transport layer protocol called ESRT, which aims to do both congestion control and energy conservation. ESRT controls the rate at which the sensor nodes report to the sink. Also, ESRT keeps track of the congestion level and reliability level. Based on these two measures, the system can be in one of the five states: no congestion and low reliability, no congestion and high reliability, congestion and low reliability, congestion and high reliability, and optimal operating region. The goal is to control the report rate so that the sink can achieve desired reliability at a minimum cost. The issue with this protocol is that when the system is highly loaded and the reliability requirements are high, it may lead to a situation where the report rate fluctuates rapidly. This is because when the system is in no congestion and low reliability state, it increases the report rate fast to achieve desired reliability. However, if congestion occurs before the sink achieves desired reliability, the protocol starts decreasing report rate quickly to get out of congestion situation. This may lead to oscillation. ------------------------------------------------------------------------------- Middleboxes: taxonomy and issues ------------------------------------------------------------------------------- This paper lists the "middleboxes" that are implemented in the internet, which threatens the end-to-end argument because they impact the design of applications. For instance, applications should be aware of NAT, and must deal with NAT in order to work with hosts inside a subnet using NAT. Also, stateful middleboxes may lead to session failures, which makes the management complex. As new middleboxes are implemented in the internet, the applications designed prior to these new middleboxes may not work properly. Also, the designers should be aware of these middleboxes when designing applications, which increase complexity of designing. To get around this, this paper suggests to identify harmful practices in middleboxes, and also identify common functions in the middleboxes so that they can standardize the requirements of middleboxes and preserve end-to-end arguments for the application designer. From: Jigar Harshad Doshi Sent: Tuesday, September 28, 2004 3:14 AM To: Indranil Gupta Subject: 598ig review 09/28 ESRT: Event to Sink Reliable Transport in Wireless Sensor Networks This paper describes a transport protocol for wireless sensor networks. Instead of handling end to end reliability the paper concentrates on handling reliability from event to sink. This takes an event centric model of the network and ignores the data centric transport model used by the wired internet. The proposed protocol tries is completely self configurable and energy aware. It does congestion control by a form of rate adaptation. But here instead of modifying the rate at which individual packets are sent the frequency of event reporting is changed. Thus the proposed architecture runs completely from the sink node. The paper differs from other approaches like PSFQ which proposes a complete transport protocol for sensor networks. RMST is a reliable data transport for sensor networks which is again a complete transport layer solution. RMST uses diffusion for routing and is selective – NACK based. Thus the unique contribution of the paper is an application specific transport with modified semantics of reliability. The paper is based on operating the frequency of reporting at an optimum point. If the frequency is kept below a threshold then the reporting is not very reliable. Also increased frequency will lead to congestion. Thus adaptation must be done to maintain an optimum point on the hill. The operating region is divided into four regions of no congestion and congestion and low and high reliability. Appropriate mechanism like aggressive multiplication is proposed to keep the protocol at an optimum operating point. The congestion detection mechanism is also changed from the packet based metric to a frequency based metric. The main contributions of this paper are a modified notion of reliability which is more applicable to sensor networks. Also all operations are pushed to the sink and the overhead is less. However the questions remain on how the selfish behavior for one flow affects other flows, and further analysis is required on the same. End to End Design Issues: This seminal paper deals with the proper placement of functionality in a distributed application, especially one over a multi layered architecture. It states that any function can be placed only with the knowledge of the application layer. If the bottom layers are designed ignoring the application layer, they introduce a lot of redundancy into the system. The authors explore a classical file transfer application implemented over a traditional layered architecture with multiple error checks. By designing insulated components we introduce redundancy and overhead into the system. This is because every layer implements unnecessary and repetitive mechanisms which can be easily aggregated. The authors point out that just relying on the application layer to do the necessary functions is not a good idea as it will mostly be inefficient. In the case of the transfer application, the entire file has to be passed multiple time so some sort of failure tolerance has to be built in. Thus a compromise is required to reach an ideal location in the design space. The authors also point out the fallacy of assuming the lower layers provide complete fault tolerance in terms of an application which failed due to a bit flip. The end to end argument is shown to have practical implications to problems like delivery guarantees, duplicate suppression, cryptography, FIFO delivery and transaction management. This paper provides a strong basis for system designers to guide them in functional placement. This is especially relevant in today’s internet where a number of functions are being provided with application layer overlays and using p2p based systems. However with the changing nature of the internet as profiled in the next paper and the introduction of middle boxes changes some of the assumptions of the paper. The design principles introduced in the paper are also suitable for the design of sensor networks where the integration of different protocols and mechanisms introduces a lot of redundancy. Since sensor network is purely application based, the principle expounded in this paper can be easily applied. Middle Boxes: Taxonomy and Issues: This document discusses middle boxes which are special devices which can perform a particular function or do some processing which are different from the standard ip routers. Middle boxes are pervasive in today’s internet-work. However they do not fall into the classically defined 7 layer stack and hierarchy. Thus this document attempts to classify such theses devices along various dimensions and also reaches a few conclusions of the impact of such devices. The classical view of the internet is an hour glass model with the narrowest part being the ip layer. Thus it allows diversity in the upper and lower layers. But this transparent ip model is being broken by a number of devices like NAT’s and other middle boxes. These devices are classified according to the following dimensions – The protocol layer at which it operates, Explicit o Implicit, Single or multi hop, inline or call out, functional or optimizing, Routing vs Processing, Soft and hard states, Failover vs. Restart. Though a lot of work has gone into classifying some of the devices as good or evil in the discrepancy it introduces into the public internet, the authors refuse to do this because some of the middle boxes though coming with disadvantages have their salient points. Some of the key findings of the classification is that most middle boxes are implicit, application layer, multi-hop, in-line, functional, hard state and must restart session on failure. Most middle boxes fit one of three broad categories: Mechanisms to connect disparate networks, mechanisms to separate networks into zones, or to improve performance. Also the rise of middle boxes though it violates the end to end principle it does not break the usefulness of the principle while developing applications. One of the key contributions of the article is a study of failures and how middle boxes can still function without catastrophic failures. This can be achieved by either rapid restart or rapid redirection. Overall middle boxes should be designed with failures in mind. Also it is observed that a key impairment of middleware centric design is that failures at multiple layers are very difficult to handle. Also security is an important feature that any middle box should have. However the specific security mechanisms are difficult to generalize. The article also gives common features that are desirable in any middle box and serve as a design guide. This paper has implications for the design of systems. As seen earlier a lot of mechanisms like overlays have complex emergent behavior and deserve further study. Mechanisms like middle boxes change the classical assumptions of system designers while designing systems. Also middle boxes beget the question if so many middle boxes are functional, then should not such functionality be added to the protocols themselves. From: Romit Roy Choudhury [croy@crhc.uiuc.edu] Sent: Tuesday, September 28, 2004 2:22 AM To: Indranil Gupta Subject: 598ig review 09/28 End to end argument in system design ------------------------------------ The key argument in this paper can be summarized as follows. A function should be implemented completely and correctly at the end points of the system, where the functions are completely understood. Complete reliance on intermediate functionalities can lead to degradation. However, intermediate implementation may be useful only as optimizations to the end-to-end functionalities. This is a very well written paper, and the arguments have stood the tests of time. However, i feel concerned how such an architecture may be applicable to wireless appendages to the internet. In other words, with the channel becoming instable, i wonder if there is a need to bring down functionalities to the lower layers, and push some of them into the network. Observe that the communication system knows the channel best, and therefore might result in better performance if it attempts to handle it. One such example is a TCP split connection approach where a single TCP connection from a wired server to a wireless client is broken into two connections. This allows for handling the wireline and wireless portions of the system with different approaches. Clearly, in such cases end to end principles are violated. While this split connection apporach has problems, it does not necessarily mean that the architecture is flawed. In other words, we need to try to understand whether the end-to-end argument makes any implicit assumption that may cease to hold with the changing face of the internet and communication paradigms. ESRT: Event to sink reliable transport in wireless sensor networks ------------------------------------------------------------------ An interesting paper that introduces the notion of reliability in a sensor network. This is probably among the first works in congestion control in sensor networks, and thereby merits credit for being able to identify the differences between traditional end-to-end reliability and the event-based reliability. The contributions of the paper, in my opinion, are as follows: + The observation that sensor applications are associated to a notion of event-reliability, and existing reliability techniques may not be applicable to this context. + The technique to implement reliability is robust to topology changes and wireless losses. + Explicit congestion notification flagging, a notion in the same spirit of wireless TCP, is an interesting way to obtain feedbacks from the network -- congestion decisions can thereby be based on concrete proof of congestion rather than packet-delivery estimations. Some serious concerns and suggestions of improvement: + Simulation set up such that only 2 or 3 hops. Also DSR used. This probably means that many sources chose routes through the same intermediate nodes. What if directed diffusion type routing is used. What if the underlying routing protocol performs load-balancing? In such cases the possibility of congestion needs to be justified/quantified. + The notion of number of packets receivedd at sink from the same event ID may not reflect how many packets came from which node. Many packets from a few nodes can satisfy the reliability criteria, but may represent inaccurate information. Also correlated data packets need to be seggregated and should not be considered as adding to the reliability. + How does the protocol know whether it is on the right side of the operating region or on the left side ?? + The protocol proposes to move computation to the sinks. However, the philosophy of sensor networks favors the tradeoffs towards having higher computation in comparison to communication (because the costs of communication is much higher). Is this paper in conflict with this typical assumption? Should partial computation be kept local so that unnecessary communication load can be curtailed right at the origin of dissemination. + How about using a push pull architecture in which the sources locally publish data at some rate, and the sink pulls data at its required reliability rate. Middleboxes: Taxonomy and Issues -------------------------------- Middleboxes can be summarized as intermediate functionalities added to the internet architecture for purposes of convenience (including managability, performance, policy-implementation, etc.). This RFC describes multiple middleboxes and categorizes them based on several possible taxonomies. My take on the RFC can be summarized as follows. The scalability/performance of the internet is probably a result of the well-designed architecture. The design decisions have stood the tests of time, and performance was an inevitable fallout. In other words, the end-to-end argument has proved to be largely correct for the wireline network architecture. In this context, middleboxes may be a suitable idea as long as it does not violate some of the design principles of the inernet architecture. However, greedy optimizations with an eye for performance-only can lead to slow degradation. For example, middleboxes like Transport relays can prove to be risky. Middleboxes may also be a good idea with the onset of wireless attachements to the global internet. In such cases, optimizations to suit the wireless characteristics may be beneficial. However, as pointed out in the RFC, application awareness is necessary to reap substantial benefits from these intermediate functionalities. ----------------------------------------------------------- Romit Roy Choudhury www.crhc.uiuc.edu/~croy ----------------------------------------------------------- From: Adeep Singh Cheema Sent: Tuesday, September 28, 2004 1:11 AM To: Indranil Gupta Cc: adeep.cheema@gmail.com Subject: 598ig review 09/28 09.28.2004 Cheema, Adeep S The End-to-End Argument cheema@uiuc.edu End-To-End Arguments in System Design The end-to-end argument suggests that low level system functions are not worth the cost of providing them at that level. Low level mechanisms such as bit recovery, duplicate message suppression etc can be modeled only as performance enhancements. The paper argues that distributing system functionality should be moved upward in layered systems closer to the applications that actually utilize them. The basic reasoning provided is that since most application goals tend to be complex, they often have multiple points of failure with network communication being one of them. In this scenario, creating an extremely reliable data communication system would not be efficient simply because it does not guarantee reliability and correctness on its own and it will work only to reduce the frequency of retries, which are inevitable given the multiple points of failure. Thus end-to-end application levels checks must be implemented no matter how reliable the communication system. Additional arguments for adding functions to lower strata are: All applications may not use them but still have to bear the additional cost of 'executing' them. Low level functions suffer from the lack of information. It is however advisable to have low-level functions if they can be integrated naturally into the system. The paper also presents arguments for not integrating low level support for functions such as delivery guarantees, secure transmission, duplicate message transmission, FIFO guarantees and transaction management. Middleboxes RFC 3234 A middlebox is an intermediary device providing functions other than standard IP routing functions on the datagram path between source and destination nodes. It may be virtual but it’s never the ultimate end-system of an application session. Middleboxes also contribute to the complexity of a system since they require configuration, are failure prone, may lead to failure of higher level applications which were not designed to work in the presence etc. The RFC aims to analyze middleboxes and their impact on distributed systems and applications. It also establishes guidelines for applicaiton and middlebox design while identifying harmful practices and requirements related to middlebox design. The document proceeds to catalog middleboxes according to various criteria and follows up by discussing several possible middlebox functions such as SOCKS, transport relay, packet classification etc. and classifies them according to the catalog. The RFC challenges the end-to-end argument suggesting that although currently the use the middleboxes may not result in much of a performance gain, it is advisable to design future infrastructure to natively support middleware as a way of eliminating the negative and compatibility oriented aspects of middleboxes. Future work: Testing and measuring performance gains on a network infrastructure that natively supports a set of middleboxes as an argument against the end-to-end principle. Event to Sink Reliable Transport in Wireless Sensor Networks Wireless Sensor Networks are an event driven paradigm which relies on a collection of nodes. These nodes must communicate effectively and reliably with a sink for desirable operation. This paper proposes a reliable transport mechanism for such communication in addition to robust modulation, media access, link error control and fault tolerant routing. ESRT has several commendable features such as self-configuration/adaptability, energy awareness which is critical in WSN’s, congestion control, collective identification which eliminated individual node ID’s and a implementation biased towards running on the sink rather than on sensor nodes. Reliable operation is defined in terms of packets received. If the number of packets required for event detection is greater than the number of packets received in case of an event occurring, then the communication is deemed reliable. The problem ESRT is solving is involves configuring the rate of reporting to achieve detection reliability with minimum resource utilization. ESRT attempts to reach such an optimal operating point. ESRT involves having the signal motes listen to sink broadcasts at the end of broadcast intervals and run local congestion detecting support. Given these functions, ESRT is simply a state machine implemented over the WSN using sink broadcasts, which is always trying to attain OOR through reinforcement of the rate of reporting based on the current state of the system. (-) Cannot provide end-to-end guarantees, tailored for WSN’s which have higher acceptable loss rates. Collective information is reliably delivered though individual information may be lost. (-) Running local protocols for congestion is needed at sensor nodes. (+) Effective use of mathematical optimization based design principles. From: Michael Treaster [treaster@cs.uiuc.edu] Sent: Tuesday, September 28, 2004 12:00 AM To: Indranil Gupta Subject: 598ig review 09/28 \documentclass[11pt]{article} \usepackage[margin=1in]{geometry} The End-to-End Approach End to End Argument in System Design This paper describes a design principle which suggests that features implemented at low levels of a system are likely to be of little use to high level applications built on the system. By implementing features at the low level, system designers are trying to make design decisions for applications they may not have envisioned. Additionally, they are trying to deploy features in a ``one size fits all'' fashion, where the same feature custom-designed for an application at the application level would be a better match to the application's needs. The paper describes a variety of situations where the end-to-end argument was not adhered to, then discusses what the ``correct'' implementation would have been. Although this paper predates peer-to-peer, wireless, and other types of distributed systems popular today, this principle should still be considered when designing and implementing these types of networks. Peer-to-peer and wireless protocols are today where networking protocols were at the time of this paper's publication in 1984. As these protocols are developed, designers must be wary of adding too much application-like functionality at the protocol layer, adding unnecessary bloat when applications are built on top of these protocols. The most interesting, unstated ramification of the end-to-end argument is that there is no single protocol that can do everything. Multiple protocols, assembled in a hierarchical structure, will always be required in order to provide only the necessary functionality for any application. ESRT in Wireless Sensor Networks This paper describes an algorithm for attaining optimal transport across a wireless sensor network. Each node in the network categorizes its congestion as Congested or Not Congested, and categorizes its reliability as Low, High, or Optimal. These categories are used as the basis for five different states in a finite state machine, and the node adjusts its reporting frequency based on its current operating state. This results in a simple distributed control for the dynamic system that is the network. This control technique represents the paper's main contribution. It demonstrates how each node can adjust its behavior based on local information in order to generate emergent ideal behavior from the network as a whole. However, although this might seem tricky at first, the algorithm is not particular sophisticated. The adjustments made by a node in any given state are fairly obvious to deduce. However, the authors do go a step further and provide some theoretical backing for their work, guidelines for the values of variables in the algorithm, and experimental evidence to support their performance claims. The paper's experiments are slightly suspect because the authors chose unusual values for the number of nodes in their two tests. They used networks with 41, 52, 62, 81, 90, and 101 source nodes. These values have no discernible pattern, and in fact they appear to be completely arbitrary. It might lead the read to conclude that many other tests with many other network sizes were used, and only the data points that demonstrated the authors' desired conclusions were chosen. This may or may not be the case, but authors should either use less arbitrary network sizes or they should provide a more detailed explanation as to why these numbers were chosen. Middleboxes: Taxonomy and Issues Middleboxes are network routing devices which provide some extra functionality in addition to standard routing behavior. This paper is a discussion of middleboxes - what middleboxes are, what classes of middleboxes exist, and the ramifications of middleboxes on applications, protocols, and security. This publication suggests that middleboxes should be designed and deployed with hesitation, because they can generate unexpected behavior at the application level. In particular, they violate the end-to-end argument, since they add additional, unexpected functionality to low level protocols that other applications are using. This work has several shortcomings. First, it tends to talk in relatively general terms. There are few details concerning specific middlebox implementations, specific problems resulting from middleboxes, or specific deployments of middleboxes. Additionally, this work describes a large number of problems, but it does not describe any solutions. How can the Internet be saved from the middleboxes? Finally, if middleboxes are as widely deployed as the paper implies, and if middleboxes cause as many problems as the paper suggests, it leads the reader to wonder how the Internet is functional at all under these types of conditions. From: Charles Yang [cmyang2@gmail.com] Sent: Monday, September 27, 2004 11:39 PM To: Indranil Gupta Subject: 598ig review 09/28 Charles Yang 598ig, Fall 2004 9/28, End-to-End Approach End-to End Arguments in System Design. J. Saltzer, D. Reed & D. Clark. The end-to-end argument can be summarized as thus: for some application inter-communication (over a network), some functionality can only be implemented in the application itself and not in the lower layers. Hence, there's no point in offering the functionality in the lower level since it will be insufficient. However, some incomplete functionality can be offered by the lower levels for the purpose of optimizing the function. A range of functions apply: encryption, dup msg detection, msg sequencing, guaranteed msg delivery, detecting host crashes, and delivery receipts – it's even applicable to other things such as file systems. The performance aspect of low-level partial functionality requires some considerations. It may well be that the lower levels only need to offer a non-perfect reliability, just an acceptable amount. There's a balance that needs to be struck between "low overhead" and reliability. If reliability goes down too much, overall performance may go down despite the lower overhead. ESRT: Even-to-Sink Reliable Transport in Wireless Sensor Networks. Y. Sankarasubramaniam, O. Akan, I. Akyildiz. In wireless sensor networks, it may be the case that end-to-end communication is not the goal – rather, an event-to-sink reliability notion may be desired, with the emphasis in the collective information. ESRT seeks to achieve reliable event detection with minimum energy expenditure and congestion by regulating the rate at which data is sent. ESRT requires that the sink node expend more processing power than the rest of the sensor nodes. The paper breaks up performance into 5 different regions: 1. no congestion, low-reliability, 2. no congestion, high-reliability, 3. congestion, high reliability, 4. congestion, low reliability, and 5. optimal operating region. In essence, by varying the reporting rate from the sensor nodes, one can travel through all 5 of these regions. The sink node must calculate the current performance of the sensornet, and tweak the input frequency, ultimately conserving energy expenditure. The main contribution of the paper is in the definitions of the various regions, and the approach to regulation at each range. (NC, LR) results in multiplicative increase in frequency. (NC,HR) yields a decrease at half the slope of (NC, LR). (C, HR) yields multiplicative decrease. (C, LR) yields exponential decrease. Some possible issues may be: does this work with multiple sinks asking for very similar information, but with different optimal reliabilities? If one required a much higher reliability than the other, there would have to be a mechanism for the sinks to know if they are "stepping on each others toes" with one constantly trying to raise the reliability which the other one is trying to lower. RFC 3234: Middleboxes: Taxonomy and Issues. B. Carpenter. RFC 3234 is basically an enumeration of various middlesboxes that are currently widely deployed on the internet. Middleboxes are essentially any intermediary "device" that performs a function other than normal, standard functions of an IP router on the datagrams path between source and destination hosts. Examples include NAT, caches, firewalls, anonymizers, etc. The issue with middle boxes is that the internet was originally rolled out with the end-to-end arguments in mind, namely, let the network connections be simple, and the applications take care of the complex functionality. Middleboxes effectively change those assumptions by performing a range of functionality of the datagrams traveling between hosts, in cases where the applications don't know anything about it. While, there's no cause for alarm, after all the internet currently works, the situation reminds us that it may be prudent to take a step back and rethink the end to end arguments in designing future networks. From: William Conner [wconner@glsn33.ews.uiuc.edu] Sent: Monday, September 27, 2004 11:16 PM To: Indranil Gupta Subject: 598ig review 09/28 END-TO-END ARGUMENTS IN SYSTEM DESIGN The end-to-end argument is a function placement principle stating that functions placed at low levels of a system may be redundant or of little value compared to their low-level implementation costs. The argument states that low-level function placement redundancy is usually only good for performance purposes. Also, the authors point out that low-level function placement might be too restrictive because it might force other higher layer applications to use low-level features that they don't want to use. For example, a streaming video application will not want to have message receipt acknowledgements along each hop. Thus, using an end-to-end design by providing only minimal functionality at the lower layers can provide more flexibility. Some examples where the end-to-end philosophy has been applied are reliable data transmission, secure data transmission, duplicate message suppression, FIFO delivery, and transaction management. An interesting aspect of the end-to-end argument is that it makes an exception in function placement for performance reasons. However, performance is often a strong motivating factor in systems research. Therefore, many systems that might benefit (in terms of performance) from function placement at lower levels might ignore end-to-end design in favor of more complex and redundant designs. Also, closely related to performance is that an end-to-end design might be quite costly. For example, if the last hop on a route from source to destination has errors frequently, it would be better to retransmit packets on that last hop only rather than wasting resources on the entire path during retransmission. ESRT: EVENT-TO-SINK RELIABLE TRANSPORT IN WIRELESS SENSOR NETWORKS Event-to-sink reliable transport (ESRT) is a transport solution for wireless sensor networks that seeks to achieve reliable event detection with minimum energy expenditure and congestion resolution. The authors of this paper identify an important distinction between end-to-end reliability provided by other transport protocols and the need for event-to-sink reliability in wireless sensor networks. In particular, they point out that end-to-end reliability might be overkill in wireless sensor networks that only want events to be tracked with a certain accuray at the sink. Thus, event-to-sink reliability only requires the reliability of collective information from source nodes to the sink rather than reliability for individual reports from each source node to the sink. Before presenting their ESRT algorithm, the authors did a preliminary study that demonstrated the need for congestion control. Although reliability initially increases with an increase in reporting frequency from source nodes, the reliability eventually decreases at some point when the network becomes too congested. The ESRT algorithm is based on the following five states: (no congestion, low reliability), (no congestion, high reliability), (congestion, high reliability), (congestion, low reliability), and optimal operating region. Basically, the sink node adjusts the reporting frequency of source nodes in an attempt to move from the other four states to the optimal operating region. For example, if there is no congestion and low reliability, then the sink node will tell the source nodes to aggressively increase their reporting frequency in order to increase reliability. Also, if there is congestion and high reliability, then the sink node will tell source nodes to cautiously decrease their reporting frequency in order to maintain reliability with lower energy costs. The paper has a proof and simulation results to demonstrate that their algorithm will converge to the optimal operating region. However, if there are many sensors always going up and down, then the sink node might have to always make adjustments to the reporting frequency (i.e., restarting the algorithm) and the algorithm might have difficulty converging. In such a scenario, it might be better to tolerate operation in a region that is less than optimal (e.g., no congestion, high reliability) in order to save the overhead of always running an algorithm that has difficulty converging. MIDDLEBOXES: TAXONOMY AND ISSUES A middlebox is any intermediary device (not necessarily a separate physical device) performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host. Middleboxes challenge the hourglass design of the Internet (as well as the end-to-end design argument) by adding protocol diversity and functionality into the network layer. An example of a middlebox would be a network address translator (NAT) that dynamically assigns a globally unique address to a host that doesn't have one, without that host's knowledge. NATs cause problems for application layer protocols that have IP address dependencies. Another example of a middlebox would be an IP firewall. A router with an IP firewall can reject packets based on its IP and transport headers in order to implement such functionality as disallowing any incoming traffic to certain port numbers or certain subnets. The authors point out a very important feature of middleboxes is that they may not be compatible with old protocols. Of course, one of the major downsides of middleboxes is that they might be incompatible with existing protocols (e.g., the NAT example). In such cases, protocols might have to be re-implemented or the implementation of the middlebox might need to be altered. This adds complexity to the existing protocols' designs. However, it seems like middleboxes might be a very good solution (and worth the additional complexity) to some problems (e.g., the IP firewall example can be useful as a filter to mitigate the damage of DDoS attacks). From: Pradeep Kyasanur [kyasanur@crhc.uiuc.edu] Sent: Monday, September 27, 2004 11:04 PM To: Indranil Gupta Subject: 598ig review 09/28 Pradeep Kyasanur 1. End to end arguments in system design, Saltzer, Reed and Clark, 1984 The end-to-end argument is a principle used to identify the appropriate layer in the networking stack to add different system functionality. This seminal paper argues for placing functionality only at a layer where it can be completely and correctly implemented. All other implementations of the functionality at lower layers are useful only as a means of enhancing performance. For many situations, this argument implies that the functionality has to be built into transport or application layers, which are located at the end hosts, hence the name "end-to-end" principle. Many examples are given to explain the application of end-to-end principle, and scenarios are presented where breaking the end-to-end principle may lead to redundant operations. Comments: + The end-to-end argument has had an enormous influence on the design of networking stack used in today's Internet by providing a design recipe. For example, end-to-end argument is the basis for adding reliable data delivery guarantees to TCP while restricting IP to be an unreliable datagram service. - As the authors themselves point out, the application of the end-to-end argument requires care in identifying the "ends". In addition, many solutions require implementation of cross-layer solutions where the end-to-end argument cannot be easily applied. For example, effective congestion control requires transport layer solutions (TCP) as well as network layer solutions (RED). 2. ESRT : Event-to-Sink Reliable Transport in wireless sensor networks, Y. Sankarasubramaniam et al, Mobihoc 2003 Reliable Transport (e.g., TCP) is an important functionality provided by the transport layer in the Internet, which is used by a large number of applications. This paper defines a reliable transport protocol that may be of use for many sensor network applications. Many sensor network applications require the collection of sensing reports (events) from many sensors at a sink node. The individual sensors may not have a distinct identity and may be unreliable. Hence, in sensor networks, reliability may be defined as "reliably sensing an event", and reliable transport may be defined as "delivering at least a threshold fraction of events to the sink". A key contribution of the paper is this sensor network specific definition of reliability. In addition, in sensor networks there is a need to minimize energy consumption. The paper proposes a reliable transport protocol that ensures exactly the desired level of reliability that reduces reporting traffic when there is more than sufficient reliability, thereby saving energy. The paper identifies the relationship between frequency of reporting events by the sensors and the frequency of received events at the receiver, and uses the measured relationship to drive the congestion control algorithm. Comments: + The notion of "event-to-sink reliability" is well suited to the needs of wireless sensor networks. + The proposed transport protocol places most of the burden on the sink, which ensures the protocol is robust to sensor failures. - The relationship between reporting traffic and event reliability is derived from ns2 simulations using specific routing and MAC protocols. The routing protocol used is DSR, while protocols such as directed diffusion may be more suitable to sensor networks. The paper does not identify how the performance of the proposed protocol may be affected if the relationship between reporting traffic and event reliability is different. - Reliability is expressed in the paper as a threshold number of received packets. Applications may have other notions of reliability, and the proposed transport protocol cannot handle alternate notions of reliability. Future work: The paper controls the amount of data sent by the sensors by controlling reporting frequency. An alternate mechanism may be to control the number of sensor nodes that need to send the information. This will enable putting "extra" sensor nodes to sleep, thereby conserving energy. Also, many proposals consider in-network aggregation of data, which may require a different notion of reliability, and different transport protocols. 3. Middleboxes: taxonomy and issues, RFC 3234 Middleboxes are defined in this RFC to be any intermediary box performing functions that are different from that of a standard IP router. Middleboxes are a popular solution to enhance the features available in the Internet infrastructure or applications without requiring a global implementation. Network Address Translator (NAT) is a well-known example of a middlebox, which enables the mapping a local address to a globally unique address. NAT (along with flat addressing) has revolutionized the IP address requirements of the Internet and has staved off the implementation of IPv6. Other examples of middleboxes presented in the RFC are NAT-PT, SOCKS gateway, IP Tunnel Endpoints, Packet classifiers, Application and Transport Gateways, Proxies, Firewalls, and Caches. Most of middleboxes implement application layer functionality, but are implemented in the Internet path between the source and the destination, thereby breaking the end-to-end model. The RFC concludes with a recommendation that future protocol designers explicitly account for middleboxes, and identifies standard functionality that needs to be implemented in all middleboxes. Comments: Middleboxes have been unfavorably viewed in the networking community because they break the end-to-end principle, and introduce unknown side effects into existing protocols. However, as the paper "Middleboxes no longer considered harmful" argues, middleboxes are increasingly being viewed as a part (albeit flawed) part of the Internet. Also, the increasing popularity of middleboxes may be symptomatic of fundamental flaws in the Internet architecture (e.g., inflexibility to addition of new features). From: Zahid Anwar Sent: Monday, September 27, 2004 9:54 PM To: Indranil Gupta Subject: 598ig review 09/28 Zahid Anwar NetId: anwar CS598IG Review End to end arguments in system design -------------------------------------------- Summary ------- The authors provide a new analysis of function placement and its associated design principles. The problem consists of creating a design principle that would generate system designs to increase performance by placing functionality at the most appropriate level. SRC present the end-to-end argument, namely putting functionality at the application level, is most often the best approach in system design. They argue that the lower level is not aware of the needs of the application making the functionality placed at the lower level insufficient and will have to be duplicated at the application level anyways. They give an example of a reliable file transfer to support their case. Other examples include Delivery guarantees, (acknowledgements), Secure transmission of data (low-level encryption), duplicate message suppression and guaranteeing FIFO. Strengths --------- + A good guideline that helps in design provided care is used to identify the end points to which the argument is applied. + Tends to reduce the amount of processing required in the network, allowing the network to operate at higher speed when processing is the bottleneck + Simple networks are more scalable than complicated networks -an important contributor to the recent success of p2p networking (e.g. Gnutella and Napster). + Simple Networks are easier to design and change, and this short design turnaround time allows them to track improvements in implementation technologies. Weaknesses ---------- - E2e checks may help detect that a component is misbehaving, however they often lack the selectivity of localized checks to detect which one. - Software design involves developing useful abstractions, like a reliable data communications network. These abstractions are designed to satisfy the needs of a wide array of expected applications e.g TCP -Ignore factors such as complexity, reusability, and developer time. -Low level architecture often designed before applications that use the mechanisms are designed, this results in more functions being imbedded at the lower levels. Future Work ----------- -It has been 20 years since the paper was published. Reed has revisited this issue and written on how end-to-end arguments remain pertinent today in the "The end of the end-to-end argument" -Clark has written about the role of e2e in the context of the changing requirements of the Internet “Rethinking the design of the Internet: The end to end arguments vs. the brave new world” Review ESRT : Event-to-Sink Reliable Transport in wireless sensor networks -------------------------------------------------------------------------- Summary ------- A transport protocol for sensor networks should ideally have reliability and congestion control but are constrained by resources such as power, storage, computation complexity and data rates. ESRT places interest on events and not individual pieces of data. Its application specific in the sense that the application defines what its desired event reporting rate should be. It primarily tries to adjust reporting rates of sources to achieve optimal reliability requirements as well as minimize energy consumption. Both congestion and reliability monitoring are the responsibility of the sink. Nodes monitor their buffer queues and inform the sink if overflow occurs. Reliability Level is calculated by the sink at the end of each interval based on packets received. The algorithm for ESRT in case of congestion is that if low reliability required then decrease reporting frequency aggressively otherwise decrease reporting only to relieve congestion. In case of no congestion and low reliability requirement increase reporting frequency aggressively otherwise decrease reporting slowing. Strengths --------- + First scheme that focuses on the e2e reliable event transfer. + reliability is controlled based on the reporting frequencies of sensor nodes Weaknesses ---------- - Needs to deal with the case of multiple concurrent events. - Congestion may be due to all sensor nodes. Need a better way to slow down the nodes causing congestion. - Pushes all complexity to the sink - Single-hop as apposed to multi hop operation only Review Middle boxes: Taxonomy and Issues --------------------------------------- Summary ------- The paper asserts that the Internet is supposed to be a bearer of openness and end-to-end philosophy. However, recently a deviation from this 'hour glass' model (small IP in middle, complex protocols above and below) has been observed. Packet filtering firewalls, NATs, SOCKS, IP tunnels, load balancers, transcoders, proxies, caches are commonly employed in the Internet for security, address depletion reasons and various other reasons. These are termed middleboxes -an intermediary device performing functions other than the normal, standard functions of an IP router. Several problems arise from the deployment of middleboxes e.g. they represent a potential obstacle to many applications because establishing connections across them is too restricted. For example p2p applications, such as Napster NetMeeting, suffer from the problem that they cannot service across NATs and firewalls. Furthermore, not only do middleboxes introduce new failure points in the Internet architecture and configuration is no longer limited to the two ends, but also middleboxes require configuration and management. IETF MIDCOM working group has proposed an approach where the application intelligence is externalized from the middlebox into trusted third parties that can assist the middlebox during its operation. Such entities are called MIDCOM agents. From: Vartika Bhandari Sent: Sunday, September 26, 2004 8:57 PM To: Indranil Gupta Subject: 598ig review 09/28 End-to-end arguments in System Design This paper examines the end-to-end argument in the design of networked systems,and discusses the merits and de-merits of placing functionality in the network rather than at the end-points. The key argument in favor of the end-to-end principle is that applications might need to replicate much of the functionality lower layers might try to provide e.g. even if a reliable link-layer is being used, the application might need a checksum+retransmit mechanism in order to protect itself against errors during buffer manipulation. Besides, the application might have strong security requirements and be unwilling to trust the lower layers. Another drawback is that if certain functionality is required by only a subset of applications, placing it in lower layers forces every application into the overhead of the unwanted feature. On the other hand, handling of tasks like reliability etc. by lower layers allows for quicker recovery from errors e.g. if a transmission error happened on a single link, it may be locally handled via an ARQ mechanism. Thus there may be signifcant performance improvement to be had depeding on what the probability of occurrence of error is. The paper thus brings out the trade-off involved in a pure end-to-end vs. "put function in the network" approach. Middleboxes: Taxonomy and Issues This RFC discusses various categories of "middeboxes" and the issues involved in the use of each. The term "middlebox" is used for an entity that is placed between the two communication endpoints, and performs more than just routing functions. Middleboxes thus violate the end-to-end principle. Some of the aspects which differentiate between different classes of middleboxes are duscussed e.g. layer of operation, explicit/implicit presence, type of state(hard/soft) etc. The commonly encountered middleboxes such as NAT, NAT-PT, SOCKS gateways, ALGs, packet classifiers etc. are discussed too. The authors arrive at the conclusion that though middleboxes are needed, future protocols should explicitly factor in their presence rather than base themselves on the end-to-end principle. This would help avoid complications that arise because of middleboxes violating protocol assumptions. Another recommendation is that the handling of middlebox failures be carefully provided for. Security is mentioned as a major issue since middleboxes make it difficult to have end-to-end encryption etc. Overall, the authors propose a more methodical and structured approach to middlebozes. They recognize them as a necessary evil (?), but believe that a number of problems would be resolved if protocol designers explicitly address their possible presence in the network. ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks This paper proposes a transport protocol for reliable and energy-efficient transport of event-related data from sensor nodes to the sink in a sensor network. The key notion is that data communication in a sensor network is primarily tied to event monitoring. Hence the relevant issue is that the sink should receive enough packets regarding a given event to be able to derive suitable information from it. Sending data at a rate higher than this can only cause congestion in the network and degrade energy-efficiency. The authors consider the network as operating in one of five distinct regions viz. No Congestion and Low Reliability, High Congestion and Low Reliability, High Congestion and High Reliability, No Congestion and High Relibility, and the Optimal Operating Region. The goal of the designed transport protocol is to steer the network towards the OOR from whichever region it is currently operating in. Some of the observations regarding network operation with increasing reporting requency are interesting (section 3). One question that seems to arise is: is the OOR always achievable (suppose multiple competing event flows)? Another issue is that ESRT seems to require feedback from sink to sources for controlling reporting frequency. This seems to indicate a regular ACK flow from sink to sources. In a sensor network, it is debatable whether one would like to have that degree of control overhead, and it might seem a better alternative to merely have limited redundancy in unreliable transmissions to get a probabilistic guarantee of information reaching sink. From: Moosa Muhammad Sent: Sunday, September 26, 2004 4:55 PM To: Indranil Gupta Subject: 598ig review 09/28 Reviews Written By: Moosa Muhammad For Presentation Dated: 9-28-2004 (1) Review of "End-To-End Arguments in System Design" This paper presents the principle of "End-to-End Arguments," which is used to guide the placement of functions among the modules of a distributed system. It specifically says that functions should be moved closer to the application that uses it. The intuition behind this idea is that functions at low levels of a system may be redundant or of little usefulness, when compared to the cost of providing them at that level. They first discuss the reliable data transmission function, to show the correct placement of it. The general idea behind this function is to transfer a file from host A to host B reliably, in spite of various possible failures that can occur along the way. Through the analysis of the possible threats that can occur, they concluded that in order to achieve this goal, the application program that performs the transfer must supply a file-transfer-specific, end-to-end reliability. Also, making the data communication layer more reliable would not reduce the burden of ensuring reliability on the application program. As a performance enhancement, it is sometimes beneficial to have an incomplete version of the function provided by the communication system itself. Therefore, a tradeoff exists between performance and making the above decision. Some other examples of the end-to-end argument that they considered included providing delivery guarantees, secure transmission of data, duplicate message suppression, etc. Some criticisms/comments regarding this paper are that it does not provide any mathematical analysis to support and strengthen their arguments. A detailed analysis of the end-to-end argument on one or two examples would have been more beneficial than providing just basic intuition, in order to apply it to various examples. A good future area of research would be to perform some quantitative performance measurements based on different levels at which reliable data communication is implemented, in order to come up with the best placement for such a function. Another good future research area would be to analyze the drawbacks of the telephone system (which supports intelligent networks, but dumb end systems), and see if such drawbacks are completely avoided by using internet-telephony (based on the end-to-end argument). (2)Review of "ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks" This paper presents a new reliable transport protocol for Wireless Sensor Networks (WSN), called the event-to-sink reliable transport (ESRT). Some important features of ESRT include a smart congestion control mechanism that serves the dual purpose of achieving reliability, along with conserving energy (which is critical in sensor networks). The algorithms of ESRT mainly run on the sink, thus leaving minimum amount of work for the resource constrained sensor nodes. If the event-to-sink reliability is lower than required, ESRT adjusts reporting frequency of source nodes aggressively in order to reach the target reliability. On the other hand, if the reliability is higher than required, then ESRT reduces the reporting frequency conservatively in order to conserve energy, while still maintaining reliability. This self-configuring nature of ESRT makes it robust to random, dynamic topology in WSN. ESRT has been designed for use in typical WSN applications involving event detection and signal estimation/tracking, and not for guaranteed end-to-end data delivery services. In order to study the relationship between the observed reliability at the sink, r, and the reporting frequency, f, of sensor nodes, they developed an evaluation environment and conducted a number of experiments. The general pattern that they noticed was that r initially increased by increasing f, but after a certain threshold, there was a big decrease in reliability, due to congestion loss. Therefore they showed that there is a need for an event-to-sink transport solution with a congestion control mechanism in WSN. A sink must be able to detect congestion in the network, but conventional PING/ACK detection methods cannot be used since event-to-sink reliability is desired instead of end-to-end reliability. ESRT monitors the routing buffer, and whenever it overflows, the source informs the sink about it. A criticism about their technique of detecting congestion is that they are assuming that all the sensor nodes (i.e. source nodes) are identical (in terms of resources, especially buffer size). This is evident since they are applying a general buffer overflow detection technique among all sensor nodes. This can be problematic if super-nodes are introduced into the network. Some future research areas that can be looked into include extending ESRT to address multiple concurrent events in the sensor field and investigating other possible reliability metrics. A very interesting future project can be to implement security protocols (for authentication, etc.) using ESRT as the underlying reliable protocol. (3)Review of "Middleboxes: Taxonomy and Issues" Middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host. The primary goal of this document is to describe and analyze the current impact of middleboxes on the architecture of the Internet and its applications. Another goal of it is to identify any necessary updates to the Architectural Principles of the Internet. This article classified different types of middleboxes, and concluded that current types of middleboxes are predominantly application layer devices not designed as part of a relevant protocol, performing required functions, maintaining hard state, and aborting user sessions when they crash. Middleboxes fit into one or more of following categories: (a) Mechanisms to connect dissimilar networks to enable cross-protocol interoperability (b) Mechanisms to separate similar networks into zones, especially security zones (c) Performance enhancement Since each extra middlebox in the communication path creates extra points of attack, therefore security is a big concern when introducing additional middleboxes. Some future areas of research include coming up with architectural guidelines for application protocol and middlebox design and identifying requirements and dependencies for common functions in the middlebox environment. This would help in creating a standardized interface, allowing middleboxes to implement a pre-defined set of functions in order to "add" itself to the underlying network. A comment regarding the general mechanism of providing security (in spite of the presence of middleboxes that may or may not have security mechanisms built-into them) is to treat middleboxes as "black-boxes" and have an outer layer that implements security primitives for each middlebox. From: Ellick M Chan Sent: Monday, September 27, 2004 11:46 AM To: Indranil Gupta Subject: CS598ig reviews 9/28/2004 Ellick Chan Reviews 9/28/2004 General issues: We examine end to end reliability arguments starting with the original MIT paper. The end to end arguments are applied to more recent middleboxes and event to sink reliable transport (ESRT) in wireless sensor networks. It seems that as applications are getting more advanced, it is becoming increasingly difficult to ensure application consistency through correct and orderly message delivery. Systems such as CATOCS (Birman), which attempt to causally order messages, can suffer from ill effects such as application incorrectness. End to end arguments hold in many cases such as real-time voice applications; here, it is more important to drop voice packets than attempt to deliver all of them correctly. End to End arguments in system design: The end to end argument in system design states that errors handled at levels as low as the protocol level have little efficacy on overall system state consistency. This is due to the inability of lower level protocols to understand the message reliability requirements of applications without their help. They concluded that many protocol-level reliability guarantees merely provided performance enhancements rather than ensuring correct functionality. Cheriton and Skeen argued against Birman’s arguments for systems like CATOCS, which attempt to apply causal ordering to messages. C&S argued that several factors would confuse such systems. Among them are false causality, hidden communications channels, and high overhead. Such reliability protocols typically incur extra overhead by relying on acknowledgement schemes and costly distributed consensus algorithms. This is done even for data that an application places little value, such as lost streaming packets. Modern systems typically have their own error handling system, such as two phase commits, Reed Solomon correction for missing packets, and packet dropping/interpolation for audio video applications that can mask the loss of data. The end to end argument becomes more relevant in today’s world where specialized applications such as multimedia streaming and sensor network propagation are better handled at a higher semantic level. MiddleBoxes: Continuing the end to end argument, this article examines various types of middleboxes, which act in the narrow area of TCP/IP’s hourglass model. These devices modify and filter IP, trying to provide higher level services by changing the behavior of the network. Common devices include NAT boxes for home and commercial use, web proxies, DNS load balancing, and IP tunnels such as VPNs. The argument is that while all these middleboxes provide desirable services, they compromise the end to end argument by complicating recovery procedures upon their failure. The majority of these failures are impossible to recover from, and require a connection restart. Simultaneously, middleboxes such as NAT cause many problems for applications wishing to use UDP or TCP behind a router. This requires the introduction of application gateways for tasks such as gaming and video conferencing. In general, it seems that many of these middleboxes are useful as short-term solutions to problems involving IP. NAT originated as a solution to the IP address shortage due in part to wasteful subnetting. Its popularity is slowing down the adoption of a more mature IP protocol, IPv6. At the same time, VPNs were developed to securely authenticate users and tunnel data without fear of outside snooping. While this seems to help the security problem in general, it can just as easily be solved by a proper implementation of IPSEC, which provides host authentication and connection security. Alternatively, applications can use a system like ssh to provide many of the same guarantees, but at an application level instead. By using this approach, failure of ssh is limited to only single machines, unlike the problems encountered by using VPN tunneling. Furthermore, the problem becomes worse as security concerns force firewalls to be erected corporate networks, leaving large groups of computers with no public addressing from the Internet, which breaks many applications such as servers and multimedia conferencing. Event to sink reliable transport ESRT: In ESRT, the authors develop a system to provide a reasonable measure of reliability in sensor networks without adversely affecting performance. ESRT is an adaptive algorithm that works by controlling reporting frequency parameters to optimize a reliability parameter, r, which is determined by the ratio of received packets to desired receive amount. The application can set a certain level of reliability according to its needs. For example, voice applications can request a 90% packet receive rate to function correctly. To detect congestion, individual nodes check buffer capacity and signal a flag when they are overloaded. ESRT operates in rounds where the reliability is measured, and the reporting rate is adjusted to adapt to current conditions. The authors determine several regions where reliability is low, good, and poor. These correspond to under frequency, optimal frequency, good reliability due to over flooding, and congested. They develop a state machine where ESRT eventually transitions to a frequency that meets application demands without consuming excessive resources. ESRT is a system that respects both protocol-level consistency and end to end arguments. By tuning the frequency parameter, applications can better adjust reliability to meet their needs. Diametrically, ESRT provides consistency like TCP or CATOCS by ensuring messages are received correctly. It takes a hybrid approach that allows an application to modify its behavior to optimize for the task. Future improvements might include more application-specific input, such as buffer parameters to define congestion, and routing hints from applications to suggest low cost routes or low latency. Applications can objectively determine their own value for f, which maximizes parameters such as power savings, or performance. By allowing the application to decide parameters, it is possible to better develop networks that are more efficient and suitable for the needs of the application.