objective - expedited(15-20min) draining of segmented video
delivery(live or vod) edge traffic.
(mid/parent traffic draining is fairly simple.. i am only focusing on
edge draining)

so re-visiting draining challenges, specifically with respect to
'sticky clients' and segmented video playback.
anyone see any gotchas with the below approach or have any other suggestions..


1. remove from dns, load balancing, etc, and all other preliminary
steps to prevent traffic to be directed to the cache(s) in question
2. disable http keep-alive at the cache
3. with respect to client connections, apply iptable rule at the cache
to allow EST connections, but deny TCP SYNs to ports 80/443(excluding
management networks, etc).
the deny rule will send an immediate TCP RST or some icmp message.
basically some immediate message to inform the client the http
resource is not available.
the SYN packet will not be silently dropped, as we want the video
client to know the network(cache ip) is not accepting new connections.

step 2 will force the client to setup a new connection after the
in-flight requested segment has completed. some clients will re-issue
a DNS request at this point
so DNS will send the client to another online cache

for clients that dont re-issue a DNS request for new connections,
step 3 will prevent the client from creating a new connection and
hopefully at this point
the client will re-issue a DNS request, thus being directed to an online cache.

in my testing, i've seen video clients from various platforms, tvs,
phones, etc send one DNS request upon startup for the selected title.
the only time these clients will ever re-issue a DNS request,
regardless of TTL, is if the target  cache/webserver IP experiences
some network event.
TCP RST, timeout, etc.

other clients will re-issue a DNS request for each new connection opened.

so steps 2 and 3 account for both of these player designs.

Reply via email to