[06:02:47] mccap joins the room [06:03:49] mccap leaves the room [06:05:12] mccap joins the room [06:10:11] Griffiths, Chris joins the room [06:10:57] Griffiths, Chris leaves the room [06:11:47] Chris Griffiths joins the room [06:13:43] eburger joins the room [06:16:56] Chris Griffiths leaves the room: Replaced by new connection [06:17:08] Chris Griffiths joins the room [06:18:33] Lee Howard joins the room [06:19:59] gorryf joins the room [06:21:23] Colman Ho joins the room [06:23:07] Lars joins the room [06:23:10] rhe joins the room [06:23:25] Is there a jabber scribe in the room? [06:23:30] shikob joins the room [06:23:35] jlcJohn joins the room [06:24:03] mathis joins the room [06:24:04] i can relay [06:24:21] Thanks [06:24:46] Leslie Daigle joins the room [06:24:46] eburger leaves the room [06:25:17] Alissa Cooper joins the room [06:26:34] Andrew McGregor joins the room [06:26:34] shamus joins the room [06:28:03] Simon Perreault joins the room [06:29:38] Alissa Cooper leaves the room [06:29:47] Alissa Cooper joins the room [06:30:00] are slides online? [06:30:01] Alissa Cooper leaves the room [06:30:04] yes [06:30:09] Alissa Cooper joins the room [06:30:16] Mat Ford joins the room [06:30:23] Alissa Cooper leaves the room [06:30:31] Alissa Cooper joins the room [06:30:44] Alissa Cooper leaves the room [06:30:52] Alissa Cooper joins the room [06:31:07] Alissa Cooper leaves the room [06:31:15] Alissa Cooper joins the room [06:31:29] Alissa Cooper leaves the room [06:31:37] Alissa Cooper joins the room [06:31:37] tachibana@jabber.org joins the room [06:31:51] Alissa Cooper leaves the room [06:31:59] Alissa Cooper joins the room [06:32:00] Slides are available from https://datatracker.ietf.org/meeting/76/materials.html [06:32:13] Alissa Cooper leaves the room [06:32:21] Alissa Cooper joins the room [06:32:35] Alissa Cooper leaves the room [06:32:43] Alissa Cooper joins the room [06:32:57] Alissa Cooper leaves the room [06:33:05] Alissa Cooper joins the room [06:33:06] Alissa Cooper leaves the room [06:37:32] Ed J. joins the room [06:41:00] Ed J. leaves the room: Logged out [06:41:01] shikob leaves the room [06:46:32] lllmartini joins the room [06:51:48] Pasi Sarolahti joins the room [06:52:02] Pasi Sarolahti leaves the room [06:52:12] PasiS joins the room [07:01:14] tmonca joins the room [07:06:06] gigix73 joins the room [07:08:05] shamus leaves the room [07:10:34] TPLUNKE joins the room [07:10:52] TPLUNKE leaves the room [07:15:13] lebobits joins the room [07:15:54] for those not in the room, that was a cool english jostling: UK vs Aussie vs US english dialects/accents. [07:16:32] Chris Griffiths leaves the room [07:16:59] can we stop with the cable examples ? [07:17:22] it would be nice to hear from someone with real bandwidth like Verizon , or other DSL providers [07:19:16] ping a buddy and have them come to mic then, eh? [07:19:36] @martini: ok, here's BT. They count? [07:19:41] giles_heron joins the room [07:20:35] now we have England vs Ireland dialects. This is cool!! [07:22:27] HELIOPOLIS joins the room [07:24:11] roehricht joins the room [07:24:11] This is going down an off topic rathole [07:24:42] SPs are in the business to provide service ! [07:25:03] not in the business to limit user's utilization [07:25:08] maybe those just shut down could have the conversation on jabber, here? [07:25:17] I'd like to hear it, anyway [07:25:50] but r they providing service if they are using DPI to find bit torrent and skype and drop them? [07:26:30] when there is competition , they will be forced to provide the service [07:26:54] so DPI is a temporary , bad idea. [07:26:59] not to drop them but to slow thme down in times of congestion [07:27:09] seems to me that higher prices are a bad user experience. [07:27:29] no. they are a free market experience :-) [07:27:33] and also that engineers don't set prices. :-) [07:27:41] the problem is that 1% of the users are presenting somthing like half of the load [07:28:07] building the network to be uncongested would double the price for everyone [07:28:09] that's not exactly the problem. [07:28:10] If kids are watching TV on demand all the time... is there a way for parents to request that their packets be dropped? [07:28:28] the goal is to bound the 1% heavy users [07:28:39] but the people trying to use bit torrent and skype don't want their traffic slowed down in times of congestion, no? [07:28:49] or, at least, reduce the negative impact on the 99% [07:28:57] not exactly. . . the goal is to make sure those 1% don't degrade everyone else's throughput [07:29:09] seems it would raise the price for the 1%, not everyone, eh? [07:29:34] which is what comcast did [07:29:49] why isn't that okay? Why is it bad for the 1% that consume 50% of the pipe to pay more? [07:29:49] yep [07:30:03] it's not sufficient [07:30:10] sufficient for whom? [07:30:11] if they pay they expect that level of service [07:30:19] and they're still messing up the other 90% [07:30:27] who "they"? the 99% or the 1%? [07:30:42] no - that is a bad service provider , that is not matching the demand [07:31:10] if there is demand service needs to be upgraded , and even the cable guys are in the process of doing just that [07:31:10] IF the 1% pay more accodingly to their usage volume, that will fund the upgrade of their access net [07:31:28] there is no constraint on their desire to consume resources [07:31:34] Under flat rate they all pay the same [07:31:45] adding capacity isn't a sufficient answer [07:31:53] @mathis: we are considering non-flat rate at present [07:31:57] so 99% od the user are subsidizing the 1% [07:32:10] @ ford: because? [07:32:10] sftcd joins the room [07:32:29] and sufficient for whom? [07:32:53] lebobits not arguing here, truly trying to understand something I haven't studied much yet [07:32:59] TCP consumes available capacity, regardless - one prominent issue is that latency sensitive apps are crowded out by latency insensitive apps for no additional benefit to anyone [07:33:02] if you are not doing flat rate, there is not a problem [07:33:19] see slide: could charge for congestion, but users don't know when there's congestion [07:33:19] but customers don't like it, and generally prefer flat rate [07:33:28] @ ford: only crowded out of the pipe is too small, right? [07:33:52] s/of/if/ [07:33:58] i don't see widespread FTTH anytime soon in the UK [07:34:02] I haven't seen a comment that not all traffic is TCP, especially packet-loss-sensitive traffic [07:34:16] there is no such thing as "not too small", at current data consumption rates [07:35:32] ok, so the point Leslie & Ford are making is that consumption demand is rising algorithmically, and there is NO way for bandwidth upgrades to keep up? [07:35:51] s/algo../logrithmically/ [07:35:57] lebobits going too fast [07:36:18] broadband deployment has driven consumption through the roof [07:37:26] Mat Ford: you're saying that oversupply is the problem? [07:37:44] oversupply of what? [07:37:53] good applications? :) [07:37:54] as did v.36 ( ? ) and v.92, and ISDN 128, and DSL first Gen, and so on? [07:38:05] you said broadband deployment has driven consumption [07:38:16] I think there was congestion on 300 baud [07:38:19] The issue is not bandwidth upgrades..... even with FTTH at 1 Gbps TCP will still fill the pipe and there will be loss. [07:38:22] before them, which led to the new gen's of xxDSL and Cable and so on? [07:38:35] we ALWAYS find a way to increase bandwidth, over time [07:38:40] always have, always will [07:38:52] DSL/Cable access rates today are 2 orders of magnitude greater than dialup [07:38:57] Right. The issue is fairness. [07:39:42] btw, I'm not disagreeing we need CONEX, just trying to push a bit on the base assumptions to see what happens [07:39:56] I still think the issue is providing information to the endpoint about congestion on the network, so the application can decide whether and what to do about it. [07:40:26] heh. . . Bob just said the opposite of what i said [07:40:31] @ Mat: and the same was true of v.92 and 9600baud [07:40:48] video was never viable at 9600baud [07:40:50] Let me put it this way... if LEDBAT could be readily applied to TCP-based applications the problem would be considerably less difficult. [07:41:01] neither was web pages [07:41:16] theloon joins the room [07:41:21] but they were at v.92, and that's why we all moved so quickly to v.92 [07:41:23] roehricht leaves the room [07:41:42] point being (or at least I'm testing the hypothesis in the discussion) the bandwidth WILL catch up [07:41:45] is ledbat still active? seems quiet over there [07:41:49] sorry, off topic. [07:41:55] there is always people working on making more bandwidth over same phy infrastructure [07:42:14] sure, we'll prvide more bandwidth, but that won't eliminate congestion [07:42:16] always vendors trying to get ahead on that point [07:42:19] What slide are we at? (3?) [07:42:21] never [07:42:26] so, is this is a working group to discuss a problem, why are we listening to a solution to a problem not defined? [07:42:26] yes slide 3 [07:42:42] @lebobits http://www.isoc.org/isoc/conferences/bwpanel/docs/20091111_bandwidth_mcpherson.pdf [07:42:53] @theloon the problem was discussed at length before you joined [07:43:20] @ Cat: looking [07:43:21] ... [07:43:30] eburger joins the room [07:43:46] so, the point is that (a ) [07:44:05] there will always be increases in bandwidth over time, BIG increases, and (b) [07:44:18] there will always be increases in demand to fill it and ( c ) [07:44:34] there will always be congestion because of (b ) [07:45:27] @lebobits yes - we want congestion - then we're making maximal use of the available resources - so the question is, in the presence of congestion, how do we ensure that people who are contributing less to the total volume of congestion suffer less? [07:45:29] and the nature of congestion impacts change with different application types (e.g., realtime apps) [07:45:48] lebobits leaves the room [07:46:02] I guess we answered all his questions satisfactorily :) [07:46:16] thankyou [07:46:53] lebobits joins the room [07:47:43] gigix73 leaves the room [07:48:07] lebobits leaves the room [07:48:07] lebobits joins the room [07:49:40] lebobits leaves the room [07:49:40] lebobits joins the room [07:49:43] lebobits leaves the room: Logging off [07:50:58] sorry, what is the sender telling the network? [07:51:12] so this method would work how for a channel change on a link which is already near or at max? [07:51:38] sender tells the network how much congestion he/she has caused [07:51:51] encountered [07:51:51] so then you need a policer to check that you're not telling fibs [07:52:01] ah - good point [07:52:06] you would still require diffserv ....... Giles just beat me to it [07:53:00] This is problems that Bob addressed in his PhD thesis: How to make it uncheatable [07:53:15] right [07:53:30] what happens if there is more then once congestion location ? [07:53:40] congestion is additive [07:53:46] doesnt matter [07:53:49] (assuming % of marked packets is low) [07:53:53] but you would stil need an egress policer to hit the apps not complying [07:54:31] it's not always about complying -- it could be about accounting [07:54:51] surely for accounting ECN is sufficient? [07:54:52] and a transport that sees these, and hence avoids not complying to the marks [07:54:57] yes that is part of the total solution : black minus red had better be positive [07:55:48] the theory is that -- with congestion exposure -- you can indicate your willingness to incur congestion (and take the charge) [07:56:41] does my willingness to pay matter? [07:56:51] so what is the purpose? Seems like we are going to spend the money we would have spend on network and tail upgrades on policing this. As an ISP I need to get more for less, not spend more to ensure less [07:57:21] I mean - I'm not willing to pay my taxes, but I still pay them ;-) [07:57:39] in this model neither the willingness to pay more or the fact that might have paid for always on matter - you get dinged - which is not want you want [07:57:40] as I have had it explained to me: if you have clear indication of customers willing to pay (literally or figuratively) for the congestion they incur, you have a better sizing of willingness to support buildout [07:57:54] as opposed to having a bunch of users who will use everything they can (and then some) but won't shell for it [07:57:56] Well, this costs something... but it lets you not bother spending on other kinds of traffic management too. [07:58:00] also it is not apps sensitive without an arbitor - who or what does that? [07:58:14] the endpoints [07:58:18] it is application-agnostic [07:59:33] sftcd leaves the room [07:59:42] Slide 8??? [07:59:55] slide 8 [07:59:59] ok [08:00:11] i understand it is app agnostic, that is kinda my problem. I need an app aware network, or at least hqos available for myself (an ISP) and/or customers individual needs [08:00:37] are you in the room? [08:00:51] (physical bof room) [08:02:02] i could see this as a possible addition to the BE and or scavenger class, as a helper, but not as a solution to the network issues we really have. Ben made a good point about the economics which is one of the reasons DPI ends up in the networks [08:02:08] Simon Perreault leaves the room [08:02:43] you might put it on BE. prob not on scavenger (as nobody wants to pay for scavenger). But yeah - no use for EF or AF. [08:04:05] Lars leaves the room [08:04:11] Lars joins the room [08:04:24] yep - none, however I was trying to be fair :) [08:06:18] Leslie - yes i'm in the room physically, sorry for missing that earlier [08:07:10] This *particular* discussion (LEDBAT-style apps) could be solved by a FS TC, and "charges" less for "background DSCP" [08:07:20] lebobits joins the room [08:08:35] We need a scavenger class microphone [08:08:54] ;-) [08:09:34] Actually the "background" class doesn't solve the WHOLE problem [08:10:33] Ah Bob just said this - it would lead to a DS hieracrchy - I like the idea of letting transport make decisions better [08:13:23] @theloon -- this is your cue to hit the mic with your point re app-agnostic [08:15:38] shamus joins the room [08:17:07] Lars leaves the room [08:18:17] I think there's a piece missing here about how endpoints decide how persistent to be [08:18:27] So Bob and Leslie have different statements of the problem. [08:18:57] take bob's word for it ;-) [08:19:55] - not sure they are so different, there are various persepctives - we're try to encourage the use of ECN (which the transport guys think is good) and give more possible transport behaviours) [08:20:06] I think we're losing track of the fact that only the immediate upstream cares which end-user is causing congestion: backbone providers only care which peer "causes" the congestion; CONEX is about having a signal which is useful to all network managers along the path. [08:20:08] Leslie: but I'm more interested in your problem [08:25:08] OK, taking Bob's word for it, and listening to current explanation, I'm still not sure I understand why this would be desirable. [08:25:35] why _which_ would be desirable? [08:26:56] so, i could get charged for congestion... ? Interesting as I have already paid to be on the network. [08:28:11] There _are_ some people who would prefer to be charged for congestion, rather than be prevented from causing congestion; it doesn't have to be a majority for this to be useful. [08:28:16] there is no way around this problem : you will need full diffserv deployment on the internet [08:28:26] this is a non-starter [08:28:34] Not true [08:28:43] Diffserv would help, true [08:28:56] But you don't need it everywhere, nor do you need this everywhere [08:28:57] this is great, I don't have to go to the mic; people keep answering my questions while I type them [08:29:07] there are application I pay for that MUST not be marked for congestion [08:29:09] I can't agree that diffserv would solve the problem, were it even possible to "fully" deploy it. [08:29:18] diffserv _will_ be required to deliver services like video and voice from the ISP [08:29:50] Also ISP do not charge to reduce congestion ! [08:29:57] Diffserve might be needed for _some_ voice traffic... [08:30:13] Some kind of queuing discipline will be useful... this is just a useful tool for providing signals for those qdiscs. [08:30:15] the actual mechanism for re-ecn will not work on a full ingress (to cpe) link, the startup time it takes to clear the way is hopeless for apps that need a "step" start [08:30:18] they charge to make money , and usage based chargin is due to lack of competition , and wil ldisappear [08:30:25] so i can't use this as an ISP [08:32:11] giles_heron leaves the room [08:32:23] You can envisage a qdisc that will look at the flows, know which are responsive, and proactively clobber those for the benefit of new flows starting. [08:32:25] giles_heron joins the room [08:32:34] The re-ecn "mechanism" needs one round-trip-time... [08:32:39] That would result in better performance for everyone [08:33:05] In fact, not even clobber... just hold them up [08:36:49] that 1 round trip will be for a flow would it not - what it I have 4k flows for torrent and all with different round trips and all taking small portions of the traffic. If I need to get them all out of the way for a single v large flow does that work? [08:38:14] theloon: indeed, different flows will have different RTTs; and if you _need_ them all out of the way, it will take the longest RTT. :^( [08:39:04] shamus leaves the room [08:40:15] Who is speaking? [08:40:21] iyengar [08:40:29] Jana Iyengar [08:40:29] jlc4john: indeed yes. For services like channel change this would kill it [08:40:38] ok [08:41:34] theloon: It's really hard to believe channel-change needs them _all_ out-of-the-way... [08:44:05] Channel change? [08:44:10] not all, but certainly as a percentage of flows for a fast start app, it will depend on the link size and the larger flow that is being driven over it. [08:44:52] How can this kill anything? What doesn't work is a consequence of the shaper disciplines, and so far as I can tell this only helps them do the right thing. [08:45:39] does understand == agree? [08:46:18] hand++ [08:46:39] No, it's agreeing that it needs ietf work [08:46:48] understood [08:46:57] WHAT happened in the "vote"? [08:47:04] sorry -- [08:47:10] Many hands raised [08:47:16] but my point is that there's a danger that those who agree that this is all a good idea are in danger of characterising those who don't agree as not understandingf [08:47:23] about half the room says they understand the problem [08:47:27] but what do I know - I'm remote, lol [08:47:30] and they like this problem statement [08:49:01] Humming didn't change anything [08:49:22] - It was easier to interpret on the audio! [08:49:37] That's a good point [08:49:49] gustav.ietf joins the room [08:50:16] telemaco.melia joins the room [08:51:48] lllmartini leaves the room [08:51:55] telemaco.melia leaves the room [08:52:32] Has the audio broken - just noise, and I was about to ask a question [08:52:40] I'm hearing it ok [08:53:29] OK - I hear now. [08:59:31] It sounds as if we're holding up chartering over worries about ISP charging models... [08:59:47] but PAYG phones are a massive part of the market [09:01:34] The status of the documents and the scope IS important [09:01:35] humyes [09:01:50] humyes dito [09:01:52] and some of it comes down to ability to incur expense. given the marginal cost of carrying 64kbps (or even carrying a voice call over GSM) the potential risk to a phone provider of giving you "all you can eat" is pretty low [09:02:08] theloon leaves the room [09:02:09] What about other IAB questions? [09:02:11] ditto when you have DSL or cable access to the Net probably [09:02:20] but for genuine broadband.... ;-) [09:02:24] giles_heron leaves the room [09:02:34] PasiS leaves the room [09:02:35] Except when the shortest undersea fiber to the rest of the world is about 3000km long [09:02:37] eburger leaves the room [09:02:51] Andrew McGregor leaves the room [09:03:06] Leslie Daigle leaves the room [09:03:16] Colman Ho leaves the room [09:03:16] gustav.ietf leaves the room [09:03:21] SO, I guess we missed the checklist of things that the IAB normally ask in requesting forming a WG??? [09:03:46] Mat Ford leaves the room [09:03:49] clarification of my anti-hum: it seems premature. To say, "modulo clarifying the problem statement, charter, intended output, and timeline, should we start a working group". BUt there's enough work here to merit a WG. [09:03:58] yes, but you can ask outside the meeting time... [09:04:02] mathis leaves the room [09:04:30] LeeH: I don't understand [09:04:55] I don't know what the working group would be, so I can't say there should be a WG. [09:05:39] I don't believe the hum indicated any more than "there's work that _could_ justify a WG. [09:05:40] - Glad to particpate remotely - thanks to people in the room for helping ... and this looks like it has some direction, and is starting to articulate itself, I am not sure exactly what will emege yet, Cheers Gorry [09:06:59] then maybe I misunderstood the question (possibly because I inferred answers to other typical IAB questions). [09:07:46] IMHO, experimental status is what the list was discussing: I wouldn't recommend chartering for immediate Proposed Standard... [09:08:05] lebobits leaves the room [09:09:51] rhe leaves the room [09:11:16] hmm. . . related question. . . how to I navigate to information about a BoF? I missed notice that this BoF was happening, didn't know about mailing list, the first time I learned of it was reviewing IETF schedule. Based on agenda, I read some of the drafts (which, again, I thought I understood at the time). [09:12:00] I can't figure out how to get there from www.ietf.org [09:13:09] To tell truth, I forget how the unwashed public is supposed to find that: I caught it as an IESG agenda issue (but of course I was already reading the re-ecn list... [09:13:54] can you take it as feedback that I've tried several times and can't find such things? [09:14:25] Lee Howard leaves the room [09:15:13] I'll be happy to (and post to the IESG list). [09:16:54] tachibana@jabber.org leaves the room [09:18:02] There was a BOFs link for the meeting... linking to: http://trac.tools.ietf.org/bof/trac/wiki [http://trac.tools.ietf.org/bof/trac/wiki] [09:20:26] gorryf leaves the room [09:22:19] HELIOPOLIS leaves the room [09:23:02] Leslie Daigle joins the room [09:24:02] Lars joins the room [09:26:07] gorryf joins the room [09:26:10] gorryf leaves the room [09:30:29] Lars leaves the room [09:33:52] Leslie Daigle leaves the room [09:42:39] mccap leaves the room [09:58:14] lllmartini joins the room [12:56:07] Colman Ho joins the room [12:58:12] Colman Ho leaves the room [14:08:26] PasiS joins the room [14:08:29] PasiS leaves the room [21:32:43] lllmartini leaves the room [23:09:27] lllmartini joins the room [23:27:47] lllmartini leaves the room [23:41:17] jlcJohn leaves the room [23:56:28] tmonca leaves the room