\chapter{\label{chap:RelatedWork}Related work}


\section{Introduction}

In this chapter, I will briefly summarize some work that is related to what I have proposed in this thesis. Part of the related work has already been introduced in the previous chapters, and so this chapter will describe what I have not discussed before. 

\subsection{Organization of the chapter}
One of the key contributions of this thesis is the exploration of integrating high-capacity all-optical circuit switches in the core of the network with a packet-switched access network. This was achieved by monitoring user-flows. Section~\ref{sec:RW:CSI} describes other approaches that also try to integrate circuit switching in the Internet. In contrast, Section~\ref{sec:RW:PSO} presents other approaches that try to extend the packet switching paradigm to the all-optical core. Because this approach differs significantly from what has been discussed previously in this thesis, Section~\ref{sec:RW:PSO} has a somewhat lengthy discussion. Finally, Section~\ref{sec:RW:FlowMeasurements} reviews other proposals for monitoring user flows in the network.

\section{\label{sec:RW:CSI}Circuit switching in the Internet}
As mentioned in Chapter~\ref{chap:Intro}, it is becoming increasingly difficult to build high-performance packet-switched routers. This is due to several reasons, such as traffic growing at a faster rate than the technology trends of electronics and the slow evolution of memory random access speeds. This calls for research into alternatives. One of these alternatives, which has also been explored by other researchers, is to integrate very high-capacity circuit switches in the core of the otherwise packet-switched Internet. The  advantage of these approaches is that circuit switching is a switching technique that is easy to support with optics. There are three main approaches that define dynamic signaling mechanisms to the circuit management process in SONET/SDH and DWDM circuits: Generalized Multiprotocol Label Switching ---GMPLS--- (Section~\ref{sec:RW:GMPLS}), Optical Internetworking Forum ---OIF--- (Section~\ref{sec:RW:OIF}), and Optical Domain Service Interconnect ---ODSI--- (Section~\ref{sec:RW:ODSI}). These three working groups provide the signaling mechanisms for managing circuits, and vendors define how to monitor traffic, what triggers circuit establishment, and how to allocate bandwidth. 

There are two architectures that address the issues of when to establish a circuit and how much bandwidth has to be allocated to it. Optical Burst Switching ---OBS--- (Section~\ref{sec:RW:PSO}) queues packets up to a threshold and then establishes a circuit with an explicit connection release time (also known as a burst). Veeraraghavan et al. (Section~\ref{sec:RW:Zing}) define an end-to-end, circuit-switched network that is parallel to the packet-switched Internet. This model only transmits large file transfers through the circuit-switched network.  

The approach proposed in Chapter~\ref{chap:TCPSwitching}, TCP Switching, differs from both approaches above in that it (usually) piggybacks the creation of a circuit on the setup phase of a TCP connection. In this respect, TCP Switching is similar to IP Switching (Section~\ref{sec:RW:IPSwitching}), in which user flows trigger the establishment of ATM virtual circuits. 


\subsection{\label{sec:RW:GMPLS}Generalized Multi-Protocol Label Switching (GMPLS)}

Coarse granularity GMPLS \cite{GMPLS01,GMPLS01routing} has been proposed within the Internet Engineering Task Force (IETF) as a way to extend Multi-Protocol Label Switching (MPLS), a packet-switching technique for traffic engineering, to TDM and DWDM circuit switching. Label-switched paths consist of a bundle of TDM channels, wavelengths and fibers with bandwidths of 51~Mbit/s or higher. GMPLS deals with issues such as signaling, routing, protection, restoration and circuit management for coarse flows and circuits. 
Because of the multiple tasks that it needs to perform, the signaling of GMPLS is complex. The exact control algorithms that decide when to establish and release the circuits are left to the vendors to develop, and they have to cope with a system of paths and circuits that evolves more slowly than the traffic in the Internet. By studying Internet traffic traces, we have seen in Chapter~\ref{chap:CoarseCircuits} that, indeed, these control algorithms would need a lot of slack in their bandwidth allocation in order to prevent bandwidth exhaustion in the circuits. 

GMPLS uses the same mechanisms as MPLS to decide when to create or destroy a circuit. GMPLS relies on an MPLS traffic-engineering server (TE server) to issue requests for new label-switched paths (LSPs) or to modify the characteristics of existing LSPs. This TE server is at the ingress of the packet-switched MPLS network, where it collects traffic information to make its decisions. Contrary to pure MPLS, GMPLS can only allocate bandwidth in discrete and coarse steps, and its control path is decoupled from the data plane. 

More specifically, GMPLS introduces:
\begin{itemize}
\item a new Link Management Protocol (LMP) to address issues of link monitoring and link management in optical networks \cite{GMPLS01routing}.
\item enhancements to the traffic engineering of OSPF and IS-IS routing protocols to advertise the availability of optical resources in the network \cite{GMPLS01routing}. This extended topology information is used to compute paths subject to specified resource and/or policy constraints using the shortest-path-first heuristic. The routing is done hop-by-hop unless a given path is requested by the ingress.

\item enhancements to Resource Reservation Protocol with Traffic Engineering (RSVP-TE) and Constraint-Based Routing Label Distribution Protocol (CR-LDP) to allow a label-switched path across the circuit-switched core to be explicitly specified \cite{GMPLS01}.
\end{itemize}


The main difference between RSVP-TE and CR-LDP is that RSVP-TE uses ``soft state'' to manage the paths (circuits are timed out unless the reservation is refreshed periodically), whereas CR-LDP uses ``hard state'' (an explicit message is required to destroy active circuits). They provide a trade-off between signaling overhead to refresh the state and complex failure recovery scenarios. In Chapter~\ref{chap:TCPSwitching}, I use soft state without having to pay a penalty in signaling overhead since any activity in the data channel automatically refreshes the state of the circuit. In a sense, I assume semitransparent switches that only understand whether a channel is being used or not. This hardware support is not always present in the switches that are considered by GMPLS, which may be completely transparent when switching information.

In both RSVP-TE and CR-LDP, the ingress has to wait for the round-trip time of a 2-way handshake to start sending data. In TCP Switching, the first packet in the flow is used to establish the circuit, and, consequently, there is no delay in sending the data.

As with the solution presented in Chapter~\ref{chap:CoarseCircuits}, GMPLS can use a hierarchy of LSPs to exploit the larger capacity of optical circuit switches that can only switch at very coarse granularities. The hierarchy is composed of packet-switched LSPs, TDM circuits, wavelengths and fibers.

GMPLS allows the establishment of bidirectional LSPs with a single control message, whereas TCP Switching only works with purely unidirectional circuits. Moreover, in GMPLS, failure recovery is a very important mechanism; however, this topic is not within the scope of this thesis. However, there are many mechanisms for protection and restoration that have been proposed \cite{Li01reliable,modiano01survivable,choi02failure} that could be applied to the solutions proposed in Chapters~\ref{chap:TCPSwitching} and~\ref{chap:CoarseCircuits}. 

In summary, GMPLS focuses on the management of coarse circuits between core routers. Its scope is slightly different than the contents of this thesis because it does not specify a control algorithm to decide when to create circuits and with which capacity. GMPLS also deals with many aspects, such as routing and path protection, that have not been addressed in this thesis.

\subsection{\label{sec:RW:ASON}ASON: Automatic Switched Optical Network}
ASON \cite{ITU01G8080} is an ongoing effort carried out by Study Group 15 of the International Telecommunications Union --- Telecommunication Standardization Sector (ITU-T) to standardize the architecture and requirements of Automatic Switched Optical Networks (ASONs). More specifically, it specifies the architecture, the distributed signaling and routing requirements, and the automated discovery techniques.
Its goal is to control the optical layers in the multi-layered transport infrastructure in an uniform way, even if each layer may have its own network topology and control mechanisms. An explicit aim is to avoid developing new protocols when existing ones will do. Consequently, ASON can either make use of GMPLS or PNNI \cite{PNNI02,ATM98Book} as the signaling protocol.


\subsection{\label{sec:RW:OIF}OIF: Optical Internetworking Forum}
The Optical Internetworking Forum (OIF) \cite{OIF01} is an industry forum that attempts to provide a unified User-Network Interface (UNI) and, in the future, a Network-to-Network Interface (NNI) for optical switches and networks. These interfaces specify the interaction between the IP and circuit-switching control planes. The OIF is not a formal standards body, but produces detailed specifications that are presented to traditional standards bodies for adoption. OIF specifications are designed to work in conjunction with GMPLS.

OIF, ASON and GMPLS share the same goal: to allow a more dynamic, automated and standardized optical networking. However, they have different concerns: ASON focuses on the architecture and requirements, GMPLS defines the building blocks, and OIF works on applications and interoperability. Despite their different focus, they all recognize the need for coordination



\subsection{\label{sec:RW:ODSI}ODSI: Optical Domain Service Interconnect }

The Optical Domain Service Interconnect (ODSI) is another industry forum that competes with OIF, but it lacks the participation by the large, established networking vendors. ODSI has also defined an optical UNI, which shares the same structure as that of OIF. Clavenna \cite{Clavenna02OpticalSignaling} has written a good overview of the differences between GMPLS, ASON, OIF and ODSI.

\subsection{{\em CA*Net 4} grid design}
CA*Net 4 \cite{StArnaud03CAnet4} is the Canadian national research network, and it is organized as a grid of wavelengths, in which circuit switches forward information transparently. CA*Net 4 is targeted towards companies with multiple sites, and universities or research centers that need to exchange a good amount of data among the different locations, and that can afford to have someone who monitors and controls the wavelength grid. These sophisticated users either lease or own the capacity that they use in the network. The network client has complete control over its own wavelengths, and he/she decides what gets added/dropped at the different nodes. The client can even sublease part of the channels into which the wavelength can be divided. Through mini Internet exchange points, the network user can completely reconfigure the circuit grid that he/she controls. 

In contrast, the proposals of Chapters~\ref{chap:TCPSwitching} and~\ref{chap:CoarseCircuits} are for a public Internet infrastructure where resources are shared by all users. In addition, these proposals are geared towards the unsophisticated end user who wants a service similar to the public Internet without having to worry about the internals of the network, or having to hold a lease on parts of the network.

\subsection{IP Switching\label{sec:RW:IPSwitching}}
TCP Switching is most similar to IP Switching \cite{IPSwitching98}, in which user flows trigger the establishment of ATM virtual circuits.  The main difference is that my proposal uses true circuits, as opposed to the use of the connection-oriented packet switching of ATM \cite{ATM98Book}. Consequently, TCP Switching can benefit from the much higher capacity of circuit switches.

IP Switching uses ATM virtual circuits, which is a packet-switching technique. With virtual circuits, resources are not necessarily reserved as with true circuits. Consequently, bandwidth is not wasted if the ATM virtual circuit remains active after the associated flow has ended. With TCP Switching, bandwidth is reserved, and it is wasted when unused. This wastage of bandwidth is very relevant since typical flows in the Internet last for only a few seconds. For this reason, the inactivity timeouts of IP switching is 60 seconds; in contrast, TCP Switching uses a timeout that is only slightly larger than the RTT (0.25-1~s). 

\subsection{Proposal by Veeraraghavan et al. \label{sec:RW:Zing}}
Veeraraghavan et al. \cite{Veeraraghavan01Zing} define a circuit-switched network that is laid in parallel to the packet-switched Internet and that reaches the end hosts. When a long file needs to be transferred, the end host creates a new end-to-end circuit in the circuit-switched network. Since this end-to-end circuit is a constant bandwidth channel that is solely reserved for that transfer, the transmission sees no losses due to queueing or contention, no packet reordering, and no delay jitter. As a result, a new transport protocol, called Zing, is proposed. This protocol has very simple error and flow control mechanisms. Another characteristic of the system is that the circuit-switching signaling is simple enough to be implemented in hardware.

The use of an end-to-end circuit-switched network has two problems: first and most importantly, as shown in Chapter~\ref{chap:ResponseTime}, circuit switching in the access network yields very bad response times for end users since large file transfers eventually monopolize the link for long periods of time. Second, the cost of a second network with the corresponding links and switches is very large, and so it is unlikely that this solution will be widely deployed in the near future. This barrier to its deployment limits its attractiveness, since one can only use Zing to exchange files with a small subset of the Internet. In contrast, the two approaches presented in Chapters~\ref{chap:TCPSwitching} and~\ref{chap:CoarseCircuits} do not require any flag days, in which all network elements have to be upgraded or changed. Consequently, these two approaches can be deployed incrementally without any changes in either the access networks or the end hosts.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\label{sec:RW:PSO}Packet switching in the optical domain}

Chapters~\ref{chap:TCPSwitching} and~\ref{chap:CoarseCircuits} have described two ways of using high-capacity all-optical switches using circuit switching by integrating circuit-switched clouds with the rest of the Internet. Several researchers have proposed a different solution that disregards the use of circuit switching and tries to extend to the backbone the packet-switching model that is used in end hosts and routers across the Internet. These authors adapt packet switching to take into account the limitations of all-optical switching and forwarding elements. This section will describe these other approaches.

El-Bawab and Shin \cite{ElBawab02OPSvision} give an overview of the state of the art in the underlying technologies that are the basis for all-optical packet switching. Their paper finds that the technological challenges that need to be solved by packet switching over optics are not minor. Many of the enabling technologies are still in the research and exploration stages, and so it is premature to build a commercial all-optical router. The most important challenges to implementation come from the lack of an effective optical buffering and packet header processing because buffering and per-packet processing are the basis for packet switching. In other areas, such as signal regeneration, packet synchronization, space crossconnects and wavelength conversion, progress has been made, but scalability, reliability and cost are still issues that need to be looked at. Even if some of the technology on which packet switching over optics depends is not there yet, one can still study its performance to see what one can achieve once the technology has been developed.

This family of solutions can be further subdivided into two based on the size of the switching units: Optical Packet Switching (OPS) switches regular IP packets, whereas Optical Burst Switching (OBS) deals with ``bursts'', units that are much larger than a regular IP packet.

\subsection{Optical Packet Switching (OPS)}

Optical Packet Switching (OPS) \cite{Yao01OpticalPacketSwitching} is the simplest and most natural extension of packet switching over optics. It consists of sending IP packets directly over the all-optical backbone. The biggest challenge that packets face in an optical switch is the lack of large buffers to solve contention. As a rule of thumb, a router needs $RTT\times bandwidth$ worth of buffering \cite{villamizar94tcp}. For an OC-192c link and an average packet length of 500 bytes, this is equivalent to a buffer space of 625,000 packets. In contrast, existing optical buffering techniques based on fiber delay loops can only accommodate a few tens of packets. With such small buffers, the packet drop rate of an optical packet switch is quite high even for moderate loads. 

OPS tries to overcome the lack of buffers by combining two other techniques to solve contention: wavelength conversion and deflection routing. If two packets arrive simultaneously, and there are no local buffers left, the optical packet switch tries first to find another free wavelength in the same fiber, and if it cannot find it, it will try a parallel path that does not have contention. The number of wavelengths is expected to be between 10 and 1000, and the number of neighboring nodes fewer than 10. 

However, these solutions also have some shortcomings: one is that even if these three dimensions (fiber loops, wavelength conversion and path deflection) seem to yield a similar number of options to solve the contention as the electrical buffers, the number of degrees of freedom is much less since there are numerous dependencies that limit the choice. Moreover, packets that are bounced to different paths may cause congestion in other wavelengths or other parts of the network, spreading local congestion across the whole network. In addition, packets no longer follow the same path, and so they may arrive out of order, which may be interpreted by TCP as losses due to congestion, and TCP may thus throttle back its rate. 

The distribution of packet sizes in the Internet is almost bimodal, with close to 40\% of the packets being 1500-byte long and almost 60\% of the packets being 40-byte long acknowledgements. This packet-size distribution precludes the use of slotted packet-switching architectures that are more efficient and easier to design.

However, the biggest problem with OPS is that IP packet sizes are too short for most optical crossconnects to be rescheduled. A 40-byte packet takes 32~ns to be received on an OC-192c link, and only 8~ns on an OC-768c link. For this reason, several researchers have proposed using bigger switching units, called {\em bursts}, in an architecture called Optical Burst Switching. 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Optical Burst Switching (OBS)}

Optical Burst Switching (OBS) was proposed in \cite{Qiao99BurstSwitching,Turner99BurstSwitching}, and it is a hybrid between packet switching and circuit switching. OBS pushes buffers to the edges of the network, leaving no buffers in the core. OBS gathers bursts of data at the ingress nodes of the backbone until the node has enough data or a burst formation timeout occurs. At this point, the burst is sent through the all-optical core. In general, the burst is preceded by a signaling message that creates a lightweight circuit with an explicit or implicit teardown time, through which the burst is sent, as shown in Figure~\ref{fig:OBSTimeDiagram}. The circuit is destroyed once the burst has been transmitted. These circuits contend with each other in the all-optical core in a similar way to how packets contend when using OPS. For this reason, OBS can also be seen as a packet-switched network that switches large packets, in which the header information precedes the data \cite{Yao01OpticalPacketSwitching}. There are different types of OBS, essentially with different degrees of signaling complexity. The high rate of burst formation in the core makes the proposals with the simplest signaling the most interesting (i.e., those with ``best-effort'' reservation that do not wait for confirmations). The two most popular flavors of OBS are called Just-In-Time (JIT), which uses circuits with an open-ended duration, and Just-Enough-Time (JET), which explicitly specifies the circuit duration when the circuit is created. 

\begin{figure}[ht]
{\centering \resizebox*{1.0\columnwidth}{!}{\includegraphics[clip]{fig/OBSTimeDiagram}} \par}
\caption[Time diagram of Optical Burst Switching.]{\label{fig:OBSTimeDiagram}Sample time diagram of a network using Optical Burst Switching.}
\end{figure}


With OBS, data is sent in batches as opposed to streamed as with regular IP or the proposals of Chapters~\ref{chap:TCPSwitching} and \ref{chap:CoarseCircuits}. This has an effect on TCP, since it relies on the packet timing to pace its transmissions. With OBS, delivery is best effort, and so the burst may be lost. Since TCP considers the loss of three consecutive packets as a sign of congestion, the loss of a burst is expensive because it makes TCP sources throttle back their transmission rate. The effect of the burst loss rate is amplified by TCP.

\subsection{Performance of OPS/OBS}
As in Chapter~\ref{chap:ResponseTime}, I will use the end-user response time as the main performance metric for these two related techniques. Let me start with OBS. According to \cite{Padhye98TCPmodeling}, the average throughput of TCP can be written, ignoring retransmission timeouts and in the absence of window-size limitations, as: 

$\mbox{Average throughput} \propto \frac{1}{RTT \cdot \sqrt{p\cdot b}}$

where $RTT$ is the round-trip time, $p$ is the packet drop probability and $b$ is the number of packets acknowledged per ACK message. As more TCP data and acknowledgement packets get bundled together in bursts of OBS, the value of $b$ will increase. The lack of buffers in OBS and existence of congestion among bursts provides a larger drop rate than with regular packet switching in electronic form. Furthermore, the burst-formation time in OBS increases the RTT, which reduces the average throughput of TCP and, thus, increases the user response time. Remember that TCP Switching also had an increase of the RTT because of the transmission times over thin circuits. As the access-link rate increases in TCP Switching, the RTT increase becomes negligible. For OBS, the RTT decreases only as the burst size is reduced. Still, through simulation using ns-2 I have found that even when we use a long burst formation latency of 50 ms, OBS leads to response times that are only about 10\% slower than TCP Switching, and so one can conclude that their response time performance is comparable. 

OBS uses electrical buffers at the ingress to aggregate regular IP packets destined to the same egress node into bursts. The aggregation reduces the number of forwarding decisions that have to be done by the OBS so that they can be done electronically. The trade-off for this is that OBS requires more buffering at the ingress of the optical backbone than the optical circuit switching solutions because IP packets in OBS have to wait until the next burst departs, whereas with circuit switching, packets belonging to active circuits are sent as soon as they arrive. Furthermore, in TCP Switching, the circuits have the same capacity as the access link, hence they are not the bottleneck in the flow path. Consequently, queueing at the circuit head is unusual. 

All these arguments indicate that the end-user performance of OBS/OPS should be very bad even under moderate loads because of the high losses in the unscheduled optical cloud. Some authors \cite{Yoo01BurstSwitching,Hsu02OBSperformance} have analyzed and performed open-loop simulations of OPS/OBS with unscheduled optical clouds, and they have found that the losses of the system are acceptable if enough wavelengths were available. However, in OBS the close-loop, multiplicative-decrease-additive-increase flow control algorithm of TCP reacts very badly to the clustered losses of OBS/OPS, and it makes TCP cut its transmission rate very aggressively. Moreover, the burst formation time has an important impact on the TCP throughput if it increases the connection RTT \cite{Detti02TCP_OBS}. Yao et al. \cite{Yao01OpticalPacketSwitching} have simulated what happens when several FTP sessions contend in an OPS, unscheduled optical core, and they show how the response time starts degrading with loads of only 30\%, and how, with link loads of only 50\%, the response times of those FTP sessions is between 15 to 20 times worse that that of an unloaded network. They also show how OBS, by aggregating packets into bursts, can achieve a slightly better performance, but the performance improvement is minor, and it still does not make the system usable under reasonable link loads.

There have been several proposals \cite{Yoo01BurstSwitching,Yao01OpticalPacketSwitching} to improve the dismal performance of OSP/OBS by creating several traffic classes with strict priorities or by giving priority to through traffic when it is contending with inbound traffic. The end result is that the high-priority class sees a network load that is much smaller than the total link load. It is as if all traffic of lower priority did not exist for the high priority class. The high-priority class gets an acceptable performance (loss rate $\approx 4\cdot 10^{-5}$) at the cost of heavily hurting the low-priority class, which gets an unacceptable performance, with loss rates of 2\% for a load $\rho=0.60$.

Even if, on average, link loads are low in the core of the network, it is not a reasonable assumption on certain links (near hot spots) and at certain moments (e.g., after rerouting traffic following a link failure). OBS/OPS would not be able to provide the maximum performance where it is needed the most. Furthermore, hotspots and failures happen in unpredictable locations at unpredictable times \cite{iyer03overload}, this makes it hard to estimate the performance of OBS/OPS in a real system.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



\section{\label{sec:RW:FlowMeasurements}Flow Measurement}  
A key component of Chapters~\ref{chap:TCPSwitching} and~\ref{chap:CoarseCircuits} is the monitoring of flows and the study of their characteristics. The off-line profiling of user flows can be used to understand how sensible the proposed solutions are and to feed the model in Section~\ref{sec:OCC:model}. On the other hand, the on-line monitoring of active flows is used to control the circuit-switched backbone in real time. Next, I will describe two approaches that can be used to study user flows.


\subsection{RFC 2722} 
RFC2722 \cite{RFC2722} presents a method to specify traffic flows as well as several components for flow measurements. The purpose of such flow-measurement system is to understand network usage and performance, which is in general done off line, rather than to control the network in real time. 

There are two related tools that use sampling of packets to study flows. Cisco offers a tool in its routers called NetFlow \cite{CiscoNetflow} that logs periodically-sampled packets in memory and later dumps the log to a permanent storage, where it is analyzed off-line. In \cite{Duffield02Flows}, the authors proposed sampling with a frequency that is the inverse of the flow size to decrease the number of samples without introducing measurement errors.

\subsection{Proposal by Estan and Varghese}
Estan and Varghese \cite{estan01new} propose a more precise method of sampling large flows (those that take a non-negligible amount of the link capacity). Their method uses less memory than NetFlow, but ignores small flows, which typically take less than 20\% of the total information rate.

As with the method listed in Section~\ref{sec:TS:FlowDetection}, this method requires the observation of every single packet in the link. The difference between the two approaches is that Estan's method is better for providing accurate statistics of big flows, whereas my method only tells how many flows are currently active (which is needed to manage circuits and to estimate their size in real-time).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusions}

This chapter discusses other proposals that are related to this thesis. Some of these proposals share the same view as this thesis to the integration of circuit and packet switching in the Internet. They develop other aspects of this integration that have not been addressed or elaborated in detail in this thesis, such as the protection, restoration and routing of circuits, or the statistical monitoring of flows. As such, my proposals of Chapters~\ref{chap:TCPSwitching} and~\ref{chap:CoarseCircuits} could be used in conjunction with this related work.

Other approaches, such as Optical Burst Switching and Optical Packet Switching, propose extending packet switching to the all-optical switches that will be found in the future in the backbone. An important observation that I would like to make about these proposals is that today electronic packet switching has not been able to displace electronic circuit switching in the core of the Internet. So, it is hard to imagine how packet switching using optics (with many more limitations than its electronic form) can be deployed instead of circuit switching (which is better suited for the bufferless environment of optical switches). One last point that is worth remembering is that, as pointed out in Chapter~\ref{chap:ResponseTime}, even if the current limitations of all-optical packet switching are solved, the end user would not see a better response time from the network.





