FST Storage and Structure

    Each link maintain a FST, which is stored in a server. All the servers have the map of <link, server> for query. Each server can maintain one or more FSTs. We initialize the map by finding the closest server to the link, and try to balance the load of each server. From \cite{Benson_Anand_Akella_Zhang_2010} and \cite{a_Greenberg_Patel_Chaiken_2009}, we can know that flows competition of links usually happen not far away the host , due to the locality of flow distribution. So it would be relatively short to solve the conflict.

    For each FST, we maintain the state of link, active list and waiting list. State 0 represent a relatively empty buffer it is free to add more flow, vise versa. We expect to set a relatively small k for all the link. From \cite{Hong_Caesar_Godfrey_2012} and \cite{McKeown_Prabhakar_Shenker_2013}, we learn that the less the rate control, the smaller the mean time would be. So we don’t have rate control, but only flow schedule.

    The priority of flows are quite generalized. It can be remaining flow size or flow deadline or some other combination.