idnits 2.17.1 draft-wagner-conex-credit-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2013) is 3942 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ConEx Working Group D. Wagner 3 Internet-Draft M. Kuehlewind 4 Intended status: Informational University of Stuttgart 5 Expires: January 13, 2014 July 12, 2013 7 ConEx Crediting and Auditing 8 draft-wagner-conex-credit-00 10 Abstract 12 Congestion Exposure (ConEx) is a mechanism by which senders inform 13 the network about the congestion encountered by previous packets on 14 the same flow. In order to make ConEx information useful, reliable 15 auditing is necessary to provide a strong incentive to declare ConEx 16 information honestly. However, there is always a delay between 17 congestion events and the respective ConEx signal at the audit. To 18 avoid state and complex Round-Trip Time estimations at the audit, in 19 [draft-ietf-conex-abstract-mech] it is proposed to use credit signals 20 sent in advance to cover potential congestion in the next feedback 21 delay duration. Unfortunately, introducing credit does not provide 22 incentives to honestly report congestion. This document lists 23 potential issues regarding the proposed crediting and discusses 24 potential solutions approaches to interpret and handle credits at the 25 audit. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 13, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. No incentives to conceal congestion by sending credits . 3 65 2.2. Handling Loss of ConEx-marked Packets . . . . . . . . . . 4 66 2.3. Independence from Audit State . . . . . . . . . . . . . . 4 67 2.4. Assumption on Distance between Congestion Events . . . . 4 68 3. Potential Credit Definition and Auditing Approaches . . . . . 4 69 3.1. Basic Audit Reference Implementation . . . . . . . . . . 5 70 3.2. Credit As Congestion Substitute . . . . . . . . . . . . . 6 71 3.3. Credit As Congestion Surcharge . . . . . . . . . . . . . 6 72 3.3.1. BDP-Scaled Surcharge . . . . . . . . . . . . . . . . 7 73 3.4. Credit As Short-Lived Congestion Risk Compensation . . . 8 74 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 7.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 In order to make ConEx information useful, reliable auditing is 85 necessary to provide a strong incentive to declare ConEx information 86 honestly. However, there is always a delay between congestion events 87 and the respective ConEx signal at the audit. To avoid state and 88 complex Round-Trip Time (RTT) estimations at the audit, in 89 [draft-ietf-conex-abstract-mech] it is proposed to use credit signals 90 sent in advance to cover potential congestion in the next feedback 91 delay duration. 93 The ConEx signal is based on loss or Explicit Congestion Notification 94 (ECN) marks [RFC3168] as a congestion indication. Following 95 [draft-ietf-conex-abstract-mech] (Section 4.4), ConEx signaling has 96 to encode ConEx capability, Re-Echo-Loss (L), Re-Echo-ECN (E) and 97 credit (C). The C (credit) signal is used to build up credits at the 98 audit in advance of congestion. 100 [draft-ietf-conex-abstract-mech] (currently) only states that the 101 "transport signals sufficient credit in advance to cover congestion 102 expected during its feedback delay". Unfortunately, introducing 103 crediting can also provide incentives to not report congestion but 104 send credits instead. While ConEx feedback should be provided timely 105 and reflect the actual congestion on a path, credits should be send 106 at any time before the congestion event and need to cover at least 107 the congestion 'costs'. Thus crediting might motivate to send 108 credits instead of ConEx congestion marks (L or E). Besides this 109 central issue, the exact meaning of these credits and their handling 110 at the audit and therefore their usage at the sender is also left 111 open up to now. This documents presents and discusses potential 112 concepts for crediting and auditing. 114 1.1. Definitions 116 Congestion occurrence 117 The occurrence of a signal congestion signal, which today corresponds 118 to a packet loss or ECN-CE mark. 120 Congestion event 121 One or more congestion occurrences that happen within one RTT and 122 therefore are perceived as one congestion event by today's congestion 123 control algorithms. 125 2. Open issues 127 A solid concept how to interpret and handle credit needs to address 128 the issues listed in the following. 130 2.1. No incentives to conceal congestion by sending credits 132 The goal of ConEx is to reveal path congestion honestly by sending 133 the right amount of L or E marks timely after an congestion 134 occurrence. The use of credit marks should not motivate to endanger 135 this goal. If credits are treated equally by an audit device, there 136 is no incentive to send additional ConEx (L or E) marks if already a 137 sufficient large number of credits have been sent in advance of the 138 congestion event. This is a major and fundamental issue of the 139 credit concept in general. 141 2.2. Handling Loss of ConEx-marked Packets 143 Due to the complexity of detecting loss of ConEx information and the 144 time dependency of this information, ConEx marks should not be 145 retransmitted. Thus ConEx marks of lost packets will never be seen 146 at an audit. Generally, two entities could be responsible to care 147 for this issue: the sender or the audit. To keep the audit simple, 148 it would be preferable having this task performed by the ConEx 149 sender. As retransmitting is not an option, the sender can only send 150 credits as a substitute instead. It is not clear if false positives 151 by the audit due to lost markings can be avoided by this. As, 152 without any knowledge about lost markings and depending on the 153 definition of credits, it is hard for the sender to determine the 154 current number of valid credits perceived by the audit. The other 155 option is having the audit estimating loss of ConEx marks without 156 requiring the sender to replace them by credit. 158 2.3. Independence from Audit State 160 An audit may be started with zero state information on existing 161 flows. As credits will have been sent in advance of congestion 162 events, it is possible that no valid credit state is available at the 163 audit when a congestion event occurs. The credit definition and the 164 respective implications for the audit should also consider handling 165 this situation. 167 The concept of crediting should consider that existing flows may be 168 rerouted, so that a flow may pass through different audits over time. 169 If rerouting and thus a change of the audit happens, it is not 170 required to have no impact at all, but starvation and finally 171 shutting down of the connection should be avoided. 173 2.4. Assumption on Distance between Congestion Events 175 Today's congestion control algorithms are designed for loss-based 176 congestion feedback and therefore aim to get congestion feedback 177 rather rarely, i.e. for typical BDPs there are losses only every some 178 RTTs. Thus it could be assumed that ConEx marks will be received at 179 the audit before the next congestion event occurs. 180 Nevertheless, if the congestion feedback is not based on loss, but 181 e.g. on ECN, a more frequent signal could provide more precise 182 information on the current congestion level and therefore allow a 183 finer reaction of the congestion control. Since this would be a 184 desirable situation, we should not base the definition of ConEx 185 credit on assumptions about the distance between congestion events. 187 3. Potential Credit Definition and Auditing Approaches 188 3.1. Basic Audit Reference Implementation 190 The objective of an audit is to verify correct usage of ConEx signals 191 and to penalize cheaters. To verify, that the congestion reported 192 using the ConEx mechanism matches the congestion actually observed by 193 the receiver, it has to monitor incoming and outgoing traffic close 194 to the receiver (beyond any point of congestion). For ConEx-capable 195 connections there are 5 types of events of interest: 197 o ECN-CE (ECN codepoint set) 199 o Loss (to be detected by the audit) 201 o Re-Echo-ECN (ConEx signal E) 203 o Re-Echo-Loss (ConEx signal L) 205 o Credit (ConEx signal C) 207 A simple implementation could keep one counter per type of event. 208 For a well-behaving sender, for each loss or ECN-CE signal the 209 respective ConEx signal will follow just one RTT later, balancing 210 both counters. Therefore, often only the balance of the counters for 211 loss or ECN and the respective ConEx signal matter, e.g. Re-Echo-Loss 212 - Loss. For a well behaving sender and disregarding loss of ConEx 213 marks, at least one balance counter will be negative right after the 214 congestion event but will recover to zero (balanced state) after one 215 RTT (for connections with typical BDPs and today's congestion 216 controls). Even if congestion occurs more frequently due to a fine 217 grained congestion notification scheme, the balance counters would be 218 negative (at about the average number of congestion occurrences per 219 RTT) but not decline over time. Nevertheless, since ConEx marked 220 packets can get lost and will not be re-sent, these balance counters 221 may decline over time. Thus the balance counters can get negative or 222 zero, but should never get positive (even when more ConEx marks are 223 received than congestion signals are observed). 225 An audit could also target to estimate loss of ConEx marked packets 226 based on an estimate of the connection's packet loss rate. It then 227 could decide how negative the balance counters are allowed to get: if 228 the audit additionally counts all packets of a connection, it can 229 easily estimate the packet loss rate. It can compare the relations 230 Lost_Packets/All_Packets and (Lost_Packets - Re-Echo-Loss)/ 231 Lost_Packets and (ECN-CE - Re-Echo-ECN)/ECN-CE respectively. Over 232 time, these relations should converge, assuming that ConEx marked 233 packets are hit with the same probability as other packets(!). 234 Therefore, the audit may decide to penalize a flow if less ConEx 235 marks are received than expected on that estimation. 237 If the audit detects misbehavior or cheating e.g. due to permanent 238 negative counters, the audit shall penalize the connection. The only 239 actually possible penalty would be dropping packets (with a certain 240 probability). The actual drop rate should provide a tangible 241 disadvantage to the sender but should not render the connection 242 unusable. E.g. it could depend on how negative the counter is. This 243 could motivate the sender to just open a new connection as 244 replacement. Moreover, false positives probably can't be avoided 245 completely. The actual definition of penalties requires further 246 research. 248 In the following different proposals for crediting are presented and 249 the handling in the audit based on this general principle is 250 discussed. 252 3.2. Credit As Congestion Substitute 254 Credit marks may be understood by the audit function as an equal 255 substitute for congestion marks. This means, that an audit device 256 will count and keep credit marks the same way as congestion marks. 257 Usually, as credits should cover the risk of causing congestion, a 258 large number of credits will be sent during Slow Start phase of TCP 259 congestion control (as the sending rate is increased quite 260 aggressively), e.g. at the start-up of a new TCP flow. Later the 261 sending rate is adjusted more slowly, thus usually no further credits 262 are needed, if the initially send credits remain valid for the 263 lifetime of a flow. During the connection the number of lost or 264 ECN-(CE)-marked packets indicating congestion should be balanced by 265 ConEx L or E marks. So at to the end of a flow's lifetime, there is 266 an amount of credits "sitting in the network" that is finally 267 discarded. 269 Audit implementation: 271 An audit maintains three counters per flow: one for credit, one for 272 loss balance and one for ECN balance (see Section 3.1). Whenever a 273 marked packet is seen, the respective counter is increased. When a 274 loss or ECN-(CE)-marked packet is observed, the respective counter is 275 decreased. 276 If the sum of the counters is negative, the flow is penalized. 278 3.3. Credit As Congestion Surcharge 279 Another option is to interpret credit as compensation for late 280 arrival of congestion marks, or surcharge on (following) congestion 281 marks. This would basically mean that the sender pays twice for 282 congestion: first in advance by sending credit marks, and one RTT 283 after the congestion event by sending the respective number of ConEx 284 L or E marked packets. 286 Audit implementation: 288 An audit maintains three counters per flow, one for credit, one for 289 loss events and one for ECN events. Whenever a marked packet is 290 seen, the respective counter is increased. When a loss or 291 ECN-(CE)-marked packet is observed, the respective counter and also 292 the credit counter is decreased. 293 If the credit counter is negative, the flow is penalized. 295 3.3.1. BDP-Scaled Surcharge 297 For the sake of completeness and mainly motivated by the audit 298 implementation below we introduce a variation of the Congestion 299 Surcharge definition. In this approach the charge that needs to be 300 provided by credits per congestion event scales with the BDP (as the 301 maximum congestion risk) and additionally the longest delay between 302 two congestion occurrences within the congestion event. More 303 precisely, the proposed auditing scheme requires the sender to react 304 on a congestion event by sending credits until there was one RTT 305 without congestion events. This means that the sender pays for a 306 single congestion occurrence at least one RTT of credit marks.. If 307 several congestion signals occur within one RTT, the sender sends 308 credit marks until one RTT after the last signal. Thus the credit 309 cost of two congestion occurrences within one RTT varies from BDP to 310 2*BDP-1. 312 Audit implementation: 314 An audit maintains three counters per flow, one for credit, one 315 balance counter for loss events and one for ECN events. Whenever a 316 L- or C-marked packet is seen, the respective balance is increased. 317 When a loss or ECN-(CE)-marked packet is observed, the respective 318 counter and also the credit counter is decreased. For any packet 319 seen while the balance is negative, the credit counter is decreased. 320 If the credit counter is negative, the flow is penalized. 322 3.4. Credit As Short-Lived Congestion Risk Compensation 324 This approach tries to provide an incentive for the sender to send 325 correct congestion feedback and not sending credits instead. One 326 basic property of the approaches presented above is the infinite 327 validity of credit. The expiry of credits could depend on the RTT or 328 other channel characteristics, but we deem the reasoning in 329 [draft-ietf-conex-abstract-mech] valid, so the audit should not need 330 to estimate channel characteristics per flow. However, credits could 331 also expire after a fixed time, e.g. 300 seconds. This expiration 332 time must be fixed and known to all senders so that they can replace 333 vanishing credit in time. 335 This timeout must at least be large enough to cover the length of a 336 feedback cycle of TCP congestion control. A feedback cycle is the 337 time between to congestion events. Today's congestion control 338 algorithms result in quite low loss rate and thus feedback rate for 339 large BDPs and therefore rather long feedback cycles. Nevertheless, 340 even for NewReno [RFC5681] being used for a single connection on a 341 1GBps link with 100ms RTT and 1500Byte segment size, a feedback cycle 342 is about ( (RTT * BDP)/2 = ) 41.6 seconds. Since even occasional 343 packet errors also discourage from using congestion controls with 344 that low probing frequency, we deem 300 seconds a safe proposal for 345 the expiration timeout. 347 Audit implementation: 349 An audit maintains three counters per flow, one for credit, one for 350 loss events and one for ECN events. Whenever a marked packet is 351 seen, the respective counter is increased. When a loss or CE-event 352 is detected, the respective counter is decreased and the credit 353 counter is decreased additionally. Incoming credits set a timer upon 354 which's timeout the credit counter is decreased. 355 Note: Since credit expiring a little later than expected does not 356 harm the overall function of the audit, it might aggregate expiration 357 timeouts, e.g. for 10 seconds so for each flow only 31 bin counters 358 would be needed. 359 If the credit counter is negative, the flow is penalized. 361 4. Discussion 363 This section shall provide an initial list of arguments as the basis 364 for further discussions. 366 For all proposals, honest congestion marks can be replaced with 367 credit marks without limitation. Moreover, for the Substitute 368 approach the sender has to the end of an connection no motivation to 369 provide any ConEx signals because he can assume that the balance at 370 the audit is far in his favor. This aspect may concern a significant 371 time, depending on which congestion rate the used congestion control 372 algorithm implements. 373 Introducing a limitation for sending credit could limit the impact of 374 this fact but first a good definition of credit limits is not obvious 375 and second it would not work for short flows. 377 Any sender-based approach to handle loss of ConEx-marked packets 378 requires to allow replacing ConEx L and E signals by credit to a some 379 extend. This is basically contradicting to hindering concealing of 380 congestion by using credits. Note: the same calculation as proposed 381 for loss handling at the audit (see Section 3.1) can also be 382 performed by the sender, allowing him to send compensational credit 383 in advance. Another advantage of sender-based loss handling is that 384 the sender may use that mechanism to compensate false positives of 385 the audit. Of course this a drawback at the same time, as it opens 386 for abuse. 388 A main advantage of handling loss at the audit is that no 389 compensation by credit is necessary, so issue#1 can be avoided. The 390 main disadvantage is that the outlined mechanism only works for 391 longer flows since the statistical deviation of the observed loss 392 rate needs be acceptable small. It must also be noted, that the loss 393 probability changes over time during a flow's life time. For today's 394 congestion control algorithms, ConEx marked packets will be sent one 395 RTT after the congestion event when the sender reduced its sending 396 rate, thus the loss rate of ConEx marked packets should be smaller 397 than the total average loss rate. So more complex estimators might 398 be necessary, further increasing the audit complexity. 400 If ConEx loss is handled by the sender, re-routing or restarting 401 audits can be expected to be handled in a similar but this definitely 402 requires further research. 404 The BDP-Scaled Surcharge-approach has several properties which we 405 deem undesirable: although the RTT is out of control of the end user, 406 for this definition he has to pay more for connections with longer 407 RTTs. Moreover, the distribution of congestion occurrences affects 408 the credit cost of one congestion event significantly. 410 Approach Section 3.4 with limited life time of credit at least solves 411 the issue of large amounts of credits being available at the audit to 412 the end of a connection. Yet the issue of cheating by sending credit 413 instead of congestion marks remains unsolved. Maybe the proposed 414 credit definition could be used with a modified audit algorithm 415 limiting the decrease of the balance counters. 417 5. Security Considerations 419 This document has no security considerations. 421 6. IANA Considerations 423 This document has no IANA considerations. 425 7. References 427 7.1. Normative References 429 [draft-ietf-conex-abstract-mech] 430 Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 431 Concepts and Abstract Mechanism", draft-ietf-conex- 432 abstract-mech-06 (work in progress), October 2012. 434 [draft-ietf-conex-destopt] 435 Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 436 Destination Option for ConEx", draft-ietf-conex-destopt-04 437 (work in progress), March 2013. 439 7.2. Informative References 441 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 442 Control", RFC 5681, September 2009. 444 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 445 of Explicit Congestion Notification (ECN) to IP", RFC 446 3168, September 2001. 448 Authors' Addresses 450 David Wagner 451 University of Stuttgart 452 Pfaffenwaldring 47 453 70569 Stuttgart 454 Germany 456 Email: david.wagner@ikr.uni-stuttgart.de 457 Mirja Kuehlewind 458 University of Stuttgart 459 Pfaffenwaldring 47 460 70569 Stuttgart 461 Germany 463 Email: mirja.kuehlewind@ikr.uni-stuttgart.de