



TSVWG Group                                                       S. Yue
Internet-Draft                                              China Mobile
Intended status: Informational                             l. Izhikevich
Expires: 7 January 2026                         University of California
                                                                 T. Tsou
                                                                  Tiktok
                                                             6 July 2025


 The Use Cases for Optimizing Transport Layer Protocols in LEO and MEO
                           Satellite Networks
               draft-yue-tsvwg-leo-transport-use-cases-00

Abstract

   This document introduces the use cases for the performance of
   existing transport protocols in LEO and MEO satellite networks. The
   use cases identify and demonstrate the current challenges faced by
   transport layer protocols in these environments.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.










Yue, et al.              Expires 7 January 2026                 [Page 1]

Internet-Draft        The Use Cases for LEO and MEO            July 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Video Streaming Service over LEO  . . . . . . . . . . . .   3
     3.2.  3GPP UE-SAT-UE Communication for 5G VN Group Service  . .   4
     3.3.  LEO Satellite Networks vs. Cellular Network . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Informative References  . . . . . . . . . . . . . . . . .   7
     6.2.  Normative References  . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   With the rapid advancement of Low Earth Orbit (LEO) and Medium Earth
   Orbit (MEO) satellite networks, these systems have become
   increasingly important for providing global connectivity, especially
   in remote and underserved areas.  However, compared to traditional
   terrestrial networks, LEO and MEO satellite networks face significant
   challenges due to their unique characteristics, such as frequent
   handovers, highly variable latencies, and periodic connection drops.
   These extreme network dynamics pose substantial difficulties for
   existing transport layer protocols, which are primarily designed for
   more stable and predictable network environments.

   Existing transport protocols, such as TCP, fail to perform optimally
   in LEO and MEO satellite networks.  For example, TCP's congestion
   control mechanisms, which rely on packet loss as a primary signal for
   congestion, can misinterpret the packet loss by handovers in
   satellite networks as a sign of network congestion, leading to
   unnecessary throughput reductions.  Transport layer protocol
   requirement for LEO satellite was introduced at
   [I-D.yang-tsvwg-leo-transport-req] .






Yue, et al.              Expires 7 January 2026                 [Page 2]

Internet-Draft        The Use Cases for LEO and MEO            July 2025


   This document introduces the use cases for the performance of
   existing transport protocols in LEO and MEO satellite networks. The
   use cases identify and demonstrate the current challenges faced by
   transport layer protocols in these environments.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Use Cases

3.1.  Video Streaming Service over LEO

   Netflix, as a major video streaming service, analyzed data over one
   million Starlink users across 85 countries over two years in
   [Izhikevich2024] . Starlink dominates the LEO satellite network
   market as the service provider with near 6,000 satellites and over
   2.6 million users.  The analysis reveals that while Starlink’s
   overall video quality matches traditional terrestrial networks,
   inherent LEO network variability, including throughput fluctuations
   and packet loss, causes a 60% rise in bitrate switches and a 200%
   increase in rebuffering events.

   Furthermore, the study highlights that Starlink exhibits lower
   throughput and higher variance compared to non-LEO terrestrial
   networks.  For instance, Starlink's throughput is typically about 50%
   of that offered by top 10 ISPs and falls below 20 Mb/s.  Over 90% of
   bitrate switches occur at throughputs below 20 Mb/s.  Additionally,
   Starlink's throughput recovery is slower: while non-LEO networks
   recover to above 10 Mb/s in about 5 seconds, Starlink takes
   approximately 15 seconds.This delay coincides with Starlink’s static
   route reconfiguration intervals between satellites and ground
   stations.

   To investigate the causes of low throughput, Netflix deployed A/B
   tests on over 1 million users.  The study identified that Starlink's
   high packet round trip times (RTTs) and increased retransmit rates
   contribute to low TCP congestion windows, resulting in lower
   throughput.  Nearly two times longer RTTs, double the retransmit
   rate, and smaller congestion windows compared to other networks were
   observed to confirm that.  The higher latency is attributed by longer
   routing paths.  The increase in Starlink retransmits is likely
   influenced by random loss on satellite links; the use of Active Queue
   Management on the Starlink WiFi router which minimizes latency at the



Yue, et al.              Expires 7 January 2026                 [Page 3]

Internet-Draft        The Use Cases for LEO and MEO            July 2025


   expense of packet loss; and potential packet reordering which may
   lead to duplicate acknowledgments and spurious retransmits.
   Increases in RTTs and retransmit rates can cause loss-based
   congestion controllers to take a long time to grow the TCP congestion
   window.  In addition, loss-based congestion controllers assume that
   any packet loss is due to congestion in the network, and therefore,
   back off when seeing indications of packet loss.  Congestion windows
   for Netflix sessions over Starlink paths being lower than over other
   networks.  With lower congestion windows, Starlink sessions are more
   likely to underutilize the true available bandwidth for a single TCP
   connection, and therefore experience lower throughput.

   To achieve higher throughput, Netflix approximated the use of
   multiple connections with MulTCP and created a modified version of
   New Reno: it grows the congestion window by three bytes for every
   acknowledged byte, and when it detects packet loss, it reduces the
   congestion window as if only one of the three emulated flows had seen
   a loss event.  However, a 30%-40% throughput increase came at the
   cost of increased retransmit rates by 300% and latency by 77%.
   Further solution is needed to better handle the dynamic
   characteristics of LEO networks and improve transmission performance.

3.2.  3GPP UE-SAT-UE Communication for 5G VN Group Service

   3GPP is a Standard Development Organization or SDO that develops and
   maintains technical spec. for mobile networks.  It is currently
   working on the final 5G-A spec. and simultaneously exploring various
   kinds of domains for the coming 6G evolution.

   3GPP has, in different releases, (near-) completed a few satellite-
   related working lis, including Satellite-access, Satellite-backhaul,
   Satellite regenerative forwarding mode, etc [TS.23.501].  As of now,
   for satellite operators who are operating 5G network with satellite
   access globally, the 3GPP plenary has concluded the requirements of
   supporting UE-satellite-UE communication for 5G VN group service
   [_GPP.SP-250400] . The 3GPP UE-Sat-UE service indicates the
   communication, between UEs under the coverage of one or more NGSO
   satellites, uses satellite access without the inter-UE traffic
   transiting thru the ground segment.

   As per the 3GPP [TS.23.501] , the 5G VN Group communication service
   is comprised of two traffic forwarding types, i.e.,

   *  local-switch type: for which the UL/DL traffic is locally
      forwarded by a single (on-board satellite) UPF (functioning like a
      router) if this UPF is the ‘anchor’ for all the participating UEs
      of the same 5G VN group;




Yue, et al.              Expires 7 January 2026                 [Page 4]

Internet-Draft        The Use Cases for LEO and MEO            July 2025


   *  inter-UPF type: for which the UL/DL traffic for the 5G VN group
      communication is forwarded between/among ‘anchors’ of different
      participating UEs.

   Here, both the local-switch and the inter-UPF forwarding types
   involve the impacts & implications as introduced by inter-satellite
   links or ISLs.  Note that, while the 3GPP simplifies the satellite
   network architecture by assuming the existence of ISL(s) have no or
   insignificant impacts on the 5G VN group service, we IETF must
   consider various types of implications associated with the dynamic
   satellite constellation networks, e.g.,

   *  High latency: thanks to potential long-distance satellite paths.

   *  high loss: harsh environment in outer space impairing the
      transmission quality, e.g., radiation, solar storm, etc.

   *  Path instability: thanks to extremely dynamic topology of
      satellite network, leading to frequent ISLs break-up &
      reconnection between satellites, satellite handover, etc.

   *  Path switchover & multi-path impacts: related to equipment
      features and network design, e.g., frequent beam scanning of
      (phased array) antennas, peering changes between/among neighboring
      satellites, UE mobility, etc.

   Compared to the deployment over terrestrial networks (or TNs), the
   traditional transport-level congestion control mechanism, e.g., TCP
   CUBIC, etc., would perform much worse due to the above adversarial
   factors.  The APNIC blog [APNIC-blog] , based on investigational
   survey, suggests it be possible to adjust the traditional TCP CUBIC
   by conducting a lost packet repair using Selective Acknowledgement
   (SACK) [RFC2883] if a packet loss event might occur at the time of a
   scheduled satellite handover or path switchover.  Remember that SACK
   is a big reason why modern TCP protocols perform well over mobile
   services.  Fortunately, the 3GPP-based UE-Sat-UE 5G VN service does
   own the capability of knowing in advance satellite scheduled changes.
   In 5G network [TS.23.501] , the 5GC NF AMF can get the satellite
   ephemeris information via different schemes and provide the satellite
   footprints to UEs for the optimization of transport services, i.e.,
   UEs leveraging satellite scheduled events to optimize the
   communication during satellite handover.  At UEs, these add-on
   information helps the TCP control algorithm distinguish between
   isolated packet loss and loss-inducing levels of network congestion.







Yue, et al.              Expires 7 January 2026                 [Page 5]

Internet-Draft        The Use Cases for LEO and MEO            July 2025


3.3.  LEO Satellite Networks vs. Cellular Network

   In this use case [Hu2023] , a measurement study was conducted to
   understand the performance characteristics of Starlink satellite
   networks and compare them with cellular networks.  The study involved
   a large-scale data collection campaign across five states in the US,
   covering diverse geographical areas and user populations.  The
   dataset includes experimental results from both Starlink and cellular
   networks, involving two types of Starlink configurations (Roam and
   Mobility) and three major cellular carriers (AT&T, T-Mobile, and
   Verizon).  The analysis reveals several key findings:

   TCP vs. UDP downlink performance.  While cellular networks show
   minimal TCP/UDP throughput differences, UDP dominates in satellite
   environments with mean rates of 128 Mbps vs. TCP’s 29 Mbps.  This
   disparity stems from TCP’s reliability mechanisms (e.g., congestion
   control), which amplify performance degradation under Starlink’s
   elevated packet loss rates (0.3%-1.3% vs. cellular’s 0.0%-0.2%).
   High loss rates trigger frequent TCP retransmissions and window size
   reductions, ultimately decreasing throughput.

   Uplink vs. downlink throughput.  Starlink’s downlink throughput
   exceeds uplink by 10x, aligning with typical user behavior favoring
   data consumption (e.g., video streaming) over generation.

   Latency.  Starlink’s Round-Trip Time (RTT) matches cellular networks
   at 50-100 ms, with only 1.8 ms (550km÷300000km/s) added per hop by
   space-ground transmission, despite the 550 km satellite altitude.

   Moving speed.  Throughput remains stable across both networks during
   high-speed movement.  For Starlink, ground terminals’ mobility is
   negligible relative to satellites’ 28,000 km/h speed.  For cellular
   networks, efficient handovers contribute to maintaining consistent
   throughput.

   TCP parallelism optimization.  Starlink achieves a better throughput
   improvement, over 50% with 4 parallel TCP connections and over 130%
   improvement with 8 connections.  TCP parallelism optimizes bandwidth
   utilization by distributing data across multiple connections, thereby
   mitigating the impact of TCP congestion control.  It also improves
   packet loss handling.  In case of packet loss in one connection,
   other connections continue data transmission, minimizing the impact
   on overall throughput.








Yue, et al.              Expires 7 January 2026                 [Page 6]

Internet-Draft        The Use Cases for LEO and MEO            July 2025


   In summary, Starlink experiences higher packet loss compared to
   cellular networks, while latency remains similar.  This high packet
   loss significantly impacts TCP performance, resulting in TCP
   throughput being only 1/5 of UDP throughput over Starlink.  TCP
   parallelism offers more benefits to Starlink than cellular networks,
   likely due to its effective handling of packet loss.

   To address these issues, multipath UDP experiments are conducted.
   However, multipath UDP initially showed only marginal throughput
   gains compared to single-path transfer.  By tuning the buffer
   settings, they achieved more significant throughput improvements.
   The results highlight the need for better solutions that can handle
   the specific characteristics of LEO networks.

4.  Security Considerations

   TBD.

5.  IANA Considerations

   This document has no requests for IANA.

6.  References

6.1.  Informative References

   [APNIC-blog]
              Huston, G., "A transport’s view of Starlink", APNIC
              Blog https://blog.apnic.net/, May 2024,
              <https://blog.apnic.net/（URL待补充）>.

   [Hu2023]   Hu, B., Zhang, X., Zhang, Q., Varyani, N., Mao, Z. M.,
              Qian, F., and Z.-L. Zhang, "LEO Satellite vs. Cellular
              Networks: Exploring the Potential for Synergistic
              Integration", CoNEXT Companion 19th International
              Conference on Emerging Networking EXperiments and
              Technologies, December 2023,
              <https://doi.org/10.1145/3624354.3630588>.

   [I-D.yang-tsvwg-leo-transport-req]
              Yang, F. and T. Tsou, "Transport Layer Protocol
              Requirement for LEO satellite", Work in Progress,
              Internet-Draft, draft-yang-tsvwg-leo-transport-req-00, 16
              March 2025, <https://datatracker.ietf.org/doc/html/draft-
              yang-tsvwg-leo-transport-req-00>.






Yue, et al.              Expires 7 January 2026                 [Page 7]

Internet-Draft        The Use Cases for LEO and MEO            July 2025


   [Izhikevich2024]
              Izhikevich, L., Enghardt, R., Huang, T.-Y., and R.
              Teixeira, "A Global Perspective on the Past, Present, and
              Future of Video Streaming over Starlink", ACM
              Journal Volume 8, Issue 3, Article 30, December 2024,
              <https://doi.org/10.1145/3700412>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [_GPP.SP-250400]
              3GPP, "New SID on Study on Integration of satellite
              components in the 5G architecture Phase 4", 3GPP SP SP-
              250400, March 2025.

6.2.  Normative References

   [RFC2883]  Podolsky, M., Floyd, S., Mahdavi, J., and M. Mathis, "An
              Extension to the Selective Acknowledgement (SACK) Option
              for TCP", Request for Comments 2883, DOI 10.17487/RFC2883,
              publisher RFC Editor, July 2000,
              <https://www.rfc-editor.org/info/rfc2883>.

   [TS.23.501]
              3GPP, "System Architecture for the 5G System (5GS)", 3GPP
              TS 23.501 (V19.3.0), March 2025,
              <https://www.3gpp.org/ftp/Specs/
              archive/23_series/23.501/>.

Authors' Addresses

   Shengnan Yue
   China Mobile
   Email: yueshengnan@chinamobile.com


   Liz Izhikevich
   University of California
   Email: lizhikev@g.ucla.edu






Yue, et al.              Expires 7 January 2026                 [Page 8]

Internet-Draft        The Use Cases for LEO and MEO            July 2025


   Tina Tsou
   Tiktok
   Email: tina.tsou@tiktok.com
















































Yue, et al.              Expires 7 January 2026                 [Page 9]
