idnits 2.17.1 draft-dujovne-6tisch-on-the-fly-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 148: '... computed is out of the scope. It MAY...' RFC 2119 keyword, line 294: '...nning within OTF MUST be event-oriente...' RFC 2119 keyword, line 420: '...ber and the parameters MUST be invoked...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 4, 2015) is 3400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 504, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 510, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-02 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-04 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-04 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH D. Dujovne, Ed. 3 Internet-Draft Universidad Diego Portales 4 Intended status: Informational LA. Grieco 5 Expires: July 8, 2015 Politecnico di Bari 6 MR. Palattella 7 University of Luxembourg 8 N. Accettura 9 University of California Berkeley 10 January 4, 2015 12 6TiSCH On-the-Fly Scheduling 13 draft-dujovne-6tisch-on-the-fly-04 15 Abstract 17 This document describes the environment, problem statement, and goals 18 of On-The-Fly (OTF) scheduling, a Layer-3 mechanism for 6TiSCH 19 networks. The purpose of OTF is to dynamically adapt the aggregate 20 bandwidth, i.e., the number of reserved soft cells between neighbor 21 nodes, based on the specific application constraints to be satisfied. 22 When using OTF, softcell and bundle reservation is distributed: 23 through the 6top interface, neighbor nodes negotiate the cell(s) to 24 be (re)allocated/deleted, with no intervention needed of a 25 centralized entity. This document aims at defining a module which 26 uses the functionalities provided by the 6top sublayer to (i) extract 27 statistics and (ii) determine when to reserve/delete soft cells in 28 the schedule. The exact reservation and deletion algorithm, and the 29 number and type of statistics to be used in the algorithm are out of 30 scope. OTF deals only with the number of softcells to be reserved/ 31 deleted; it is up to 6top to select the specific soft cells within 32 the TSCH schedule. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 8, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Allocation policy . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Allocation methods . . . . . . . . . . . . . . . . . . . . . 4 70 4. Cell and Bundle Reservation/Deletion . . . . . . . . . . . . 5 71 5. Getting statistics and other information about cells through 72 6top . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6. Events triggering algorithms in OTF . . . . . . . . . . . . . 7 74 7. Bandwidth Estimation Algorithms . . . . . . . . . . . . . . . 8 75 8. OTF external CoAP interface . . . . . . . . . . . . . . . . . 9 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Informative References . . . . . . . . . . . . . . . . . 11 79 10.2. External Informative References . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an 85 amendment to the Medium Access Control (MAC) protocol defined by the 86 IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel 87 Hopping (TSCH) mode of IEEE802.15.4e is the object of this document. 89 On-The-Fly (OTF) scheduling is a 1-hop protocol with which a node 90 negotiates the number of soft cells scheduled with its neighbors, 91 without requiring any intervention of a centralized entity (e.g., a 92 PCE). This document describes the OTF allocation policies and 93 methods used by two neighbors to allocate one or more softcells in a 94 distribution fashion. It also proposes an algorithm for estimating 95 the required bandwidth (BW). This document defines the interface 96 between OTF and the 6top sublayer ([I-D.wang-6tisch-6top]), to 97 collect and retrieve statistics, or allocate/delete cells and 98 bundles. This document defines a framework; the algorithm and 99 statistics used are out of scope. This draft follows the terminology 100 defined in [I-D.ietf-6tisch-terminology] and addresses the open issue 101 related to the scheduling mechanisms raised in 102 [I-D.ietf-6tisch-tsch]. 104 2. Allocation policy 106 OTF is a distributed scheduling protocol which increases/decreases 107 the bandwidth between two neighbor nodes (i.e., adding/deleting soft 108 cells) by interacting with the 6top sublayer. It retrieves 109 statistics from 6top, and uses that information to trigger 6top to 110 add/delete softcells to a particular neighbor. The algorithm which 111 decides when to add/delete softcells is out of scope. For example, 112 6top might decide to add a cell if some queue of outbound frames is 113 overflowing. Similarly, OTF can delete cells when the queue has been 114 empty for some time. OTF only triggers 6top to add/delete the soft 115 cells, it is the responsibility of the 6top sublayer to determine the 116 exact slotOffset/channelOffset of those cells. In this document, the 117 term "cell" and "soft cell" are used interchangeably. 119 All the soft cells allocated are part of best effort track, i.e. with 120 TrackID=00, as defined in [I-D.wang-6tisch-6top]. These cells can be 121 used for forwarding any packet in the queue, regardless of the 122 specific track it belongs to. OTF manages the global bandwidth 123 requirements between two neighbor nodes; per-track management is 124 currently out of scope. 126 OTF is prone to schedule collisions. Nodes might not be aware of the 127 cells allocated by other pairs of nodes. A schedule collision occurs 128 when the same cell is allocated by different pairs in the same 129 interference space. The probability of having allocation collision 130 may be kept low by grouping cells into chunks (see 131 [I-D.ietf-6tisch-terminology] and [I-D.ietf-6tisch-architecture] for 132 more details). The use of chunks is outside the scope of this 133 current version of the OTF draft. 135 The "allocation policy" is the algorithm used by OTF to decide when 136 to increase/decrease the bandwidth allocated between two neighbor 137 nodes in order to satisfy the traffic requirements. These 138 requirements can be expressed in terms of throughput, latency or 139 other constraints. 141 This document introduces the following parameters for describing the 142 behavior of the OTF allocation policy: 144 SCHEDULEDCELLS: The amount of soft cells scheduled in a bundle on 145 the best effort track between two neighbors. 147 REQUIREDCELLS: Number of cells requested by OTF to 6top, a non- 148 negative value. How this is computed is out of the scope. It MAY 149 be an instantaneous request, or a value averaged on several 150 measurements. 152 OTFTHRESH: Threshold parameter introducing cell over-provisioning in 153 the allocation policy. It is a non-negative value expressed as 154 number of cells. Which value to use is application-specific and 155 out of scope. 157 The OTF allocation policy compares the number of required cells 158 against the number of scheduled ones, using the OTF threshold for 159 bounding the signaling overhead due to negotiations of new cells. In 160 details: 162 1. If REQUIREDCELLS is greater than SCHEDULEDCELLS, OTF asks 6top to 163 add one or more soft cells to the bundle on the best effort 164 track. 166 2. If REQUIREDCELLS is greater or equal than SCHEDULEDCELLS- 167 OTFTHRESH, and it is lower than or equal to SCHEDULEDCELLS, OTF 168 does not perform any bundle resizing, since the scheduled cells 169 are sufficient for managing the current traffic conditions. 171 3. If REQUIREDCELLS is lower than SCHEDULEDCELLS-OTFTHRESH, OTF asks 172 6top to delete one or more soft cells from the bundle on the 173 best-effort track. 175 When OTFTHRESH=0, any discrepancy between REQUIREDCELLS and 176 SCHEDULEDCELLS triggers a 6top negotiation of soft cells. Other 177 values for the OTFTHRESH over-provision the scheduled number of 178 cells, reducing the number of triggered 6top negotiations. 180 The number of soft cells to be scheduled/deleted for bundle resizing 181 is out of the scope of this document and implementation-dependant. 183 3. Allocation methods 185 Beyond the allocation policies that describe the approach used by OTF 186 for fulfilling the node bandwidth requests, the OTF framework also 187 includes Allocation Methods that specify how OTF issues commands to 188 the 6top sublayer. In other words, the allocation methods represent 189 the mechanisms that are used by the allocation policies. 191 In detail, OTF includes two distinct allocation methods: soft cell 192 and bundle allocation methods. Each Allocation Policy can use either 193 one or both allocation methods. As specified in 194 [I-D.wang-6tisch-6top], 6top provides a set of commands that allows 195 OTF to allocate/delete soft cells. The same set of commands can be 196 used for reserving bundles. 198 With the soft cell allocation method, OTF has 6top reserve a single 199 soft cell on the best effort track, for allowing a given node to 200 exchange traffic with a specific neighbor. The 6top layer allocates 201 and maintains this cell. If a bundle is already reserved between the 202 same pair of neighbors, on the same track, this request translates 203 into a bundle resize request. The newly allocated cell increases the 204 size of the already existing bundle. Similarly, when OTF realizes 205 there is a reduction of traffic exchanged between the two neighbors, 206 it may asks 6top to delete a softcell from the best effort track, 207 i.e. to decrease the size of the bundle on the best effort track. If 208 no bundle with TrackID=00 exists, the 6top softcell create command 209 generates a new bundle of size 1. 211 With the bundle allocation method, OTF sends bundle allocation 212 requests to the 6top sublayer, specifying the bundle size (the number 213 of soft cells) and the TrackID=00. Scheduling N softcells is 214 equivalent to asking for a bundle of size N. The cells within the 215 bundle are allocated by 6top (and thus, used for traffic exchange) 216 only afterwards, according to the nodes bandwidth need. 218 4. Cell and Bundle Reservation/Deletion 220 In order to reserve/delete softcells, OTF interacts with 6top 221 sublayer. To this aim OTF uses the following set of commands offered 222 by 6top: CREATE.softcell, and DELETE.softcell. When creating 223 (deleting) a softcell, OTF specifies the track the cell belongs to 224 (i.e., best effort track, TrackID=00), but not its slotOffset nor the 225 channelOffset. If at least one cell on the best effort track already 226 exists, the CREATE.softcell and DELETE.softcell, translate into 227 INCREASE and DECREASE the bundle size, respectively. 6top is 228 responsible for picking the specific cell to be added/deleted within 229 the bundle. Before being able to do so, source and destination nodes 230 go through a cell negotiation process. This process is out of scope 231 of 6top and OTF. In order to reserve a best effort bundle, OTF uses 232 the CREATE.softcell command, set TrackID=00, but asks 6top for 233 multiple softcells. Following OTF request, 6top either (i) creates a 234 new bundle, if no cells were reserved already on the best effort 235 track, or (ii) increases the bundle size of the already existing 236 best-effort bundle. By using the DELETE.softcell command, and asking 237 for deleting multiple softcells, OTF has 6top delete the entire best 238 effort bundle. 240 OTF provides a policy for 6top to generate CREATE/DELETE.softcells 241 commands, policy that is out of 6top scope [I-D.wang-6tisch-6top]. 242 Such policy is not the only one that can be used by 6top. Others may 243 be defined in the future. 245 5. Getting statistics and other information about cells through 6top 247 Statistics are kept in 4 data structures of 6top MIB: CellList, 248 MonitoringStatusList, NeighborList, and QueueList. 250 CellList provides per-cell statistics. From this list, an upper 251 layer can get per-bundle statistics. OTF may have access to the 252 CellList, by using the CoAP-YANG Model, but actually cell-specific 253 statistics are not significant to OTF, since softcells can be re- 254 allocated in time by 6top itself, based on network conditions. 256 MonitoringStatusList provides per-neighbor and slotframe statistics. 257 From it an upper layer (e.g., OTF) can get per bundle overview of 258 scheduling and its performance. Such list contains information about 259 the number of hard and soft cells reserved to a given node with a 260 specific neighbor, and the QoS (that can be expressed in form of 261 different metrics: PDR, ETX, RSSI, LQI) on the actual bandwidth, and 262 the over-provisioned bandwidth (which includes the over-provisioned 263 cells). 6top can use such list to operate 6top Monitoring Functions, 264 such as re-allocating cells (by changing their slotOffset and/or 265 channelOffset) when it finds out that the link quality of some 266 softcell is much lower than average. Unlike 6top, OTF does not 267 operate any re-allocation of cells. In fact, OTF can ask for more/ 268 less bandwidth, but cannot move any cell within the schedule. Thus, 269 the 6top Monitoring function is useful to OTF, because it can provide 270 better cells for a given bandwidth requirement, specified by OTF. 271 For instance, OTF may require some additional bandwidth (e.g. 2 cells 272 in a specific slotframe) with PDR = 75%; then, 6top will reserve 3 273 slots in the slotframe to meet the bandwidth requirement. In 274 addition, when the link quality drops to 50%, 6top will reserve 4 275 slots to keep meeting the bandwidth requirement. Given that OTF 276 operates on the global bandwidth between two neighbor nodes, it does 277 not need to be informed from 6top about cells' re-allocation. 279 NeighborList provides per-neighbor statistics. From it, an upper 280 layer can understand the connectivity of a pair of nodes. Based on 281 the quality of the link, e.g., LQI under threshold, OTF may ask 6top 282 to delete some cells, in order to reserve them for better-connected 283 links. 285 QueueList provides per-Queue statistics. From it, an upper layer can 286 know the traffic load. OTF, based on such queue statistics (e.g., 287 average length of the queue, average age of the packet in queue, 288 etc.) may trigger a 6top CREATE.softcell (DELETEsoftcell) command for 289 increasing (decreasing) the bandwidth and be able to better serve the 290 packets in the queue. 292 6. Events triggering algorithms in OTF 294 The Algorithms running within OTF MUST be event-oriented. As a 295 consequence, OTF requires to connect the algorithms with external 296 events to trigger their execution. The algorithm also generates one 297 or more events when it is executed, such as a new softcell 298 allocation. Both type of events, the one which triggers the 299 algorithm and the ones which are generated by the execution of the 300 algorithm are called OTF events. 302 The following notation is used on the definition of OTF events: 304 BW <- BWA(B,T,S(B,T)) where: 306 BWA: Bandwidth allocation algorithm 308 BW: Bandwidth 310 T: Best Effort Track 312 B: Bundle 314 S(B,T) Statistics for bundle B on track T 316 M(B,T): Actual bundle size for bundle B on track T 318 The OTF events are defined as: 320 Event A: A new bundle B on track T is created. The OTF events 321 generated by the algorithm are: 323 1. Add a new entry in the storage M for bundle B on track T. 325 2. Ask 6top for S(B,T). 327 3. BW <- BWA(B,T,S(B,T)). 329 4. Ask 6top to allocate a bundle of size BW. 331 5. M(B,T)<-BW. 333 Event B: A packet is waiting to be transmitted on any track, but no 334 cell is available (i.e., saturation). The OTF events generated by 335 the algorithm are: 337 1. Collect stats S(B,T) from 6top. 339 2. BW <- BWA(B,T,S(B,T))). 341 3. Ask 6top to increase the bundle size up to BW. 343 4. If (allocation successful) then M(B,T)<-BW. 345 Event C: The usage of a bundle B on track T is too low, below a pre- 346 established threshold. The OTF events generated by the algorithm 347 are: 349 1. Collect stats S(B,T) from 6top. 351 2. BW <- BWA(B,T,S(B,T)). 353 3. Ask 6top to decrease the bundle size to BW. 355 4. If (allocation successful) then M(B,T)<-BW. 357 Event D: The usage of a bundle B on track T is too high, above a pre- 358 established threshold. The OTF events generated by the algorithm 359 are: 361 1. Collect stats S(B,T) from 6top. 363 2. BW <- BWA(B,T,S(B,T)). 365 3. Ask 6top to increase the bundle size to BW. 367 4. If (allocation successful) then M(B,T)<-BW. 369 Event E: Bundle B on track T is deleted. The OTF events generated by 370 the algorithm are: 372 1. purge M(B,T). 374 7. Bandwidth Estimation Algorithms 376 OTF supports different bandwidth estimation algorithms that can be 377 used by a node in a 6TiSCH network for checking the current traffic 378 conditions and thus the actual bandwidth usage. By doing so, one can 379 adapt (increase or increase) the number of scheduled cells/bundles 380 for a given pair of neighbors (e.g., parent node and its child), 381 according to their needs. OTF supports several bandwidth estimation 382 algorithms numbered 0 to 255 in the OTF implementation. The first 383 algorithm (0) is reserved to the default algorithm that is described 384 below. By using SET and GET commands, one can set the specific 385 algorithm to be used, and get information about which algorithm is 386 implemented. 388 Steps of the default bandwidth estimation algorithm, running over a 389 parent node: 391 Step 1: Collect the bandwidth requests from child nodes (incoming 392 traffic). 394 Step 2: Collect the node bandwidth requirement from the application 395 (self/local traffic). 397 Step 3: Collect the current outgoing scheduled bandwidth (outgoing 398 traffic). 400 Step 4: If (outgoing < incoming + self) then SCHEDULE soft cells/ 401 bundles to satisfy bandwidth requirements. 403 Step 5: If (outgoing > incoming + self) then DELETE the soft cells 404 that are not used. 406 Step 6: Return to step 1. 408 The default bandwidth estimation algorithm introduced in this 409 document adopts a reactive allocation policy, i.e., it uses 410 OTFTHRESH=0. In this case, at Step 4, new soft cells will be 411 scheduled, using the cell allocation method, only if there are no 412 free cells in the bundle that can satisfy the current request of soft 413 cells. The node asks 6top for increasing the bundle size by using 414 the bundle allocation method. 416 8. OTF external CoAP interface 418 In order to select the current OTF algorithm and provide functional 419 parameters from outside OTF, this module uses CoAP with YANG as the 420 data model. The algorithm number and the parameters MUST be invoked 421 in different CoAP calls. 423 The path to select the algorithm is '6t/e/otf/alg' with A as the 424 algorithm number. 426 +------------------------------------------+ 427 Header | POST | 428 +------------------------------------------+ 429 Uri-Path| /6t/e/otf/alg | 430 +------------------------------------------+ 431 Options | CBOR( {AlgNo: 123} ) | 432 +------------------------------------------+ 434 Figure 1: Algorithm number POST message 436 To obtain the current algorithm number: 438 +------------------------------------------+ 439 Header | GET | 440 +------------------------------------------+ 441 Uri-Path| /6t/e/otf/alg | 442 +------------------------------------------+ 443 Options | Accept: application/cbor | 444 +------------------------------------------+ 446 Figure 2: Algorithm number GET message 448 An example is: 'coap://[aaaa::1]/6t/e/otf/alg' 450 The current algorithm parameter path is '6t/e/otf/alg/par'. 452 +------------------------------------------+ 453 Header | POST | 454 +------------------------------------------+ 455 Uri-Path| /6t/e/otf/alg/par | 456 +------------------------------------------+ 457 Options | CBOR( {Par: 0x1234} ) | 458 +------------------------------------------+ 460 Figure 3: Algorithm number POST message 462 An example follows: 'coap://[aaaa::1]/6t/e/otf/alg/par' 464 9. Acknowledgments 466 Special thanks to Prof. Kris Pister for his valuable contribution in 467 designing the default Bandwidth Estimation Algorithm, and to Prof. 468 Qin Wang for her support in defining the interaction between OTF and 469 6top sublayer. 471 Thanks to the Fondecyt 1121475 Project, to INRIA Chile "Network 472 Design" group and to the IoT6 European Project (STREP) of the 7th 473 Framework Program (Grant 288445). 475 10. References 477 10.1. Informative References 479 [I-D.ietf-6tisch-terminology] 480 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 481 "Terminology in IPv6 over the TSCH mode of IEEE 482 802.15.4e", draft-ietf-6tisch-terminology-02 (work in 483 progress), July 2014. 485 [I-D.ietf-6tisch-architecture] 486 Thubert, P., Watteyne, T., and R. Assimiti, "An 487 Architecture for IPv6 over the TSCH mode of IEEE 488 802.15.4e", draft-ietf-6tisch-architecture-04 (work in 489 progress), October 2014. 491 [I-D.ietf-6tisch-tsch] 492 Watteyne, T., Palattella, M., and L. Grieco, "Using 493 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 494 Statement and Goals", draft-ietf-6tisch-tsch-04 (work in 495 progress), December 2014. 497 [I-D.wang-6tisch-6top] 498 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 499 Operation Sublayer (6top)", draft-wang-6tisch-6top-00 500 (work in progress), October 2013. 502 10.2. External Informative References 504 [IEEE802154e] 505 IEEE standard for Information Technology, "IEEE std. 506 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 507 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 508 2012. 510 [IEEE802154] 511 IEEE standard for Information Technology, "IEEE std. 512 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 513 and Physical Layer (PHY) Specifications for Low-Rate 514 Wireless Personal Area Networks", June 2011. 516 Authors' Addresses 517 Diego Dujovne (editor) 518 Universidad Diego Portales 519 Escuela de Informatica y Telecomunicaciones 520 Av. Ejercito 441 521 Santiago, Region Metropolitana 522 Chile 524 Phone: +56 (2) 676-8121 525 Email: diego.dujovne@mail.udp.cl 527 Luigi Alfredo Grieco 528 Politecnico di Bari 529 Department of Electrical and Information Engineering 530 Via Orabona 4 531 Bari 70125 532 Italy 534 Phone: 00390805963911 535 Email: a.grieco@poliba.it 537 Maria Rita Palattella 538 University of Luxembourg 539 Interdisciplinary Centre for Security, Reliability and Trust 540 4, rue Alphonse Weicker 541 Luxembourg L-2721 542 LUXEMBOURG 544 Phone: (+352) 46 66 44 5841 545 Email: maria-rita.palattella@uni.lu 547 Nicola Accettura 548 University of California Berkeley 549 Berkeley Sensor & Actuator Center 550 490 Cory Hall 551 Berkeley, California 94720 552 USA 554 Email: nicola.accettura@eecs.berkeley.edu