Applicability of UNITE

1. Applicability of UNITE K. K. Ramakrishnan, Gísli Hjálmtýsson, Kobus VanderMerwe, Flavio Bonomi, Sateesh Kumar, Michael Wong, Vijay Samalam, Michael J. Miller AT&T Labs-Research, CSI ZeitNet/Cabletron, StratumOne, GTE Labs, IDT ATM Forum/98-0786 Oct. 1998 ATM Forum Presentation

2. Motivation • Connection oriented networks challenge:to support short-lived flows • Native ATM Connectionless Service to support short-lived control traffic • Our focus: support broad range of short-lived traffic on a best-effort basis • IP: the default “interface” between application and the network • significant portion of the traffic is carried on a best-effort basis • Few possible ways to carry short-lived flows: • carry the traffic on a default VC - a default “control plane” • use existing UNI signaling to set up a VC • use a more efficient, lightweight signaling protocol • UNITE uses the 3rd approach • connection setup overhead low • latency for the beginning of data transmission is low

3. Applications benefited by UNITE: Client-Server • Client-Server request-response exchanges such as • ATM Name Service, LAN Emulation configuration • LAN Emulation Client (LEC) - LAN Emulation Server(LES) exchange • Desire: low latency. Minimize the impact on subsequent interactions • the latency for interaction eventually impacts application response time • Pre-existing VC between every client and these servers: infeasible • Having a default VC requires every switch in the network to • reassemble and route frames; provision the default VC • limit usage to limited exchanges between client and server • UNITE switches cells;only a single cell msetup that has to be routed. • benefit higher for multiple message exchanges • allows us to use a UNITE connection for all client-server exchanges

4. Wireless ATM Applications • Wide range of short-term interactions for wireless ATM • mobile location management, registration; handoff signaling • mobile paging • Characterized by need for quick response but may have quite different latency requirements • Potential for multiple requests and responses of multiple packets • generate varying amounts of data • A single default VC: Provisioning the VC can be difficult • interference of traffic (e.g., paging traffic vs. handoff; purely signaling vs. impacting the bearer channel) can be undesirable • no distinction between traffic from different sources to different destinations (network generated vs. user generated flows can have different requirements)

5. Wireless ATM Applications benefited by UNITE • UNITE offers potential to set up distinct VCs as required • isolate latency-tolerant signaling messages (e.g., registration) from messages that impact the bearer channel (e.g., handoffs) • Potential for isolation between the different best-effort connections • Switches and the Network Operator has the freedom to offer differentiation of the service between these connections • UNITE connection setup overhead can be amortized quickly • UNITE does not preclude aggregation of flows over a VC • e.g., network generated short-lived transactions could use a common VC • handoff signaling, location management - interactions between network entities • UNITE’s latency sensitivity in determining route may be worthwhile

6. Supporting Packet Telephony: Framework • Several possible scenarios for packet telephony to evolve • H.323 terminals are ATM end-points • communicate with other terminals and Gatekeepers etc. over ATM • H.323 terminals interface to the network using IP • interface to ATM network: either router (IP over ATM) or H.323 gateway • phones come through the PSTN to a H.323 Gateway H.323 Terminal H.323 Terminal ATM Network H.323 GW H.323 GW Network Network Phone Phone H.323 GK H.323 GK

7. Supporting Packet Telephony • Large amount of call level signaling carried as best effort traffic • higher layer (either transport or application) provides reliability • Considerable traffic generated by H.323 control (H.245, H.225) • Latency sensitive: reduced call-setup delay directly improves post-dial delay • Wide-ranging, rich set of control interactions defined in H.323 • Call setup interactions (client-GK & client-client) with tight delay constraints • enhancements with more flexibility on delay: features, multimedia call capability negotiation • Difficult to have a single default VC - inadequate isolation • Even Gatekeeper-H.323 terminal TCP connections: heavyweight • managing many of these long-lived connections is difficult • Having many long-lived ATM connections pose similar problem

8. Supporting Packet Telephony with UNITE • Setting up connections on-demand: reasonably high setup rate • UNITE can be used to setup a connection “on-demand” for • carrying H.225 messages between terminal and Gatekeeper • avoids having long-term connections between clients and gatekeeper • setting up this connection doesn’t usually require address resolution • setting up H.245 control channel between terminals • potentially more intensive exchange of messages • e.g., capability exchange, open logical channel • can be used even for Gatekeeper-Gatekeeper exchanges, if needed • UNITE isolates different flows with possibly different requirements • Evolution of call-signaling could make use of connections efficiently for transactions between clients and Gatekeepers

9. Supporting IP over UNITE • The application’s interface to the network is predominantly IP • Accommodate large scale and operating range • ability to connect a large number of routers to the ATM backbone • support a wide range of traffic characteristics • from short-lived flows to sustained long-lived flows • Difficult to support with pre-configured VCs or a default VC ATM Backbone Rtr Rtr Src Server Rtr Rtr Rtr

10. short-cut VC for a flow ATM Backbone Rtr Rtr Src Server IP packets Rtr default route for all packets Rtr Rtr IP over ATM • Set up SVCs between routers at the edge of the ATM network • Determining when to setup the VC and efficiently setting up the VC complement the solution to the address resolution problem • IP packets follow a default routed path until short-cut VC is setup • need a mesh of pre-provisioned default paths • Once short-cut (SVC) established, remaining packets flow on SVC • potential for some packets to be delivered out-of-order • packets arriving at ingress router may have to be buffered until SVC setup

11. Some statistics on IP traffic behavior • Incoming AT&T WorldNet Traffic by Protocol • 18 hours of dial traffic from WorldNet in Bridgeton on July 22, 1997 • obtained from study by several people in AT&T Labs. Research, including Jennifer Rexford, Anja Feldmann and Ramon Caceres

12. Flow Sizes for World Wide Web Traffic Web server-to-client response traffic • Port-to-port flows (single TCP session to client, 60-second timeout) • Failed TCP sessions: 4% of flows with < 150 bytes • Cache hit, empty/moved page: 21% of flows with 150-400 bytes • Web transfer (image, text): 75% of flows with > 400 bytes • Many medium sized flows (short web transfers) • Most bytes belong to long flows (large images, large files) • Typical intuition: most packets belong to a small number of flows • set up short-cuts only for these flows because connection setup is expensive • remaining traffic - “short-lived” flows carried on default routed path • But, still a very large number of short-lived flows on default path • larger the scale (routers, diversity of end-points), more difficult to determine what is short-lived vs. long-lived: more difficult to precisely setup shortcuts

13. Short-cuts for World Wide Web Traffic • Creating a short-cut connection for every web transfer (projecting to a 155 Mbit/second link) • avg. 240 short-cut setups/sec per link; max. 610 short-cut setups/sec per link • significant bursts in setup rate on 10-100 second time scale • Total number of simultaneous short-cut connections • avg. of 17,150 connections on 155 Mbps link; max. of 35,950 connections • Highly desirable to setup short-cuts efficiently; use less state • Heuristics to reduce number of short-cut connections useful • setup after x pkts; aggregating at host,egress router level; delay setting up • But how to adapt: changing application dynamics, network topology, configuration, scale? • e.g., new application behavior may result in higher initial burst of packets?

14. Benefits of UNITE in supporting Web Transfers • UNITE allows aggressive setup of short-cuts • allows for adapting to changing application behavior • Don’t have to provision default routed path to carry a lot of traffic • more of the traffic can be carried on short-cut as needed • UNITE’s fast setup enables achievement of good performance, even without good heuristics • try to minimize the need for separate policies for short and long-lived flows • VCs use less memory: can deal with varying levels of aggregation

15. Benefits of UNITE in supporting IP • UNITE allows the network to adapt better to route changes • e.g., large number of packets re-directed to a new ingress router • fast setup (enabling earlier transmission of data) reduces buffer requirements at ingress router; • low latency to transmit also reduces the number of packets sent on default routed path - reduction in number of out-of-order packets • allows network to distribute buffer usage across router and switches • Delivering a large number of out-of-order pkts can hurt performance • e.g., TCP goes through fast retransmit and triggers congestion control methods • UNITE supports a full range of multicast architectures in a uniform manner • we believe networking will naturally evolve to support large-scale multicast

16. IP rtr IP rtr Carrying IP over UNITE • Using the IP over ATM model: resolve address using NHRP/ARA • Efficiently carry IP packets over UNITE: connections setup very cheaply. • Arriving IP packet initiates a single cell micro-setup over UNITE • IP packet may be transmitted immediately after 1st hop state setup • overhead is one cell + one hop latency • Compress IP headers when packets sent over UNITE VC - reduce ATM’s “cell-tax” IP Network UNITE msetup IP packet Ack marker IP packet

17. ATM Backbone Rtr C Rtr A Src Dest Rtr D Rtr B Destination Based Routing • Straightforward setting up of VC from each ingress to egress router • potential for setting up N2 VCs • if UNITE VCs are cheap enough, maybe no problem • But, with “VC merging”, can establish substantially fewer VCs • multipoint-point tree to each egress router • simple convention: use well-known flow ID (flow ID 0) for call reference • ingress routers set up Leaf Initiated Join using Rtr.C’s address + flow ID 0 • Efficient in setting up ATM path; clean abstraction.

18. Relationship between UNITE and the new FUNI? • Frame-based UNI over SONET:forward frames using a short-handle • avoid routing every packet based on destination address • forward packets based on VPI/VCI of a connection that is setup • Motivation for Frame-based UNI? • Could be to carry IP traffic more efficiently • UNITE can potentially help by setting up the connection quickly • provide a VPI/VCI to allow transmission of data quickly • UNITE QoS byte able to differentiate routes based on class of service and load • may meet the requirements for a large subset of traffic carried over this FUNI • Question remains: do we need connections setup efficiently or not?

19. Why are Issues of Scale Important, Now? • Substantial investment likely to be underway in providing high-speed packet communication access to a significantly larger number of people (maybe U.S. focus now, but expect to be true worldwide) • The number of packet forwarding devices used will explode • Two ways for a technology to evolve • have backbone functionality & allow IP to reach from consumer to backbone • allow the backbone to reach back further towards the consumer • The technology that meets the needs of multiple services co-existing in a scalable manner will likely see growth • these services are at least: data access and well-understood telephony • Either ATM allows larger scale interconnectivity or IP supports QoS adequate at least for telephony

20. UNITE can meet the Requirements of Native ATM Connectionless Service • CLS shall rely on existing or evolving ATM addressing and routing • UNITE uses existing ATM addresses and routing framework • only the forwarding of the setup has changed • CLS shall support throughput that is scalable and manageable • by providing individual connections for flows, UNITE allows throughput to scale both for data (as link speeds change) and connection setups. • CLS shall allow differentiation of traffic • with QoS byte for class/load sensitive routing, UNITE allows for differentiation of routes. Best effort capability in UNITE can be enhanced further to support Diffserv-like semantics quite easily • CLS shall not require reliable transfer of traffic • UNITE offers best-effort connectivity.

21. UNITE can meet the Requirements of Native ATM Connectionless Service (contd…) • CLS shall specify inter-working with ATM switches and networks that do not provide native CLS capabilities • UNITE has offered two ways of interoperating with existing switches • with switches that support UNI and UNITE: parallel control planes • with switches that do not support UNITE: using a “border”/signaling gateway function • CLS shall constrain its resource impact on connection-oriented traffic • setting up a separate connection for best-effort is the best way to manage this resource impact • CLS shall support appropriate security services • we will address these as soon as possible

22. UNITE can meet the Requirements of Native ATM Connectionless Service • CLS shall provide latency that is significantly smaller than that for setting up an equivalent SVC • this is the primary goal of UNITE, to set up a connection that has much less overhead and latency than a UNI connection setup.

23. Summary • A number of applications need efficient support for short-lived flows • Communication networks have to operate in large scale • Even best-effort short-lived flows need isolation from each other • Connection oriented networks need to evolve to meet these needs • A mesh of pre-provisioned connections or a single default VC are unlikely to be acceptable solutions • UNITE supports short-lived flows with minimal state in the network • high throughput for connection establishment • low latency to begin transmission • UNITE isolates different flows with possibly different requirements • UNITE shapes state in a network in a way that would also fit IP

24. Motion • The TCAG approve a work item to: • study the use of UNITE as a lightweight signaling protocol for best-effort communication • in addition, examine the applications where such lightweight signaling is needed and appropriate.