Iljitsch van Beijnum

IMDEA Networks

Author Statistics

Papers

Citation

H-Index

i-10 index

Research Field

One-ended multipath TCP

Iljitsch van Beijnum

Normal TCP/IP operation is for the routing system to select a best path that remains stable for some time, and for TCP to adjust to the properties of this path to optimize throughput. A multipath TCP would be able to either use capacity on multiple paths, or dynamically find the best performing path, and therefore reach higher throughput. By adapting to the properties of several paths through the usual congestion control algorithms, a multipath TCP shifts its traffic to less congested paths, leaving more capacity available for traffic that can't move to another path on more congested paths. And when a path fails, this can be detected and worked around by TCP much more quickly than by waiting for the routing system to repair the failure. This memo specifies a multipath TCP that is implemented on the sending host only, without requiring modifications on the receiving host.

Multipath TCP

Multipath routing

Source

Cite

Citations (1)

Crypto Based Host Identifiers

Iljitsch van Beijnum

Source

Cite

Citations (2)

Explicitly accommodating origin preference for inter-domain traffic engineering

Rolf Winter Iljitsch van Beijnum

Inter-domain traffic engineering is an important aspect of network operation both technically and economically. Traffic engineering the outbound direction is less problematic as routers under the control of the network operator are responsible for the way traffic leaves the network. The inbound direction is considerably harder as the way traffic enters a network is based on routing decisions in other networks. There are very few mechanisms available today that facilitate inter-domain inbound traffic engineering, such as prefix deaggregation, AS path prepending and systems based on BGP communities. These mechanisms have severe drawbacks such as an increase of the size of global routing table or providing only coarse-grained control. In this paper we propose and evaluate an alternative mechanism that does not increase the size of the global routing table, is easy to configure through a simple numeric value and provides a finer-grained control compared to existing mechanisms that also do not add additional prefixes to the global routing table.

Table (database)

Routing domain

Prefix

Hierarchical routing

10.1145/2245276.2245389

Cite

Citations (4)

The Shim6 architecture for IPv6 multihoming

IEEE Communications Magazine (2010)

Alberto García-Martínez Marcelo Bagnulo Iljitsch van Beijnum

The Shim6 architecture enables IPv6 multihoming without compromising the scalability of the global routing system by using provider aggregatable addresses. To do so, hosts use different addresses as locators for data packet transmission, but present the same source and destination identifier pair to transport and upper layers. The components of this architecture are the Shim6 entity, which maps and translates upper-layer identifiers and locators for remote hosts; the Shim6 protocol, which exchanges mapping information between two hosts that communicate; and the REAP protocol, which monitors the existing unidirectional paths and finds new valid locator combinations in case of failure. To protect against new vulnerabilities this architecture may introduce compared to IPv6, Shim6 hosts use either cryptographically generated addresses or hash-based addresses.

Multihoming

IPv6 address

10.1109/mcom.2010.5560599

Cite

Citations (24)

FTP consideration for IPv4/IPv6 transition

Dapeng Liu Zhen Cao Iljitsch van Beijnum

The File transfer protocol(FTP) has a long histroy,, but still being widely used. The first concept of FTP was described RFC 114, and then was specified in RFC 354. FTP can work in IPv4 environment and then was extended to IPv6. RFC 2428 defines IPv6 extensions of FTP. In the IPv6-IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. This document discusses the details for FTP to work in IPv4-IPv6 transitiion scenario. This document gives recommendation regarding how IPv6 FTP client should behave in 6to4 scenario.

IPv4

Source

Cite

Citations (0)

Router buffer sizing

Iljitsch van Beijnum

Buffer (optical fiber)

Source

Cite

Citations (0)

GAPI: A Geographically Aggregatable Provider Independent Address Space to Support Multihoming in IPv6

Py M Iljitsch van Beijnum

Multihoming

Source

Cite

Citations (2)

IPv4 Address Space: 2.46 Billion Down, 1.25 Billion to Go

Iljitsch van Beijnum

In September 2005, The Internet Protocol Journal published an article about the IPv4 address space consumption[1]. At that time,projections done by Geoff Huston and Tony Hain varied widely,because the number of /8 address blocks in use had gone up sharply in early 2005. So what has happened since then, and what can we expect for the not-too-distant future?

IPv4

Source

Cite

Citations (0)

IPv4/IPv6 Coexistence and Transition: Requirements for solutions

Marcelo Bagnulo Fred Baker Iljitsch van Beijnum

This note presents the problem statement, analysis and requirements for solutions to IPv4/IPv6 coexistence and eventual transition in a scenario in which dual stack operation is not the norm.

IPv4

Source

Cite

Citations (2)

Multi-path BGP: motivations and solutions

Cambridge University Press eBooks (2012)

Francisco Valera Iljitsch van Beijnum Alberto García-Martínez Marcelo Bagnulo

Although there are many reasons for the adoption of a multi-path routing paradigm in the Internet, nowadays the required multi-path support is far from universal. It is mostly limited to some domains that rely on IGP features to improve load distribution in their internal infrastructure or some multi-homed parties that base their load balance on traffic engineering. This chapter explains the motivations for a multi-path routing Internet scheme, commenting on the existing alternatives, and detailing two new proposals. Part of this work has been done within the framework of the Trilogy research and development project, whose main objectives are also commented on in the chapter.

Trilogy

10.1017/cbo9780511920950.013

Cite

Citations (11)