One document matched: draft-wagner-conex-audit-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="info" docName="draft-wagner-conex-audit-01">
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc toc="yes"?>
	<?rfc symrefs="yes"?>
	
	<front>
		<title abbrev="ConEx Auditing">
			Auditing of Congestion Exposure (ConEx) signals
		</title>
		
		<author initials="D." surname="Wagner" fullname="David Wagner">
			<organization>University of Stuttgart</organization>
			<address>
				<postal>
					<street>Pfaffenwaldring 47</street>
					<city>70569 Stuttgart</city>
					<country>Germany</country>
				</postal>
				<email>david.wagner@ikr.uni-stuttgart.de</email>
			</address>
		</author>
		
		<author fullname="Mirja Kuehlewind" 
				  initials="M." surname="Kuehlewind">
			<organization>University of Stuttgart</organization>
			<address>
				<postal>
					<street>Pfaffenwaldring 47</street>
					<city>70569 Stuttgart</city>
					<country>Germany</country>
				</postal>
				<email>mirja.kuehlewind@ikr.uni-stuttgart.de</email>
			</address>
		</author>
		
		
		<date year='2014' />
		<area>Transport</area>
		<workgroup>ConEx Working Group</workgroup>
		<abstract> 
			<!--t>
				This document yet is a rough draft and contains lots of todos, only partly indicated as such. 
				The text on credit is just here to have one place to document the meaning. It will be shortened and put into an introducing section in sec.3 
			</t-->
			<t>
				Congestion Exposure (ConEx) is a mechanism by which senders inform the network 
				about the congestion encountered by previous packets on the same flow. 
				Reliable auditing is necessary to provide a strong incentive to declare ConEx information honestly. 
				<!--> However, there is always a delay between 
				congestion events and the respective ConEx signal at the audit. 
				In order to also provide a signal for risking congestion in the future, in <xref target="draft-ietf-conex-abstract-mech"/> 
				it is proposed to use credit signals sent in advance. < -->
				This document defines how the signals are handled by an audit and lists requirements for an audit implementation. 
				This document does not mandate a particular design but identifies state and functions that any auditor element must provide to fulfill the requirements stated in <xref target="draft-ietf-conex-abstract-mech"/>.
				<!--It also discusses the security of the proposed system and lists potential attacks on it. -->
			</t>
		</abstract>
	</front>
	<middle>
		<section title="Introduction" anchor="sec-intro">
			<t>
				In order to make ConEx information useful, reliable auditing is necessary to provide a strong 
				incentive to declare ConEx information honestly. However, there is always a delay between 
				congestion events and the respective ConEx signal at the audit. 
				In <xref target="draft-ietf-conex-abstract-mech"/> 
				it is proposed to use credit signals sent in advance to cover potential congestion in the next feedback delay duration. 
			</t>
			<t>
				The ConEx signal is based on loss or Explicit Congestion Notification (ECN) marks <xref target="RFC3168"/> as a congestion indication.
				Following <xref target="draft-ietf-conex-abstract-mech"/> (Section 4.4), ConEx signaling has to encode ConEx capability, Re-Echo-Loss (L), Re-Echo-ECN (E) and credit (C). 
				<!-->    The ConEx congestion signaling is defined for IPv6 in <xref target="draft-ietf-conex-destopt"/> 
				as four bits in an own destination option. While the X (ConEx-capable) bit indicates if a packet
				is ConEx-capable or not, the L (loss experienced) and the E (ECN Congestion Experienced (CE)) 
				bits provide the ConEx congestion information. 
				< -->
				<!--The C (credit) signal is used to build up credits at the audit in advance of congestion.<-->
			</t>
			<!-- t><xref target="draft-ietf-conex-abstract-mech"/> (currently) only states that the 
				"transport signals sufficient credit in advance to cover congestion expected during its feedback delay". 
				Unfortunately, introducing crediting can also provide incentives to not report congestion but send 
				credits instead. While ConEx feedback should be provided timely and reflect the actual congestion on
				a path, credits should be send at any time before the congestion event and need to cover at least
				the congestion 'costs'.
				Thus crediting might motivate to send credits instead of ConEx congestion marks (L or E). 
				Besides this central issue, the exact meaning of these credits and their handling at the audit 
				and therefore their usage at the sender is also left open up to now. 
				This documents presents and discusses potential concepts for crediting and auditing. 
			</t-->

			<section title="Meaning of the Re-Echo Signals">
				<t>
					By the Re-Echo-Loss signal a sender exposes to the network that this transport has experienced loss very recently. 
					By the Re-Echo-ECN signal a sender exposes to the network that this transport has experienced an ECN-CE mark very recently. 
					For the audit this means, that if it detects a loss or an ECN-CE mark for a ConEx-enabled flow, 
					for a compliant sender the corresponding Re-Echo-Loss or Re-Echo-ECN signals must be observed in the near future. 
				</t>
			</section>
			<section title="Meaning of Credit Signal">
				<t>
					The Credit signal represents potential for congestion. 
					A ConEx-enabled sender should signal sufficient credit in advance to any congestion event. 
					If a congestion event occurs, a corresponding amount of credit is consumed. 
					If the sender intends to take the same risk again, it just must replace this consumed credit as non-consumed credit does not expire. 
				</t>
			</section>
			<!--
			<section title="Meaning of credit for TCP congestion control">
				<t>
					For today's TCP congestion control, this applies to both phases of a connection: 
					<vspace blankLines='1'/>
					During slow start phases, a node increases its sending rate, typically doubling it during a Round Trip Time (RTT). 
					This obviously implies two things: 
					First, the congestion risked during the past RTT has not occured, so the already sent credit is still valid. 
					Second, the congestion risk is now increased due to the higher sending rate and accordingly more credit has to be sent covering the additional risk for congestion. 
					<vspace blankLines='1'/>
					During congestion avoidance phases, the congestion occurs from time to time.
					This congestion consumes credit which the sender must replace.
				</t>
			</section>
			-->
			<section title="Definitions">
				<t>
					Congestion signal
					<vspace blankLines='0'/>
					The occurrence of a packet loss or ECN-CE mark.
					We do not consider other signs such as increased delay as congestion signals. 
					<!-- In the future there could be other protocols of explicit congestion signaling. -->
				</t>
				<t>
					Congestion event
					<vspace blankLines='0'/>
					One or more congestion signals within one RTT. 
					For today's congestion control algorithms all these signals trigger just one reaction regardless of their number. 
				</t>
				<t>
					Connection
					<vspace blankLines='0'/>
					A connection between transport layer endpoints that allows bidirectional signalling, e.g. a TCP connection.
				</t>	
				<t>
					Flow
					<vspace blankLines='0'/>
					The flow of packets of a connection in one direction. 
					Therefore for a flow sender and receiver are well defined. 
					With regard to ConEx auditing, only one flow of any observed connection is audited, see <xref target='sec-placing'/>. 
				</t>
			</section>
		</section>
		<section title="Audit Implementation">
			<t>
				An audit element shall be a shadow device, i.e. its presence should not be detectable for well-behaving senders. 
				The objective of an audit is to verify that senders signal the ConEx information correctly and to penalize cheaters. 
				For this, the audit element has to maintain state for any active ConEx-enabled flow. 
				<!--This means, on each arriving packet it must 
				<list style='symbols'> 
					<t> detect newly starting flows and create a state entry if it is ConEx-enabled </t>
					<t> assign all packets of a ConEx-enabled flow to that entry and handle it accordingly </t>
				</list><-->
				It may maintain appropriate timers to remove flows that have been idle for too long. 
				Flows can be audited independently, there are no dependencies. 
				<!-- In the following we will only consider ConEx-enabled flows. -->
					
				There are two aspects the auditor has to check for each flow: 
				<list style='symbols'>
					<t> if the congestion reported using the ConEx mechanism matches the congestion actually observed by the receivers and  </t>
					<t> if sufficient credit marks have been sent to signal the congestion risk in advance.  </t>
				</list>
				The audit penalizes a flow if it fails either of these two criteria. 
			</t>
			<t>
				This document does not mandate a particular design but identifies state and functions that any auditor element must provide to fulfill the requirements stated in <xref target="draft-ietf-conex-abstract-mech"/>.
			</t>
			<section title="Placing an Audit Element" anchor="sec-placing">
				<t>
					An audit element should be placed so that it can observe all congestion signals of audited flows. 
					If both congestion signals, ECN and loss, are detected directly, all auditing should take place beyond any potential source of congestion, i.e. any potential bottleneck, towards the receiver of that flow. 
					In that case it must be placed beyond any potential multi path routing in order to be able to identify all packet losses. 
					For unencrypted TCP and maybe other protocols, losses can be easily detected indirectly by monitoring the sender's retransmissions, making loss auditing simple and reliable at the same time. 
					Such ConEx-loss audit function must be placed close to the sender before any bottleneck where retransmissions might get lost. 
					Therefore it might make sense to have ConEx-loss auditing and ConEx-ECN auditing separated. 
					Nevertheless, this applies for certain deployment scenarios only. 
					Therefore we describe a combined loss and ECN ConEx auditor in the following which must be placed close to the receiver, beyond any potential bottleneck. 
					<!--Note that this requirement can alos be fulfilled by a logical auditor that is physically distributed to all potential paths to a destination. /!-->
				</t>		
			</section>
			<section title="Per Flow State" anchor="sec-state">
				<t>
					ConEx auditing must be performed per incoming ConEx-enabled flow, so all monitoring, assessment and penalizing is per flow. 
				</t>
				<t>
					An audit maintains state for each active connection that is updated on every packet of that flow. 
					Such state entry is created when the first packet of an unknown flow is observed. 
					It is deleted when either the corresponding connection is closed conforming to its transport layer protocol or a timeout expired. 
					This timeout should be chosen to keep false negatives low, i.e. avoiding timing out still active flows. 
					In contrast, false positives, recognizing two flows as one, are expected typically being a smaller issue since in most cases the sender is the same host and either complies to the protocol or not. 
					We recommend setting this timeout to 60 seconds, a value also common e.g. in NAT middle boxes. 
				</t>
				<t>
					An audit should maintain an RTT_MAX estimation per flow. <!-- to avoid false positives for flows with smaller RTT as well as false negatives.-->
					
					This value should be as close to the maximum RTT observed by the sender as possible. 
					RTT_MAX must not be chosen smaller than the RTT observed by the sender. 

					<vspace blankLines='0' />
					An audit maintains the following variables per flow:
					<list style='symbols'> 
						<t> 
							ECN-CE counter (ECN-CE codepoint set) 
							<vspace blankLines='0' />
							When an ECN-CE-marked packet is observed, the counter is increased by the number of IP payload bytes. 
						</t>
						<t> 
							Loss counter (to be detected by the audit element, see also Section 5.5 in <xref target="draft-ietf-conex-abstract-mech"/>) 
							<vspace blankLines='0' />
							When a loss is observed, the counter is increased by the number of IP payload bytes. 
						</t>
						<t> 
							Re-Echo-ECN  counter (ConEx signal E) 
							<vspace blankLines='0' />
							When Re-Echo-ECN-marked packet is seen, the counter is increased by the number of IP payload bytes. 
						</t>
						<t> 
							Re-Echo-Loss counter (ConEx signal L) 
							<vspace blankLines='0' />
							When Re-Echo-Loss-marked packet is seen, the counter is increased by the number of IP payload bytes. 
						</t>
						<t> 
							Credit state 
							<vspace blankLines='0' />
							Whenever a ConEx-marked packet (Re-Echo-Loss or Re-Echo-ECN) is seen and Credit state is greater than zero, the counter is decreased by the number of IP payload bytes.
							When a Credit-marked packet is seen, the counter is increased by the number of IP payload bytes. 
							<vspace blankLines='0'/>
							Please note that the meaning of the Credit variable differs from the other variables: 
							While all other variables are life-time counters for the flow and thus grow monotonously, the credit buffer just reflects the current signaled credit. 
							It shrinks and grows as congestion is experienced and credit is sent. 
						</t>
						<t> 
							RTT_MAX 
						</t>
						<t> 
							is_in_penalty_state
						</t>
						<t> 
							p, an EWMA of the congestion rate (loss and/or ECN-CE marks)
						</t>
						<t>
							x, an EWMA of the rate of Re-Echo-Loss and/or Re-Echo-ECN marks. If a packet carries both flags, it must be counted twice.
						</t> 
						
						<t> current drop probability </t>
					</list>
					If the flow is part of a bidirectional connection, an auditor may use information from the return flow in order to define RTT_MAX 
					and to detect packet losses. 

				</t>
			</section>
			<section title="Penalty Criteria" anchor="sec-assessment">
				<t>
					Generally, a connection is judged on three criteria, one concerning exposure of loss, one on exposure of ECN-based congestion signaling and one on announcing potential congestion by credit. 
					A flow is considered misbehaving if at least one of the three conditions is met. 
				</t>
				<t>
					A connection is assumed behaving abusive if
					<list style='symbols'> 
						<t> the Credit state is zero, </t>
						<t> losses observed in the last 2x RTT_MAX period are not exposed by Re-Echo-Loss signals, and </t>
						<t> ECN-CE signals received in the last 2x RTT_MAX period are not exposed by Re-Echo-Loss signals.</t>
					</list>
					The first criterion should be checked each time a packet of that flow towards the destination is observed. 
					If Credit state is zero, is_in_penalty_state is set to true, else set to false.
					<!-- Nevertheless, the audit neither limits the credit rate, which a policer might do, nor is it unforgiving regarding credit. -->
					<!-- If Credit state is zero, the flow is penalized but once the sender sends new Credit, it will not be penalized as long as Credit is positive.--> 
				</t>
				<t>
					The other two criteria shall be checked periodically based on timeouts. 
					The timeout t must be equal or bigger than 2x RTT_MAX. 
					There are n timers used and n should be equal or bigger than 2. 
					To do the check, an audit element must store n snapshots of the ECN-CE and loss counter. 
					When the timeout fires, the oldest set of values is compared with the current values of Re-echo-Loss and Re-Echo-ECN, respectively. 
					If the saved loss counter is greater than the current Re-Echo-Loss counter, or saved ECN-CE counter is greater than the current Re-Echo-ECN counter, 
					is_in_penalty_state is set to true, else set to false. 
					<!-- Both criteria regarding the ConEx signals should be checked at distinct points of time only, so it is only necessary to store a limited number of old states.
					These criteria should at least be checked once in RTT_MAX. 
					The audit may consider an estimation of loss of ConEx-marked packets in favor of the sender in its calculations, see Section <xref target='sec-loss'/>. -->
				</t>
				<t>
					A flow may have not enough data at a time where it needs to send ConEx markings and by this fall into misbehaving state (is_in_penalty_state is true) 
					during a phase of inactivity. 
					If the sender then restarts sending packets carrying markings for all failed criteria, the sender is assumed being well-behaving (in dubio pro reo). 
					Therefore the auditor shall not drop packets which carry all required flags, but use the normal penalty on all others. 
				</t>
				<t>
					For example, if credit is zero and the losses experienced in the 2xRTT_MAX period are not compensated by sufficient Re-Echo-Loss signals, 
					packets carrying both the C and the L flag will not be subject of the penalty function. 
					Nevertheless, packets carrying only the C-flag or only the L-flag will. 
				</t>
			</section>
			<section title="Appropriately Penalizing Misbehaving Flows" anchor="sec-penalizing">
				<t>
					If a flow is detected to misbehave, the audit must start penalizing immediately. 
					The only actually possible penalty is dropping packets (with a certain probability). 
					In order to not incentivize senders to simply start new flows when detecting being penalized by an audit element, 
					the penalty of a misbehaving flow should be proportional to the misbehavior.  <!-- cite Bob's diss. At least somewhere-->
				</t>
				<t>
					Please note that we require the sender to make sure that any ConEx mark will reach the receiver, so it is responsible for timely retransmission of any lost ConEx signal. 
				</t>
				<t>
					The actual drop rate must provide a tangible disadvantage to the sender but should not make the connection unusable. 
					An auditor should aim at forwarding not more packets than would have been successfully sent with the exposed congestion rate. 
					Since the congestion rate may vary over time, the auditor should use an exponentially-weighted moving average (EWMA) 
					for each flow to define the congestion rate p. 
					An auditor should also maintain a EWMA for the rate of ConEx-signals (Re-Echo-Loss and Re-Echo-ECN) x. 
				</t>
				<t>
					TODO: what are appropriate weighting factors alpha in EWMA? 
				</t>
				<t>
					Assume the packet rate is r and congestion rate is p, but only p-x congestion is signaled by the sender using ConEx (c < p). 
					The audit should aim at giving the flow just a rate of r*(x/p). 
					In other words, it should drop (p-x)/p of the traffic, so its drop probability should be (p-x)/p. 
					Therefore the audit just keeps updated x and p, and derives the drop probability as (p-x)/p. 
				</t>
			</section>	
			<section title="Audit start for existing connections">
				<t>
					An audit may be started with zero state information on existing flows, e.g. due to (re-)started audit or re-routing of flows. 
					As credits will have been sent in advance of congestion events, it is possible that no valid credit state is available at the audit when a congestion event occurs. 
					An audit implementation should take this into account by ignoring the first criterion for some time. 
					We recommend starting to take credit into account after one minute. 
				</t>
				<t>
					TODO: is this the right way? this should be enough for the first congestion epoch, but disregards credit build up in slow start. 
					Or give some credit on Credit for the start? how much? 
				</t>
			</section>
			<section title="Handling Loss of ConEx-marked Packets" anchor="sec-loss">
				<t>
					ConEx-marked packets will be sent just after the sender noticed a congestion signal, so often this sender will just have reduced its sending rate. 
					Thus the loss probability for ConEx-marked packets is expected to be lower than for the average flow. 
					Nevertheless, ConEx-marked packets can be lost. 
					The sender should <!-- keep track of wether the packets that are recognized as lost have been ConEx-marked and --> re-send the ConEx-signal. 
					This induces additional delay for that ConEx-signal but this is taken into account by using 2xRTT_MAX as threshold for penalties. 
					By that false positives of the auditor misbehavior detection are avoided. 
					Only if two ConEx-marked packets are lost in subsequent RTTs, the auditor will penalize a flow of a well-behaving sender. 
					To avoid even these rare cases at least for long-lasting connections, the audit may use the fraction of lost packets of that connection 
					to allow for the same fraction of loss for each ConEx-mark (E, L and C) for a time longer than 2xRTT_MAX. 
					<!--It can compare the relations Lost_Packets/All_Packets and (Lost_Packets - Re-Echo-Loss)/Lost_Packets and (ECN-CE - Re-Echo-ECN)/ECN-CE respectively. 
					Over time, these relations should converge, assuming that ConEx marked packets are hit with the same probability as other packets(!). <-->
					Nevertheless, the rare event of loss of ConEx-marked packets will often cause the audit to penalize the flow for one RTT. 
					We deem this price being acceptable for the clean and robust auditor design made possible by making the sender responsible for successful delivery of ConEx signals. 
				</t>
			</section>
		</section>
		<!--<section title="Open issues" anchor="sec-issues">
			<t>
				Todo
			</t>
		</section>-->
		<section title="Acknowledgements" anchor="sec-ack">
			<t>
				We would like to thank Bob Briscoe for his input (based on research work of his PhD thesis).
			</t>
		</section>
		<section title="Security Considerations" anchor="sec-security">
			<t>
				Here known / identified attacks will be discussed. Bob Briscoe's dissertation provides good material here. big TODO. 
			</t>
		</section>
			
		<section title="IANA Considerations" anchor="sec-iana"> 
			<t>This document has no IANA considerations.</t>
		</section>
	</middle>
	<back>
		<references title="Normative References">
			<reference anchor="draft-ietf-conex-abstract-mech" >
				<front>
					<title>Congestion Exposure (ConEx) Concepts and Abstract Mechanism</title>
					
					<author initials="M" surname="Mathis">
					<organization></organization></author>
					<author initials="B" surname="Briscoe">
					<organization></organization></author>
					<date  month="October" year="2013"/>
				</front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-conex-abstract-mech-08"/>
			</reference>
			<reference anchor="draft-ietf-conex-destopt" >
				<front>
					<title>IPv6 Destination Option for ConEx</title>
					<author initials="S" surname="Krishnan">
					<organization></organization></author>
					<author initials="M" surname="Kuehlewind">
					<organization></organization></author>
					<author initials="C" surname="Ucendo">
					<organization></organization></author>
					<date  month="March" year="2013"/>
				</front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-conex-destopt-05"/>
			</reference>
			<?rfc include="reference.RFC.3168" ?>
		</references>
		<references title="Informative References">
			<?rfc include="reference.RFC.5681" ?>
			<?rfc include="reference.RFC.3168" ?>
		</references>
	</back>
</rfc>