TCP Inside SSTP: Why Retransmission Happens Twice

Word of mouth arrives before the protocol does. Ask around and SSTP is the slow one, the option you avoid unless something forces it. That reputation describes one failure mode on one kind of path.

The mechanism is real. It is also conditional, which the reputation never mentions.

Two Reliable Streams on One Path

SSTP wraps its tunnel inside an HTTPS session. HTTPS runs over TCP, and that outer stream guarantees ordered delivery. A single missing segment therefore holds back everything queued behind it. Later bytes belonging to other inner conversations wait anyway.

Inner TCP flows keep their own ordering and congestion control. They cannot see the outer recovery, so all they observe is a stall. A stall is the signal that tells them the path is congested.

Both layers now back off at the same time. That is the whole interaction, and one lost segment is enough to start it.

Where the Effect Appears and Where It Does Not

On a clean path the outer stream rarely recovers anything. The interaction never triggers, and SSTP carries interactive traffic perfectly well. The blanket claim fails on exactly this point.

The effect appears when loss or reordering reaches the underlying path. A congested Wi-Fi link or a mobile connection with variable latency creates the conditions. A blocked outer queue then turns into visible delay inside the tunnel.

It also scales with the workload. Many parallel flows fill the queue and make head-of-line blocking worse. One interactive session over the same path may feel acceptable.

What the Symptom Usually Is Not

Not every slow session is this problem. A steady low rate from the first packet points at capacity, shaping or a server limit. Pauses that line up with local congestion point at queueing on the access link.

The remedies differ, which is why the diagnosis comes first. Buffer tuning does nothing for a shaped link. Switching protocols does nothing for a server that is out of capacity. Repeated resets point somewhere else entirely.

# outer path quality to the SSTP endpoint
ping -c 50 203.0.113.44 | tail -3
mtr -rwc 50 203.0.113.44

# is the local link saturated while the session stalls?
sar -n DEV 2 5

# retransmissions on the outer connection
ss -tin dst 203.0.113.44

Run the measurement while the problem is happening. A capture taken during a healthy minute proves nothing about the loop that runs during the bad one.

A Comparison Worth Trusting

If another transport is genuinely available, compare it under control. Same host, same network, same destination and same task. Both runs belong inside the same ten minutes so the path conditions match.

Changing a port does not change a protocol. Importing an unrelated profile into an SSTP client does not create an alternative transport. The comparison means something only when the server offers the second option.

Keep TLS verification in place throughout. Performance work is not a reason to accept an unverified certificate. If stalls appear mainly while the uplink is saturated, look at queueing before blaming the layering.