idnits 2.17.1 draft-cfb-ippm-spinbit-new-measurements-01.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 abstract seems to contain references ([I-D.trammell-ippm-spin]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 1, 2019) is 1760 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group M. Cociglio 3 Internet-Draft Telecom Italia 4 Intended status: Experimental G. Fioccola 5 Expires: January 2, 2020 Huawei Technologies 6 F. Bulgarella 7 R. Sisto 8 Politecnico di Torino 9 July 1, 2019 11 New Spin bit enabled measurements with one or two more bits 12 draft-cfb-ippm-spinbit-new-measurements-01 14 Abstract 16 This document introduces additional measurements by using the same 17 spin bit signal as defined in [I-D.trammell-ippm-spin]. The spin bit 18 signal alone is not enough to evaluate correctly in every network 19 condition the RTT of a flow. In order to solve this problem, it is 20 theorized the possibility of introducing an additional validation 21 signal called delay bit, similar to what is done done by the Valid 22 Edge Counter (VEC), but using just one bit instead of two. An 23 alternative with two bits is also introduced with a so called loss 24 bit. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 2, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Spin bit and Delay bit mechanism . . . . . . . . . . . . . . 3 68 2.1. Delay Sample generation . . . . . . . . . . . . . . . . . 5 69 2.1.1. The recovery process . . . . . . . . . . . . . . . . 5 70 2.2. Delay Sample reflection . . . . . . . . . . . . . . . . . 6 71 3. Using the Spin bit and Delay bit for Hybrid RTT Measurement . 7 72 3.1. End-to-end RTT measurement . . . . . . . . . . . . . . . 7 73 3.2. Half-RTT measurement . . . . . . . . . . . . . . . . . . 7 74 3.3. Intra-domain RTT measurement . . . . . . . . . . . . . . 7 75 4. Observer's algorithm and Waiting Interval . . . . . . . . . . 8 76 5. Adding a Loss bit to Delay bit and Spin bit . . . . . . . . . 9 77 6. Round Trip Packet Loss measurement . . . . . . . . . . . . . 9 78 6.1. RTT dependent Packet Loss using one bit . . . . . . . . . 10 79 6.2. RTT independent Packet Loss using two bits . . . . . . . 10 80 7. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 7.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 11.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 [I-D.trammell-ippm-spin] defines an explicit per-flow transport-layer 94 signal for hybrid measurement of end-to-end RTT. This signal 95 consists of three bits: a spin bit, which oscillates once per end-to- 96 end RTT, and a two-bit Valid Edge Counter (VEC), which compensates 97 for loss and reordering of the spin bit to increase fidelity of the 98 signal in less than ideal network conditions. 100 In this document it is introduced the delay bit, that is a single bit 101 signal that can be used together with the spin bit by passive 102 observers to measure the RTT of a network flow, avoiding the spin bit 103 ambiguities that arise as soon as network conditions deteriorate. 104 Unlike the spin bit, which is actually set in every packet 105 transmitted on the network, the delay bit is set only once per round 106 trip. 108 This document defines a hybrid measurement RFC 7799 [RFC7799] path 109 signal to be embedded into a transport layer protocol, explicitly 110 intended for exposing end-to-end RTT to measurement devices on path. 112 The document introduces a mechanism applicable to any transport-layer 113 protocol, then explains how to bind the signal to a variety of IETF 114 transport protocols, and in particular to QUIC and TCP. 116 The application of the Spin bit to QUIC is described in 117 [I-D.ietf-quic-spin-exp] which adds the spin bit only (without the 118 VEC) to QUIC for experimentation purposes. 120 Note that both the spin bit and the delay bit are inspired by RFC 121 8321 [RFC8321]. This is also mentioned in [I-D.trammell-quic-spin]. 123 2. Spin bit and Delay bit mechanism 125 The main idea is to have a single packet, with a second marked bit 126 (the delay bit), that bounces between client and server during the 127 entire connection life. This single packet is called Delay Sample. 129 A simple observer placed in an intermediate point, tracking the delay 130 sample and the relative timestamp in every spin bit period, can 131 measure the end-to-end round trip delay of the connection. In the 132 same way as seen with the spin bit and the VEC, it is possible to 133 carry out other types of measurements. The next paragraphs give an 134 overview of the observer capabilities. 136 In order to describe the delay sample working mechanism in detail, we 137 have to distinguish two different phases which take part in the delay 138 bit lifetime: initialization and reflection. The initialization is 139 the generation of the delay sample, while the reflection realizes the 140 bounce behavior of this single packet between the two endpoints. 142 The next figure describes the Delay bit mechanism: the first bit is 143 the spin bit and the second one is the delay bit. 145 +--------+ -- -- -- -- -- +--------+ 146 | | -----------> | | 147 | Client | | Server | 148 | | <----------- | | 149 +--------+ -- -- -- -- -- +--------+ 151 (a) No traffic at beginning. 153 +--------+ 00 00 01 -- -- +--------+ 154 | | -----------> | | 155 | Client | | Server | 156 | | <----------- | | 157 +--------+ -- -- -- -- -- +--------+ 159 (b) The Client starts sending data and 160 sets the first packet as Delay Sample. 162 +--------+ 00 00 00 00 00 +--------+ 163 | | -----------> | | 164 | Client | | Server | 165 | | <----------- | | 166 +--------+ -- -- 01 00 00 +--------+ 168 (c) The Server starts sending data 169 and reflects the Delay Sample. 171 +--------+ 10 10 11 00 00 +--------+ 172 | | -----------> | | 173 | Client | | Server | 174 | | <----------- | | 175 +--------+ 00 00 00 00 00 +--------+ 177 (d) The Client inverts the spin bit and 178 reflects the Delay Sample. 180 +--------+ 10 10 10 10 10 +--------+ 181 | | -----------> | | 182 | Client | | Server | 183 | | <----------- | | 184 +--------+ 00 00 11 10 10 +--------+ 186 (e) The Server reflects the Delay Sample. 188 +--------+ 00 00 01 10 10 +--------+ 189 | | -----------> | | 190 | Client | | Server | 191 | | <----------- | | 192 +--------+ 10 10 10 10 10 +--------+ 193 (f) The client reverts the spin 194 bit and reflects the Delay Sample. 196 Figure 1: Spin bit and Delay bit 198 2.1. Delay Sample generation 200 During this first phase, endpoints play different roles. First of 201 all a single delay sample must be bouncing per round trip period (and 202 so per spin bit period). According to that statement and in order to 203 simplify the general algorithm, the delay sample generation is in 204 charge of just one of the two endpoints: 206 o the Client, when connection starts and spin bit is set to 0, 207 initializes the delay bit of the first packet to 1, so it becomes 208 the delay sample for that marking period. Only this packet is 209 marked with the delay bit set to 1 for this round trip period; the 210 other ones will carry only the spin bit; 212 o the server never initializes the delay bit to 1; its only task is 213 to reflect the incoming delay bit into the next outgoing packet 214 only if certain conditions occur. 216 Theoretically, in absence of network impairments, the delay sample 217 should bounce between client and server continuously, for the entire 218 duration of the connection. Actually, that is highly unlikely mainly 219 for two different reasons: 221 1) the packet carrying the delay bit might be lost during its journey 222 on the network which is unreliable by definition; 224 2) one of the two endpoints could stop or delay sending data because 225 the application is limiting the amount of traffic transmitted; 227 To deal with these problems, the algorithm provides a procedure to 228 regenerate the delay sample and to inform a possible observer that a 229 problem has occurred, and then the measurement has to be restarted. 231 2.1.1. The recovery process 233 In order to relieve the server from tasks that go beyond the mere 234 reflection of the sample, even in this case the recovery process 235 belongs to the client. A fundamental assumption is that a delay 236 sample is strictly related to its spin bit period. Considering this 237 rule, the client verifies that every spin bit period ends with its 238 delay sample. If that does not happen and a marking period 239 terminates without a delay sample, the client waits a further empty 240 period; then, in the following period, it reinitializes the mechanism 241 by setting the delay bit of the first outgoing packet to 1, making it 242 the new delay sample. The empty period is needed to inform the 243 intermediate points that there was an issue and a new delay 244 measurement session is starting. 246 2.2. Delay Sample reflection 248 The reflection is the process that enables the bouncing of the delay 249 sample between client and server. The behavior of the two endpoints 250 is slightly different. With the exception of the client that, as 251 previously exposed, generates a new delay sample, by default the 252 delay bit is set to 0. 254 Server side reflection: when a packet with the delay bit set to 1 255 arrives, the server marks the first packet in the opposite direction 256 as the delay sample, if it has the same spin bit value. While if it 257 has the opposite spin bit value this sample is considered lost. 259 Client side reflection: when a packet with delay bit set to 1 260 arrives, the client marks the first packet in the opposite direction 261 as the delay sample, if it has the opposite spin bit value. While if 262 it has the same spin bit value this sample is considered lost. 264 In both cases, if the outgoing marked packet is transmitted with a 265 delay greater than a predetermined threshold after the reception of 266 the incoming delay sample (1ms by default), reflection is aborted and 267 this sample is considered lost. 269 It is noteworthy that differently from what happens with the VEC for 270 which the reflection always concerns the edge of the period, in this 271 case reflection takes place for the packet that is carrying the delay 272 bit regardless of its position within the period. For this reason it 273 is necessary to introduce that condition of validation in order to 274 identify and discard those samples that, due to reordering, might 275 move to a contiguous period. Furthermore, by introducing a threshold 276 for the retransmission delay of the sample, it is possible to 277 eliminate all those measurements which, due to lack of traffic on the 278 endpoints, would be overestimated and not true. Thus, the maximum 279 estimation error, without considering any other delays due to flow 280 control, would amount to twice the threshold (e.g. 2ms) per 281 measurement, in the worst case. 283 3. Using the Spin bit and Delay bit for Hybrid RTT Measurement 285 Unlike what happens with the spin bit for which it is necessary to 286 validate or at least heuristically evaluate the goodness of an edge, 287 the delay sample can be used by an intermediate observer as a simple 288 demarcator between a period and the following one eliminating the 289 ambiguities on the calculation of the RTT found with the analysis of 290 the spin-bit only. The measurement types, that can be done from the 291 observation of the delay sample, are exactly the same achievable with 292 the spin bit only (with or without the VEC). 294 3.1. End-to-end RTT measurement 296 The delay sample generation process ensures that only one packet 297 marked with the delay bit set to 1 runs back and forth on the wire 298 between two endpoints per round trip time. Therefore, in order to 299 determine the end-to-end RTT measurement of a QUIC flow, an on-path 300 passive observer can simply compute the time difference between two 301 delay samples observed in a single direction. Note that a 302 measurement, to be valid, must take into account the difference in 303 time between the timestamps of two consecutive delay samples 304 belonging to adjacent spin-bit periods. For this reason, an 305 observer, in addition to intercepting and analyzing the packets 306 containing the delay bit set to 1, must maintain awareness of each 307 spin period in such a way as to be able to assign each delay sample 308 to its period and, at the same time, identifying those periods that 309 do not contain it. 311 3.2. Half-RTT measurement 313 An on-path passive observer that is sniffing traffic in both 314 directions -- from client to server and from server to client -- can 315 also use the delay sample to measure "upstream" and "downstream" RTT 316 components. Also known as the half-RTT measurement, it represents 317 the components of the end-to-end RTT concerning the paths between the 318 client and the observer (upstream), and the observer and the server 319 (downstream). It does this by measuring the delay between a delay 320 sample observed in the downstream direction and the one observed in 321 the upstream direction, and vice versa. Also in this case, it should 322 verify that the two delay samples belong to two adjacent periods, for 323 the upstream component, or to the same period for the downstream 324 component. 326 3.3. Intra-domain RTT measurement 328 Taking advantage of the half-RTT measurements it is also possible to 329 calculate the intra-domain RTT which is the portion of the entire RTT 330 used by a QUIC flow to traverse the network of a provider (or part of 331 it). To achieve this result two observers, able to watch traffic in 332 both directions, must be employed simultaneously at ingress and 333 egress of the network to be measured. At this point, to determine 334 the delay between the two observers, it is enough to subtract the two 335 computed upstream (or downstream) RTT components. 337 The spin bit is an alternate marking generated signal and the only 338 difference than RFC 8321 [RFC8321] is the size of the alternation 339 that will change with the flight size each RTT. So it can be useful 340 to segment the RTT and deduce the contribution to the RTT of the 341 portion of the network between two on-path observers and it can be 342 easily performed by calculating the delay between two or more 343 measurement points on a single direction by applying RFC 8321 344 [RFC8321]. 346 4. Observer's algorithm and Waiting Interval 348 Given below is a formal summary of the functioning of the observer 349 every time a delay sample is detected. A packet containing the delay 350 bit set to 1: 352 o if it has the same spin bit value of the current period and no 353 delay sample was detected in the previous period, then it can be 354 used as a left edge (i.e., to start measuring an RTT sample), but 355 not as a right edge (i.e., to complete and RTT measurement since 356 the last edge). If the observation point is symmetric (i.e., it 357 can see both upstream and downstream packets in the flow) and in 358 the current period a delay sample was detected in the opposite 359 direction (i.e., in the upstream direction), the packet can also 360 be used to compute the downstream RTT component. 362 o if it has the same spin bit value of the current period and a 363 delay sample was detected in the previous period, then it can be 364 used at the same time as a left or right edge, and to compute RTT 365 component in both directions. 367 Like stated previously, every time an empty period is detected, the 368 observer must restart the measurement process and consider the next 369 delay sample that will come as the beginning of a new measure, then 370 as a left edge. As a result, being able to assign the delay sample 371 to the corresponding spin period becomes a crucial factor for the 372 proper functioning of the entire algorithm. 374 Considering that the division into periods is realized by exploiting 375 the spin bit square wave, it is easy to understand that the presence 376 of spurious spin edges -- caused by packet reordering -- would 377 inevitably lead the observer to overestimate the amount of periods 378 actually present in the transmission. This results in a greater 379 number of empty periods detected and the consequent decrease of the 380 actual RTT samples achievable. Therefore, in order to maximize the 381 performance of the whole algorithm, the observer must implement a 382 mechanism to filter out spurious spin edges. 384 To face this problem the waiting interval has to be introduced. 385 Basically, every time a spin bit edge is detected, the observer sets 386 a time interval during which it rejects every potential spurious 387 edges observed on the wire. While, at the end of the interval it 388 starts again to accept changes in the spin bit value. This 389 guarantees a proper protection against the spurious edges in relation 390 to the size of the interval itself. For instance, an interval of 5ms 391 is able to filter out edges that have been reordered by a maximum of 392 5ms. Clearly, the mechanism does its job for intervals smaller than 393 the RTT of the observed connection (if RTT is smaller than the 394 waiting interval the observer can't measure the RTT). 396 5. Adding a Loss bit to Delay bit and Spin bit 398 It is possible to introduce a mechanism to evaluate also the packet 399 loss together with the delay measurement. In particular, the Client 400 can select and mark a train of packets for this purpose, by using a 401 loss bit, additionally to the spin bit and delay bit. 403 These packets bounce between Client and Server to complete two rounds 404 and an Observer counts the marked packets during the two rounds and 405 compares the counters to find Round Trip(RT) losses. 407 The problem to be solved is to choose the right number of packets to 408 mark to avoid marked packets congestion on the slowest traffic 409 direction. But the solution is simple, because it is enough to 410 choose the number of packets that transit on the slowest direction 411 during an RTT. 413 6. Round Trip Packet Loss measurement 415 The Client generates a train of marked packets (Packet Loss Samples) 416 by using the additional bit called Loss bit. The marked packets are 417 generated at the slowest direction rate (only when a packet arrives 418 the Client marks an outgoing packet). The Server reflects these 419 packets accordingly and, as a consequence, it could insert some not- 420 marked packets. Then the client reflects the marked packets and the 421 server reflects the marked packets again. The Client generates a new 422 train of marked packets and so on. 424 The Packet Loss calculation can be made after the comparison of 425 counters taken by the on-path passive observer. Indeed the Observer 426 in the middle (upstream or downstream) sees the packet train twice 427 and so it calculates the Observer Round Trip Packet Loss that, 428 statistically, will be equal to the end-to-end Round Trip Packet 429 Loss. So this measurement can be simply referred as Round Trip 430 Packet Loss (RTPL). 432 In addition, this methodology allows Half-RTPL measurement and Intra- 433 domain RTPL measurement, in the same way as described in the previous 434 Sections for RTT measurement. 436 The method allows the packet loss calculation for a portion of the 437 traffic but it is useful to perform RT Packet Loss measurement that 438 gives useful information coupled with RTT. 440 6.1. RTT dependent Packet Loss using one bit 442 Using a single bit in addition to the spin bit and delay bit enables 443 passive measurability of the end-to-end round-trip loss rate. 445 The algorithm requires a mechanism to individually identify each 446 train of packets in order to enable the observer to distinguish 447 between trains belonging to different rounds. This is achieved by 448 introducing a temporal pause of 2*RTT duration during which no marked 449 packets are forwarded. Marked packets are generated by the client 450 for the duration of an RTT in order to be synchronized with the spin 451 bit algorithm and to have a sufficient numbers of marked packets. 453 However, this single bit methodology replies and exposes the RTT of 454 the connection in any case, when the spin bit and the delay bit are 455 used and when these are disabled. 457 6.2. RTT independent Packet Loss using two bits 459 An RTT independent version of this algorithm requires two bits and 460 can be used when both spin bit and delay bit are disabled.This 461 implies that an observer must be able to determine whether the spin 462 bit is active and correctly spinning or not (choosing, accordingly, 463 the right version of packet loss measurement to be used). 465 Without using the spin bit, it is difficult to find the right pause 466 duration but, with a two bits packet loss field, the temporal pause 467 necessary to distinguish the different train of packets is no longer 468 needed. That's because packets generated and reflected by the client 469 are marked using two different marking values. Furthermore, instead 470 of generating marked packets for the duration of an RTT, a fixed 471 duration for the generation phase can be used (e.g. 100ms). 473 In this way, no information related to the RTT of the connection is 474 transmitted on the wire. 476 7. Protocols 478 7.1. QUIC 480 The binding of this signal to QUIC is partially described in 481 [I-D.ietf-quic-spin-exp], which adds the spin bit only to QUIC. 483 From an implementation point of view, the delay bit is placed in the 484 partially unencrypted (but authenticated) QUIC header, alongside the 485 spin bit, occupying one of the two bits left reserved for future 486 experiments. As things stand, according to 487 [I-D.ietf-quic-transport], the proposed scheme of the first header's 488 byte would be 01SDRKPP. 490 7.2. TCP 492 The signal can be added to TCP by defining bit 4 of bytes 13-14 of 493 the TCP header to carry the spin bit, and eventually bits 5 and 6 to 494 carry additional information, like the delay bit and the loss bit. 496 8. Security Considerations 498 The privacy considerations for the hybrid RTT measurement signal are 499 essentially the same as those for passive RTT measurement in general. 501 9. Acknowledgements 503 tbc 505 10. IANA Considerations 507 tbc 509 11. References 511 11.1. Normative References 513 [I-D.ietf-quic-spin-exp] 514 Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin 515 Bit", draft-ietf-quic-spin-exp-01 (work in progress), 516 October 2018. 518 [I-D.ietf-quic-transport] 519 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 520 and Secure Transport", draft-ietf-quic-transport-20 (work 521 in progress), April 2019. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, 525 DOI 10.17487/RFC2119, March 1997, 526 . 528 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 529 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 530 May 2016, . 532 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 533 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 534 "Alternate-Marking Method for Passive and Hybrid 535 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 536 January 2018, . 538 11.2. Informative References 540 [I-D.trammell-ippm-spin] 541 Trammell, B., "An Explicit Transport-Layer Signal for 542 Hybrid RTT Measurement", draft-trammell-ippm-spin-00 (work 543 in progress), January 2019. 545 [I-D.trammell-quic-spin] 546 Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, 547 T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit 548 Passive Measurability of Two-Way Latency to the QUIC 549 Transport Protocol", draft-trammell-quic-spin-03 (work in 550 progress), May 2018. 552 Authors' Addresses 554 Mauro Cociglio 555 Telecom Italia 556 Via Reiss Romoli, 274 557 Torino 10148 558 Italy 560 Email: mauro.cociglio@telecomitalia.it 562 Giuseppe Fioccola 563 Huawei Technologies 564 Riesstrasse, 25 565 Munich 80992 566 Germany 568 Email: giuseppe.fioccola@huawei.com 569 Fabio Bulgarella 570 Politecnico di Torino 572 Email: fabio.bulgarella@guest.telecomitalia.it 574 Riccardo Sisto 575 Politecnico di Torino 576 Corso Duca degli Abruzzi, 24 577 Torino 10129 578 Italy 580 Email: riccardo.sisto@polito.it