The initial window MAY be two packets (instead of the current initial window of one packet). For packets of at most 1460 bytes, the initial window MAY be three packets. For packets of at most 1095 bytes, the initial window MAY be four packets. 2 The Burstiness of Current TCP in Slow-Start: cwnd = 1 packet:) send one data packet ( receive one ACK increase cwnd to 2 packets:) send two back-to-back packets ( receive one ACK (a delayed ACK) increase cwnd to 3 packets:) send three back-to-back packets 3 The Burstiness of Current TCP with a Dropped Ack: cwnd = N packets, N packets are in pipe: ( receive one ACK, acking two packets) send two back-to-back packets ( receive one ACK, acking two packets) send two back-to-back packets ONE ACK IS DROPPED IN THE NETWORK

Abstract. Reactivity, the ability to detect and react to events, is an essential functionality in many information systems. In particular, Web systems such as online marketplaces, adaptive (e.g., recommender) systems, and Web services, react to events such as Web page updates or data posted to a server. This article investigates issues of relevance in designing high-level programming languages dedicated to reactivity on the Web. It presents twelve theses on features desirable for a language of reactive rules tuned to programming Web and Semantic Web applications. 1

During the past few years, Internet telephony has evolved from a toy for the technically savvy to a technology that, in the not too distant future, may replace the existing circuit-switched telephone network. Supporting the widespread use of Internet telephony requires a host of standardized protocols to ensure quality of service (QoS), transport audio and video data, provide directory services, and enable signaling. Signaling protocols are of particular interest because they are the basis for advanced services such as mobility, universal numbers, multiparty conferencing, voice mail, and automatic call distribution. Two signaling protocols have emerged to fill this need: the ITU-T H.323 suite of protocols and session initiation protocol (SIP), developed by the Internet Engineering Task Force (IETF). In this paper we examine how SIP is used in Internet telephony. We present an overview of the protocol and its architecture, and describe how it can be used to provide a number of advanced services. Our discussion of some of SIP’s strengths—its simplicity, scalability, extensibility, and modularity—also analyzes why these are critical components for an IP telephony signaling protocol. SIP will prove to be a valuable tool, not just for end-toend IP services, but also for controlling existing phone services.

Abstract not found

Abstract — By analyzing a two-month trace of more than 25 million emails received at a large US university campus network, of which more than 18 million are spam messages, we characterize the spammer behavior at both the mail server and the network levels. We also correlate the arrivals of spam with the BGP route updates to study the network reachability properties of spammers. Among others, our significant findings are: (a) the majority of spammers (93 % of spam only mail servers and 58 % of spam only networks) send only a small number of spam messages (no more than 10); (b) the vast majority of both spam messages (91.7%) and spam only mail servers (91%) are from mixed networks that send both spam and non-spam messages; (c) the majority of both spam messages (68%) and spam mail servers (74%) are from a few regions of the IP address space (top 20 “/8” address spaces); (d) a large portion of spammers (81 % of spam only mail servers and 27 % of spam only networks) send spam only within a short period of time (no longer than one day out of the two months); and (e) network prefixes for a non-negligible portion of spam only networks (6%) are only visible for a short period of time (within 7 days), coinciding with the spam arrivals from these networks. We discuss the implications of the findings for the current anti-spam efforts, and more importantly, for the design of future email delivery architectures. I.

Spam has become a major problem that is threatening the efficiency of the current email system. Spam is overwhelming the Internet because 1) emails are pushed from senders to receivers without much control from recipients, and 2) the cost for delivering emails is very low. In this paper, we present an anti-spam framework that slows down spammers: by adding delay to email delivery, and by consuming more sender resources. Both delay and resource consumption are controlled based on the likelihood of the source of email messages being a spammer, so that our technique only impact the spammers and has negligible impact on normal email senders. The mechanisms are implemented in the TCP level at the recipient side without requiring any modifications at the sender side. Our evaluations show that selectively delaying connections can effectively slow down a spammer thousands of times when they use a simple setup or use open relays. The mechanism of increasing sender's resource consumption can significantly slow down spammers even when they are spamming from their own optimized servers.

Unsolicited bulk electronic mail (spam) is increasingly plaguing the Internet Email system and deteriorating its value as a convenient communication tools. In this paper we argue that the difficulties in controlling spam can be attributed to the lack of receiver control on how different Email messages should be delievered on the Internet. In the current Email delivery architecture, a user can send messages to another at will, regardless of whether or not the latter is willing to accept the message. Based on this observation, we propose a differentiated message delivery architecture—DiffMail. In DiffMail, a user can classify Email senders into multiple classes and handle messages from each class differently. For example, although a receiver may directly accept messages from the regular correspondents, he may selectively ask other senders to store messages on the senders ’ own mail servers, and pull the messages only if and when he wants to. In this paper we present the DiffMail architecture and illustrate some of the appealing advantages using real-world Email archives. 1.

Abstract. Unsolicited commercial email, commonly known as spam, has become a pressing problem in today’s Internet. In this paper we re-examine the architectural foundations of the current email delivery system that are responsible for the proliferation of email spam. We argue that the difficulties in controlling spam stem from the fact that the current email system is fundamentally sender-driven and distinctly lacks receiver control over email delivery. Based on these observations we propose a Differentiated Mail Transfer Protocol (DMTP), which grants receivers greater control over how messages from different classes of senders should be delivered on the Internet. In addition, we also develop a formal mathematical model to study the effectiveness of DMTP in controlling spam. Through numerical experiments we demonstrate that DMTP can effectively reduce the maximum revenue that a spammer can gather; moreover, compared to the current SMTP-based email system, the proposed email system can force spammers to stay online for longer periods of time, which may significantly improve the performance of various real-time blacklists of spammers. Furthermore, DMTP provides an incremental deployment path from the current SMTP-based system in today’s Internet.

In this paper we argue that the difficulties in controlling unwanted Internet traffic, such as email SPAM, stem from the fact that many Internet applications are fundamentally sender-driven and distinctly lack receiver control over traffic delivery. However, since only receivers know what they want to receive, receiver-driven approaches may often have clear advantages in restraining unwanted traffic. In this paper, we re-examine the implications of the two common traffic delivery models: sender-push and receiver-pull. In the sender-push model, a sender can deliver traffic at will to a receiver, who can only passively accept the traffic, such as in the SMTP-based email delivery system. In contrast, in the receiver-pull model, receivers can regulate if and when they wish to retrieve data, such as the HTTP-based web access system. We argue that the problem of unwanted Internet traffic can be mitigated to a great extent if the receiver-pull model is employed by Internet applications, whenever appropriate. Using three popular applications – email, mobile text messages, and asynchronous voice messages – as examples, we demonstrate that asynchronous communication protocols can be easily designed using the receiver-pull communication model to suppress unwanted Internet traffic. 1

Abstract. Recently, social networks such as Facebook have experienced a huge surge in popularity. The amount of personal information stored on these sites calls for appropriate security precautions to protect this data. In this paper, we describe how we are able to take advantage of a common weakness, namely the fact that an attacker can query popular social networks for registered e-mail addresses on a large scale. Starting with a list of about 10.4 million email addresses, we were able to automatically identify more than 1.2 million user profiles associated with these addresses. By automatically crawling and correlating these profiles, we collect detailed personal information about each user, which we use for automated profiling (i.e., to enrich the information available from each user). Having access to such information would allow an attacker to launch sophisticated, targeted attacks, or to improve the efficiency of spam campaigns. We have contacted the most popular providers, who acknowledged the threat and are currently implementing our proposed countermeasures. Facebook and XING, in particular, have recently fixed the problem. 1