Transcript atm98-786
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 Network H.323 GW ATM Network H.323 GW 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 Src Rtr Server Rtr Rtr Rtr 10 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 short-cut VC for a flow ATM Backbone Rtr Src IP packets Rtr Rtr Server Rtr default route for all packets Rtr 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 Name port % bytes %packets % flows packets bytes per per flow packet www 80 56.75 nntp 119 24.65 pop-3 110 1.88 Cuseeme 7648 0.95 aol 5190 1.18 s_www 443 0.74 IRC 6667 0.27 ftp-data 20 0.65 domain 53 0.19 ftp 21 0.05 other 0.64 unknown 12.04 44.79 12.90 3.17 1.85 1.53 0.79 0.74 0.64 0.58 0.30 1.07 31.62 74.58 1.20 2.80 0.03 0.31 0.99 0.16 0.26 10.69 0.52 1.13 7.33 12 210 22 1375 97 16 89 47 1 11 19 84 819 1235 384 333 500 603 239 659 210 112 384 246 duration (seconds) 11.2 132.6 10.3 192.0 190.0 14.2 384.6 30.1 0.5 31.4 27.6 98.0 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 Carrying IP over UNITE IP Network IP packet IP rtr IP rtr UNITE msetup Ack marker IP packet 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” 17 Destination Based Routing ATM Backbone Rtr A Rtr C Src Dest Rtr D Rtr B 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 highspeed 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.