Could VM hate UDP 443 QUIC ?

[legacy1]

Just thinking VM like their download they don't care about upload but in order to download you need to send something and VM don't want you sending the real amount and do ack suppression but what if VM QoS these packets for upstream so even if your latency goes to hell TCP download remains more stable with low latency for ack suppression packets. But then the problem is UDP QUIC does not apply unless VM do one of two things like block UDP 443 (in router mode) to force TCP 443 or QoS UDP packets at a size for things that use QUIC like YouTube...

[IPFreely]

I have no idea why the forum thought I would be interested in this but while I'm here...

I don't think you understand what ack suppression is for: it's not bandwidth.

You are wrong to think it bypasses congestion suggesting you either don't know what ack suppression does or don't understand how the DoCSIS upstream works. 

You are wrong to think router mode is required to block things. All cable modems have basic stateless firewall capability. 

A large proportion if not the majority of traffic to and from Google is already QUIC. It's fine. From RFC 9000 a value more than high enough given the frequency of the upstream MAP and the request-grant-transmit cycle on DoCSIS is the default acknowledgement delay:

max_ack_delay (0x0b):

The maximum acknowledgment delay is an integer value indicating the maximum amount of time in milliseconds by which the endpoint will delay sending acknowledgments. This value SHOULD include the receiver's expected delays in alarms firing. For example, if a receiver sets a timer for 5ms and alarms commonly fire up to 1ms late, then it should send a max_ack_delay of 6ms. If this value is absent, a default of 25 milliseconds is assumed. Values of 2^14 or greater are invalid. 

[gitty]

The amount of saved bandwidth depends on the rate of ACKs. The more ACKs the modem receives, before it is grated access to transmit the next queued ACK, the more ACKs will be compressed into one.

The responsiveness of TCP... ACKs received later will be combined with the ACK that is further up the queue (if there is one), so they will be transmitted earlier, compared to when suppression is off.

[legacy1]

But it is about bandwidth that is save at the modem side before sending upstream when 4K 60FPS by TCP (by blocking UDP443) bursts a chunk of video I see 2.5Mb upload as I download the chunk how much bandwidth before sending out the modem is that reduced by vs QUIC? followed by VM doing a bit of QoS for the ack suppression at the modem side and having Docsis slots for them packets not that their is any proof of that but let say thats the case...    

[gitty]

I guess it is what it is. QUIC just works differently than TCP. The ACKs are encrypted, so the modem cannot apply suppression like it does for TCP.

Trying to block it... I don't think that is the way forward. 😊

A note: ACK suppressions happens at the DOCSIS layer, so router mode is not required for it to work.

[legacy1]

The ACK's that have data are encrypted but all ACK's with and without data have info like Sequence Number, Acknowledgment number even timestamps in the clear so it is possible to do suppression...edit yes for TCP not for  QUIC

what I mean is the ISP should not block QUIC just that it puts more load on the upstream 

thinking about why wouldn't QUIC not reduced the ACK in its protocol?