From: Pandya, Akshay <AkshayPandya@WireCo.com>
Sent: Wednesday 23 September 2026 21:19
To: Justin Cottrell <justin.cottrell@mirazon.com>; Pajevic, Aleksandar (External) <apajevic.ext@libertyglobal.com>; Van Steen, Steven <svansteen@libertyglobal.com>; Liberty Global - CSD IP Infrastructure and Voice <CSDIPInfrastructureandVoice@libertyglobal.com>; noc@vodafoneziggo.com; b2b.ops@vodafoneziggo.com; Liberty Global Central Network Support <cns@libertyglobal.com>; LibertyGlobal-DL- CoreNetworkOperations <CoreNetworkOperations@libertyglobal.com>
Cc: Liberty Global Peering Team <peering@aorta.net>; Liberty Global-Mail2Ticket Update <mail2ticketupdate@libertyglobal.com>; Baumgarten, Rick <RickBaumgarten@WireCo.com>; Ribeiro, Artur <ArturRibeiro@WireCo.com>; Paul Bratcher <paulbratcher@WireCo.com>
Subject: RE: [External] P4|INC000005996181|Bandwidth/Path issues from multiple providers to Portugal

From: Justin Cottrell <justin.cottrell@mirazon.com>
Sent: Wednesday, September 23, 2026 10:42 AM
To: Pajevic, Aleksandar (External) <apajevic.ext@libertyglobal.com>; Pandya, Akshay <AkshayPandya@WireCo.com>; Van Steen, Steven <svansteen@libertyglobal.com>; Liberty Global - CSD IP Infrastructure and Voice <CSDIPInfrastructureandVoice@libertyglobal.com>; noc@vodafoneziggo.com; b2b.ops@vodafoneziggo.com; Liberty Global Central Network Support <cns@libertyglobal.com>; LibertyGlobal-DL- CoreNetworkOperations <CoreNetworkOperations@libertyglobal.com>
Cc: Liberty Global Peering Team <peering@aorta.net>; Liberty Global-Mail2Ticket Update <mail2ticketupdate@libertyglobal.com>; Baumgarten, Rick <RickBaumgarten@WireCo.com>; Ribeiro, Artur <ArturRibeiro@WireCo.com>; Paul Bratcher <paulbratcher@WireCo.com>
Subject: Re: [External] P4|INC000005996181|Bandwidth/Path issues from multiple providers to Portugal

From: Justin Cottrell <justin.cottrell@mirazon.com>
Sent: Wednesday 23 September 2026 16:50
To: Pajevic, Aleksandar (External) <apajevic.ext@libertyglobal.com>; Pandya, Akshay <AkshayPandya@WireCo.com>; Van Steen, Steven <svansteen@libertyglobal.com>; Liberty Global - CSD IP Infrastructure and Voice <CSDIPInfrastructureandVoice@libertyglobal.com>; noc@vodafoneziggo.com; b2b.ops@vodafoneziggo.com; Liberty Global Central Network Support <cns@libertyglobal.com>; LibertyGlobal-DL- CoreNetworkOperations <CoreNetworkOperations@libertyglobal.com>
Cc: Liberty Global Peering Team <peering@aorta.net>; Liberty Global-Mail2Ticket Update <mail2ticketupdate@libertyglobal.com>; Baumgarten, Rick <RickBaumgarten@WireCo.com>; Ribeiro, Artur <ArturRibeiro@WireCo.com>; PaulBratcher <PaulBratcher@wireco.com>
Subject: Re: [External] P4|INC000005996181|Bandwidth/Path issues from multiple providers to Portugal

From: Pajevic, Aleksandar (External) <apajevic.ext@libertyglobal.com>
Sent: Wednesday, September 23, 2026 6:32 AM
To: Pandya, Akshay <AkshayPandya@WireCo.com>; Justin Cottrell <justin.cottrell@mirazon.com>; Van Steen, Steven <svansteen@libertyglobal.com>; Liberty Global - CSD IP Infrastructure and Voice <CSDIPInfrastructureandVoice@libertyglobal.com>; noc@vodafoneziggo.com <noc@vodafoneziggo.com>; b2b.ops@vodafoneziggo.com <b2b.ops@vodafoneziggo.com>; Liberty Global Central Network Support <cns@libertyglobal.com>; LibertyGlobal-DL- CoreNetworkOperations <CoreNetworkOperations@libertyglobal.com>
Cc: Liberty Global Peering Team <peering@aorta.net>; Liberty Global-Mail2Ticket Update <mail2ticketupdate@libertyglobal.com>; Baumgarten, Rick <RickBaumgarten@WireCo.com>; Ribeiro, Artur <ArturRibeiro@WireCo.com>; PaulBratcher <PaulBratcher@wireco.com>
Subject: RE: [External] P4|INC000005996181|Bandwidth/Path issues from multiple providers to Portugal

From: Justin Cottrell <justin.cottrell@mirazon.com>
Sent: Wednesday, September 16, 2026 9:43 AM
To: Liberty Global - CSD IP Infrastructure and Voice <CSDIPInfrastructureandVoice@libertyglobal.com>; Van Steen, Steven <svansteen@libertyglobal.com>; noc@vodafoneziggo.com <noc@vodafoneziggo.com>; b2b.ops@vodafoneziggo.com <b2b.ops@vodafoneziggo.com>; Liberty Global Central Network Support <cns@libertyglobal.com>; LibertyGlobal-DL- CoreNetworkOperations <CoreNetworkOperations@libertyglobal.com>
Cc: Liberty Global Peering Team <peering@aorta.net>; Liberty Global-Mail2Ticket Update <mail2ticketupdate@libertyglobal.com>; Baumgarten, Rick <RickBaumgarten@WireCo.com>; Pandya, Akshay <akshaypandya@wireco.com>; Ribeiro, Artur <arturribeiro@wireco.com>
Subject: Re: P4|INC000005996181|Bandwidth/Path issues from multiple providers to Portugal

We are investigating a repeatable TCP performance issue affecting communications between our sites in Portugal and multiple international locations.

The most severe symptom is reduced TCP throughput when traffic is transmitted FROM Portugal toward international destinations.

Testing has been performed from two separate Portugal locations, PTMA and Oliveira, using multiple remote destinations and multiple test methodologies.

The most important control test is communication between the two Portugal locations.

PTMA and Oliveira can sustain approximately 480–500 Mbps using a SINGLE TCP connection when communicating with each other.

When essentially the same testing is performed from Portugal toward international destinations, individual TCP flows can fall to approximately 30–80 Mbps.

Multiple parallel TCP streams frequently recover several hundred Mbps of aggregate throughput.

This strongly suggests that the affected circuits have substantially more aggregate capacity than an individual affected TCP flow is able to utilize.

AS33915 appears in routing associated with our Netherlands location and is therefore one of the networks we are asking to assist with investigation.

We are not asserting that AS33915 is responsible for the condition. We are requesting assistance determining whether the impairment occurs within AS33915, at an interconnection/peering boundary, or elsewhere along the international path.

Public test endpoint:

193.126.229.227

PTMA has been tested using two independent Internet connections.

Testing has also been performed with the customer firewall and switching infrastructure removed from the path by connecting the test endpoint directly to the ISP circuit.

Public test endpoint:

83.240.185.210

Oliveira is a physically separate Portugal location and provides an important independent comparison with PTMA.

Public test endpoint:

93.117.236.142

Routing associated with this destination traverses/reaches AS33915.

Public test endpoint:

95.171.126.204

Additional private/VPN testing has also been performed against the Poland network.

The most useful baseline is PTMA ↔ Oliveira.

These sites are independent Portugal locations.

PTMA → Oliveira:

~501 Mbps

Oliveira → PTMA:

~484 Mbps

PTMA → Oliveira, 8 streams:

~505 Mbps

Oliveira → PTMA, 8 streams:

~482 Mbps

There is essentially no severe single-flow TCP penalty between the Portugal sites.

A single TCP connection is capable of utilizing approximately 500 Mbps.

This is important because it demonstrates that neither Portugal endpoint has an inherent 30–80 Mbps TCP limitation.

It also provides a known-good baseline against which the international tests can be compared.

This has produced some of the clearest directional results.

Netherlands → PTMA:

~346 Mbps

PTMA → Netherlands:

~42.2 Mbps

This represents approximately an 8:1 difference between directions during the comparable test.

Netherlands → PTMA:

~909 Mbps

PTMA → Netherlands:

~292 Mbps

The ability to reach approximately 292 Mbps outbound using parallel connections while a single connection reaches only approximately 42 Mbps demonstrates that substantially more aggregate path capacity exists than the single TCP connection can utilize.

Additional public-path UDP testing delivered approximately:

300 Mbps offered → ~300 Mbps delivered

400 Mbps offered → ~401 Mbps delivered

A 500 Mbps offered-load test averaged approximately 384 Mbps and exhibited significant short-term throughput variation.

Again, the path can transport substantially more traffic than the affected ~42 Mbps single TCP flow.

PTMA ↔ Netherlands RTT is approximately:

46 ms

TCP PsPing testing was stable and did not show persistent end-to-end loss during the referenced test.

A second Portugal site reproduces the same general behavior.

Oliveira → Netherlands:

~31 Mbps

Oliveira → Netherlands:

~466 Mbps

This is a particularly significant result.

The same Oliveira endpoint that sustains approximately 484 Mbps using ONE TCP connection to PTMA sustains only approximately 31 Mbps on a single TCP connection toward the Netherlands.

Adding parallel connections increases aggregate throughput to approximately 466 Mbps.

Therefore:

Oliveira → PTMA:
~484 Mbps single TCP

Oliveira → Netherlands:
~31 Mbps single TCP

Oliveira → Netherlands:
~466 Mbps with 8 TCP streams

This is difficult to reconcile with a simple bandwidth limitation at the Oliveira site.

The issue is not limited to the Netherlands test.

Testing from Oliveira toward Poland also demonstrated reduced outbound TCP performance.

Oliveira → Poland:

~78 Mbps

Oliveira → Poland:

~143 Mbps

Although the characteristics are not identical to the Netherlands path, international outbound performance is again significantly below the approximately 480–500 Mbps single-flow performance demonstrated between the two Portugal sites.

Private/VPN testing has also demonstrated outbound degradation from PTMA toward Poland.

One eight-stream PTMA → Poland test achieved approximately:

~90 Mbps aggregate

UDP testing at lower offered rates performed substantially better from a packet-loss perspective.

These tests involve VPN/private infrastructure and are therefore treated as supporting evidence rather than our primary public-Internet control.

Our strongest evidence remains the direct public endpoint testing.

Testing has also been performed from Germany and the United States.

Germany testing demonstrated that our Netherlands endpoint is capable of receiving substantially higher aggregate TCP throughput from another geographic region.

For example, Germany → Netherlands using eight TCP streams with a 1 MB window reached approximately:

~564 Mbps

The same Netherlands endpoint therefore is not simply capped at the low throughput observed from Portugal.

United States/private-path testing has also been performed, although because those tests include VPN infrastructure we do not use them as the primary evidence for this escalation.

The public Portugal ↔ Netherlands and Portugal ↔ Portugal comparisons provide a much cleaner control.

A significant amount of effort has been made to eliminate customer equipment as a cause.

At PTMA, testing has been performed with the test computer connected directly to the ISP service.

This removes the following equipment/functions from the tested path:

• FortiGate firewall

• IPsec VPN

• UTM/security inspection

• Cisco access switching

• Customer LAN infrastructure

The international behavior remained reproducible.

Testing was subsequently performed through a SECOND independent PTMA Internet provider.

The two PTMA providers use materially different upstream transit paths.

Despite this, similar destination-dependent and flow-dependent performance behavior was observed.

This significantly reduces the likelihood that a single PTMA firewall, switch, ISP access circuit, or unique upstream carrier is responsible for the entire issue.

One of the most repeatable characteristics is the difference between single and parallel TCP flows.

Examples:

PTMA → Netherlands:

Single TCP:
~42 Mbps

8 TCP streams:
~292 Mbps

Oliveira → Netherlands:

Single TCP:
~31 Mbps

8 TCP streams:
~466 Mbps

PTMA → Oliveira:

Single TCP:
~501 Mbps

8 TCP streams:
~505 Mbps

The Portugal domestic path behaves normally.

The international paths exhibit dramatically greater dependence on parallel TCP flows.

This suggests investigation should focus on conditions capable of disproportionately affecting individual long-lived TCP flows rather than solely aggregate interface utilization.

Potential areas for investigation include, but are not limited to:

• Low-level packet loss

• TCP retransmissions

• Queue congestion

• Microbursts

• Policers

• Traffic shaping

• ECMP/flow hashing

• Congested individual LAG/ECMP members

• Peering/interconnection congestion

• Asymmetric routing

• Receive-window/congestion-window interaction

• Packet reordering

• Path-specific MTU/MSS behavior

These are investigation areas, not conclusions regarding the root cause.

During testing toward the Netherlands endpoint, routing associated with the destination enters or converges toward the AS33915 network.

Observed AS33915-associated addresses on tested paths have included:

213.51.64.x

213.51.7.187

Earlier testing from PTMA's primary ISP reached the Netherlands through an AS6453 path before entering the Netherlands-side network.

Testing through PTMA's second provider followed a materially different Vodafone/Cable & Wireless transit path.

Despite the different upstream paths from Portugal, similar performance behavior was observed toward the Netherlands destination.

This makes the common downstream portion of the path particularly interesting.

However, we want to emphasize:

We are NOT concluding that AS33915 is responsible.

The problem could exist:

• within an upstream transit network,

• at the interconnection with AS33915,

• within AS33915,

• on the destination access network,

• or as the result of an interaction between multiple networks.

We are requesting AS33915's assistance specifically because visibility from within the network is required to distinguish these possibilities.

We would appreciate review of the path toward:

93.117.236.142

during synchronized testing from our Portugal endpoints.

Specifically, we would appreciate examination of:

1. Interface utilization and congestion along the relevant path.

2. Interface discards or queue drops.

3. LAG/ECMP member utilization and errors.

4. Whether individual TCP flows could be consistently hashing onto a congested or impaired member.

5. Policers or traffic-management policies affecting traffic from the relevant Portugal prefixes.

6. Peering/interconnection utilization toward the Portugal transit providers.

7. BGP path selection for traffic toward and from:

• 193.126.229.227

• 83.240.185.210

8. Return-path routing from AS33915 toward both Portugal destinations.

9. Any asymmetric routing between the forward and reverse paths.

10. Packet loss that may be too small to appear clearly in ordinary ICMP testing but significant enough to affect long-RTT TCP throughput.

11. Any known congestion or capacity issue at the relevant European interconnection points.

We would be happy to coordinate a live test with the AS33915 network team.

The preferred test would use:

Portugal:
193.126.229.227

Netherlands:
93.117.236.142

We can run the following sequence while AS33915 monitors the relevant interfaces:

1. Single TCP stream – Portugal → Netherlands

2. Single TCP stream – Netherlands → Portugal

3. Eight TCP streams – Portugal → Netherlands

4. Eight TCP streams – Netherlands → Portugal

5. Controlled UDP at 100 Mbps

6. Controlled UDP at 200 Mbps

7. Controlled UDP at 300 Mbps

8. Traceroute/MTR in both directions

We can provide exact timestamps to correlate each test with network telemetry.

Packet captures can also be collected simultaneously at both endpoints if required.

The core issue can be summarized very simply:

PTMA → Oliveira, Portugal:
~501 Mbps SINGLE TCP

Oliveira → PTMA, Portugal:
~484 Mbps SINGLE TCP

PTMA → Netherlands:
~42 Mbps SINGLE TCP

Oliveira → Netherlands:
~31 Mbps SINGLE TCP

Yet parallel connections can recover hundreds of Mbps on the affected international paths.

This means the Portugal systems are demonstrably capable of approximately 500 Mbps single-flow TCP performance.

The severe degradation emerges primarily when traffic traverses longer/international paths.

The condition has been reproduced:

• From two separate Portugal sites

• Through multiple Portugal Internet providers

• With customer firewall/switch infrastructure removed in direct testing

• Using public Internet endpoints

• In both single and parallel TCP testing

• With UDP demonstrating additional aggregate path capacity

We therefore believe this warrants investigation at the IP transit/peering/core-network level.

Again, we are not assigning fault to AS33915. We are asking for assistance determining whether the impairment occurs inside AS33915, at an interconnection involving AS33915, or elsewhere along the path.

We can provide raw iPerf3 results, PsPing output, traceroutes, PathPing output, source/destination addresses, packet captures and exact timestamps.

Thank you for any assistance in getting this case to the appropriate IP Core / Backbone / Peering engineering team.

From: Liberty Global - CSD IP Infrastructure and Voice <CSDIPInfrastructureandVoice@libertyglobal.com>
Sent: Wednesday, September 16, 2026 9:40 AM
To: Justin Cottrell <justin.cottrell@mirazon.com>; Liberty Global - CSD IP Infrastructure and Voice <CSDIPInfrastructureandVoice@libertyglobal.com>; Van Steen, Steven <svansteen@libertyglobal.com>; noc@vodafoneziggo.com <noc@vodafoneziggo.com>; b2b.ops@vodafoneziggo.com <b2b.ops@vodafoneziggo.com>; Liberty Global Central Network Support <cns@libertyglobal.com>; LibertyGlobal-DL- CoreNetworkOperations <CoreNetworkOperations@libertyglobal.com>
Cc: Liberty Global Peering Team <peering@aorta.net>; Liberty Global-Mail2Ticket Update <mail2ticketupdate@libertyglobal.com>; Baumgarten, Rick <RickBaumgarten@WireCo.com>; Pandya, Akshay <akshaypandya@wireco.com>; Ribeiro, Artur <arturribeiro@wireco.com>
Subject: [External] P4|INC000005996181|Bandwidth/Path issues from multiple providers to Portugal

—Steven