Transcript
T6: SDN in practice: Microsoft's Swan Discussion
Critique 1.
Path allocations are ultimately derived by solving a multicommodity flow (MCF) problem. This has several potential issues: a. Reconvergence: this optimization (a linear program) needs to be continually resolved as traffic patterns shift. For only a 40switch network this takes close to a minute and Fig. 8 in Merlin [1] reports this doesn't grow linearly. In the worst case (184k traffic classes, 9k bandwidth guarantees) required 41 minutes to solve. b. Churn: after solving the MCF, forwarding rules still need to be installed on the switches. Numbers from Facebook's production network indicate this results in roughly 70 routing state changes perdevice and perminute! There is also an issue with the number of unique paths used O(10000) after < 100 iterations which could exhaust the limited flow tables.
2. As a counterpoint, though, they do point out that in B4 there are only 13 traffic classes in total and a modest number of sites ('a few dozen') so the widearea setting may be more tractable. Furthermore, in SWAN they also develop an approximation algorithm and demonstrate it achieves nearoptimal utilization in practice, plus the fact that it is in production deployment confirms its feasibility. 3. (Ref: Fig 1) The paper largely discusses throughput efficiency, yet only mentions 'latency' a total of nine times and this in spite of the motivation that interactive traffic being sensitive to delay and degradation. I found a reference to Amoeba [2] which explores precisely this issue: aside from data volume, a user can also specify a completion deadline and the system has a mechanism to guarantee these requirements are met whilst also maintaining high utilization. The full paper is not yet available but it will be presented at EuroSysnext week. 4. This is a very good piece of work, the paper is thorough in its coverage and packed with findings and results:
a. Motivating examples can be readily understood so even without understanding the technique you get a sense of what even makes this possible and why global optima are better than local and greedy choices. b. All this is based on commodity switches, which also entails dealing with capacity limits on forwarding rules and the need to provide consistency for updates and the paper also addresses these in ample detail. c. Multistage rule updates are especially ingenious and a clear extension over the previous baseline: a year earlier another SIGCOMM paper proposed 50% slack, where this only uses 10% scratch space and can covers 95% of cases with a twostage update. = References = [1] http://www.cs.cornell.edu/~jnfoster/papers/merlin.pdf [2] http://dl.acm.org/citation.cfm?id=2741957 [3] http://web.engr.illinois.edu/~cyhong/pub/SWANtalk.pdf
Birkner, Rüdiger 1. The paper introduces a method of reconfiguring the data plane without causing any congestion or disruptions. This is not only useful for WANs, but for any network in which many switches have to be updated and the timing of the updates is not deterministic. 2. By centralizing the traffic engineering in the SWAN controller, instead of relying on greedy path selection in each router, it is possible to offer SLA support. In addition, knowing some the traffic patterns and characteristics (e.g. priority, bandwidth) allows to increase the utilization of the links while offering the same service. However, this is only possible, when operating the networks, data centers and the services. 3. SWAN takes the limited forwarding table sizes into account and strives for an optimal solution respecting those limitations. Future SDN switches will most likely allow for more forwarding rules and therefore, even better utilization of the network might be possible. Yu, Xinyuan 1. Is the condition of congestionfree so strict? Moderate congestion may not affect so much. If moderate congestion is tolerated, is it possible to have a better overall performance?
2. Although it provides detailed experiment, it still needs to be figured out how the performance will change, if we have nextgeneration SDN switches, for example, the network’s capacity is improved much. 3. Is swan has much wider using scenario except from interDC network, if we change to different sets of priority level, for example in other autonomous systems?
Defense
Pappas, Christos In my opinion, the value of the SWAN paper lies in its practicality: the described techniques have been applied in practice in order to provide benefits to operators, hence, the benefits are not only claimed, but also demonstrated. Specifically, SWAN addresses the inefficiencies of MPLSTE and has following interesting characteristics: 1. The centralized global view of the network (that the distributed nature of MPLSTE does not have) allows to make coordinated decisions. The global view contains not only topology information, but is enriched with traffic demands from the latency tolerant services. The enriched knowledge base extends the decisions to new dimensions (apart from the normal ones like failure handling); the controller can create paths, assign them to services, and instruct ratelimits for services Two practical problems regarding the forwarding plane are addressed: 2. Applying the controlplane decisions in the data plane, in such a way that no traffic is dropped during the updates. To achieve this, scratch capacity is set aside (not strictly), which allows to transition from the initial configuration to the final one, in a number of steps; the number is bounded by a function of the scratch capacity. This gives operators a tunable parameter regarding updating state. 3. The other data plane problem, is flowrule capacity at switches. This is another constraint when making updates. To solve this problem, an LP problem is formed and solved to respect the restrictions from the underlying hardware in the data plane.
Schmid, Stefan The paper introduces a softwaredriven WAN to optimize link utilization between data centers. In order to reach their goal, different challenges are identified and solutions presented: service rate allocation updating forwarding state (congestionfree) number of rules optimization (to fit into SDN switch flow table)
overall SWAN design 1. All these topics could fill a paper by themselves. It seems like the authors try to solve everything at once. It might be more useful to focus on one problem at a time and investigate further, describe in more details and also provide more results. Further there are only a few testbed experiment results shown. It would have been more interesting to show more testbed measurements, even compare them to other solutions and implementations instead of showing simulation results. 2. The authors suggest to reserve slack bandwidth for forwarding state updates to prevent congestion during updates. It is proven that new routes are established in maximum up to ceil(1/s)1 steps. Are all these intermediate steps guaranteed to be loop free? To not waste the slack bandwidth when there are no route updates, background traffic can occupy this leftover link capacity. To still guarantee to finish route updates within the bound number of steps some fraction of background traffic will be lost. Shortening the update cycle will therefore also lead to more background traffic loss. 3. The authors do not mention what their strategy in deploying such a WAN would look like. Gradually replacing switches in the network might disrupt service and not lead to any advantages in link utilization. The presented performance improvements might only show when fully deployed. The system also only relays on one backup controller which does not maintain network state. The backup controller needs to acquire the network state before being able to configure and update routes. During this time, service might be disrupted.
Lee, TaeHo 1. The paper says that interactive flows are not regulated since they are delaysensitive. In addition, the paper argues that interactive flows are overestimated using past history to account for unexpected increase in interactive flows. However: * Can sudden increase in interactive flows create problems (e.g., congestion) to elastic class traffic? * How much should it be overestimated? How accurate would be the measurement using the past history? 2. Paper does not justify some of the parameters (e.g., T_h=10 seconds for demand estimation, T_s=5 minutes for service broker to update the controller). Why are these settings realistic or sufficient? 3. For flows in service priority classes other than interactive, they may need to wait up to T_s before the flows can be allowed to transmit. Is this design reasonable?As paper mentions, some flows are less tolerant of delay than others. How can the proposal cope with this variance in delay requirements between different flows?
4. How steady are the traffic volumes/demands? The paper assumes that the past history/statistics can be used to estimate traffic volume/demand. Is this accurate or sufficient? What about bursts?
Schinde, Pravin
*** Advantages Trying to solve the problem of deterministic QoS for connections in presence of other bandwidth hungry background flows Globally allocating the resources, controlling the sending rates at the hosts Based on current conditions SWAN decides how much traffic each service can send, and configures the network to carry that traffic. They tackle the hard problem of congestion free topology changes by modifying the rules in stages, and making sure that there is always enough breading space for such rule modifications They optimize the system for number of forwarding entries available in the hardware. They expose the treadoff between quick solution and suboptimal solution. *** Limitations The network they are targeting is the backbone network to connect datacenters. I would guess that switching hardware used in such a setup would be fairly highend, and hence should not have low limits on hardware forwarding entries supported So, I am not sure if optimization for number of forwarding entries is that important for this situation. Most probably this is a bias on my side, but this seems quite similar to problems that Dragonet tries to solve. Here system is trying to efficiently use available hardware forwarding rules while providing QoS to applications.
van Genlder, Jasper 1. Correct me if I am wrong but choosing SWAN means you should implement it for your whole application stack, Otherwise might end up in scenarios that you webservice is asking SWAN for more bandwidth and then shifting the bottleneck to the connection of the webservice and databaseservice but the databaseservice is not aware of SWAN and can thus not ask for more bandwidth. 2. For this to work almost whole your chain in the network must speak "SWAN" (from the service broker up to the swan controller). But not only that with only one service you cannot leverage the benefits yet you need to have more services running SWAN in order to reap the benefits of calculating the best paths. This means you would have to overhaul your whole network in order to leverage the benefits of SWAN. 3. Something that confused me was: " Further, hosts stop sending traffic when they are unable to contact the (primary and secondary) service broker " does that mean the hosts
also know SWAN ? because this would have an even larger impact and then you either go all in on SWAN or you do not. 4. I further think the paper is well written allot of technical details and allot or problems are covered. This also meant it was a lot of information to comprehend, but I yet have to see whether it is feasible to implement it in a real environment.
