Results 1 - 10
of
308
RTP: A Transport Protocol for Real-Time Applications
"... Status of this Memo This document is an Internet Draft. Internet Drafts are working documents ..."
Abstract
-
Cited by 1666 (110 self)
- Add to MetaCart
Status of this Memo This document is an Internet Draft. Internet Drafts are working documents
IP-based Protocols for Mobile Internetworking
, 1991
"... We consider the problem of providing network access to hosts whose physical location changes with time. Such hosts cannot depend on traditional forms of network connectivity and routing because their location, and hence the route to reach them, cannot be deduced from their network address. In this p ..."
Abstract
-
Cited by 191 (4 self)
- Add to MetaCart
We consider the problem of providing network access to hosts whose physical location changes with time. Such hosts cannot depend on traditional forms of network connectivity and routing because their location, and hence the route to reach them, cannot be deduced from their network address. In this paper, we explore the concept of providing continuous network access to mobile computers, and present a set of IP-based protocols that achieve that goal. They are primarily targeted at supporting a campus environment with mobile computers, but also extend gracefully to accommodate hosts moving between different networks. The key feature is the dependence on ancillary machines, the Mobile Support Stations (MSSs), to track the location of the Mobile Hosts. Using a combination of caching, forwarding pointers, and timeouts, a minimal amount of state is kept in each MSS. The state information is kept in a distributed fashion; the system scales well, reacts quickly to changing topologies, and does ...
Development of the Domain Name System
- In Proc. ACM SIGCOMM
, 1998
"... (Originally published in the Proceedings of SIGCOMM ‘88, ..."
Abstract
-
Cited by 191 (1 self)
- Add to MetaCart
(Originally published in the Proceedings of SIGCOMM ‘88,
An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks
, 2001
"... Attackers can render distributed denial-ofservice attacks more difficult to defend against by bouncing their flooding traffic off of reflectors; that is, by spoofing requests from the victim to a large set of Internet servers that will in turn send their combined replies to the victim. The resulting ..."
Abstract
-
Cited by 128 (0 self)
- Add to MetaCart
Attackers can render distributed denial-ofservice attacks more difficult to defend against by bouncing their flooding traffic off of reflectors; that is, by spoofing requests from the victim to a large set of Internet servers that will in turn send their combined replies to the victim. The resulting dilution of locality in the flooding stream complicates the victim's abilities both to isolate the attack traffic in order to block it, and to use traceback techniques for locating the source of streams of packets with spoofed source addresses, such as ITRACE [Be00a], probabilistic packet marking [SWKA00], [SP01], and SPIE [S+01]. We discuss a number of possible defenses against reflector attacks, finding that most prove impractical, and then assess the degree to which different forms of reflector traffic will have characteristic signatures that the victim can use to identify and filter out the attack traffic. Our analysis indicates that three types of reflectors pose particularly significant threats: DNS and Gnutella servers, and TCP-based servers (particularly Web servers) running on TCP implementations that suffer from predictable initial sequence numbers. We argue in conclusion in support of "reverse ITRACE" [Ba00] and for the utility of packet traceback techniques that work even for low volume flows, such as SPIE.
On the Effectiveness of DNS-based Server Selection
- In Proceedings of IEEE Infocom
, 2001
"... ..."
A Scalable and Highly Available Web Server
- In Proceedings of the 1996 IEEE Computer Conference (COMPCON
, 1996
"... We describe a prototype scalable and highly available web server, built on an IBM SP-2 system, and analyze its scalability. The system architecture consists of a set of logical front-end or network nodes and a set of back-end or data nodes connected by a switch, and a load balancing component. A com ..."
Abstract
-
Cited by 100 (7 self)
- Add to MetaCart
We describe a prototype scalable and highly available web server, built on an IBM SP-2 system, and analyze its scalability. The system architecture consists of a set of logical front-end or network nodes and a set of back-end or data nodes connected by a switch, and a load balancing component. A combination of TCP routing and Domain Name Server (DNS) techniques are used to balance the load across the front-end nodes that run the Web (httpd) daemons. The scalability achieved is quantified and compared with that of the known DNS technique. The load on the back-end nodes is balanced by striping the data objects across the back-end nodes and disks. High availability is provided by detecting node or daemon failures and reconfiguring the system appropriately. The scalable and highly available web server is combined with parallel databases, and other back-end servers, to provide integrated scalable and highly available solutions. 1 Introduction With the explosion of traffic on the World Wi...
A model, analysis, and protocol framework for soft state-based communication
, 1999
"... \Soft state " is an often cited yet vague concept in network protocol design in which two or more network entities intercommunicate in a loosely coupled, often anonymous fashion. Researchers often de ne this concept operationally (if at all) rather than analytically: a source of soft state tran ..."
Abstract
-
Cited by 90 (7 self)
- Add to MetaCart
\Soft state " is an often cited yet vague concept in network protocol design in which two or more network entities intercommunicate in a loosely coupled, often anonymous fashion. Researchers often de ne this concept operationally (if at all) rather than analytically: a source of soft state transmits periodic \refresh messages " over a (lossy) communication channel to one or more receivers that maintain a copy of that state, which in turn \expires " if the periodic updates cease. Though a number of crucial Internet protocol building blocks are rooted in soft state-based designs | e.g., RSVP refresh messages, PIM membership updates, various routing protocol updates, RTCP control messages, directory services like SAP, and so forth | controversy is building as to whether the performance overhead of soft state refresh messages justify their qualitative bene t of enhanced system \robustness". We believe that this controversy has risen not from fundamental performance tradeo s but rather from our lack of a comprehensive understanding of soft state. To better understand these tradeo s, we propose herein a formal model for soft state communication based on a probabilistic delivery model with relaxed reliability. Using this model, we conduct queueing analysis and simulation to characterize the data consistency and performance tradeo s under a range of workloads and network loss rates. We then extend our model with feedback and show, through simulation, that adding feedback dramatically improves data consistency (by up to 55%) without increasing network resource consumption. Our model not only provides a foundation for understanding soft state, but also induces a new fundamental transport protocol based on probabilistic delivery. Toward this end, we sketch our design of the \Soft State Transport Protocol " (SSTP), which enjoys the robustness of soft state while retaining the performance bene t of hard state protocols like TCP through its judicious use of feedback. This research was supported by DARPA contract N66001-96-C-8508, by the State of California under the MICRO program, and by
A Layered Naming Architecture for the Internet
, 2004
"... Currently the Internet has only one level of name resolution, DNS, which converts user-level domain names into IP addresses. In this paper we borrow liberally from the literature to argue that there should be three levels of name resolution: from user-level descriptors to service identifiers; from s ..."
Abstract
-
Cited by 81 (7 self)
- Add to MetaCart
Currently the Internet has only one level of name resolution, DNS, which converts user-level domain names into IP addresses. In this paper we borrow liberally from the literature to argue that there should be three levels of name resolution: from user-level descriptors to service identifiers; from service identifiers to endpoint identifiers; and from endpoint identifiers to IP addresses. These additional levels of naming and resolution (1) allow services and data to be first class Internet objects and (2) facilitate mobility and provide an elegant way to integrate middleboxes into the Internet architecture. We further argue that flat names are a natural choice for the service and endpoint identifiers. Hence, this architecture requires scalable resolution of flat names, a capability that distributed hash tables (DHTs) can provide.

