I can only conclude they do that or something like it, based on the following observations:

1. When I stream MP3 content unencrypted from home to any other location, everything works well for up to the first half hour or so, and then packets start coming through so slowly as to result in about five seconds of buffering per second of music played. Once this starts to happen, I'm similarly unable to access, due to timeouts, any of the other services I host from home for my own use. If I stop MP3 playback and wait a couple of hours, the problem clears up, but only until I start streaming music again.

2. When I stream Ogg or FLAC content unencrypted &c., &c., I always get smooth playback for as long as I care to use it, and all my other home services work fine.

3. When I stream MP3 content via HTTPS &c., &c., I always get smooth playback for as long as I care to use it, and all my other home services work fine.

Of further note: All the locations from which I've observed this problem offer sufficient downstream bandwidth to support streaming of 320Kbps CBR MP3 files, as indicated both by the fact that doing so over HTTPS works fine, and that streaming FLAC at much higher bitrates also works fine. I used to stream MP3 (but not FLAC) over Verizon DSL, which had barely enough upstream bandwidth to support it (and not enough for FLAC), and never had this sort of problem. The only variables in the admittedly informal tests I've run have been transport encryption and content encoding; in particular, all the content, regardless of format, comes from the same hardware, through the same HTTP server, across the same path through my local network.

I suppose these observations might plausibly lead to some conclusion other than the one I've drawn, but I don't see how; if you do, I'd like to hear about it.