[18:56:28] chris_griffiths joins the room [18:58:56] Lars joins the room [19:01:47] Agenda Bashing [19:02:43] Sebastian.Kiesel joins the room [19:02:47] Megumi joins the room [19:02:51] Stanislav Shalunov [19:03:00] bnsmith joins the room [19:03:07] Recap of TANA BOF/Discuss charter [19:03:21] syi101 joins the room [19:04:06] Discussing WG History [19:04:40] 2 BOF emerged from P2PI workshop at MIT in May [19:04:47] Tana BOF: transport [19:04:59] Alto BoF for overlay routing [19:05:19] Are the slides on line? [19:05:26] I was unable to find them [19:05:59] they will be loading the slides [19:06:05] at a later time [19:06:29] they should be online at https://datatracker.ietf.org/meeting/73/materials.html but they aren't [19:06:40] agreed [19:06:50] the chairs advised they will need to load them [19:07:31] two work items [19:07:40] experimental congestion control [19:08:00] and current practices and implications of using multiple connections in applications [19:08:19] Chris Donley joins the room [19:08:25] still discussing charter - congestion control requirements [19:08:49] 1. saturate the bottleneck [19:09:00] 2. keep delay low when no other traffic [19:09:06] 3. quick yield to tcp [19:09:15] 4. add little to queing delays [19:09:35] next slide - congestion crontrol document track [19:09:51] initially experimental [19:10:10] WG will consider if appropriate to ask IESG to advance to standards track [19:10:15] next slide [19:10:21] Multiple Connections [19:10:33] 1. applications routinely open multiple connections [19:10:47] BitTorrent: to create a connected mesh [19:11:12] Speaking to multiple connections based on application [19:11:35] Web Browsers: to parallelize web app latency [19:11:59] Postfix and Qmail: to parallelize SMTP RTT's and application latencies [19:12:11] Download managers: to get more and more stable throughput [19:13:08] next slide [19:13:18] Cont. Multiple Connections [19:13:26] Evil? Mostly Not [19:13:38] "limit of one connection per family?" [19:13:43] poorly documented [19:13:48] poorly understood [19:13:52] RobbTopolski joins the room [19:13:56] full of hacks and extra control loops [19:14:01] no guidelines [19:14:35] E. Bannum speaking: Interested in this document [19:14:41] saumitra.m.das joins the room [19:14:55] congestion control slows down [19:15:38] suggested working on document towards this issue [19:15:52] next slide: Multiple Connection document [19:16:01] document cuurent techniques [19:16:08] discuss consequences [19:16:16] provide guidance [19:16:22] While it's true that larger number of sessions can allow a greater share of bandwidth, that truth assumes that there is no limit. In our residential networks, however, there are small limits that are imposed by the broadband modem. Any benefit is erased. [19:16:24] (where appropriate [19:16:36] next slide [19:16:44] Goals and Milestones [19:17:16] B. Briscoe [19:17:18] speaking [19:17:36] speaking to congestion control requirements [19:18:09] creating an API to control [19:18:12] its not clear if the multiple connections refer to ledbat connections [19:18:23] or native tcp or a combination [19:19:28] B. Brisco: any new congestion control should not assume how much share it has [19:20:15] network controlling everything, would like congestion control covering [19:20:31] Dave Oran speaking [19:20:31] (clarify): While it's true that larger number of *standard TCP* connections can allow a greater share of bandwidth, that effect assumes that there is no *other limiting factor*. In our residential networks, however, there are *relatively small ceilings* that are imposed by the subscriber's broadband modem. Any benefit is erased. [19:21:05] congestion control algorythm [19:21:10] should be documented [19:21:19] Matt Mathis: speaking [19:21:31] joins the room [19:21:35] move one size fits all for transport [19:21:56] make things explicit [19:23:46] are there slides somewhere? [19:23:55] unfortunately they have not uploaded them [19:24:01] trying to keep up with what is presented [19:24:06] B. Briscoe speaking [19:24:15] want the endpoints control the flow sizes [19:24:24] Tim Shepard speaking [19:24:38] speaking to slide Congestion Control req [19:24:47] quickly yield to TCP [19:25:25] yield to any protocol [19:25:59] can folks hear online? [19:26:06] Yes --- [19:26:17] ok [19:26:18] good [19:26:22] A little bit of hum, but quite understandable [19:26:34] (the hum seems only to be in this room) [19:26:57] Andrew C [19:26:59] speaking now [19:27:01] <---- wimax connection, btw ---- [19:27:41] end Stanislav presentation [19:27:46] Next Presentation [19:27:47] If we're discussing how to do Congestion Control for a scavenger-like service, aren't we missing the point? [19:28:01] LEDBAT APP Practices and Recommendations [19:28:14] ford@jabber.isoc.org joins the room [19:28:22] Satish Raghunath [19:28:29] can you all hear Satish [19:28:30] ? [19:28:34] speaking [19:28:40] Goals in draft [19:28:50] is the agenda online somewhere? [19:28:54] Not as well, he'd better not get any quieter. [19:29:02] http://www.ietf.org/proceedings/08nov/agenda/ledbat.txt [19:29:06] posted agenda [19:29:12] no slides are available yet [19:29:23] much better [19:29:27] Looking for feedback on his draft [19:29:39] next slide [19:29:44] Terminology [19:29:52] Bandwidth [19:29:55] Volume [19:29:59] Capacity [19:30:04] Long Lived Connection [19:30:07] next slide [19:30:16] P2P and Multiple Connections [19:30:20] Pro's [19:30:29] Resiliency/Reliability [19:30:35] Faster download times [19:30:44] Cons: [19:30:56] Increased bandwidth Consumption [19:31:07] congestion, burstiness have impact on delay [19:31:15] sensative traffice [19:31:21] Lars E. Speaking [19:31:38] This draft may use non p2p applications [19:31:44] Dave Oran speaking [19:31:56] Comment: P2P's use of multiple connections has nothing to do with P2P's use of a lot of bandwidth. [19:32:40] All transfers will use whatever bandwidth it can get. (exception, intentionally light self-limiting uses, like BITS) [19:33:08] Lars E. Speaking [19:33:19] last comment on Cons [19:33:34] more state needed within TCP termination devices and middleboxes [19:33:42] Question: Is "State" going to be a network operator problem when we start moving to IPv6? [19:33:46] Bob Brisco [19:33:47] speaking [19:34:01] would you like me to ask that question Rob? [19:34:22] Joe Touch speaking [19:35:02] Chris -- yes [19:35:23] Ilich Van Beljnum [19:36:27] Ilich Van Beljnum -- the BitTyrant paper showed that the knee of the curve usually fell between 35-85 peers [19:37:54] Speaking? [19:38:01] simov joins the room [19:38:34] simon joins the room [19:38:35] There are users that abuse anything they can tweak. [19:38:45] ford@jabber.isoc.org leaves the room [19:39:09] momose joins the room [19:39:21] Thanks [19:39:22] mscharf joins the room [19:39:23] np [19:39:31] shikob joins the room [19:39:38] next slide [19:39:41] Recommendations [19:39:45] Current Thinking [19:40:04] congestion control algorithm that yields to TCP [19:40:13] scavenger class [19:40:22] AQM suggestions [19:40:31] aggressive Idle/Session timout [19:40:33] Mat Ford joins the room [19:40:36] simov leaves the room [19:40:38] for P2P TCP [19:40:54] control connections (PEX, etc) in middleboxes [19:41:05] Number of TCP connections [19:41:24] Bob Brisco speaking [19:41:32] is this draft going to be about TCP [19:41:36] or about LEDBAT [19:42:03] this draft is more looking back [19:42:03] cabo joins the room [19:42:04] yes [19:42:19] If transit providers are remarking packets on admission, and not restoring them on exit of their segment, then they're in violation. [19:42:42] Up to now, nobody has cared. But we can fix that. [19:42:44] Lars Eggert Speaking [19:44:08] howard.i.green joins the room [19:44:23] Megumi leaves the room [19:44:25] momose leaves the room [19:44:27] in violation of what? remarking what? this isn't a diffserv network [19:44:45] howard.i.green leaves the room [19:45:46] Of Diffserv -- the idea that users can mark packets to give ISPs instructions is a diffserv implementation. That operators might remark these packets should not be a reason to avoid taking that path. The operators should be encouraged to behave. [19:45:47] Cory Fairhurst [19:45:50] vijay.gurbani joins the room [19:45:50] speaking [19:46:24] Gorry actually [19:46:24] Lars: please summarize for the minutes; this is what I have: Lars provided some input on the intent of this work item. How many connections in general. May need a different document for how many connections for a less than best effort applications [19:46:31] ok? [19:46:35] Saumitra Das [19:46:37] speaking [19:47:09] Joe Touch speaking [19:47:49] many things to coordinate between hosts [19:48:01] what does it mean to coordinate [19:48:04] RobbTopolski leaves the room [19:48:10] ldondeti joins the room [19:48:31] operators should be encouraged to behave??? it's *their* network! [19:49:11] Lars Eggert speaking [19:49:35] JonathanLennox joins the room [19:49:45] should the network have a role here [19:50:32] Ilitch speaking [19:50:53] Robb Topolski joins the room [19:51:29] Stuart Cheshire speaking [19:52:14] BitTorrent doesn't upload simulaneously on its connections, either. It uses a slot-and-choke algorithms. Most connections are practically idle. [19:53:55] Anja Feldman speaking [19:55:13] next slide [19:55:20] Next steps [19:55:40] Revise Draft based on WG inputs on current practices and pros/cons of the same [19:55:52] introduce recommendation sections [19:55:58] end of slides [19:56:17] Murari Sridharan [19:56:23] Low Priority TCP [19:56:27] can you all hear him [19:56:36] better? [19:56:37] difficult [19:56:46] very good [19:56:48] ok [19:56:56] Low Priority TCP [19:57:00] Background [19:57:17] End-system based approach for content distribution [19:57:23] OS updates, prefetching, etc [19:57:35] Background Transfer Service (BATS) [19:57:48] receciver window adaptation [19:57:56] to create a low priority service [19:58:20] simlation of experimenta studies withing user-mode process and in kernel mode [19:58:27] of Windows TCP/IP stack [19:58:57] Tightly couple capacity interference and rate control [19:58:59] Megumi joins the room [19:59:01] next slide [19:59:04] Design [19:59:12] Key Observations [19:59:21] 2 theorems [19:59:22] magnus joins the room [19:59:52] in both the delay and loss of contrained cases the gooput normalized by receiver window and constant over range [19:59:56] Mat -- it's "our" Internet and "our" standard and "our" traffic. Physical ownership doesn't give anyone free reign. The Internet is a cooperative and is based on interoperability standards -- including DiffServ. If I mark packets X and backbone marks it Y, it's allowed to do that in the STD as long as it marks it back to X before exit. [20:00:35] TomP joins the room [20:00:36] Operating point can change dynamically [20:00:44] Currently, they're not restoring them to X -- and nobody's really complained because end points aren't using this -- (yet). [20:00:52] @robb i'm not a diffserv expert, but i believe you're wrong [20:01:11] next slide [20:01:14] there is nothing in diffserv that says that markings are preserved end-to-end [20:01:24] Theory vs Simulation [20:01:32] see slides when published [20:01:43] I'll look it up later, Lars, I think its there but maybe I'm projecting from something else. [20:01:56] next slide [20:01:59] type,Chris,type! :-) [20:02:02] Algorithm [20:02:08] Rate Limiting Mode [20:02:25] used to get accurate RTT samples and/or to hibernate the connection [20:02:40] allows window to be completely shut or opens 2MMS [20:02:47] Windows scaling mode [20:02:55] nothing to confuse with TCP WS [20:03:02] primary mode of operation [20:03:29] uses binary search to driver towards target window assuming the value lies between wmin & wmax [20:03:37] when no congestion is detected [20:03:51] when congestion is detected [20:04:03] methods to detect congestion [20:04:09] Variances in RTT [20:04:18] CTCP style backlog estimation [20:04:31] next slide [20:04:34] Summary [20:04:42] Maintains low delay [20:04:48] yields to TCP [20:04:59] consumes residual capacity effectively [20:05:28] requires no support from the network although addtional information can be uses to improve estimation of the target window [20:05:36] requires no changes in the sender [20:05:41] challenges [20:05:49] getting a good basertt [20:05:56] when to dump the basertt [20:06:03] route flaps, changing conditions [20:06:19] eliminating noise in the RTT estimation/detecting congenstion [20:06:32] yield to TCP over reasonable time scales [20:06:45] ok to be conservative but flows should not starve [20:06:49] end slides [20:07:02] Questions? [20:07:09] Samitra Das [20:07:11] speaking [20:07:12] Question: As envisioned, would this define a new protocol type in the IP header? Or would this appear as one of the existing protocols? [20:07:29] would you like me to ask that? [20:07:33] yes please [20:09:09] Q: Even though yield to TCP, how to consume residual capacity effectively in this approach, please clarify ! [20:10:09] howard.i.green joins the room [20:10:10] Okay, thanks [20:10:21] Lars Eggert speakiong [20:10:23] speaking [20:10:31] good question, sy. [20:10:36] thks [20:10:56] Nick Weaver A Couple Academic Thoughts on LEDBAT [20:11:18] can you hear him? [20:11:34] I think that if users see their systems as being quiet and they don't understand why, they may avoid using that algorithm :-( [20:11:38] he's okay. [20:11:43] first slide:There are two seperate problems [20:11:57] without the use of packet marking or AQM [20:12:27] detect buffer occupancy problems [20:12:49] ISP flow problem [20:13:05] May need to keep some channel capacity open for new flows [20:13:26] Is there one congestion control mechanism suitable for both problems? [20:13:49] or do we need to combine multiple mechanisms into one protocol definition [20:13:51] next slide [20:14:03] The second problem is well researched [20:14:12] Why won't the ideas in the fololwong work [20:14:13] ? [20:14:39] Final slide [20:14:41] howard.i.green leaves the room [20:14:53] LEDBAT should be defined as a TCP operating mode [20:15:40] Only one side needs to usa a defined congestion control policy (a'la 4CP) [20:15:47] Greatly eases deployment issues [20:15:59] Should it also include Re-ECN? [20:16:16] Comment in response to Nick's VG presentation: Even if there is no silver bullet, as a "to do item" for the WG, in the recommendations and current practices paper, we ought to address the issue that Nick brings up on how to deal with large modem buffers. [20:16:16] DiffServ marking should be used mostly as a notification mechanism to the network [20:16:38] John Touch Speaking [20:17:35] Aah, RFC 2686 [20:17:52] Bob Brisco [20:17:53] speaking [20:18:08] Robb Topolski leaves the room [20:19:53] Gorry speaking [20:20:08] lellel joins the room [20:20:35] Ilitjch speaking [20:20:50] Robb Topolski joins the room [20:21:31] end slides [20:21:51] Stanislav Shalunov Low Extra Delay Congestion Control [20:21:51] You're doing a great job Chris, TYVM [20:21:58] np [20:22:11] hopefully the slides will get postes so this all makes sense [20:22:26] First slide [20:22:30] Problem [20:22:36] TCP fills buffer [20:22:45] Buffer can be 1 second or more [20:22:54] interactive applications fail [20:22:55] agree with robb! have the chairs buy you beer afterwards [20:23:06] "The internet is down" [20:23:08] funny [20:23:19] How large should the buffer be, anyway? [20:23:24] Home connections [20:23:33] 1.5 Mb/s down [20:23:37] 128 kb/s up [20:23:51] Megumi leaves the room [20:23:54] RTT=50ms (ping somewhere.interesting) [20:24:05] single bulk uploading TCP connection [20:24:15] MSS = 14xxx [20:24:25] Optimal buffer size [20:24:30] A. 50ms [20:24:35] b. 100ms [20:24:41] c. < 50ms [20:24:47] d. > 10 ms [20:24:52] correction [20:24:59] d. > 100 ms [20:25:35] next slide [20:25:39] No right answer [20:25:47] 50 ms is 1/2 of a packet [20:25:52] 100 ms is 1 packet [20:26:07] large buffer (say 1 second) leads to standing queue [20:26:49] Iljitch speaking [20:27:04] why would you want to buffer for 100's ms [20:27:51] lellel leaves the room [20:28:01] Matt Mathis speaking [20:29:03] Nick Weaver speaking [20:29:53] Stuart Cheshire [20:29:56] speaking [20:30:29] next slide [20:30:37] Different congestion control [20:30:44] measure one-way delay [20:30:52] estimate queuing component [20:30:56] drive to a target [20:31:01] converge and stay there [20:31:35] next slide [20:31:39] Status [20:31:45] implemented [20:31:46] tested [20:31:55] deplloyed in BitTorrent DNA [20:32:06] Soon in uTorrent [20:32:18] plan to propose as LEDBAT solution candidate [20:32:25] didn't yet publish draft [20:32:31] next slide [20:32:35] One way Delay [20:32:42] clock offset doesn't matter [20:32:49] CLock skew matters to some extent [20:33:07] RTT doesn't cut it because of reaction to reverse-path congestion [20:33:24] not a big deal for loss-based protocols because ACK's are cumulative [20:34:41] Anja Feldman speaking [20:34:58] Joe Touch [20:35:03] speaking [20:36:44] next slide [20:36:55] Estimate queueing delay [20:37:03] current - base [20:37:08] this is where offset cancels [20:37:20] works because delays are non-negative [20:37:32] both measurements may need filtering [20:37:37] anja speaking [20:38:10] Stuart Cheshire [20:38:15] speaking [20:39:54] Iljitch speaking [20:40:31] jishac joins the room [20:41:27] Marshall Eubanks speaking [20:41:40] next slide [20:41:48] magnus leaves the room [20:41:48] Drive queue to target [20:41:52] shikob leaves the room [20:42:02] Low delay on saturated pipe doesn't happen by accident [20:42:08] need to keep track of delay and react [20:42:17] target in units of time autoscales [20:42:23] don't look at differences [20:42:32] scales poorly to high speeds [20:42:39] too fragilel [20:44:02] next slide [20:44:06] Converge [20:44:18] TCP oscillation artifact of having to cause loss [20:44:29] The close to target, the slowr the change [20:45:16] Details [20:45:19] next slide [20:45:24] Noise filtering [20:45:30] forget very old base delay [20:45:33] route changes [20:45:37] machine suspended [20:45:40] clock skew [20:45:49] use smaller packets on slow links [20:46:00] controller location: sender vs receiver [20:46:02] ... [20:47:38] Iljitch speaking [20:49:42] Gorry speaking [20:51:05] (not to room) I don't understand the confusion -- isn't using several small packets to avoid large latency the tactic that VOIP uses? [20:51:06] Joe Touch is speaking [20:52:12] andrew m. speaking [20:52:17] next slide [20:52:22] Deteriorate to TCP [20:52:24] Can someone explain this confusion to me? [20:52:40] increase no faster than 1 packet/RTT [20:52:47] deacreasing faster is OK [20:52:56] halve window on loss [20:53:02] no more than once per RTT [20:53:07] Q: BTW, How to implement small packet on slow link? [20:53:13] safety net if base delay completely wrong [20:53:20] Take some input from AQM as TCP [20:54:39] lars eggert speaking [20:55:00] leaves the room [20:55:22] syi101 -- unless I'm lost (which I think I am based on the room confusion), it's adjustable in the TCP parameters as to size, scaling, timing. http://www.dslreports.com/tweaks is a page that can help users optimize for their connection. [20:56:09] Thks Robb [20:56:30] jishac leaves the room [20:57:11] next slide [20:57:14] Yield to TCP [20:57:18] Queue builds [20:57:25] Queing delay increased before loss [20:57:40] Delay based congestion control gets the signal before loss-based [20:57:45] Mat Ford leaves the room [20:58:10] saumitra.m.das leaves the room [20:58:12] Last slide skipping [20:58:26] Any last questions [20:58:55] So many thks Chris !!! [20:58:56] Thank you, Chris (and all else responsible), for letting me participate. [20:59:09]