[00:01:13] stpeter leaves the room: Logged out [00:01:48] Leslie Daigle leaves the room [00:02:22] stpeter joins the room [00:02:33] stpeter leaves the room [02:21:21] Carsten Bormann leaves the room [05:40:10] Stewart Bryant joins the room [06:46:25] Stewart Bryant leaves the room [14:28:28] Stewart Bryant joins the room [14:51:48] Stewart Bryant leaves the room [16:05:44] Stewart Bryant joins the room [18:08:02] beroset joins the room [18:08:06] beroset leaves the room [18:08:19] beroset joins the room [18:08:25] beroset leaves the room [18:25:21] Stewart Bryant leaves the room [18:56:24] Stewart Bryant joins the room [20:04:05] Stewart Bryant leaves the room [20:25:18] Stewart Bryant joins the room [21:19:48] Stewart Bryant leaves the room [22:06:45] Joao joins the room [22:09:37] Ted joins the room [22:13:02] Stewart Bryant joins the room [22:14:22] Chairs are brining the BoF to order; part b [22:14:46] Colman Ho joins the room [22:14:59] gigix73 joins the room [22:15:07] Review of the note well, and re-welcome. [22:15:09] satoru.matsushima joins the room [22:15:20] Matt Zekauskas joins the room [22:15:37] Atarashi Yoshifumi joins the room [22:15:54] Summary of feedback: hard to parse the charter; lack of clarity of what "it" is in the charter. It should all be experimental. Danger of too many cycles "It's IRTF", and questions of how it works with MPLS. [22:16:15] The BoF chairs have tried to distill the community feedback and adjust the Charter to take it into account. [22:16:28] Leslie Daigle joins the room [22:16:47] gorryf joins the room [22:16:51] Slides are posted to the meeting materials page [22:17:30] "It" is the 'generative technology"--the building block . That is the main proposed work [22:17:53] Slide shows the relationship of that technology to other, related issues. [22:18:09] Reviewing the current charter text on generative technology [22:18:41] Major work items are: experimental Specification of v4 and v6 packet structure to encapsulate CONEX (header bits, interpretation) [22:19:02] Experimental Spec for modifications to TCP to timely transpart of congestion information from destination to sender. [22:19:23] [If you would like something relayed to the mic, please preface with MIC:] [22:19:40] Any comments? [22:19:44] None. [22:20:40] Oops, one: experimental of specifcation of IP headers--would that invalidate anything in existing standards track docs? Not of which we are aware? [22:21:30] How about experimental documents? Maybe--but this is really a question related to RE-ECN as a solution, not the charter text. The one modification would be shifting a reserved bit to an experimental one (As ECN did) [22:21:42] Would also need to work out the relationship to ECN nonce. [22:22:19] In IPv6 might have more degrees of freedom. (New speaker) Potentially might have new capabilities for v6 than v4. [22:22:46] Ingemar: it's a bit defensive to go for experimental. [22:23:08] Chairs: we have had quite strong feedback that it should go to experimental. We understand some folks want standards track. [22:23:51] Starting at experimental does not mean it stops there. [22:24:02] George: I see only two work items; is there other work? [22:24:07] YEs, but these are the major item. [22:24:10] items. [22:25:04] David Black: This is the path that many other things in this space have taken--e.g ECN. [22:25:31] Matt: There is another strategy here: develop a spec in the abstract and leave the coding to later. [22:26:02] iyengar@jabber.org joins the room [22:26:25] Ingemar: If we move the clock back twenty years, this wouldn't have been all that useful, compared to now. [22:28:34] Tim Shepherd: I'm not sure I understand the question, but if it were done twenty years ago, it would be useful now. But now, there is so much installed base it won't be useful now--the technology will take time to get out there (10 years). But it is important to do the work--if we don't do it now, it won't be available in 10. [22:29:08] Leslie: Not trying to say that we have all the answers--we're trying to build something to start down the road. Using Experimental fits that. [22:29:53] McDysan: Likes the approach Matt put forward. Is this really worth doing this in v4, given the installed base, but maybe it could fit into v6, and the timeline fits there. [22:30:54] A speaker points out that 20 years ago folks might not have expected the bandwidth pricing we've actually seen. [22:31:11] Chairs rule that an issue that would take too much time to explore in this time. [22:31:21] Now reviewing the question of whether this is IRTF work. [22:32:46] Now reviewing "narrowing Scope"--worries that there was less clarity and less completed research on use cases [22:32:59] That would illustrative uses of the generative technology [22:35:05] Now reviewing "some potential use of the generative technology" slide [22:35:17] Notes that it may be input to congestion management or incentives. [22:35:22] Now on "work on use cases" [22:36:47] Now, are there comments on the proposed narrowed charter. [22:37:32] Comment is that if the narrowed charter gets us out the door, we should do it; we can get it changed later after we've got our nose in the door. [22:37:39] Chairs ask for IESG comments. [22:38:04] Names? [22:38:50] John Leslie says he has no problem with the narrowing, but he doesn't understand why this would make them happier (or define a generative technology) [22:38:57] iyengar: sorry, he didn't say his name. [22:39:12] I'm capturing those when I can hear them. [22:39:36] bob.briscoe joins the room [22:40:13] Chairs: the use cases seem to be the most ill-understood bit of the effort, so focusing there may help us make progress while we clear up the issue. [22:41:24] Ross: This looks like interesting research that is not likely to get deployed any time soon. He does understand that there are large operators in the room and that have spent lots of time on this. As long as we are clear that the deployment is not "run and out deploy", that's okay. [22:41:43] Further discussion on the bits left in v4 and the overall availability. [22:42:57] Bob says he thinks it is find for it to be experimental. Having something here is necessary for people to imagine what they can do with it. [22:43:10] Without a testbed, it's difficult to understand what it is for. [22:43:27] Bob would not want to use the last bit of IPv4 for something that needs proving. [22:43:49] He wants the same problem that happened to NATs to be avoided in traffic management stpace. [22:44:09] Until people can see what you could do, people won't know whether it is needed. [22:44:45] (New Speaker): This is an important problem, and we need to recognize that it is happening now and if we avoid this it may cause later breakage. [22:45:15] Jason: Bob's last point was a very good one--if we do not standardize something DPIbased solutions will proliferate and not interoperate. [22:45:40] John Leslie: Really don't even understand how we intend to narrow the charter. [22:46:19] Chairs: To be clear: we want general support for work for a reduced charter--the actual reduction would be hammered on the list. [22:46:28] John: under that theory, no objection. [22:46:52] Chairs: we will follow up with IESG and the mailing list. [22:47:31] One last comment: narrowed scope addresses the issues by service providers and after solving that known problem, we can see what else we can do. [22:47:45] Ken: Will the IESG members who have expressed concern do so on the list? [22:47:54] Chairs: We will encourage them to do so. [22:48:17] Lars was good enough to get text and Adrian yesterday engaged; we will try to get the same on the list. [22:48:34] Dave McDysan: will the narrowed charter get expanded at some point in the future? [22:49:18] After experimentation, for example, we might have an opinion on v4 retrofitting. Could this drive v6 adoption? That would have a tremendous benefit? [22:49:24] That's Dave's approach. [22:49:44] Chairs: we will not just engineer for v4. [22:50:03] Matt: the coding problem is much harder in v4 than v6; that's why abstract design and simulations may be the best approach. [22:50:21] Chairs: the balance there is getting to be abstract without being lost in possibilities. [22:50:38] Matt: I have very little patience for process--so I have trouble with focus on charters. [22:50:43] Stewart Bryant leaves the room [22:51:06] In the charter, it might be better to say something like "elements all along the path to get info on congestion all along the path". [22:51:27] The interesting policy may be in downstream congestion, but seeing the whole path's congestion may be important. [22:51:53] Chris: I have a little bit of a problem with stealing header bits. He's not convinced that there aren't other approaches. [22:52:09] We see congestion and deal with it every day. [22:52:26] Chairs: that was addressed yesterday extensively; please review the material. [22:52:46] Chris: we address this today, but we are looking ways at looking at ways in the tcp layer to do this. [22:52:52] He's a little conflicted. [22:53:03] He's wondering if it is a transport vs. IP issue. [22:53:37] Chairs: this is a good discussion, and the abstract protocol approach may help, but there is also a good bit of research on how to do this [22:53:43] Influx of IESG [22:53:50] Adrian's baaaack [22:54:33] Adrian: the discussion of experimental does gel with how he feels; he's still nervous about using the last bit in v4--can we cut it in half? [22:54:46] An option might be to work on this v6 first, and if it is valuable, retrofit. [22:54:53] If it doesn't fly, no harm done. [22:55:02] There are his high order bits. [22:55:19] Chairs: can you comment on the narrowing of use cases? [22:56:20] Adrian: (after clarification) In in particular that would allow the intermediate cloud to be mpls. Good. [22:56:36] Adrian: was there any more discussion of level of demand? timing? [22:57:13] Chairs: some of the discussion did ask when it would be deployed--don't have an answer, but we do clearly have interested. [22:57:46] Putting up a slide of survey after Hiroshima on activity (2 implementors, 10 promised implementation efforts) plus many others (slides jumped off, sorry) [22:58:40] Strong encouragement to run this experiment on v6, because of the "very last bit" problem. He's glad that the narrowed scope allows MPLS. [22:59:02] He's not sure whether misbehavior in the "white cloud" will impact this? [22:59:15] Atarashi Yoshifumi leaves the room [22:59:26] Chairs: threats analysis discusses this--a malicious node might be able to affect this. [23:00:13] Further discussion; Bob says the point of connex is measuring congestion in the whole path. [23:01:52] Ted asks whether this a requirement request for the chartered to include? [23:01:59] Answer: yes [23:02:19] Bob: we thought long and hard about using up the last bit of v4 and should we just do this in v6. [23:02:40] The difficulty is that any sensible trial *now* requires traffic that isn't there on v6. [23:02:54] gorryf leaves the room [23:03:08] Instead, they proposed ways of timing out the code so that the code point could be reused. [23:03:23] That would be more useful. [23:03:49] Speaker from BT: as a provider, why would I want to express that my network is congested? [23:04:54] ANdrew McLachlan [23:05:08] We should be careful to understand that and not assume that it will be marked. [23:05:25] The motivation for the operators to be deployed must be clear [23:05:44] Tim Shepherd states that it would be a burden if this was limited to v6. [23:06:04] Someone has to decide whether that burden should be placed on this work. [23:06:34] Chairs: it's good to have those comments injected, but we need to balance concerns. [23:07:01] Dave McDysan: v6 networks are likely to be provisioned at lower capacity than v4, so it may be congestion is easier to demonstrate here. [23:08:00] bob.briscoe leaves the room: Replaced by new connection [23:08:01] bob.briscoe joins the room [23:08:05] Mat Ford: The idea that this should be v6 and v4 doesn't make a lot of sense to me--we're talking about reclassifying it is experimental. We're not setting this bit in stone. [23:08:20] This is to let people try things out. [23:08:28] gigix73 leaves the room [23:08:34] Chairs: Is there a standards-based use envisioned for that last bit? [23:09:40] Lars: a proposal to limit this to v6 but add a work item to examine how to experiment safely with v4. We can take that work item to the community; if approved, conex can be rechartered to experiment using that identified method. [23:09:54] Lars: we will get useful data from v6 [23:10:37] Mark Handley: If we use anything it has to be experimental first--so having it pass through an experimental phase for any use of this bit. [23:10:56] The key thing is how to declare the experiment over so it could be reused if the experiment has not born fruit. [23:11:12] (Chairs close meeting and take further discussion to the list) [23:11:15] Matt Zekauskas leaves the room [23:11:18] Ted leaves the room [23:11:20] iyengar@jabber.org leaves the room [23:11:43] Joao leaves the room [23:11:47] Colman Ho leaves the room [23:12:49] Leslie Daigle leaves the room [23:13:41] satoru.matsushima leaves the room [23:29:05] Atarashi Yoshifumi joins the room [23:34:01] Matt Zekauskas joins the room [23:34:20] Atarashi Yoshifumi leaves the room [23:34:54] Leslie Daigle joins the room [23:46:30] bob.briscoe leaves the room [23:50:55] Leslie Daigle leaves the room [23:55:15] Stewart Bryant joins the room