Time Driven Priority Router Implementation and First Experiments

Baldi, Mario; Marchetto, Guido; Risso, Fulvio; Galante, G.; Scopigno, Riccardo; Stirano, F.

doi:10.1109/icc.2006.254821

Cited by 8 publications

(18 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…5 that includes also a prototypal pipeline forwarding router developed at the Politecnico di Torino [8]. Two streaming video flows are generated by a video server (to the left), transported, with deterministic quality of service, through a network of one router and two multi-terabit/s switches (all implementing pipeline forwarding) and delivered to two different video clients.…”

Section: Cmentioning

confidence: 99%

Multi-Terabit/s IP Switching with Guaranteed Service for Streaming Traffic

Baldi

Ofek

2006

Proceedings IEEE INFOCOM 2006. 25TH IEEE International Conference on Computer Communications

Self Cite

View full text Add to dashboard Cite

As traffic on the Internet continues to grow exponentially, there is a real need to solve transmission and switching scalability. Moreover, future Internet traffic will be dominated by streaming media flows, such as video-telephony, video-conferencing, 3D video, virtual reality, and many more. Consequently, network solutions will need to offer quality of service and traffic engineering together with the abovementioned scalability-i.e., over-provisioning is not likely be a viable solution to accommodate streaming media traffic. This paper describes the architecture of a ultra-scalable IP switch and the first experiments with a prototypal implementation. The switch scalability is a consequence of it operating pipeline forwarding of packets, which also results in quality of service guarantees for UDP-based streaming applications, while preserving elastic TCP-based traffic as is, i.e., without affecting any existing applications based on "best-effort" services. Moreover, the prototype demonstrates the low complexity of pipeline forwarding implementation as the deployed network gear was realized from off-the-shelf components in only nine months through the design, implementation, and testing efforts of the authors. I. THE PROBLEM The steady Internet growth over the past few years is impressive, but services so far deployed over the Internet are nothing compared to the ones that can still be deployed. One likely scenario is that the future Internet will be dominated by applications such as (3D) video on demand, high quality videoconferencing, distributed gaming, (3D) virtual reality, remote surveillance, and many more. These applications generate traffic that is either by nature streaming or can be effectively handled as such (e.g., large file transfers). Moreover, most of these applications need a minimum guaranteed quality in order to be usable. Consequently, there is a real need to solve scalability and traffic engineering simultaneously-specifically, without using over-provisioning in order to provide predictable service. Concerning scalability, it is interesting noting that Cisco's top-of-the-line router, CRS-1, has a per chassis switching capacity of 640 Gb/s (the announcement of 92 Tb/s is to be divided by 2, to avoid twice packets first entering and exiting the switch, and then by 72 chassis's), which represents an improvement over the Cisco 12000 by a factor of only 2 after 5 years of development-not the 18 months during which the Internet traffic doubles. This paper shows how the Internet can benefit from UTC-based pipeline forwarding of IP packets that enables (i) ultra-scalable IP switches-10-50 Tb/s in a single chassis, (ii) quality of service (QoS) for UDP-based streaming applications (as a bonus since a deterministic service is inherent to the switching solution itself), while (iii) preserving elastic TCP-based best-effort traffic as is. Notice that no change can be seen when observing a link: standard (whole) IP packets encapsulated into Ethernet or PPP frames transit. II. UTC-BASED PIPELINE FORWARDING...

show abstract

Section: Cmentioning

confidence: 99%

Multi-Terabit/s IP Switching with Guaranteed Service for Streaming Traffic

Baldi

Ofek

2006

Proceedings IEEE INFOCOM 2006. 25TH IEEE International Conference on Computer Communications

Self Cite

View full text Add to dashboard Cite

show abstract

“…Future navigation systems like the European Galileo and the Chinese BeiDou will only improve the availability of a global time reference. Alternatively, several solutions for distributing the synchronisation reference directly through the network can be adopted; see for instance [16,17], and, specifically for TDP, [18].Although the availability of global time empowers global coordination, it does not mean that synchronisation needed for PF comes for free, as it requires the ability, for both end systems and routers, to send packets 'at the correct time' to properly respect the schedule. Specially considering the end systems, this may be a challenge because of the so called 'latency', which can be informally defined as the difference between the time when a packet should be received (sent), and the time when it is actually received (sent).…”

mentioning

confidence: 99%

Measuring and reducing the impact of the operating system kernel on end‐to‐end latencies in synchronous packet switched networks

et al. 2011

Self Cite

View full text Add to dashboard Cite

This paper presents an evaluation of the impact of the so-called operating system (OS) latencies on the performance of a synchronous network based on global time coordination. The concept of end-to-end latency was first defined by extending the concept of latency used to evaluate the performance of real-time systems and the end-to-end latency provided by a general-purpose OS was measured as a benchmark. Finally, real-time techniques were used to reduce the worst-case values of such a latency, showing how a gateway between synchronous and asynchronous networks can be implemented by using commercial-off-the-shelf hardware and a proper software stack (based on a real-time version of Linux). The use of a real-time OS is still a nontrivial task, which requires experience and the analysis of the specific application to devise the proper techniques to be applied. This work dissects the problem of OS-to-network data transfer (and vice versa) identifying the key sources of latencies and delay jitter, and solving each problem with the application of a proper technique.is only possible if packets are sent and received according to an appropriate schedule, and such a schedule is strictly respected. For example, if a router receives at the same time two packets sent to the same interface, it is not able to properly forward them without buffering. Such a strict synchronisation between routers and end systems can be achieved by means of global time references such as Universal Time Coordinated (UTC), or Global Positioning System Time (GPST), the time used by the global navigation system, which is available also for civilian use for free and without restrictions in normal times. Future navigation systems like the European Galileo and the Chinese BeiDou will only improve the availability of a global time reference. Alternatively, several solutions for distributing the synchronisation reference directly through the network can be adopted; see for instance [16,17], and, specifically for TDP, [18].Although the availability of global time empowers global coordination, it does not mean that synchronisation needed for PF comes for free, as it requires the ability, for both end systems and routers, to send packets 'at the correct time' to properly respect the schedule. Specially considering the end systems, this may be a challenge because of the so called 'latency', which can be informally defined as the difference between the time when a packet should be received (sent), and the time when it is actually received (sent). Whereas modern hardware (even off-the-shelf hardware) is generally able to provide the low latencies needed for PF, the software stack is more problematic, as the latencies generated by an operating system (OS) kernel can be large enough to compromise the correct forwarding of packets or to force to use a low bitrate, as it will be shown in Section 3.Whereas some works related to high-performance network applications only consider average throughput and do not care about the latencies introduced by the OS [19,20], it ha...

show abstract

“…The necessary requirement for pipeline forwarding is having common time reference (CTR). In this design UTC (coordinated universal time) is used for CTR, consequently, the method used in the testbed is called UTC-based pipeline forwarding ([1]- [3]). …”

Section: Pipeline Forwardingmentioning

confidence: 99%

“…More flexibility could however be required at the edge of the network as offered, for example, by conventional IP destination-address-based routing. Time-driven priority (TDP) [3][7] is a synchronous packet scheduling technique that implements UTCbased pipeline forwarding and can be combined with conventional IP routing to achieve the abovementioned flexibility. Packets entering a switch from the same input port during the same TF can be sent out from different output ports, according to the rules that drive IP packet routing.…”

Section: Time-driven Prioritymentioning

confidence: 99%

“…This paper presents a scalable testbed demonstrating a method known as pipeline forwarding ([1]- [3]) that is particularly suitable to carry streaming media applications over the Internet since it offers: 1) High scalability of network switches Terabit/s in a single chassis); 2) Service guarantees (deterministic delay and jitter, no loss) for (UDP-based) constant bit rate (CBR) and variable bit rate (VBR) streaming applications -as needed, while 3) Preserving the support of elastic, TCP-based traffic, i.e., existing applications based on "besteffort" services are not affected in any way. In the presented testbed, shown in Fig.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation