Congestion Exposure (ConEx) Concepts and Use Cases
draft-ietf-conex-concepts-uses-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-10-05
|
05 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2012-10-05
|
05 | (System) | IANA Action state changed to No IC |
2012-10-05
|
05 | Cindy Morgan | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-10-05
|
05 | Cindy Morgan | IESG has approved the document |
2012-10-05
|
05 | Cindy Morgan | Closed "Approve" ballot |
2012-10-05
|
05 | Cindy Morgan | Ballot approval text was generated |
2012-10-05
|
05 | Wesley Eddy | Ballot writeup was changed |
2012-10-05
|
05 | Wesley Eddy | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-08-10
|
05 | Martin Stiemerling | [Ballot comment] Excellent document, just two minor issues: - I can understand that in Section 1 the overview of the documents was added, but I … [Ballot comment] Excellent document, just two minor issues: - I can understand that in Section 1 the overview of the documents was added, but I wonder why these individual drafts are listed: - [I-D.briscoe-conex-initial-deploy] - [I-D.briscoe-conex-data-centre] They are also mentioned down in the draft in Section 5. The point is that they describe some potential cases, but are not agreed with the WG. I would remove them. - This ref seems to be missing some information, e.g., where it was published! [Bauer09] Bauer, S., Clark, D., and W. Lehr, "The Evolution of Internet Congestion", 2009. |
2012-08-10
|
05 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2012-08-09
|
05 | Ron Bonica | [Ballot comment] This may be a DISCUSS-DISCUSS, but I would like to pose the following questions: 1) Can CONEX distinguish between congestion that occurs on … [Ballot comment] This may be a DISCUSS-DISCUSS, but I would like to pose the following questions: 1) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs downstream?. For example, assume that my ISP deploys CONEX. Assume also that a loss-prone link connects my PC to the CPE router in my kitchen. The TCP stack on my PC will report lots of loss. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network? 2) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs upstream? For example, assume that my ISP deploys CONEX. Assume also that I subscribe to a stream that incurs loss before it hits my ISPs network. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network? 3) Is the applicability of CONEX restricted to access networks, where it is possible to deploy per-user policers at the distant end of the network from the user? 4) Can CONEX markings be used as an attack vector? 5) How will CONEX behave in networks where incoming traffic can be characterized as follows: 90% is streaming UDP over IP multicast 10% is TCP. In this example, assume that multicast traffic is responsible for 90% of the congestion and that the multicast receivers send traffic in the reverse direction very infrequently. 6) How will CONEX work in a transition scenario, when some transport layer stacks are CONEX aware and others are not. 7) Does CONEX encourage traffic originators to falsify congestion markings? |
2012-08-09
|
05 | Ron Bonica | [Ballot Position Update] Position for Ronald Bonica has been changed to No Objection from Discuss |
2012-07-16
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-07-16
|
05 | Alissa Cooper | New version available: draft-ietf-conex-concepts-uses-05.txt |
2012-04-18
|
04 | Benoît Claise | [Ballot comment] Initially, I put a DISCUSS-DISCUSS because I was missing some information to correctly review the draft (This was advised by Ron Bonica). Discussing … [Ballot comment] Initially, I put a DISCUSS-DISCUSS because I was missing some information to correctly review the draft (This was advised by Ron Bonica). Discussing with Wes Eddy off line, maybe I should have put "Defer". Anyway, sorry for the confusion. Now that I had a 1:1 with Eddy, many points are clarified, and here is my feedback. - One of my confusion reading the draft was that I was missing the link with RFC3168. After a conf. call with Wes Eddy, I understand that your plan is to use an IPv6 destination option, and that RFC3168 is a very not required (but might be used, if I read http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-03#section-3 correctly). It would be nice to say a few words about this in the draft. - From the charter: The purpose of the CONEX working group is to develop a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Question about how to do define the notion of flow inside the IP layer? I see an IPv6 destination option in http://tools.ietf.org/html/draft-ietf-conex-destopt-02, but I don't see any encoding for a flow in there? - Section 1, Introduction As described in Figure 1, congestion control currently relies on the transport receiver detecting these 'Congestion Signals' and informing the transport sender in 'Congestion Feedback Signals.' Do you always assume that, because you receive a congestion signals for a specific TCP session, the congestion is for this entire session? I see more and more cases for which a router does a Deep Packet Inspection, and treat applications differently, as opposed to the 5 tuple. Is this a use case for CONEX? Without a DPI engine on the sender, I don't see how this could work... - What is happening in case of ECMP? One router is congested, and not the other one. Is the CONEX enabled sender clever enough to mark only the affected flow (based on the 5 tuple)? - Following on the two previous points, I would like to see the issues/limitations documented. Issue 1: one round trip late Issue 2: the congested device MUST support CONEX. The Sender MUST support CONEX Issue 3: DPI engine must be supported on the sender, if we want to differentiate per application Issue 4: ECMP (if this is one) Issue 5: not UDP etc.. From there, the use cases are limited. I see one though: managed services, bought by an enterprise customer, out of a single service provider - Section 2.3 "rest-of-path congestion" (also known as "downstream congestion") is the level of congestion that a traffic flow is expected to experience between the measurement point and its final destination. What is a flow? The draft doesn't tell if the congestion is at layer 3, layer 4 or layer 7. In contrast, the ConEx signals inserted into IP headers as shown in Figure 1 indicate the congestion along a whole path from source to destination. source and destination what? IP addresses, or IP address/protocol/ports, or maybe IP address/protocol/ports/session id. That's a key question in my mind. Same remark in section 2.4, what is user's traffic Congestion: In general, congestion occurs when any user's traffic suffers loss, ECN marking, or increased delay as a result of one or more network resources becoming overloaded. - Section 2.4 definitions You define congestion here, while section 2.1 already defines congestion The definition used for the purposes of ConEx is expressed as the probability of packet loss (or the probability of packet marking if ECN is in use). This definition focuses on how congestion is measured, rather than describing congestion as a condition or state. - Section 3.1 By deploying a congestion policer at the BRAS location, the network operator can measure the congestion-volume created by users within the access nodes and police misbehaving users before their traffic affects others on the access network. My issue (again) with this use case, is if the BRAS sees a high congestion-volume ratio, it will police all traffic from that users. However, that users might at the same time be part of a webex call (voice + video), doing a backup, and downloading with P2P. And the flow/session/application (to be clarified) you want to slowdown are the P2P, then then backup, and not the webex. - 6. Security. Am I able to send a message (from my own IP address) with an IPv6 destination option containing the IP address of my neighbor, so that his packets are slowed down, and I can benefit from the full cable infrastructure? Seems like an important question... |
2012-04-18
|
04 | Benoît Claise | Ballot comment text updated for Benoit Claise |
2012-04-12
|
04 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Shawn Emery. |
2012-04-12
|
04 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-04-12
|
04 | Benoît Claise | [Ballot comment] Regarding my clarifying questions, Wes and I will take it off line. |
2012-04-12
|
04 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2012-04-12
|
04 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2012-04-12
|
04 | Benoît Claise | [Ballot discuss] This is a DISCUSS-DISCUSS I'm busy reviewing https://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/, and I have some clarifying questions on CONEX first. Let me ask them here, … [Ballot discuss] This is a DISCUSS-DISCUSS I'm busy reviewing https://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/, and I have some clarifying questions on CONEX first. Let me ask them here, instead of (potentially) polluting the draft review process. Looking at the CONEX charter, I'm unable to find the connection with the RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP"? In other words, what's the issue with RFC3168 that needs to be solved in this WG? Or this WG about the sender relaying the congestion information (from the transport protocol) back into the network in-band at the IP layer, and that would be done with RFC3168? Please let know. draft-ietf-conex-concepts-uses-04 is not clear about the link with RFC3168 Or this WG is about a CONEX enabled router to monitor and have policies based on the congestion-volume? To understand congestion-volume, consider a simple example. Imagine Alice sends 1GB while the loss-probability is a constant 0.2%. Her contribution to congestion -- her congestion-volume -- is 1GB x 0.2% = 2MB. If she then sends 3GB while the loss-probability is 0.1%, this adds 3MB to her congestion-volume. Her total contribution to congestion is then 2MB+3MB = 5MB. I.e.: Alice flow 1 (characterized by IPFIX I.E.s if we want to export the flow ), counter = 1 GB, average loss-probability = 0.2 Alice flow 2 (characterized by IPFIX I.E.s if we want to export the flow), counter = 3 GB, average loss-probability = 0.1 |
2012-04-12
|
04 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2012-04-12
|
04 | Wesley Eddy | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-04-12
|
04 | Ralph Droms | [Ballot comment] I could use a little help understand the example in section 3.1. Do I have it right that ConEx is used to provide … [Ballot comment] I could use a little help understand the example in section 3.1. Do I have it right that ConEx is used to provide information about congestion in a flow to devices that are not directly experiencing the congestion? In the use case in section 3.1, the congestion policer is placed exactly at the point where the existence of congestion is known. Why is any signaling mechanism needed at all? In the first paragraph of section 3.2, how does ConEx specifically encourage the use of scavenger transport protocols, relative to other congestion policing mechanisms? Does the second paragraph of section 3.2 suggest that ConEx is used to actively affect traffic management in a way that is not directly related to congestion experienced at the user device? That is, the receiver uses artificially generated congestion signals to cause ConEx marking that affects its received traffic. This use case is fine, except that labeling the receiver->sender signaling as "congestion feedback" is no longer accurate. |
2012-04-12
|
04 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-04-12
|
04 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-04-12
|
04 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-04-12
|
04 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-04-11
|
04 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-04-11
|
04 | Sean Turner | [Ballot discuss] Interesting that congestion-volume can be measured in one of two ways. If I'm the user in s3.2 (or in the last para of … [Ballot discuss] Interesting that congestion-volume can be measured in one of two ways. If I'm the user in s3.2 (or in the last para of s3.3) will I know which measurement technique was used? Is it up to the operator to decide which one to use? |
2012-04-11
|
04 | Sean Turner | [Ballot comment] s2.2: Maybe: Congestion-volume is a property of traffic, whereas congestion describes *a property of* a link or a path. s3.1: … [Ballot comment] s2.2: Maybe: Congestion-volume is a property of traffic, whereas congestion describes *a property of* a link or a path. s3.1: 1st para: manage really meanest throttle and management means throttling right ;) s3.1: I'm obviously not hard over on either of these: Monitor is much a nicer term than policer, but maybe monitor is overloaded. Also "police traffic" maybe "manage misbehaving". s3.3: For give the security guy, but "scavenger transports" refers to ... Vultured TCP (vTCP)? |
2012-04-11
|
04 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2012-04-11
|
04 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-04-11
|
04 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2012-04-10
|
04 | Pearl Liang | IESG: IANA has reviewed draft-ietf-conex-concepts-uses-04.txt, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any … IESG: IANA has reviewed draft-ietf-conex-concepts-uses-04.txt, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. |
2012-04-10
|
04 | Alexey Melnikov | Request for Telechat review by GENART Completed. Reviewer: Alexey Melnikov. |
2012-04-10
|
04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-04-10
|
04 | Brian Haberman | [Ballot comment] In general, this is a good high-level description of what the community should expect in the coming CONEX drafts. I do have a … [Ballot comment] In general, this is a good high-level description of what the community should expect in the coming CONEX drafts. I do have a few questions though... 1. The draft talks about attributing congestion-volume contributions. Shouldn't there be some description of how that would be done? That sounds like a lot of state to maintain when congestion begins to occur. 2. Conceptually, if a CONEX-aware device in a network sees 10 packets of varying size from a single source and all have these CONEX markings, how do I equate the congestion-volume contribution of that source? Are there assumptions made about the packets' characteristics *in the last RTT* based on the packets seen in the current RTT? |
2012-04-10
|
04 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-04-10
|
04 | Stephen Farrell | [Ballot comment] Section 2.4: what (if any) metric is used for rest-of-path and upstream- congestion? Is it volume? If so, or if not, be good … [Ballot comment] Section 2.4: what (if any) metric is used for rest-of-path and upstream- congestion? Is it volume? If so, or if not, be good to say that. |
2012-04-10
|
04 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-04-10
|
04 | Ron Bonica | [Ballot discuss] This may be a DISCUSS-DISCUSS, but I would like to pose the following questions: 1) Can CONEX distinguish between congestion that occurs on … [Ballot discuss] This may be a DISCUSS-DISCUSS, but I would like to pose the following questions: 1) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs downstream?. For example, assume that my ISP deploys CONEX. Assume also that a loss-prone link connects my PC to the CPE router in my kitchen. The TCP stack on my PC will report lots of loss. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network? 2) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs upstream? For example, assume that my ISP deploys CONEX. Assume also that I subscribe to a stream that incurs loss before it hits my ISPs network. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network? 3) Is the applicability of CONEX restricted to access networks, where it is possible to deploy per-user policers at the distant end of the network from the user? 4) Can CONEX markings be used as an attack vector? 5) How will CONEX behave in networks where incoming traffic can be characterized as follows: 90% is streaming UDP over IP multicast 10% is TCP. In this example, assume that multicast traffic is responsible for 90% of the congestion and that the multicast receivers send traffic in the reverse direction very infrequently. 6) How will CONEX work in a transition scenario, when some transport layer stacks are CONEX aware and others are not. 7) Does CONEX encourage traffic originators to falsify congestion markings? |
2012-04-10
|
04 | Ron Bonica | Ballot discuss text updated for Ronald Bonica |
2012-04-09
|
04 | Ron Bonica | [Ballot discuss] This may be a DISCUSS-DISCUSS, but I would like to pose the following questions: 1) Can CONEX distinguish between congestion that occurs on … [Ballot discuss] This may be a DISCUSS-DISCUSS, but I would like to pose the following questions: 1) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs downstrea?. For example, assume that my ISP deploys CONEX. Assume also that a loss-prone link connects my PC to the CPE router in my kitchen. The TCP stack on my PC will report lots of loss. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network? 2) Can CONEX distinguish between congestion that occurs on the local network and congestion that occurs upstream? For example, assume that my ISP deploys CONEX. Assume also that I subscribe to a stream that incurs loss before it hits my ISPs network. My ISP will detect this and when it congests, it will penalize me even further, even though I am not contributing to loss on the ISP's network? 3) Is the applicability of CONEX restricted to access networks, where it is possible to deploy per-user policers at the distant end of the network from the user? 4) Can CONEX markings be used as an attack vector? |
2012-04-09
|
04 | Ron Bonica | [Ballot comment] In Section 3.1, please be specific about the policer counting IP-Layer-ConEx-Signals, and not Congestion-Feedback-Signals |
2012-04-09
|
04 | Ron Bonica | [Ballot Position Update] New position, Discuss, has been recorded for Ronald Bonica |
2012-04-06
|
04 | Adrian Farrel | [Ballot comment] A fine document that would have been enhanced by a short exposure of the Conex references to live up to the "entry point" … [Ballot comment] A fine document that would have been enhanced by a short exposure of the Conex references to live up to the "entry point" claim. --- Classic ASCII-art. Well done! |
2012-04-06
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-04-05
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2012-04-05
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2012-04-04
|
04 | Alexey Melnikov | Request for Last Call review by GENART Completed. Reviewer: Alexey Melnikov. |
2012-04-03
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2012-04-03
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2012-03-30
|
04 | Wesley Eddy | Ballot has been issued |
2012-03-30
|
04 | Wesley Eddy | [Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy |
2012-03-30
|
04 | Wesley Eddy | Ballot writeup was changed |
2012-03-30
|
04 | Wesley Eddy | Created "Approve" ballot |
2012-03-30
|
04 | Wesley Eddy | Placed on agenda for telechat - 2012-04-12 |
2012-03-29
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2012-03-29
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2012-03-29
|
04 | Amy Vezza | Last call sent |
2012-03-29
|
04 | Amy Vezza | State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (ConEx Concepts and Use Cases) to Informational RFC The IESG has received a request from the Congestion Exposure WG (conex) to consider the following document: - 'ConEx Concepts and Use Cases' as an Informational 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 2012-04-12. 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 This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-conex-concepts-uses/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-03-29
|
04 | Wesley Eddy | Last call was requested |
2012-03-29
|
04 | Wesley Eddy | Last call announcement was generated |
2012-03-29
|
04 | Wesley Eddy | Ballot approval text was generated |
2012-03-29
|
04 | Wesley Eddy | Ballot writeup was generated |
2012-03-29
|
04 | Wesley Eddy | State changed to Last Call Requested from AD Evaluation |
2012-03-28
|
04 | Wesley Eddy | State changed to AD Evaluation from Publication Requested |
2012-03-28
|
04 | Cindy Morgan | (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? … (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? The working group is requesting that ConEx Concepts and Use Cases be published as an Informational RFC, as indicated in the document's title page header. The document provides motivation for exposing path congestion information to the network nodes and discusses how such information can be used in network traffic management. It outlines the congestion exposure (ConEx) principle, discusses its use in practical networks, and paves the way for future documents to detail the protocol, mechanisms, packet formats etc., hence an Informational status is appropriate. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. ConEx Concepts and Use Cases document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. The document explains the motivation for including a ConEx marking at the IP layer, which is to expose the path congestion information to the network nodes. It particularly focuses on how the ConEx marking can serve as the basis for more efficient and effective traffic management than what exists on the Internet today. The main idea of ConEx is for the sender to continually signal expected congestion in the headers of any data it sends. To a first approximation, the sender does this by relaying the 'Congestion Feedback Signals' such as ECN back into the IP layer. This information travels unchanged across the network to the receiver and enables the intermediate IP layer devices to observe information about the whole path congestion. The document describes several use cases of exposing congestion and delves into a particular use case of how network operators can perform better traffic management. It describes how ConEx based traffic management can make highly efficient use of capacity. In times of no congestion, all traffic management restraints can be removed, leaving the network's full capacity available to all its users; on the other hand if some users on the network cause disproportionate congestion, the traffic management function can learn about this and directly limit those users' traffic in proportion to the congestion caused by them and protect the service of other users sharing the same capacity. ConEx based traffic management presents a significant change in terms of the options available to network operators for managing traffic on their networks. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document is a result of a many hours/emails of discussion spanned over 20 months. Two points that stand out in the WG process are: 1. In the beginning, the document was a mix of a several closely related use cases for ConEx. After much discussion, the document zeroed in on the central use case of ConEx which is informing traffic management, while also providing a discussion of other benefits of ConEx in a separate section. Even though this process took some time, it ultimately helped shape the clarity and focus of the current document. 2. The working group also had an intense discussion on whether the role of statistical multiplexing over longer timescales should be a separate use case. It was ultimately folded in with one of the existing use cases. 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? There are no existing implementations of the protocol and is not expected to be as this point. The ConEx Concepts and Use Cases document serves as an introduction and motivation for the upcoming documents that describe more precisely the ConEx mechanisms, IPv6 packet formats and TCP modifications. We expect vendor implementations as we get closer to publishing all the exact ConEx mechanisms. Phil Eardley has performed a thorough technical review of a previous version of this document. All his comments have been taken care of. Phil Eardley's review improved the quality and readeability of the document, but there is no substantive change in direction as such. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Nandita Dukkipati is the document shepherd. Wesley Eddy 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. The document provides the motivation for ConEx. It explains the key concepts in ConEx and goes on to use these concepts to describe how ConEx can significantly improve Internet traffic management. It presents a convincing case of how ConEx can be effectively used for traffic management, while also discussing other benefits of ConEx. The document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The reviews have been thorough both in depth and breadth and the shepherd has no concerns about them. (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. The document serves as a motivation and introduces the Congestion Exposure concept and as such does not require any of the above mentioned specific reviews. (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. The document shepherd does not have any specific concerns or issues with the current document. (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. All authors of this document have confirmed that there are no IPR dsclosures on the document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is no IPR disclosure filed that references this document. (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? Overall, the consensus is strong. The working group as a whole understands and agrees with the document. A few individuals have a preference for certain specific use cases, such as the role of ConEx in statistical multiplexing over different timescales and/or to attach equal importance to all problems that Conex solves. That aside, there is a general consensus that the document reads better when focussed on a central use case and discussing that at length as opposed to rambling on all use cases. (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.) There has been no such such threat of an appeal or extreme discontent. (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. No errors or warnings found. idnits 2.12.13 /tmp/draft-ietf-conex-concepts-uses-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (March 2, 2012) is 23 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-briscoe-conex-initial-deploy - is the name correct? -- No information found for draft-ietf-conex-abstract-mech - is the name correct? -- No information found for draft-kuehlewind-conex-accurate-ecn - is the name correct? -- No information found for draft-kuehlewind-conex-tcp-modifications - is the name correct? Summary: 0 errors (**), 0 warnings (==), 5 comments (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such formal reviews have been required as no MIB media type or URI type is specified in the document. (13) Have all references within this document been identified as either normative or informative? Yes. All references are identified as informative. (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? There are no normative references. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. The document does not have any downward normative references. (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. The publication of this document does not change the status of any existing RFCs. (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 IANA Consideration section correctly mentions that the document does not require actions by IANA. The document does not introduce any specific mechanism or protocol and hence there is no need for any IANA considerations. (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. There are no new IANA registries. (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. The document does not contain any XML codes, BNF rules or MIB definitions. |
2012-03-28
|
04 | Cindy Morgan | State changed to Publication Requested from AD is watching |
2012-03-28
|
04 | Cindy Morgan | Note added 'Nandita Dukkipati (nanditad@google.com) is the document shepherd.' |
2012-03-28
|
04 | Cindy Morgan | Intended Status changed to Informational from None |
2012-03-02
|
04 | Alissa Cooper | New version available: draft-ietf-conex-concepts-uses-04.txt |
2011-10-25
|
03 | (System) | New version available: draft-ietf-conex-concepts-uses-03.txt |
2011-07-11
|
02 | (System) | New version available: draft-ietf-conex-concepts-uses-02.txt |
2011-04-01
|
03 | Wesley Eddy | State changed to AD is watching from Publication Requested. |
2011-04-01
|
03 | Wesley Eddy | Draft added in state Publication Requested |
2011-03-14
|
01 | (System) | New version available: draft-ietf-conex-concepts-uses-01.txt |
2010-11-18
|
00 | (System) | New version available: draft-ietf-conex-concepts-uses-00.txt |