TCP Modifications for Congestion Exposure (ConEx)
draft-ietf-conex-tcp-modifications-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-03-15
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-02-16
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-01-29
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-01-20
|
10 | (System) | RFC Editor state changed to EDIT from MISSREF |
2015-11-20
|
10 | (System) | RFC Editor state changed to MISSREF |
2015-11-20
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-11-20
|
10 | (System) | Announcement was received by RFC Editor |
2015-11-19
|
10 | (System) | IANA Action state changed to No IC from In Progress |
2015-11-19
|
10 | (System) | IANA Action state changed to In Progress |
2015-11-19
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-11-19
|
10 | Cindy Morgan | IESG has approved the document |
2015-11-19
|
10 | Cindy Morgan | Closed "Approve" ballot |
2015-11-19
|
10 | Cindy Morgan | Ballot approval text was generated |
2015-11-19
|
10 | Martin Stiemerling | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-11-19
|
10 | Martin Stiemerling | Ballot writeup was changed |
2015-10-14
|
10 | (System) | Notify list changed from draft-ietf-conex-tcp-modifications@ietf.org, draft-ietf-conex-tcp-modifications.ad@ietf.org, conex-chairs@ietf.org, "Suresh Krishnan" to (None) |
2015-10-13
|
09 | Mirja Kühlewind | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-10-13
|
10 | Mirja Kühlewind | New version available: draft-ietf-conex-tcp-modifications-10.txt |
2015-10-01
|
09 | Amy Vezza | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2015-10-01
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-10-01
|
09 | Stephen Farrell | [Ballot comment] Seems like a fine thing to experiment with. I hope the results are interesting. The security considerations really ought take into account or … [Ballot comment] Seems like a fine thing to experiment with. I hope the results are interesting. The security considerations really ought take into account or at least mention potential misbehaviour by middleboxes and also how conex might be affected by DoS attacks. |
2015-10-01
|
09 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-10-01
|
09 | Benoît Claise | [Ballot comment] No objection to the document itself, but I really expect a new version based on Warren's feedback, as agreed by Suresh (document shepherd) … [Ballot comment] No objection to the document itself, but I really expect a new version based on Warren's feedback, as agreed by Suresh (document shepherd) Warren's feedback below. Be ye not afraid -- I have reviewed this document as part of the operations directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operation area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Version reviewed: draft-ietf-conex-tcp-modifications-09 Summary: I am not sure that this document is ready, and believe that review is needed from the Ops ADs. I believe that interactions with TCP feedback need to be performed very carefully, and I do not have the knowledge to adequately evaluate these, hopefully others with this experience (Transport ADs?) have also evaluated the document. The document needs significant readability cleanup and nit fixing. Detail: I found the document difficult to read -- there are a large number of typos, areas with lack of precision, ambiguities and grammar issues. This made a full evaluation difficult. I went to read the 'Document Quality' section of the Shepherd report to see if this was noted, but it was simply boilerplate. The document is marked as Experimental. I would be more concerned if it were a different stream... Open questions: Section 7 Open Areas for Experimentation; "This decision was taken because most network devices today expirience byte-congestion where the memory is filled exactly with the number of bytes a packet carries. However, there are also devices that may allocate a certain amount of memory per packet, no matter how larger a packet is." Citation needed; many devices I am familiar with split packets into multiple fixed size cells. e.g Juniper Q5 chips split packets into 96, 112, 128, 144, 160, or 176 byte cells and spray these across the fabric.I believe the Cisco CRS (and similar architectures) perform similar cell splitting. RFC7141 did not seem to contain this, but I may have missed it. In my opinion the document should discuss monitoring and reporting. What parameters should implementations expose to the user / operator? I think that the document should also discuss how this technique does or does not suffer from the potential of global synchronization (although this may be covered in other ConEx documents that I am not familiar with). The Security Considerations and Open Areas for Experimentation sections sort of discuss coexistence / deployment, but not in much depth Nits are readability issues - in a number of cases I was not entirely sure what was intended, so my suggestions may not be correct. Whereas loss has to be minimized, ECN can provide more fine-grained [O] Whereas loss has to be minimized, [P] Do you mean While, not whereas? I'm not sure how to parse this. feedback information. ConEx-based traffic measurement or management mechanisms could benefit from this. ... 3. Counting congestion ... The outstanding bytes counted based on ECN feedback information are maintained in the congestion exposure gauge (CEG), as explained in Section 3.2. When the sender sends a ConEx capable packet with the E or L flag set [O] When the sender sends a ConEx capable packet with the E or L flag set [P] When the sender sends a ConEx capable packet with the E or L flag set, [R] punctuation it reduces the respective counter by the byte-size of the packet. This is explained for both counters in Section 4.1. Note that all bytes of an IP packet must be counted in the LEG or CEG to capture the right number of bytes that should be marked. Therefore the sender SHOULD take the payload and headers into account, up to and including the IP header. However, in TCP the information how large the headers of an lost or marked pacekt were is [O] information how large the headers of an lost or marked pacekt [P] information regarding how large the headers of a lost or marked packet [R] readability, grammar, and typo (three changes) usually not available, as only payload data will be acknowledged. If equal-sized packets, or at least equally distributed packet sizes [O] or at least equally distributed packet sizes [P] or at least equally distributed packet sizes, [R] grammar can be assumed, the sender MAY only add and subtract TCP payload bytes. ... 3.1. Loss Detection This section applies whether or not SACK support is available. The following subsection in addition handles the case when SACK is not [O] The following subsection in addition handles [P] The following subsection (3.1.1) handles [R] Clarity available. A TCP sender detects losses and subsequently retransmits the lost data. Therefore, ConEx sender can simply set the ConEx L flag on all retransmissions in order to at least cover the amount of bytes lost. If this aprroach is taken, no LEG is needed. [O] aprroach [P] approach [R] spelling However, any retransmission may be spurious. In this case more bytes have been marked than necessary. To compensate this effect a ConEx [O] To compensate this effect [P] To compensate for this effect, [R] grammar sender can maintain a local signed counter, the (LEG), that indicats [O] indicats [P] inidicates [R] spelling the number of outstanding bytes to be sent with the ConEx L flag and also can become negative. Using the LEG, when a TCP sender decides that a data segment needs to be retransmitted, it will increase LEG by the size of the TCP payload bytes in the retransmission (assuming equal sized segments such that the retransmitted packet will have the same number of header bytes as the original ones): For each retransmision: [O] retransmision [P] retransmission [R] spelling LEG += payload Note, how the LEG is reduced when the ConEx L marking are set is described in section Section 4. Further to accommodate spurious restransmissions, a ConEx sender [O] restransmissions [P] retransmissions [R] spelling SHOULD make use of heuristics to detect such spurious retransmissions (e.g. F-RTO [RFC5682], DSACK [RFC3708], and Eifel [RFC3522], [RFC4015]) if are already available in a given implementation. If no [O] if are already available in a given implementation. [P] if already available in a given implementation. [R] grammar mechanism for detecting spurious retransmissions is available, the ConEx sender MAY chose to implement one of the mechanism stated above. However, given the inaccuracy that ConEx may have anyway and the timeliness of ConEx information, a ConEx MAY also chose to not componsate for spurious retransmission. In this case if spurious [O] componsate [P] compensate [R] spelling retransmissions occur, the ConEx sender simple has sent too much [O] retransmissions occur, the ConEx sender simple has sent too much [P] retransmissions occur, the ConEx sender simply has sent too many [R] grammar x 2 ConEx signals which e.g would decrease the congestion allowance in a ConEx policer unnecessary. [O] in a ConEx policer unnecessary. [R] ? Cannot parse. If a heuristic to detect spurious retransmission is used and has [O] If a heuristic to detect spurious retransmission is used [P] If a heuristic method is used to detect spurious retransmission [R] readability, and was missing a noun after heuristic. Could use analysis instead. determined that a certain number of packets were retransmitted erroneously, the ConEx sender subtracts the payload size of these TCP packets from LEG. If a spurious reransmission is detected: [O] reransmission [P] retransmission [R] spelling LEG -= payload Note that the LEG can get negative, if too many L marking have [O] Note that the LEG can get negative [P] Note that LEG can become negative [R] clarity already been sent. This case is further discussed in section Section 6. 3.1.1. Without SACK Support If multiple losses occur within one RTT and SACK is not used, it may take several RTTs until all lost data is retransmitted. With the scheme described above, the ConEx information will be delayed considerably, but timeliness is important for ConEx. However, for ConEx it is not important to know which data got lost but only how much. During the first RTT after the initial loss detection, the [O] However, for ConEx it is not important to know which data got lost but only how much. [P] For ConEx, it is important to know how much data was lot; it is not important to know what data is lost. [R] readability amount of received data and thus also the amount of lost data can be estimated based on the number of received ACKs. ... 3.2. ECN ... DeliveredData covers the number of bytes that has been newly delivered to the receiver. Therefore on each arrival of an ACK, DeliveredData will be increased by the newly acknowledged bytes (acked_bytes) as indicated by the current ACK, relative to all past ACKs. The formula depends on whether SACK is available: if SACK is not avaialble SACK_diff is always zero, whereas is ACK information is [O] avaialble [P] available [R] spelling available is_dup and is_after_dup are always zero. With SACK, DeliveredData is increased by the number of bytes provided by (new) SACK information (SACK_diff). Note, if less unacknowledged bytes are announced in the new SACK information than in the previous ACK, SACK_diff can be negative. In this case, data is newly acknowledged (in acked_bytes), that has previously already been accumulated into DeliveredData based on SACK information. Otherwise without SACK, DeliveredData is increased by 1 SMSS on duplicate acknowledgements as duplicate acknowledgements do not [O] as duplicate acknowledgements [P] because duplicate acknowedgements [R] grammar. Since would also be fine, instead of as. acknowlegde any new data (and acked_bytes will be zero). For the [O] acknowlegde [P] acknowledge [R] spelling subsequent partial or full ACK, acked_bytes cover all newly acknowledged bytes including the ones that where already accounted which the receiption of any duplicate acknowledgement. Therefore [O] the ones that where already accounted which the receiption of any duplicate acknowledgement [P] those already accounted for with the receipt of any duplicate acknowledgement. [R] spelling, grammar, inability to parse the original. I *think* this is what was meant. DeliveredData is reduced by one SMSS for each preceding duplicate ACK. Consequently, is_dup is one if the current ACK is a duplicated ACK without SACK, and zero otherwise. is_after_dup is only one for the next full or partial ACK after a number of duplicated ACKs without SACK and num_dup counts the number of duplicated ACKs in a row (which usually is 3 or more). With classic ECN, one congestion marked packet causes continuous congestion feedback for a whole round trip, thus hiding the arrival of any further congestion marked packets during that round trip. A more accurate ECN feedback scheme (AccECN) is needed to ensure that feedback properly reflects the extent of congestion marking. The two cases, with and without a receiver capable of AccECN, are discussed in the following sections. 3.2.1. Accurate ECN feedback With a more accurate ECN feedback scheme (AccECN) that is supported by the receiver either the number of marked packets or the number of [O] by the receiver either the number [P] by the receiver, either the number [R] grammar/punctuation marked bytes will be feed back from the receiver to the sender and is [O] feed back [P] fed back [R] spelling therefore know at sender-side. In the latter case the CEG can [O] therefore know at sender-side. In the latter case the CEG can [P] therefore know at sender-side. In the latter case, the CEG can [R] grammar/punctuation directly be increased by the number of marked bytes. Otherwise if D is assumed to be the number of marks, the gauge (CEG) will be conservatively increased by one SMSS for each marking or at max the number of newly acknowledged bytes: CEG += min(SMSS*D, DeliveredData) 3.2.2. Classic ECN support ... To extract more than one ECE indication per RTT, a ConEx sender could set the CWR flag continuously to force the receiver to signal only one ECE per CE mark. Unfortunately, the use of delayed ACKs [RFC5681] (which is common) will prevent feedback of every CE mark; if a CWR confirmation is received before the ECE can be sent out on the next ACK, ECN feedback information could get lost (depeding on [O] depeding [P] depending [R] spelling the actual receiver implementation). Thus a sender SHOULD set CWR only on those data segments that will presumably trigger a (delayed ACK. The sender would need an additional control loop to estimated [O] to estimated [P] to estimate [R] grammar which data segments will trigger an ACK in order to extract more timely congestion notifications. Still the CEG SHOULD be increased [O] Still the CEG SHOULD be increased [P] Still, the CEG SHOULD be increased [R] readability by DeliveredData, as one or more CE marked packets could be acknowledged by one delayed ACK. 4. Setting the ConEx Flags By setting the X flag, a packet is marked as ConEx-capable. All packets carrying payload MUST be marked with the X flag set, including retransmissions. Only if no congestion feedback information is (currently) available, the X flag SHOULD be zero, such as for control packets on a connection that has not sent any (user) data for some time e.g., sending only pure ACKs which are not carrying any payload. [O] Only if no congestion feedback information is (currently) available, the X flag SHOULD be zero, such as for control packets on a connection that has not sent any (user) data for some time e.g., sending only pure ACKs which are not carrying any payload. [P] The X flag SHOULD be zero only if no congestion feedback information is (currently) available (e.g. for control packets on a connection that not sent any user data for some time and is sending only pure ACKs that are not carrying any payload). [R] grammar and readability 4.1. Setting the E or the L Flag As described in section Section 3.1, the sender needs to maintain a CEG counter and might maintain a LEG counter. If no LEG is used, all retransmission will be marked with the L flag. Further, as long as the LEG or CEG counter is positive, the sender marks each ConEx-capable packet with L or E respectively, and decreases the LEG or CEG counter by the TCP payload bytes carried in the marked packet (assuming headers are not being counted because packet sizes are regular). No matter how small the value of LEG or CEG, if it is positive, the sender MUST NOT defer packet marking to ensure ConEx signals are timely. Therefore the value of LEG and CEG [O] No matter how small the value of LEG or CEG, if it is positive, the sender MUST NOT defer packet marking to ensure ConEx signals are timely. [P] No matter how small the value of LEG or CEG, if the value is positive the sender MUST NOT defer packet marking; this ensure ConEx signals are timely. [R] readability. will commonly be negative. If both LEG and CEG are positive, the sender MUST mark each ConEx- capable packet with both L and E. If a credit signal is also pending (see next section), the C flag can be set as well. 4.2. Setting the Credit Flag ... Recall that CSC will be decreased whenever congestion occurs, therefore CSC will need to be replenished as soon as CSC drops below [O] Recall that CSC will be decreased whenever congestion occurs, therefore CSC will need [P] CSC will be decreased whenever congestion occurs; therefore, CSC will need [R] grammar F. Also recall that the sender can set the C flag on a ConEx-capable packet whether or not the E or L flags are also set. In TCP Slow Start, the congestion window might grow much larger than during the rest of the transmission. Likely, a sender could consider sending fewer than F credits but risking being penalized by an audit function. However, the credits should at least cover the increase in sending rate. Given the exponential increase as implemented in the TCP Slow Start algorithm which means that the sending rate doubles every RTT, a ConEx sender should at least cover half the number of packets in flight by credits. Note that the number of losses or markings within one RTT does not solely depend on the sender's actions. In general, the behavior of the cross traffic, whether active queue management (AQM) is used and how it is parameterized influence how many packets might be dropped or marked. As long as any AQM encountered is not overly aggressive with ECN marking, sending half the flight size as credits should be sufficient whether congestion is signaled by loss or ECN. To maintain half of the packet in flight as credits, of course half [O] To maintain half of the packet in flight as credits, of course half [P] consider removing "of course" -- otherwise, put commas around it. [R] readability/grammer of the packet of the initial window must be C marked. In Slow Start marking every fourth packet introduces the correct amount of credit as can be seen in Figure 1. ... 5. Loss of ConEx information Packets carrying ConEx signals could be discarded themselves. This will be a second order problem (e.g. if the loss probability is 0.1%, the probability of losing a ConEx L signal will be 0.1% of 0.1% = 0.01%). Further, the penality an audit induces should be propotional [O] Further, the penality an audit induces should be propotional [P] Further, the penalty an audit induces should be proportionate [R] spelling x 2 to the mismatch of expected ConEx marks and observed congestion, therefore the audit might only slightly increase the loss level of this flow. Therefore, an implementer MAY choose to ignore this problem, accepting instead the risk that an audit function might wrongly penalize a flow. Nonetheless, a ConEx sender is responsible to always signal [O] responsible to always signal [P] responsible for always signalling [R] grammar sufficient congestion feedback and therefore SHOULD remember which packet was marked with either the L, the E or the C flag. If one of these packets is detected as lost, the sender SHOULD increase the respective gauge(s), LEG or CEG, by the number of lost payload bytes in addition to increasing LEG for the loss. 6. Timeliness of the ConEx Signals ConEx signals will only be useful to a network node within a time delay of about one RTT after the congestion occurred. To avoid further delays, a ConEx sender SHOULD send the ConEx signaling on the next available packet. Any or all of the ConEx flags can be used in the same packet, which allows delay to be minimised when multiple signals are pending. The need to set multiple ConEx flags at the same time, can occur if e.g [O] at the same time, can occur [P] at the same time can occur [R] unnecessary comma; grammar an ACK is received by the sender that simultaneously indicates that at least one ECN mark was received, and that one or more segements [O] segements [P] segments [R] spelling were lost. This may e.g. happen during excessive congestion, where [O] may e.g. happen uring excessive congestion, where [P] may happen during excessive congestion, if [R] readability the queues overflow even though ECN was used and currently all forwarded packets are marked, while others have to be dropped nevertheless. Another case when this might happen is when ACKs are [O] nevertheless. [P] [delete "nevertheless"] [R] readability lost, so that a subsequent ACK carries summary information not previously available to the sender. If a flow becomes application-limited, there could be insufficient bytes to send to reduce the gauges to zero or below. In such cases, the sender cannot help but delay ConEx signals. Nonetheless, as long as the sender is marking all outgoing packets, an audit function is unlikely to penalize ConEx-marked packets. Therefore, no matter how long a gauge has been positive, a sender MUST NOT reduce the gauge by more than the ConEx marked bytes it has sent. If the CEG or LEG counter is negative, the respective counter MAY be reset to zero within one RTT after it was decreased the last time or one RTT after recovery if no further congestion occurred. 7. Open Areas for Experimentation All proposed mechanisms in this document are experimental, and therefore further large-scale experimentation in the Internet is required to evaluate if the signaling provided by these mechanisms is accurate and timely enough to produce value for ConEx-based (traffic management or other) mechanisms. The current ConEx specifications assume that congestion is counted in number of bytes (including the IP header that directly encapsulates the CDO and everything that IP header encapsulates) [draft-ietf-conex-destopt]. This decision was taken because most network devices today expirience byte-congestion where the memory is [O] expirience [P] experience [R] spelling filled exactly with the number of bytes a packet carries. However, there are also devices that may allocate a certain amount of memory per packet, no matter how larger a packet is. These devices get congested based on the number of packets in their memory and therefore in this case congestion is determined by the number of packets that have been lost or marked. Furthermore, a transport layer endpoint, such as a TCP sender or receiver, might not know the exact number of bytes that a lower layer was carrying. Therefore a TCP endpoint may only be able to estimate the exact number of congested bytes (assuming that all lower layer header have the same length). If this estimation is sufficient to work with the ConEx [O] If this estimation is sufficient to work with the ConEx [P] If this estimation is sufficient to work with, the ConEx [R] readability signal needs to be further evaluated in tests in the Internet together with different auditor implementations. Further, the proposed marking schemes in this document are designed under the assumption that all TCP packets of a ConEx-capable flow are of equal size or that flows have a constant mean packet size over a rather small time frame, like one RTT or less. In most implementations this assumption might be taken as well and probably is true for most of the traffic flows. However, it should be evaluted how much the accuracy degrades if this precondition is not fulfilled, while the proposed scheme is used. Especially evaluating this with real traffic from different application is important to make a decision if the proposed schemes are sufficient or a more complexe scheme is needed. [O] However, it should be evaluted how much the accuracy degrades if this precondition is not fulfilled, while the proposed scheme is used. Especially evaluating this with real traffic from different application is important to make a decision if the proposed schemes are sufficient or a more complexe scheme is needed. [P] If this proposed scheme is used, it is necessary to evaluate how much accuracy degrades if this precondition is not met. Evaluating with real traffic from different applications is especially important in making the decision regarding whether the proposed schemes are sufficient or whether a more complex scheme is needed. [R] grammar, spelling, readability In this context the proposed scheme to set credit markings in Slow Start runs a risk to provide an insufficient number of markings which can cause an audit function to penalize this flow. Both the proposed credit scheme for Slow Start as well as the scheme in Congestion Avoidance must be evaluated together with one or more specific implementations of an ConEx auditor to ensure that both algorithms, in the sender and in the auditor, work propoerly together with a low [O] propoerly [P] properly [R] spelling risk of false positives (which would lead to penalization of an honest sender). However, if a sender is wrongly assumed to cheat, the penalization of the audit should be adequate and should allow an honest sender using a congestion control scheme that is commonly used today to recover quickly. Another open issue is the accuracy of the ECN feedback signal. At time of publication of this document there is no AccECN mechanism s pecified yet, and further AccECN will also take some time to be [O] s pecified yet, [P] specified yet, [R] spelling widely deployed. This document proposes an advanced compatibility mode for Classic ECN. The proposed mechanism can provide more accurate feedback by utilizing the way Classic ECN is speficed but [O] speficed [P] specified [R] spelling [O] loosing information [P] losing information [R] spelling this risk is in a real deployment scenario, further experimental evaluation is needed. The following argument is intended to prove that suppressing repetitions of ECE, however, is still safe against possible congestion collapse due to lost congestion feedback and should be further proven in experimentation: Repetition of ECE in classic ECN is intended to ensure reliable delivery of congestion feedback. However, with advanced compatibility mode, it is possible to miss congestion notifications. This can happen in some implementations if delayed acknowledgements are used. Further an ACK containing ECE can simply get lost. If [O] Further an ACK [P] Further, an ACK [R] readability only a few CE marks are received within one congestion event (e.g., only one), the loss of one acknowledgements due to (heavy) congestion on the reverse path can prevent that any congestion notification is received by the sender. However, if loss of feedback exacerbates congestion on the forward path, more forward packets will be CE marked, increasing the likelihood that feedback from at least one CE will get through per RTT. As long as one ECE reaches the sender per RTT, the sender's congestion response will be the same as if CWR were not continuous. The only way that heavy congestion on the forward path could be completely hidden would be if all ACKs on the reverse path were lost. If total ACK loss persisted, the sender would time out and do a congestion response anyway. Therefore, the problem seems confined to potential suppression of a congestion response during light congestion. Anyway, even if loss of all ECN feedback leads to no congestion [O] Anyway [P] Furthermore [R] tone response, the worst that could happen would be loss instead of ECN- signaled congestion on the forward path. Given compatibility mode does not affect loss feedback, there would be no risk of congestion collapse. 10. Security Considerations ... However, if the receiver is solely interested in making the sender draw down its allowance, the net effect will depend on the sender's congestion control algorithm as permanetly adding more and more [O] permanetly [P] permanently |
2015-10-01
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-10-01
|
09 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-09-30
|
09 | Barry Leiba | [Ballot comment] Section 7 is nice -- thanks for the detail. |
2015-09-30
|
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-09-30
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-09-30
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Warren Kumari. |
2015-09-30
|
09 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-09-30
|
09 | Alissa Cooper | [Ballot comment] Section 3.1.1: s/a ConEx MAY also chose to not componsate/a ConEx sender MAY also chose not to compensate/ Section 4.2: s/To maintain half … [Ballot comment] Section 3.1.1: s/a ConEx MAY also chose to not componsate/a ConEx sender MAY also chose not to compensate/ Section 4.2: s/To maintain half of the packet in flight/To maintain half of the packets in flight/ |
2015-09-30
|
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-09-30
|
09 | Ben Campbell | [Ballot comment] The IPR declaration at http://datatracker.ietf.org/ipr/1922/ lists this draft as a related work. I'm not sure what that means--but it's not mentioned in the … [Ballot comment] The IPR declaration at http://datatracker.ietf.org/ipr/1922/ lists this draft as a related work. I'm not sure what that means--but it's not mentioned in the shepherd write up. -- near end of 3.1: s/reransmission/retransmission |
2015-09-30
|
09 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-09-30
|
09 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-09-30
|
09 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-09-30
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-09-28
|
09 | Martin Stiemerling | Ballot has been issued |
2015-09-28
|
09 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2015-09-28
|
09 | Martin Stiemerling | Created "Approve" ballot |
2015-09-28
|
09 | Martin Stiemerling | Ballot writeup was changed |
2015-09-28
|
09 | Martin Stiemerling | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-09-23
|
09 | Martin Stiemerling | Changed consensus to Yes from Unknown |
2015-09-23
|
09 | Martin Stiemerling | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2015-09-14
|
09 | Ron Bonica | Request for Last Call review by GENART Completed: Ready. Reviewer: Ron Bonica. |
2015-08-31
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-08-26
|
09 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-08-26
|
09 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-conex-tcp-modifications-09, which is currently in Last Call, and has the following comments: We understand that this … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-conex-tcp-modifications-09, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object. If this assessment is not accurate, please respond as soon as possible. |
2015-08-26
|
09 | Martin Stiemerling | Placed on agenda for telechat - 2015-10-01 |
2015-08-26
|
09 | Takeshi Takahashi | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Takeshi Takahashi. |
2015-08-23
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Warren Kumari |
2015-08-23
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Warren Kumari |
2015-08-20
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ron Bonica |
2015-08-20
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ron Bonica |
2015-08-20
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Takeshi Takahashi |
2015-08-20
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Takeshi Takahashi |
2015-08-17
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2015-08-17
|
09 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TCP modifications for Congestion Exposure) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TCP modifications for Congestion Exposure) to Experimental RFC The IESG has received a request from the Congestion Exposure WG (conex) to consider the following document: - 'TCP modifications for Congestion Exposure' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-08-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1922/ |
2015-08-17
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2015-08-17
|
09 | Cindy Morgan | Last call announcement was generated |
2015-08-16
|
09 | Martin Stiemerling | Last call was requested |
2015-08-16
|
09 | Martin Stiemerling | Ballot approval text was generated |
2015-08-16
|
09 | Martin Stiemerling | Ballot writeup was generated |
2015-08-16
|
09 | Martin Stiemerling | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-08-16
|
09 | Martin Stiemerling | Last call announcement was generated |
2015-08-06
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-08-06
|
09 | Mirja Kühlewind | New version available: draft-ietf-conex-tcp-modifications-09.txt |
2015-07-22
|
08 | Martin Stiemerling | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::Point Raised - writeup needed |
2015-06-01
|
08 | Martin Stiemerling | The result of the expert review. Review by Wes Eddy: 1) I was very curious about implementation status, and saw that this part of the … The result of the expert review. Review by Wes Eddy: 1) I was very curious about implementation status, and saw that this part of the shepherd write-up had not been filled out, so I'm still curious whether it has been implemented. 2) In the first paragraph of section 1, I think it should be more clear whether the intent is to describe modifications to ConEx, to TCP, or to both. This would just help to make the scope more clear early on. 3) It's confusing that section 2 has a MUST for implementing SACK and ECN, but that the algorithms described in the document do not actually require SACK or ECN to be in use in order to basically work. It seems that this really should be a "SHOULD" rather than a "MUST", because it obviously makes sense to do, but proper operation doesn't actually require SACK and ECN. 4) Instead of "preferably with AccECN feedback" in section 2, I think this is a classical case where using "SHOULD" would be appropriate. 5) The second to last paragraph in section 2 has a "should" (lowercase) that might be better as a SHOULD, though it's not really clear to me. How exact the ConEx signal has to be in order to produce value for the network or flow(s) is not very clear, and probably an open research topic that would be good to mention, as this is going for Experimental and not all the answers are known. Some of the guidance in the document seems to be based purely on some trains of logic and reasoning rather than from measurements or experience that might (or might not) differ from logic and reason. 6) In section 3, the discussion of equal-sized packets seems like it would be of dubious use or clarity to someone implementing this. It seems to me like it would be pretty tough to figure out in the TCP code whether or not equal-sized packets or even equally distributed packet sizes are valid assumptions ahead of time for a given connection. At least, I can't imagine how this logic would work in general, beyond toy cases. 7) The last paragraph before section 3.1 (starting with "Otherwise, if a sender") is a really confusing paragraph for me, at least. I think the whole thing needs to be restructured and clarified. For instance "memorize or estimate" are two very different things, and it's not clear which is recommended or whether it's really the number of packets or of bytes in those packets that's relevant, the way other text is worded. In this section, in general, some high level simple equations, diagrams, or more clear sketch about the relation of the signals that show up in packets, the counters that are being kept, and the estimated or actual numbers of header and data bytes and packets being tracked. 8) Section 3.2.2 seems like it should be split up a bit. Part of it is purely describing how to perform the counter tracking, but much of it is just a handwaving argument about a possible way to get more than one ECE indication per CE mark by setting CWR continuously. While I think it's probably correct, it's really a confusing discussion without some diagram or walk-though scenarios, and unfortunately I don't think someone fresh that took up this document in order to write some code would have a good feeling about what they just should specifically do or not do after reading this section once or twice. It seems to me like a separate section or appendix could hold the discussion about this and note it as future research for experimentation. 9) Section 4.2 has "Howver" instead of "However". 10) In section 4.2, 5th paragraph, there are other flavors of startup behavior than just slow start, even published as RFCs (Limited Slow Start, Quick-Start, etc), and others in widespread implementations. Probably this means that the guidance in Section 4.2 should be phrased generically based on the behavior of startup and probing algorithms in general and not specific to the slow-start doubling. 11) I think "halve" should be "half" in 2 places in section 4.2. 12) There should definitely be a "Future Research" topics section, or something like this that identifies clearly why this has been brought as Experimental rather than Standards Track and suggests productive future work in some of the areas where the document waffles. 13) I know as an author, I may be biased, but I think the problem of loss estimation is not exactly the same as that of detecting and correcting from spurious retransmission events; some simple algorithms for loss estimation on a TCP sender are described and measured in an old paper: http://dl.acm.org/citation.cfm?id=974038&dl=ACM&coll=DL&CFID=678407041&CFTOKEN=41231580 The guidance in section 3.1 of this I-D about a sender using some heuristics to detect spurious retransmissions and account for them seems too unspecific to me, and I would guess that recommending a particular algorithm or construction for specifically measuring or estimating packet losses is more appropriate for implementers to understand what they need to do. 14) In general, I do think it can be read and understood, but I would also think it will not be easy to directly implement for someone without a lot of time to do their own research and look into the many tradeoffs or several open-ended parts of this document. It reads more like a general discussion of how to implement ConEx for TCP than a precise specification. |
2015-06-01
|
08 | Martin Stiemerling | IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation::External Party |
2015-05-26
|
08 | Martin Stiemerling | currently under expert review. |
2015-05-26
|
08 | Martin Stiemerling | IESG state changed to AD Evaluation::External Party from AD Evaluation |
2015-05-07
|
08 | Martin Stiemerling | IESG state changed to AD Evaluation from AD Evaluation::External Party |
2015-05-06
|
08 | Suresh Krishnan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Experimental. This document proposes some concrete algorithms for determining how much credit to signal during congestion avoidance and slow start. The wider goal of ConEx is to reflect the 'cost' of the risk of causing congestion on those that contribute most to it. Experimentation is encouraged to improve or maintain performance while reducing the risk of causing congestion (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). Working Group Summary This draft has been a working group document for about 4 years and has been well reviewed. There are no major issues open on the contents of this draft. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Suresh Krishnan is the document shepherd. Martin Stiemerling is the responsible area director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document and I believe that it is ready to be sent to the IESG for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The conex working group has not been very active recently. I would characterize the consensus behind this document to be strong, based on the strong concurrence of few individuals with others being silent. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document does not require any IANA action. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2015-04-27
|
08 | Martin Stiemerling | Intended Status changed to Experimental from None |
2015-04-22
|
08 | Mirja Kühlewind | New version available: draft-ietf-conex-tcp-modifications-08.txt |
2015-03-27
|
07 | Marcelo Bagnulo | Notification list changed to draft-ietf-conex-tcp-modifications@ietf.org, draft-ietf-conex-tcp-modifications.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org, "Suresh Krishnan" <suresh.krishnan@ericsson.com> from draft-ietf-conex-tcp-modifications@ietf.org, draft-ietf-conex-tcp-modifications.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org |
2015-03-27
|
07 | Marcelo Bagnulo | Document shepherd changed to Suresh Krishnan |
2015-02-17
|
07 | Cindy Morgan | Notification list changed to draft-ietf-conex-tcp-modifications@ietf.org, draft-ietf-conex-tcp-modifications.ad@ietf.org, conex-chairs@ietf.org, conex@ietf.org from draft-ietf-conex-tcp-modifications@ietf.org, draft-ietf-conex-tcp-modifications.ad@ietf.org, conex-chairs@ietf.org, draft-ietf-conex-tcp-modifications.shepherd@ietf.org, conex@ietf.org |
2015-02-17
|
07 | Martin Stiemerling | still waiting for the shepherd to be assigned. |
2015-02-17
|
07 | Martin Stiemerling | IESG state changed to AD Evaluation::External Party from AD Evaluation |
2015-02-14
|
07 | Mirja Kühlewind | New version available: draft-ietf-conex-tcp-modifications-07.txt |
2015-02-10
|
06 | Martin Stiemerling | Shepherd write-up and shepherd are missing. Chairs notified. |
2015-02-10
|
06 | Martin Stiemerling | IESG state changed to AD Evaluation from Publication Requested |
2015-02-09
|
06 | Nandita Dukkipati | State Change Notice email list changed to draft-ietf-conex-tcp-modifications@ietf.org, draft-ietf-conex-tcp-modifications.ad@ietf.org, conex-chairs@ietf.org, draft-ietf-conex-tcp-modifications.shepherd@ietf.org, conex@ietf.org |
2015-02-09
|
06 | Nandita Dukkipati | Responsible AD changed to Martin Stiemerling |
2015-02-09
|
06 | Nandita Dukkipati | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2015-02-09
|
06 | Nandita Dukkipati | IESG state changed to Publication Requested |
2015-02-09
|
06 | Nandita Dukkipati | IESG process started in state Publication Requested |
2014-11-13
|
06 | Mirja Kühlewind | New version available: draft-ietf-conex-tcp-modifications-06.txt |
2014-02-14
|
05 | Mirja Kühlewind | New version available: draft-ietf-conex-tcp-modifications-05.txt |
2013-07-15
|
04 | Mirja Kühlewind | New version available: draft-ietf-conex-tcp-modifications-04.txt |
2013-05-30
|
03 | Richard Scheffenegger | New version available: draft-ietf-conex-tcp-modifications-03.txt |
2012-11-22
|
(System) | Posted related IPR disclosure: British Telecommunications plc's statement about IPR claimed in draft-ietf-conex-abstract-mech-06 | |
2012-05-10
|
02 | Mirja Kühlewind | New version available: draft-ietf-conex-tcp-modifications-02.txt |
2012-03-12
|
01 | Mirja Kühlewind | New version available: draft-ietf-conex-tcp-modifications-01.txt |
2011-12-21
|
00 | (System) | New version available: draft-ietf-conex-tcp-modifications-00.txt |