[16:23:46] Melinda joins the room [16:24:05] Melinda leaves the room [22:08:39] Joao joins the room [22:10:22] chsharp@cisco.com joins the room [22:12:40] gigix73 joins the room [22:12:49] Matt Zekauskas joins the room [22:14:21] Leslie Daigle joins the room [22:14:40] Ted joins the room [22:14:48] Colman Ho joins the room [22:15:03] Hi, if you would like something reflected to the room, please let me know by putting *MIC* into your comment. [22:15:12] jlcJohn joins the room [22:15:43] I will be jabber scribing. If you don't have access to the audio stream, please let me know, otherwise, I will reference the slides. [22:15:52] On screen now, Connext BoF title slide. [22:16:07] er Conex BoF title slide [22:16:19] Chairs; Leslie, Phil [22:16:41] Carsten Bormann joins the room [22:16:45] Note well is reviewed [22:17:25] stpeter joins the room [22:17:29] Review of what has happened since Bar BoF in Stocklhom: GIIC workshop and BoF in Hiroshima [22:17:56] yoshifumi.nishida joins the room [22:17:57] (Agenda is here: http://www.ietf.org/proceedings/10mar/agenda/conex.txt ) [22:18:45] Charter developed on mailing list, IESG had some comments, these have been discussed on the list; the BoF is addressing the larger question of "why congestion exposure" [22:18:59] that this is important, tractable, engineering problem, in order to respond to IESG comments [22:19:10] Not a deep dive; the wiki has proposals etc. [22:19:55] adrianfarrel joins the room [22:19:58] are blue sheets going around? [22:20:25] Tomorrow has an additional session; the agenda for that will be posted after today's, taking into account what has happened so far. [22:20:29] don't think so, think I see the clipboards on the desk at the front [22:21:02] Stewart Bryant joins the room [22:21:09] Congestion exposure problem space slide up [22:21:23] Can someone point me to a definition of the term "congestion exposure"? thx [22:21:31] Congestion exposure, re-ecn is an implmentation, and there are also uses of congestion exposure. [22:21:54] chsharp: there is one in the proposed charter: http://www.ietf.org/iesg/evaluation/conex-charter.txt [22:22:01] Carsten Bormann leaves the room [22:22:13] to allow senders to inform the network of the level of congestion they expect their packets to encounter end-to-end. This information is currently only visible at the transport layer in the end systems. With the CONEX mechanism, it will be possible to provide sufficient information in each IP datagram so that any node along the network path can see the expected rest-of-path congestion. [22:22:28] And now the problem statement slide, with visuals [22:22:57] Next bit of meeting: traffic management problems, then Rich Woundy giving an ISP perspective on current solutions [22:23:11] Then Alissa Cooper will focus on traffic management approaches. [22:23:28] from the slides: congestion exposure is "A mechanism by which IP datagrams can signal the total rest-of-path congestion that they are expecting along the entire path they are traversing." [22:23:46] Are slides available on-line? [22:24:06] yes [22:24:12] https://datatracker.ietf.org/meeting/77/materials.html [22:24:21] search that page for "conex" [22:24:21] Leslie Daigle leaves the room [22:24:39] shikob joins the room [22:24:56] http://www.ietf.org/proceedings/10mar/slides/conex-1.pdf should be Mat's slides from the proceedings site [22:25:11] A/V logistics at the front of the room, vamp till ready [22:25:25] Headline: "Some data" [22:25:38] thx, not linked from the tools version of agenda. [22:26:01] reference to hOp://isoc.org/bandwidth [22:26:11] Other slides here: https://datatracker.ietf.org/meeting/77/materials.html (at "Conex") [22:26:17] hmm, copy-paste issue .... [22:26:26] Now on slide three [22:26:28] see http://isoc.org/bandwidth [22:26:37] "impact of broadband" [22:26:42] Now 4, reviewing impact of broadband [22:26:56] bob.briscoe joins the room [22:27:37] Showing the japanese example (slide 5) [22:28:46] Notes that this is not entirely representative, but a good indicator of markets with high-speed internet [22:29:02] Now onf 6, "Shifting sands"; notes increasing use of private peering [22:29:34] Notes that long tail requires a generalized solution [22:29:40] Now on "Pinch points", slide 7 [22:29:52] No active queue management at the edge [22:31:15] Conclusions: potential impact of individual subscribers on bottleneck links increases; more applications competing; additional capacity may not be cost-effective solution [22:31:30] Current tools have limitations, alternative schemes need to be evaluated [22:31:32] Slide 8 [22:31:44] Questions? [22:32:25] Hannes: There is also an MIT project which is trying to get access to operator data to run similar analysis [22:32:34] that may give us valuable data sources in the next few months. [22:32:39] (It is not yet available) [22:32:59] Dave McDyson: there is another aspect [22:33:14] satoru.matsushima joins the room [22:33:29] Leslie Daigle joins the room [22:33:34] Congestion which occurs at these bottlenecks that occur over limited periods of time. [22:34:02] There is a "busy hour"; is it within scope to look at incentives to balance traffic over time. [22:34:07] Is this in scope? [22:34:31] Leslie notes that this part of the point; you'll see more of this in Alissa's presentation. [22:34:39] Richard Woundy: [22:34:47] Perspectives on Congestion Exposure. [22:34:59] Agenda slide for his presentation up now [22:35:12] Constraints for an ISP slide. [22:35:32] (must be responsive, must balance external concerns, capacity increases are not instantaneous) [22:35:45] Comes down to: what is the impact on the customer? [22:36:01] If people call, do we know what is going on? Sometimes yes. [22:36:05] Stewart Bryant leaves the room [22:36:24] But it could be outside our network but mainly having an impact on our network. [22:36:33] Carsten Bormann joins the room [22:37:07] Notes that regulators in the U.S. are asking about the impact of congestion. what is the feedback mechanism? [22:37:32] These concerns are also external concerns. [22:38:11] Example of delay in increasing capacity: difficulty reaching site due to weather or access controls. [22:38:29] Now on "Requirements for a Long term solution" [22:38:41] Aim is to provide best network experience for broadest set of customers. [22:38:49] Trying to minimize cross-customer service. [22:38:57] Financially: reduce customer care calls. [22:39:15] Enable the customers to control their own experience [22:39:24] Enable continued Internet evolution [22:39:30] Support a reasonable network capacity [22:39:48] ford@jabber.isoc.org joins the room [22:40:22] Now on Potential use cases for congestion exposure [22:40:42] How could it be used? As an input to congestion management. [22:40:55] Discovery and diagnosis of "whole path" congestion issues. [22:43:48] Gives an example: we were being accused of throttling an online gaming application. [22:44:10] Only information available on internal blog, which required being a customer of the game. [22:44:26] Carsten Bormann leaves the room [22:44:36] But this did not resolve the problem; to submit a query, they had to play up to level 5 in the game to pose the questions. [22:44:55] After they did, they were able to get the diagnosis done. [22:44:59] He's now at level 11 [22:45:20] Maybe at some point conex will help work around DDOS. [22:45:34] (if malware writers don't work around it succesfully) [22:45:41] Now on "Next Steps for Engineering" [22:46:29] Two aspects to the Congestion Exposure ecosystems: software implementation ecosystem; network deployment ecosystem [22:46:47] The first is in progress; the second requires isps, app and content providers, and consumers/home networks [22:47:03] Carsten Bormann joins the room [22:47:06] That may 2-3 years for funding, protyping, lab testing, etc. [22:47:14] This is just for the engineering issues. [22:48:04] Dave McDysan/Verizon: Scope question--will that be discussed today on what use cases and which bottlenecks are in scope? [22:48:40] Really a question to the chairs. [22:49:01] This is the scope of the discussion of the charter--the current charter doesn't have use cases as the heart of the charter. [22:49:05] They are examples. [22:49:49] No proposal to standardize the use cases; we can talk about that, but it is a question of an approach. At the moment, it is about creating a generative technology. [22:50:27] Hannes: Thanks for sharing the solution you've showed the community. He hopes other operators will follow your lead. [22:50:53] It would be interesting to see a more generic solution, whether it is within this group or not. What can be done today is an interesting question for the transition period. [22:51:08] Interesting properties: protocol agnostic is one. [22:51:29] Rich is participating in the MIT project and will help get the data to the WG. [22:51:45] Alisa reviews the reasons for doing traffic management. [22:51:56] Cheaper, schedule management, fine-grained control [22:53:00] Just throwing capacity at the problem: straightforward, meets growing deman [22:53:26] Drawbacks: expensive, cannot increase peer networks capacity, not amenable to market segmentation, costs spread across all customers [22:54:22] Current approaches: volume-based, rate-based, application-based. Combinations of the above, addressing two design decisions [22:54:35] What metric for the decision and what is the action to be taken? [22:55:09] Now reviewing volume-based: uses bytes over some time frame [22:55:24] It's simple and can be used for either caps or penalties. [22:55:46] drawbacks: restrictive in times of little traffic; not restrictive enough in times of lots of traffic. [22:57:06] Next approach is rate-based; transmission rate per user [22:57:28] simple, but overconstrains in low usage periods and underconstrained during high volume periods [22:57:40] Application-based, limits throughput of specific applications. [22:58:04] Benefits: sensitive to app characteristics and same tools (DPI) may also be in use. [22:58:31] Drawbacks: arms race with apps developers, expensive, high upgrade cycle, and may have public policy issues. [22:58:46] Combinations now being discussed. [22:59:00] Lars joins the room [22:59:05] Use volume to identify heavy users, then limit their rate or app usage. [22:59:23] Now reviewing congestion exposure's benefits. [22:59:36] Creates incentives for approaches like LEDBAT [23:00:13] Exposes end-to-end congestion. Requires transparency to every node, which may help capacity palanning [23:00:29] avoids app-specific issues. [23:00:46] enables internet-wide solutions [23:01:08] Questions? [23:01:38] Dave McDysan: this is a good taxonomy [23:02:03] But it gets back to an access-network oriented scope. Do we care about transit provider issues? [23:03:18] Discussion of characteristics of different networks on this effort. [23:03:33] Leslie: largely what we've seen today, but certainly not the only place. [23:03:57] Now there is a pause: to ensure we're all clear that we have an agreed scope. [23:04:30] Everyone seems to be clear on the scope, based on the "silence is agreement" model. [23:04:52] Now on to the Charter text discussion. Not all will get discussed today, but the meeting tomorrow will pick up where we leave off today. [23:04:59] satoru.matsushima leaves the room [23:05:22] First slide is the heart of the charter, describing the "heart"--the generative technology. [23:06:16] Is it any node in the network or any node in the path? [23:07:00] Someone from microsoft: This is coming across as very wired network-specific. [23:07:17] Exposing ip-related feedback into the network may not work for wireless. [23:07:57] Matt Mathias: related comment--is it worth doing some test marketing to people have not read it before and ask them whether they know what it means. [23:08:33] The language is future tense about anticipated congestion, where the bits are about what happened in the past. [23:09:29] Leslie asked whether the IESG is a good model for this; Matt responds maybe, but they are a bit spoiled, having had one discussion already. [23:10:09] Actually, Leslie asked if this clarified material for the IESG concerns [23:10:11] Hannes responds to the previous speaker on the wireless carrier issue--more participation is valuable, and there are different issues in how congestion develops and fades in the wireless networkis. [23:10:17] (Thanks for the correction) [23:10:46] Ingemar Johansson [23:11:02] Ingemar plans to submit a document to the IETF that covers wireless. [23:11:14] Carsten Bormann leaves the room [23:12:05] Lars Eggart: he's a little disappointed. The charter had good consensus, then a rough trip through the IESG/IAB. He'd have liked to see more people with dots at the mics. If there were here today, some resolution by the next session would be possible. [23:12:47] Adrian Farrel has not really found this session useful in resolving his issues, though he would agree that parsing the future historic tense of the paragraph here. [23:12:57] gigix73 leaves the room [23:13:22] Once had parsed that, he was able to understand where the group was going, but he is still not convinced that there is demand for it. [23:13:41] He is cautious about burning cycles on items that might not get traction. [23:14:14] Leslie is happy to address the detailed comments once the core question of whether this IETF or IRTF work; she had hoped that the presentations today would address that. [23:14:37] Henry from BT: He's not sure how this would get deployed. [23:14:48] It may need to clarification in the charter. [23:15:37] Leslie's point--you don't deploy just "this", you deploy something based on this. If we don't have a generative technology, it's not clear how we move forward. [23:15:55] Lars thanks Adrian for sticking his head out on this and taking point on resolution. [23:16:30] David Harrington had some concerns that he wasn't sure how this was to be used inter-provider and whether there wasn't an incentive to cheat. [23:16:39] Closed the mic to let them re-sort the room. [23:16:40] Lars leaves the room [23:16:40] yoshifumi.nishida leaves the room [23:16:43] Thanks see you tomorrow. [23:16:46] ford@jabber.isoc.org leaves the room [23:16:48] Ted leaves the room [23:16:48] adrianfarrel leaves the room [23:16:52] bob.briscoe leaves the room [23:16:52] Leslie Daigle leaves the room [23:17:18] jlcJohn leaves the room [23:18:18] Colman Ho leaves the room [23:19:15] Joao leaves the room [23:19:25] stpeter leaves the room: Logged out [23:21:52] chsharp@cisco.com leaves the room [23:24:09] Matt Zekauskas leaves the room [23:32:19] Carsten Bormann joins the room [23:32:42] shikob leaves the room [23:40:07] Carsten Bormann leaves the room [23:40:24] Colman Ho joins the room [23:41:23] Matt Zekauskas joins the room [23:41:42] Colman Ho leaves the room [23:43:50] Carsten Bormann joins the room [23:46:05] Leslie Daigle joins the room [23:48:34] stpeter joins the room [23:53:57] Matt Zekauskas leaves the room