Internetworking and computing over satellite networks

INTERNETWORKING AND COMPUTING OVER SATELLITE NETWORKS INTERNETWORKING ANO COMPUTING OVER SATELLITE NETWORKS Edited by YONGGUANG ZHANG HRL Laboratories, LLC Springer Science+Business Media, LLC Library of Congress Cataloging-in-Publication Data Intemetworking and Computing over Satellite Networks Yongguang Zhang (Ed.) ISBN 978-1-4613-5073-6 ISBN 978-1-4615-0431-3 (eBook) DOI 10.1007/978-1-4615-0431-3 Copyright O 2003 by Springer Science+Business Media New York Originally published by Kluwer Academic Publishers in 2003 Softcover reprint ofthe hardcover Ist edition 2003 AII rights resetved No part ofthis work may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, microfilming, recording, or otherwise, without prior written permission from the Publisher, with the exception of any material supplied specificalIy for the purpose ofbeing entered and executed on a computer system, for exclusive use by the purchaser ofthe work Permission for books published in Europe: permissions@wkap.n1 Permissions for books published in the United States of America: permissions@wkap.com Printed on acid-free paper The Publisher offers discounts on this bookfor course use and bulk purchases For further information, send email lo • Contents List of Figures xi List of Tables xv Preface xvii Contributing Authors xxi The Role of Satellite Networks in the 21st Century SanK Dao Introduction Internet over Satellite Architecture 2.1 The Roles of Satellite Network in the Internet 2.2 The Role of Satellite in the Satellite Network Common Applications Visions for the Future 4.1 Commercial Market 4.2 The DARPA NGI Vision Challenges Satellite Constellation Networks Lloyd Wood Introduction Benefits of Going to LEO Describing the Systems Geometry, Topology and Delay Delay Handover Networking Design Simulators Summary 9 10 11 13 13 15 17 19 23 26 28 31 32 vi INTERNE1WORKING AND COMPUTING OVER SATELLITE NE1WORKS Medium Access Control Protocols for Satellite Communications Srikanth V Krishnamurthy and Chen Liu and Vikram Gupta I Introduction Polling Based Access Protocols Fixed Assignment Multiple Access (FAMA) Protocols 3.1 Frequency Division Multiple Access (FDMA) 3.2 Time Division Multiple Access (TDMA) 3.3 Code Division Multiple Access (CDMA) Random Access Protocols 4.1 Asynchronous Random Access Protocols 4.1.1 Aloha 4.1.2 Selective-Reject Aloha (SREJ-Aloha) 4.2 Synchronous Random Access Protocols 4.3 Carrier Sense Multiple Access (CSMA) Demand Assignment Multiple Access (DAMA) Protocols 5.1 Demand Assignment Based on FDMA 5.2 Making Reservations by Contention Based Access 5.2.1 Reservation Aloha (R-Aloha) 5.2.2 Priority-Oriented Demand Assignment (PODA) 5.2.3 Split-Channel Reservation Multiple Access (SRMA) 5.2.4 The Time-of-Arrival Collision Resolution Algorithm (CRA) 5.2.5 Packet-Demand Assignment Multiple Access (PDAMA) Hybrid Protocols 6.1 Round-Robin Reservations (RRR) 6.2 Interleaved Frame Flush-Out (IFFO) 6.3 Split-Channel Reservation Upon Collision (SRUC) 6.4 Announced Retransmission Random Access (ARRA) 6.5 Scheduled-Retransmission Multiple Access (SRMA) 6.6 Response Initiated Multiple Access (RIMA) 6.7 Combined FreelDemand Assignment Multiple Access 6.8 Fixed Boundary Integrated Access Scheme (FBIA) 6.9 Combined Random/Reservation Multiple Access (CRRMA) Conclusions and Summary 35 35 41 41 42 43 45 46 47 47 49 50 52 52 56 57 57 58 62 63 67 69 69 71 74 75 77 81 83 85 87 90 Direct Broadcast Satellites and Asymmetric Routing 95 Yongguang Zhang Introduction Problems with Dynamic Asymmetric Routing 2.1 Unicast 2.2 Multicast Tunneling: A Practical Solution Demonstration of Tunneling Approach RFC 3077: The IETF Standard 5.1 Topology and Requirements 5.2 Tunneling Mechanism Details 5.3 Dynamic Tunnel Configuration 5.4 Tunneling Protocol 95 96 96 98 98 100 103 104 105 107 109 vii Contents 5.5 Current Status Limitations and Long-Term Solutions 110 III Using Satellite Links in the Delivery of Terrestrial Multicast Traffic Kevin C Almeroth Introduction Overview of Multicast Deployment Satellite Delivery of Multicast Integrating Satellite and Terrestrial Networks Using Satellite Paths for Multicast Sessions 5.1 Motivation and Metrics 5.2 Methodology 5.3 Results When to Use Satellites? 115 115 117 118 118 120 120 122 122 128 TCP Performance over Satellite Channels Thomas R Henderson Introduction Transmission Control Protocol (TCP) Overview 2.1 Basic TCP Operation 2.2 Connection Establishment and Release 2.3 Basic Loss Recovery and Congestion Avoidance 2.4 Enhanced Loss Recovery and Congestion Avoidance TCP Performance Problems over Satellite Links Enhancing TCP Performance using Standard Mechanisms 4.1 Window scale 4.2 Path MTU discovery 4.3 Error correction 4.4 Further loss recovery enhancements Research Issues 5.1 Connection startup 5.2 Shared TCP state and TCP pacing 5.3 Link asymmetry 5.4 Experimental loss recovery techniques 5.5 Implementation details 5.6 TCP fairness 5.7 Using multiple data connections 5.8 Header compression 5.9 TCP Performance Enhancement Proxy 5.10 Additional protocols Summary TCP Performance Enhancement Proxy Yongguang Zhang Introduction 131 131 132 132 132 134 135 136 138 138 139 139 140 142 143 146 147 148 149 149 151 152 152 153 154 159 159 viii INTERNETWORKING AND COMPUTING OVER SATELLITE NETWORKS The Motivation 2.1 The Slow-Start Problem 2.2 The Window Size Problem The Practical Solution 3.1 Basic Architecture 3.2 Example: Deployment in HNS DirecPC 3.3 Alternative Architecture and Mechanisms The Big Argument 4.1 The End-to-end Reliability Issue 4.2 The Fate Sharing Issue The "Show Stopper"? 5.1 Conflicts between IPsec and TCPPEP 5.2 The End-to-end Security Issue 5.3 Researches on Resolving the Conflicts with IPsec Conclusion 161 161 162 163 164 166 168 170 170 171 172 172 174 176 177 Performance Evaluation of TCP splitting over Satellite 181 Mingyan Liu Introduction Model-based Analysis 2.1 Network Model 2.2 Lossless Links 2.2.1 Delay Models 2.3 Links with Random Losses 2.3.1 The Server-Proxy Link is lossless 2.3.2 Random Losses on Both Links Discussion 3.1 Initial Window Size 3.2 Slow or Congested Proxy 3.3 File Size 3.4 Connection With Asymmetric Segments The Experiment System Measurement-based Analysis 5.1 Effect of File Size and Caching 5.2 Effect of congestion and packet losses 5.3 Effect of embedded objects and persistent connection Implications on System Design Conclusion Scheduling Data Broadcast Shu Jiang and Nitin H Vaidya Introduction The Basic Model 2.1 Persistent User Model 2.2 Impatient User Model Theoretical Results On-line Scheduling Algorithm 181 185 185 186 187 190 190 192 193 193 195 197 197 199 201 201 205 211 215 216 221 221 223 223 224 224 225 Contents ix Performance Evaluation 226 5.1 Validation of algorithm 227 5.2 Persistent user case 228 5.3 Impatient user case 229 Conclusions 230 Appendix: Deriving the Mean Access Time and the Variance of Access Time 231 Appendix: Minimizing the Variance of Access Time 233 Appendix: Deriving the Service Ratio 234 Appendix: Maximizing the service ratio 235 Appendix: Deriving The Mean Tuning Time 236 10 Information Dissemination Applications Eddie C Shek and Son K Dao and Darrel J Van Buer Introduction lIDS architecture Mobile User Profiling Dynamic User Profile Clustering and Aggregation 4.1 Incremental Clustering Framework 4.2 Adaptive Re-clustering 4.3 Evaluation Data Dissemination techiques 5.1 Predictive Dissemination and Caching 5.2 Bandwidth-Aware Filtering 5.3 Reliable Multicast-based Dissemination Implementation and Demonstration Conclusions Index 239 240 242 243 246 247 249 250 254 254 255 256 257 257 261 List of Figures 1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4 2.5 2.6 2.7 A satellite network as a data communication network GEO, MEO, and LEO satellites Satellite network roles in the Internet Satellite roles in a satellite network Internet over satellite application taxonomy Orbit altitudes for satellite constellations and proposals Repeating satellite approach, e.g Globalstar, Skybridge Full networking and routing approach, e.g Iridium, Teledesic A rosette constellation: the Spaceway NGSO proposal A star constellation: the Boeing Teledesic proposal One-way delay between Quito and London via constellations How handover can affect traffic in flight 2.8 Path delay for high-rate traffic over a small timescale 3.1 Uplink and downlink channels in satellite communications 3.2 Channel multiplexing in FDMA 3.3 Slot allocation in TDMA 3.4 ALOHA: case when no collisions occur 3.5 ALOHA: an example of a collision 3.6 Splitting packets into sub-packets 3.7 Examples to show collisions with ALOHA and S-ALOHA 3.8 (a) Standard S-ALOHA (b) adding a second uplink channel 3.9 Implicit reservations 3.10 Explicit then implicit reservation 3.11 Frequency multiplexing in INTELSAT SPADE 3.12 PODA frame structure 3.13 Aggregating messages to reduce preamble overhead 3.14 SRMA: the RAM version 3.15 Stations as leaves of a binary tree 3.16 Example of the binary tree contention resolution algorithm 16 18 18 20 22 25 26 27 36 42 44 48 49 50 51 52 54 55 57 59 61 62 64 66 xii INTERNETWORKING AND COMPUTING OVER SATELLITE NETWORKS 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 5.1 5.2 5.3 5.4 5.5 5.6 5.7 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 7.1 7.2 Frame Structure in PDAMA The mechanics of the RRR protocol The structure of frames used in the IFFO Protocol IFFO reservation scheme SRUC channel subdivision Frame format for ARRA Frame structure of SRMA protocol Retransmission reservation for SRMAIFF protocol Functional diagram of RIMA CFDAMA operations Frame structure used in the FBIA scheme Functional block diagram for depicting CRRMA A Performance comparison of the various MAC protocol types Applying distance-vector to UDL Applying reverse path forwarding to UDL Approaching the UDLR problem with a tunneling mechanism A demonstration network configuration Generic topology for RFC 3077 Scenario using the link-layer tunneling mechanism DTCP HELLO message packet format VDL encapsulation packet format Architecture of MBone-Over-Satellite experiment Group membership details for the 42nd IETF groups Breakdown of group membership Packet loss for Channell audio receivers Packet loss for Channell video receivers Jitter for selected terrestrial and DirecPC sites One-way delay for selected terrestrial and satellite sites An example of a TCP data transfer Basic operation ofTCP Reno Experimental file transfer performance of different TCP Typical performance with a standard TCP implementation Correct SACK behavior with a modified TCP implementation TCP latency of a segment server reply using standard TCP Typical packet sequences for TCP and TrrCp The effect of a single competing short-delay connection Future satellite networking topology TCP slow-start illustrated Effect of TCPPEP 68 70 71 72 74 76 78 80 82 84 86 89 92 97 99 100 101 104 106 108 110 119 123 124 125 125 126 127 133 135 141 141 142 144 144 150 153 162 165 Information Dissemination Applications 247 by sacrificing some of the optimality in the clustering through the use of a request group cover diameter tolerance In addition, we allow the bounding of the number of groups that translates to the number of multicast channels that is limited in a real network The algorithm is composed of components: (i) incremental clustering that adds new user requests into existing clustering, and (ii) a continuous process of adaptive re-clustering that reconfigures the existing clustering which optimality may have deteriorated since its creation as users move and change interest over time The dynamic clustering framework can work with arbitrary applicationdependent user profile formulations To simplify discussion on clustering, we assume that each user's information needs is determined entirely by his geographic location and we capture the profile of each mobile user as a collection of grids lying in its neighborhood along reachable paths as described earlier 4.1 Incremental Clustering Framework The submission, update, or cancellation of user requests triggers the profile clustering process Given the needs of profile clustering for intelligent vehicle information sharing, the algorithm to reconfigure an existing profile clustering when a new request is submitted consists of main steps: Try to find an existing group in the clustering that closely covers the request A profile group G covers a user request u if the group request assumed by the group completely subsumes the request It is often desirable to include the new user profile u into the group G since the information carried in the multicast channel servicing G is guaranteed to satisfy the information needs of u However, if G completely covers u but the collection of grids in the profile of G is much larger than that of u, we may not want to include u into group G since doing so means user u will be receiving information satisfying the profile G which contains a lot of material irrelevant to u As a result, a coverage threshold, COVER_THRESHOLD, is defined as a means to control the inaccuracy of clustering that can be tolerated A request is assigned to a group that completely covers it only if the difference between the their coverage is below the threshold For example, if the threshold is small, a request is assigned to an existing group only if their coverage is very similar On the other hand, if the threshold is large, a request may be assigned to an existing group in the profile clustering even if there is little overlap If multiple existing groups satisfy the criteria, we cluster the user into the group that has the smallest coverage to get the tightest fit for the user 248 INTERNETWORKING AND COMPUTING OVER SATELLITE NETWORKS More formally, given our spatial formulation of user profiles, we cluster user u into group G if and only if a) Profile(G);d Profile(u), b) IProfile(G) - Profile(u)1 / IProfile(G)1 < COVER_THRESHOLD, and c) there does not exist group F such that IProfile(F)1 < IProfile(G)1 Try to expand existing group that is the closest in coverage to the request If we cannot simply include a user into an existing group that completely cover it, we may want to consider clustering the user u into an existing group G which coverage largely overlap that of the user and expanding the group's coverage in the process However, we may not want to so if doing so would cause the coverage of the resultant group to expand significantly to the extent that members of the group begin to receive much irrelevant information As a result, an expansion threshold, EXPAND_THRESHOLD, is defined to control the extent of expansion in a group's coverage that is allowed Specifically, the group that is closest to the request in coverage cannot be expanded to include the request if the increase in the group's coverage from its original coverage is larger than the threshold If the threshold is small, groups are allowed very limited expansion in coverage On the other hand, groups not expand arbitrarily if the threshold is large The threshold introduces a tunable means of allowing inaccuracy in clustering as a tradeoff for profile clustering stability If multiple existing groups satisfy the criteria, we cluster the user into the group that has the smallest expanded coverage to minimize the deterioration of clustering quality for existing users More formally, given our spatial formulation of user profiles, we cluster user u into group G and expand the coverage of G if and only if a) IProfile(G)uP1t!file(u)-Profile(G)I/ IP1t!file(G)1 < EXPAND3HRESHOW, and b) there does not exist group F such that IProfile(F) u Profile(u)1 < IProfile(G) U Profile(u)1 If all else fails, generate a new profile group that covers the user request The new group will serve as a new locus of clustering to which new user requests are attracted Moreover, it may later be merged with other groups as its coverage migrates due to changes in its membership and the coverage of its members of the configurable parameters The optimal choices COVER_THRESHOLD and EXPAND_THRESHOLD are dependent on the application requirements and the characteristics of network infrastructure This dependency will be illustrated later when we present experiment simulation results Note also that the evaluation of coverage depends on the formulation of user profiles The formulation of the decision rules may be different if we choose a different profile formulation, but the general framework remains the same Information Dissemination Applications 4.2 249 Adaptive Re-clustering Once the objects are clustered, we try to preserve the original clusters as far as possible - as objects move or require new information, the group they are in is modified to reflect these changes However, over time this may lead to improper clustering of entities The entities in a particular group may drift far apart enough from each other such that the coverage area of the group becomes undesirably large Also, two clusters may change their coverage such that their information coverage overlaps to an extent that it would be justified to merge the two clusters into a single cluster The problem of clustering evolving user profile poses interesting problems If the re-cluster frequency is high, it becomes expensive and intrusive since it may result in frequent changes in assignment of user profiles to groups On the other hand, infrequent re-clustering allows the quality of clustering to deteriorate as user profiles change This may result in a higher network load, and imposes a higher caching resource requirement As a result, the main issue is to strike a balance between avoiding frequent re-clustering and achieving accurate clustering Factors affecting the optimal time frame to consider include the available bandwidth, cache size, the expected update rate of information, and the expected rate of change of user profiles Later in this section we will show how the choice of re-clustering frequency affects the clustering quality We tackle the dynamics of user profiles by using a two-phased approach towards maintaining group assignments Periodically, the assignment of entities to clusters is "reviewed" This review consists of two phases: a splitting phase and a merging phase: • Splitting Phase In the splitting phase, each group and the entities in it are examined and if the entities in the group have moved significantly away from each other, the group is split into multiple smaller clusters We tackle the task of deciding whether a group should be split into multiple clusters by re-clustering the entities in the group within themselves If the entities in the group should logically belong to a single cluster, the re-clustering will result in a single cluster If, on the other hand the entities in the group have moved far apart from each other since the last time the clusters were reviewed, so much so that their being in the same group cannot be justified, the result of the reclustering will be two or more smaller clusters consisting of subsets of the entities in the original cluster Re-clustering the entities within a group is less expensive because the number of entities being re-clustered is a lot smaller than the total number of entities in the system Within a group, we first randomly pick an entity as the locus of clustering All 250 • 4.3 INTERNETWORKING AND COMPUTING OVER SATELLITE NETWORKS other entities in the group are then incrementally clustered in a random order following the incremental clustering algorithm described before Merging Phase In the merging phase, groups in the existing clustering are pair-wise examined To simplify the clustering and reduce the number distinct groups, we may want to merge groups if they overlap to a large extent Merging groups that not sufficiently overlap results in a group that contains members whose coverage does not closely fit the group coverage and this results in the member users subscribing to a multicast data channel in IIDS that contains a lot of irrelevant information As a result, for each pair of groups in a clustering, we measure of the ratio of grids that appear in only one group against the total number grids If this ratio is less than the parameter GROUP_MERGE_THRESHOLD, the clusters are merged if no other pairs of groups have a lower ratio As the threshold increases, the less overlap groups have to have for them to be merged and the more relaxed the merging criteria is The merging process repeats until no pairs of groups satisfy the merging criteria More formally, given our formulation of user profiles, we define the "group merge expansion ratio" as gmer(F,G) = I (Profile(F) u Profile(G)) - (Profile(F) n Profile(G))1 / IProfile(F) u Profile(G)I, and we merge groups F and G if and only if (i) gmer(F,G) < GROUP_MERGE_THRESHOLD and (ii) there does not exists other groups I and J such that gmer(I,J) < gmer(F,G) Evaluation The profile-clustering algorithm contains a number of parameters that can be adjusted to tune the balance between the overhead, accuracy, and simplicity of the clustering generated They include the re-clustering frequency, the cluster-merging threshold, and the group-joining threshold One of the most important parameters that can be used to adjust the quality of clustering is the group-merging threshold that controls the allowable overlap between overlapping groups before they are combined into an aggregated group Here, we will show some simulation results and discuss the effects of changing one of the parameters, namely the cluster merging threshold, on vehicle information dissemination We will present a series of IS-minute simulation runs of the dynamic clustering algorithm with a simulated user environment consists of 30 vehicles following random paths in the road map shown in Figure 10-2 251 Information Dissemination Applications 25 ~ - 'E 20 +lI: , -~ lJ :::l g-o ,