introduction.tex

\section{Introduction}

\acused{IP}
\acused{TCP}
\acused{UDP}

Since its inception, the Internet has induced a flood of innovative
networking technologies and applications. 
The topmost architectural layer, the Application layer, has traditionally 
proven most receptive to new protocols and services. 
The layers below have come to present a higher barrier to entry for 
new ideas: 
The Transport and Internet layer are dominated by 
\ac{IP}, \ac{TCP} and \ac{UDP} which have evolved as 
the common middle ground between all Internetworked hosts, 
making changes difficult to deploy on a Internet-wide scale.
On the Link layer, it is expensive and complex to create new hardware 
that implements new protocols.


Recently, \acf{SDR} and \acf{SDN} have made it practical to implement 
and deploy research ideas within the current architectural and 
deployment constraints.
This work describes an analogous technique called 
\acfp{SDS} for implementing and deploying research ideas 
that are suitable for applying at the level of the socket \ac{API}.
A key feature of this approach is that it 
allows new networking functionality to be deployed incrementally,  
without modification to existing networks or applications, 
without special hardware, % (unlike \ac{SDR} and \ac{SDN}), 
and in a user-controlled, end-to-end fashion.

The \ac{SDS} architecture we propose comprises Application-layer 
protocol implementations that both exhibit Transport-layer semantics 
to their callers, and expect the same semantics to call into. 
Therefore, \ac{SDS} components can be chained or stacked 
arbitrarily while still providing Transport-layer socket semantics 
to the application. 
\acp{SDS} thus encourage breaking down functionality into composable 
functional components.

This property has a real-world benefit:
Since new Transport-layer protocols are difficult to deploy 
on the Internet, the prevailing wisdom for implementors is to put new
Transport-layer functionality in the Application layer instead,
where middleboxes are less likely to interfere with it. 
New protocols then either use existing Transport-layer protocol
implementations (as TLS and uTP do, for example), or at least reuse
their header formats (e.g. TCP Minion) to form the actual packets
sent. Following this approch, implementors are free to define any 
Application-layer \ac{API} they deem suitable for their protocol. 
%and later change it at will, too.

We observe that implementing Transport-layer
functionality as Application-layer protocols with arbitrary, possibly
volatile \acp{API}, has undesirable effects on the usability and
reusability of such protocols: The programmer is required to use
an \ac{API} different from the Transport layer's, and consequently,
protocol implementations for the same functionality are not necessarily
exchangeable, even when they could be from the perspective of the
task they perform (e.g. different congestion control algorithms).

In contrast, an \ac{SDS} implementation of the desired functionality 
will present the usual socket \ac{API} calls, making it trivial to 
replace or combine functionality.

\albert{Further points to make: Coordination, dynamicity.}



The rest of the paper is structured as follows:

Section~... discusses the \ac{SDS} architecture we envision.
Section~... presents \ac{SDS} in the context of related work.
In Section~..., we introduce \textit{Affix}, our prototype \ac{SDS} 
implementation.
Section~... evaluates Affix with respect to overhead inflicted, 
functionality enabled, and code complexity.
Section~... concludes.
% E.g., can we make Affix call
% into IP, and reuse the TCP/UDP header while modifying the other
% transport-layer functions, as Minion does? Re-implement TCP /
% components of it with greater flexibility? SILO did this I think.)