Forum Discussion

Bryan_A's avatar
Bryan_A
Icon for Altostratus rankAltostratus
Jun 07, 2017

Streaming video, TCP reset packets, standard virtual server

We have a standard virtual server that has a few apache servers as pool members. We notice when content is streamed via web browser, MP4 for example, a connection build-up occurs between the LTM and the pool member. This happens when viewing the MP4 in a browser and manipulating or "scrubbing" the scroll bar in the video to navigate around. A TCPDUMP captured on my client machine reveals that when performing this "scrubbing", TCP RST packets are generated from the client and sent to the F5. Also we see many "cancelled" requests in Chrome when looking at the HTTP headers/network information. These seem to correspond somewhat to the TCP RST packets. To me this indicates the content is no longer needed, and to cancel/tear down the request and connection. The F5 however seems to simply drop the RST packets and does not forward or send new ones to the pool member. This causes all the requests generated from "scrubbing" to be served by the pool member, instead of being cancelled/removed from the connection table. During this time, the LTM<->Pool Member side of the proxy becomes network saturated, and slows everything down until the requests complete. Sometimes this can last a few minutes. The client side of the connection generally remains unaffected.

 

The one thing that seems to fix it is to change the virtual to a Performance L4 type. After doing this I can see RST packets making it to the pool member, however we lose layer 7 functionality by doing that so it is a last resort.

 

I also verified that by bypassing the F5, this behaviour does not occur and the TCP RST packets are received and processed by the apache server.

 

Would love to hear some ideas. I have tried https://support.f5.com/csp/article/K8894 already with no luck. Have also tried disabling the HTTP profile on the VIP with no luck.

 

Running 12.1.2 HF1. I do have a case open but interested in ideas here too.

 

Thanks

 

1 Reply

  • Hi,

     

    I guess Performance (L4) solves this problem because it's packet-by-packet, no content spooling on BIG-IP etc. So RST packets are just passed to backend.

     

    You mentioning that reason against using it is loosing L7 functionality - but what exactly? iRules, cookie persistence?

     

    If you tried to remove HTTP profile from Standard then you as well was disabling L7 - so why not use Performance (L4) if it works for your apps?

     

    Piotr