http://permalink.gmane.org/gmane.ietf.tsv-area hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.tsv-area/449 <pre>We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit t</pre> hammondjohnson< at >hushmail.com 2013-04-27T17:53:07 http://permalink.gmane.org/gmane.ietf.tsv-area/448 <pre>Hi, For those interested in LEDBAT (and: apologies for the noise to those who are not): a paper on LEDBAT by Michael Welzl &amp; I has just appeared, available here: http://dx.doi.org/10.1109/LCOMM.2013.040213.130137 Comments are welcome. Thanks, David. ================================================================= David ROS http://www.rennes.enst-bretagne.fr/~dros/ "It would seem that you have no useful skill or talent whatsoever," he said. "Have you thought of going into teaching?" -- Terry Pratchett </pre> David Ros 2013-04-24T15:27:50 http://permalink.gmane.org/gmane.ietf.tsv-area/447 <pre>Hi all. I would like to know your feedback (especially from tcmtf co-authors) about this proposal of Ken: - Currently, we are thinking about document A including these things: 1) Protocol stack (it would be the "reference model") 2) a negotiation mechanism to decide the options to use at each layer 3) a mechanism to setup/release a tunnel between a multiplexer and a de-multiplexer - The proposal of Ken is to split this into two documents: I, including 1) II, including 2) and 3) As Ken says, "One thing to keep in mind is that if it's possible that 2 and 3 (below) can change over time and yet 1 (the reference model) does not,(...)" What do you think? Would this complicate or simplify things? Considering the possibility of having a Working Group, would it be a better approach to split the problem this way? Thanks a lot, Ken and everyone! Jose to 3 fine. I you'd like the (i.e. </pre> Jose Saldana 2013-03-19T10:34:24 http://permalink.gmane.org/gmane.ietf.tsv-area/446 <pre>Hi Joe, The facts of the matter are that none of the Transport ADs have *ever* been storage experts, and nonetheless, the Transport Area has turned out significant work on NFS and iSCSI. What this means is that while it's a bonus if we can find an AD who is an expert in one or both of these storage protocols (they are *completely different*, FWIW), that's not a necessary job requirement - we have well over a decade of "running code" leadership experience that neither Transport AD needs to be a storage expert. Thanks, --David +++Sent from Blackberry ----- Original Message ----- From: Joe Touch [mailto:touch&lt; at &gt;isi.edu] Sent: Monday, March 18, 2013 12:41 AM To: Black, David Cc: Martin Stiemerling &lt;martin.stiemerling&lt; at &gt;neclab.eu&gt;; tsv-area&lt; at &gt;ietf.org &lt;tsv-area&lt; at &gt;ietf.org&gt; Subject: Re: IETF#86 TSVAREA draft minutes posted Hi, David, I'm confused by your clarification below. Does this mean: a) your ADs have always had sufficient storage expertise already b) your ADs didn't always have sufficient storage expertise</pre> Black, David 2013-03-18T04:55:41 http://permalink.gmane.org/gmane.ietf.tsv-area/445 <pre>Hi, David, I'm confused by your clarification below. Does this mean: a) your ADs have always had sufficient storage expertise already b) your ADs didn't always have sufficient storage expertise, but that wasn't considered an impediment to their work, and as a result didn't necessitate that you to train them i.e., you did fine with (at least some) ADs who didn't have storage expertise beforehand Joe On 3/17/2013 9:24 PM, Black, David wrote: </pre> Joe Touch 2013-03-18T04:41:09 http://permalink.gmane.org/gmane.ietf.tsv-area/444 <pre> I can imagine! One thought, have tests been done that indicate that generally an all-TCP-ACK "flow" (as seen in the egress direction) is still considered a "thin" flow? In the ADSL case with 20 meg down and 1 meg up, I seem to remember that ACKing 20 megabit/s of traffic uses 30-40% of the upstream bandwidth so it's a matter of opinion if this is actually a thick flow or not? I'm trying to understand how codel handles the use case of 100 upload torrent TCP sessions (all trying to run max upload speed) and a single tcp http/ftp download. This is one of the most common complaints I've seen over the years about bufferbloat, uploading destroys download performance. Another thing that I would like to see tested on Linux is the combination of fq_codel and shaping the speed. This is for the use case in ETTH selling for instance a 100/10 connection, where the 10 upstream connection is achieved by policing the bw in the ETTH access switch (the physical port is 100/100. It would give the user a better </pre> Mikael Abrahamsson 2013-03-18T04:30:36 http://permalink.gmane.org/gmane.ietf.tsv-area/443 <pre>Minor, but important correction - I'm recorded as saying: also, chairs of storage WGs are grateful that ADs have never had storage expertise Uh, not exactly. What I thought I said is that the storage WG chairs (storm, nfsv4 chairs) are grateful that we've never had to educate the ADs to turn them into storage experts - we'd of course welcome ADs who already are storage experts ;-). Thanks, --David (storm WG co-chair) </pre> Black, David 2013-03-18T04:24:35 http://permalink.gmane.org/gmane.ietf.tsv-area/440 <pre>To begin with, I tend to use the term 'flow queuing' to distinguish what we're doing with classic "fair queuing", which is overbound in most people's minds, and some of what we do is "unfair" by some metrics. Secondly, an extremely important factoid about why we got so excited about fq_codel (which is really DRR, in term derived from SFQ, combined with CoDel along with detecting thin vs. thick flows) is its performance: If my memory serves me correctly, Eric Dumazet has bench marked fq_codel, when running on a modern x86 processor with modern NIC's only takes a few percent of one x86 core at a 10gE rate. And we get higher total bandwidth over the link as a result. Eric, please correct me if I'm wrong, but you did say I could quote you! Similarly, Dave Taht reports when using fq_codel on CeroWrt (a 600mhz MIPS commodity home router), while the cost of running the fq_codel algorithm is visible in the performance traces, it's well down the list of what functions in Linux are taking the CPU time on that arc</pre> Jim Gettys 2013-03-17T19:12:16 http://permalink.gmane.org/gmane.ietf.tsv-area/439 <pre>Hi all, The draft minutes for the TSVAREA meeting have been posted: http://www.ietf.org/proceedings/86/minutes/minutes-86-tsvarea Thanks to Matt Ford and Bill Cerveny for taking notes and also to Richard Scheffenegger for being the jabber scribe. Martin </pre> Martin Stiemerling 2013-03-16T17:53:15 http://permalink.gmane.org/gmane.ietf.tsv-area/437 <pre>One note on this one, although I probably will not join AQM, but instead watch for useful results to emerge: I assume a simple tail-drop example was used to make the point. Proportional random marking/dropping should be used for reasons that we're all familiar with. Despite that, this is an example of how ECN is supposed to be configured - CE is supposed to tell the receiver "I would have dropped this packet, but I'm sending it to you instead as a favor - tell the sender to adjust its transmission behavior as if the packet had been dropped, but there's no need to retransmit this packet." Thanks, --David (RFC 3168 co-author) </pre> Black, David 2013-03-14T13:04:02 http://permalink.gmane.org/gmane.ietf.tsv-area/436 <pre>Hi, Sorry in case I misunderstood. More below: On Mar 14, 2013, at 6:54 AM, Fred Baker (fred) &lt;fred&lt; at &gt;cisco.com&gt; wrote: Up to here, I agree. Just for clarification, you mean: mark it but not react to it? (Which is possible, because the nonce isn't used…) Okay, now I understand where this is coming from. I didn't say "using ECN for ECN-capable traffic" does that. For context, here's your scheme again: (Let's call the lower threshold M, and the higher one N.) Reading this again, I now see that I probably just misunderstood you - apologies. I had somehow thought that you'd *always* drop non-ECN-capable traffic at M, as opposed to the randomized behavior given by an AQM. This would have meant that only ECN-capable traffic can make the queue grow beyond M. I now see that this is surely not what you meant and agree that this makes sense - sorry. Cheers, Michael </pre> Michael Welzl 2013-03-14T12:07:39 http://permalink.gmane.org/gmane.ietf.tsv-area/435 <pre>This will be my last note on the topic on tsvwg. I'd like to believe that by tomorrow we will have all joined aqm&lt; at &gt;. On Mar 14, 2013, at 6:54 AM, Fred Baker (fred) &lt;fred&lt; at &gt;cisco.com&gt; wrote: Following up on the comment about M and N. Let me show you some (old and low speed) slides that I use as examples in this class of discussion. It's not ECN vs loss, it's AQM vs tail-drop. However, since AQM-using-ECN and AQM-using-loss are examples of AQM, and the argument in the draft is to use both depending on the capabilities of the traffic, I think it's applicable. ftp://ftpeng.cisco.com/fred/dpreed/Bufferbloat_Masterclass.pdf I'm looking at slides 11 and 12. Comments on the rest of the deck are interesting, but I'd suggest taking that private in order to not muddy this discussion. The slides were pulled together as a simple and understandable example of what I said above about M and N. "AQM", in this case, is "RED"; other algorithms will display slightly different characteristics, but I assert that they will</pre> Fred Baker (fred 2013-03-14T11:55:09 http://permalink.gmane.org/gmane.ietf.tsv-area/434 <pre>Thanks. On Mar 13, 2013, at 10:09 PM, Wesley Eddy &lt;wes&lt; at &gt;mti-systems.com&gt; wrote: </pre> Fred Baker (fred 2013-03-14T11:21:38 http://permalink.gmane.org/gmane.ietf.tsv-area/433 <pre> On Mar 14, 2013, at 12:43 AM, Michael Welzl &lt;michawe&lt; at &gt;ifi.uio.no&gt; wrote: I don't understand your comment. Fill me in please? If I have a tail-drop queue, TCP using CUBIC or New Reno seeks to keep the queue full. If the queue has N positions (there are many ways to measure a queue, bear with this one for the purpose of the example), worst case delay approximates waiting for N messages, and general case delay is predicted by queuing theory to shoot for N when the link has 95% utilization or whatever. With any AQM algorithm, the same queue will accept N messages in the event that it gets a burst, but will start marking/dropping at some point M significantly less than N, so that the queue depth tends to approximate M, not N. That's the whole point of any AQM algorithm. How M is chosen or predicted is of course different for various algorithms. The pushback I generally hear about ECN is that people will mark traffic as ECN-capable in order to work around AQM algorithms signaling early; to make them signal la</pre> Fred Baker (fred 2013-03-14T10:54:20 http://permalink.gmane.org/gmane.ietf.tsv-area/432 <pre> Could you please elaborate on how you came to this conclusion? Why would it be better to drop the packet than to ECN-mark it? Concrete example: Buffer depth &gt; 30 ms = mark ECN traffic, drop non-ECN traffic Buffer depth &gt; 50 ms = drop all draffic The congestion signal to TCP at buffer depth 30 ms is the same for both ECN and non-ECN traffic, so I don't see how this would increase the delay? </pre> Mikael Abrahamsson 2013-03-14T05:11:20 http://permalink.gmane.org/gmane.ietf.tsv-area/431 <pre> I'll have to look into what devices we're using and what CPUs they're using. The WNDR3800 seems to be a fairly high end device when I look at the price point. However, the other part of your reply sounds hopeful. I read draft-nichols-tsvwg-codel-01 and I now realise that yes, it shouldn't be too cpu intensive as the hashing into bins sounds efficient on a per-packet level. Would having multiple bin "trees" increase CPU usage a lot? I'm thinking of the use case where there are 10 computers in the home, of which one is doing 100 upload TCP sessions (bittorrent). If there was some mechanism that could identify a source IP address that caused most of the congestion and put them in a separate bin "tree" (basically each source IP would get its own set of bins, up to a maximum of perhaps 16 trees) and then these sets of bins would be emptied in a round-robin fashion (MDRR perhaps?). Or perhaps there would just be a "high volume speaker" tree and a "low volume speaker" tree, and it would be enough t</pre> Mikael Abrahamsson 2013-03-14T05:07:37 http://permalink.gmane.org/gmane.ietf.tsv-area/430 <pre>Clarification in line, sorry: On Mar 14, 2013, at 12:43 AM, Michael Welzl &lt;michawe&lt; at &gt;ifi.uio.no&gt; wrote: … no, not everybody. The non-ECN users will still be doing fine. Cheers, Michael </pre> Michael Welzl 2013-03-14T04:48:20 http://permalink.gmane.org/gmane.ietf.tsv-area/429 <pre>Hi, About this two-level threshold idea: Great, I turn on ECN, and that gives me more delay, just what I want! And, even better: the more people use ECN, the more delay everybody gets. Seriously, I see the incentive idea behind this two-level marking idea, but one has to carefully consider the increased delay vs. gained throughput trade-off in such a scheme. Cheers, Michael </pre> Michael Welzl 2013-03-14T04:43:10 http://permalink.gmane.org/gmane.ietf.tsv-area/426 <pre>Following on the TSVAREA meeting today, we started a new non-WG mailing list called "AQM" for Active Queue Management topics: https://www.ietf.org/mailman/listinfo/aqm This is intended to be the place to discuss drafts, and proposing a BoF or WG charter for AQM work, along with anything else related to sizing and managing buffers that may be relevant. If the folks who are interested could join there, and gradually shift the conversations to it, off of TSVWG (who have other fish to fry), that would be excellent. Thanks for your feedback today! </pre> Wesley Eddy 2013-03-14T02:09:29 http://permalink.gmane.org/gmane.ietf.tsv-area/425 <pre>I think this is the kernel of something useful, a few comments in-line. That's what I thought you intended. Agree 1/2 would be ok We need to be careful if that the incentive is correct - but you didn't have space to explain the algorithm. If these really are shown to work on all scenarios... Then that could be ok, but I am not sure yet alg work in all places. </pre> gorry< at >erg.abdn.ac.uk 2013-03-13T23:01:43 http://permalink.gmane.org/gmane.ietf.tsv-area/424 <pre> On Mar 13, 2013, at 2:28 PM, &lt;gorry&lt; at &gt;erg.abdn.ac.uk&gt; wrote: As I just said to Mikael, I don't think I worded that one well. I'm envisaging two thresholds, testing two stress levels. It a lower one, one marks ECN-capable traffic and drops non-ECN-capable traffic; at the higher one, one drops from all traffic. What "threshold" means in a given algorithm is algorithm-dependent, however. Well, 3168 says that TCP should respond in the same way it responds to loss. By that, what they mean is that it reduces cwnd, and if in slow-start, exit slow-start. The other thing it does to respond to loss is to retransmit a message. There is obviously no need to retransmit, but it should indeed play with cwnd in some way. How it responds will be specific to the congestion control algorithm, though. With newreno, it might set cwnd to 1 or to the initial value, or perhaps halve it. With CUBIC, IIRC, it reduces it by a smaller fraction. With CalTech FAST, which is a delay-based model and tunes toward the knee, I could imag</pre> Fred Baker (fred 2013-03-13T22:10:09 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.tsv-area