* [Bloat] experimental TCP theatre/LARP --- June 7 talk at oclug @ 2013-06-10 13:18 Michael Richardson [not found] ` <20130610140949.GN729@idallen.ca> 0 siblings, 1 reply; 2+ messages in thread From: Michael Richardson @ 2013-06-10 13:18 UTC (permalink / raw) To: bloat; +Cc: Ian I did my talk on June 7. It was an attempt to implement TCP as theatre. It did not go as well as I would have liked, VJ's fountain analogy is much more powerful, but significantly less portable. We implemented the Toffee Consumption Protocol, which involved moving candies from one table to another, using shot-glasses to represent segments of data, and playing cards to represent sequence numbers. Slides are at: http://www.sandelman.ca/SSW/talks/toffee-control-protocol-2013/bloatgame.html I should have included more supporting material from Nichols paper. I was concerned that the transmitter would operate too fast, and that I would be unable to slow the packets down enough. In fact the transmitter didn't have enough power, and the packets did go to fast, and we got no interesting congestion. A key thing is that packets take longer (visually, have to stretch out!) when going through a constriction. It might have been possible to implement that had we used multiple people to carry a single packet. So for instance, using canoe paddles or sticks or tent poles for packets rather than candy. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ ^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <20130610140949.GN729@idallen.ca>]
* Re: [Bloat] experimental TCP theatre/LARP --- June 7 talk at oclug [not found] ` <20130610140949.GN729@idallen.ca> @ 2013-06-10 18:00 ` Michael Richardson 0 siblings, 0 replies; 2+ messages in thread From: Michael Richardson @ 2013-06-10 18:00 UTC (permalink / raw) To: bloat; +Cc: Ian! D. Allen [-- Attachment #1: Type: text/plain, Size: 2681 bytes --] Ian! offers these ideas, should someone else want to try. I don't know when I'll have another chance. On Mon, Jun 10, 2013 at 09:18:05AM -0400, Michael Richardson wrote: >I did my talk on June 7. It was an attempt to implement TCP as theatre. >It did not go as well as I would have liked, VJ's fountain analogy is >much more powerful, but significantly less portable. Good try, though. I think you can work around your problems. Perhaps like this: Get rid of the glasses. People can pick up one toffee with one hand. Get rid of the sequence numbers. It's not centrally relevant to understanding buffer bloat. Rather than having people walk/run from the transmitter, make them go down a "receiving line" of ten people that represents the transmission line delay and capacity. The toffee carriers have to shake hands for one full second at each of the ten people before moving on to the next person. If you have, say 11 or 12 people picking up toffee and circulating back for more, the transmission line will be operating at full capacity with no dead time. Adding another ten or twenty people picking up toffee won't make it any faster, and will significantly increase latency. You can demonstrate latency by giving one of the toffee carriers at the transmitter a big URGENT sign to wear around their neck when they pick up their toffee and seeing how long it takes for that packet to get to the receiver. Adding more buffers (toffee carriers) to the circuit doesn't increase network carrying capacity but does make latency much worse. If you want to introduce a delay in the line, e.g. the slowest router, pick one person in the middle of the receiving line who has to shake hands for five or ten seconds before letting the person move on. If you want to demonstrate what you can do to work around buffer bloat at your end, show that when you throttle back the number of toffee carriers to exactly match the line carrying capacity, you have maximum throughput with minimum latency. So your job at your end of the line is to figure out what that carrying capacity is and arrange not to transmit faster than that number, so that buffers don't accumulate. If/when this demonstration is working, you might talk about what happens if a packet is lost or out-of-sequence or times out, but that might be too much. -- | Ian! D. Allen - idallen@idallen.ca - Ottawa, Ontario, Canada | Home Page: http://idallen.com/ Contact Improv: http://contactimprov.ca/ | College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/ | Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/ [-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --] ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-06-10 18:00 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-06-10 13:18 [Bloat] experimental TCP theatre/LARP --- June 7 talk at oclug Michael Richardson [not found] ` <20130610140949.GN729@idallen.ca> 2013-06-10 18:00 ` Michael Richardson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox