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/455 <pre>Hi Jose, I like your latter proposal. TCM-* should be enough: TCMTF technology is provided (and leveraged) by TCM-* elements. Only a comment on your first statement: we *can* invent new English verbs. English does not have stupid institutions like our Academy, but this is a completely different discussion... Be goode, On 17 Jun 2013, at 09:31 , Jose Saldana wrote: -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego&lt; at &gt;tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx </pre> Diego R. Lopez 2013-06-17T13:39:35 http://permalink.gmane.org/gmane.ietf.tsv-area/454 <pre>Hi, Fernando. I agree with you. We are talking about standards so precision is important. I don't think we should use the "verb" "to TCMTF" nor "TCMTFing" nor "TCMTFed". We cannot invent new English verbs. What about "optimization"?. This concept summarizes the three layers. We can use it this way: - A TCMTF optimizer - A packet optimized by means of TCMTF - A flow optimized by means of TCMTF - An optimized packet - An optimized flow - A TCMTF-optimized packet - A TCMTF-optimized flow - A TCMTF packet - A TCMTF flow - the TCMTF optimization can be applied to that flow - the impact of TCMTF optimization on protocol dynamics I have another question here: could we use only TCM instead of TCMTF? Remember that TF means "traffic flows", so a TCMTF flow would be a "tunneling compressed multiplexed traffic flows flow". Perhaps a TCM flow would be enough in those cases. TCM does not have another related meaning and it is shorter than TCMTF (http://www.acronymfinder.com/TCM.html) - A TCM optimizer - A TCM-opti</pre> Jose Saldana 2013-06-17T07:31:49 http://permalink.gmane.org/gmane.ietf.tsv-area/453 <pre>These are the main changes included in the draft charter v6 (ordered by paragraphs): 1. I have moved the sentence about the overhead to the end of the paragraph, in order to say that “For both the delay-sensitive and delay-insensitive applications, their small data payloads incur significant overhead” 2. I have put the scenarios in bullets, and I have improved some of the descriptions a bit. 6. I have changed the name of the document: instead of “document A” it is now “TCMTF – reference model”. 7. Now we are talking about another document “TCMTF – negotiation protocol”. In addition, I have put the two signaling functionalities in bullets. 7. As discussed in the list, we would talk about “setup/release a TCMTF session”. 8. I have changed the name of the document, from “document B” to “TCMTF recommendations” 8. According to Gorry’s suggestion, I have added this sentence: “The eventual impact of multiplexing on protocol dynamics (e.g. when multiplexing TCP flows) will also have to be a</pre> Jose Saldana 2013-06-13T08:43:05 http://permalink.gmane.org/gmane.ietf.tsv-area/452 <pre>This is the new proposal, adapted to the new distribution of the documents. I explain the changes in another e-mail. It is also here, in a formatted version: http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf TCMTF charter draft v6 Description of Working Group 1. In the last years we are witnessing the raise of new real-time services that use the Internet for the delivery of interactive multimedia applications: VoIP, videoconferencing, telemedicine, video vigilance, online gaming, etc. Due to the need of interactivity, many of these services use small packets (some tens of bytes), since they have to send frequent updates between the extremes of the communication. In addition, some other services also send small packets, but they are not delay-sensitive (e.g., instant messaging, m2m packets sending collected data in sensor networks using wireless or satellite scenarios). For both the delay-sensitive and delay-insensitive applications, their small data payloads incur significant overhead</pre> Jose Saldana 2013-06-13T08:37:51 http://permalink.gmane.org/gmane.ietf.tsv-area/451 <pre>In the conf-call of yesterday it was also clear that for the IETF it is better to split Document A into two documents: - The "TCMTF reference model" (1): the protocol stack and scenarios. It should be said that each protocol at each layer will use its own signaling mechanisms. - The "TCMTF-specific signaling": there are some things we will need to deploy: - a negotiation mechanism (2) to decide the options to use at each layer (e.g. a mux and demux agree on using ROHC+PPPMux+GRE) - a mechanism to setup/release a TCMTF tunnel (3)between a multiplexer and a de-multiplexer The current draft is the TCMTF "reference model", since it does not talk about specific signaling issues. By now, we don't have to propose the "TCMTF specific signaling". It would be something to be deployed if the Working Group is created. This same idea was proposed by Ken Carlberg in February. The advantages of this new distribution of the documents are (quoting Ken): Once discussed, I would create a new charter proposal includ</pre> Jose Saldana 2013-06-05T10:56:24 http://permalink.gmane.org/gmane.ietf.tsv-area/450 <pre>Please consider volunteering for the NOMCOM. -------- Original Message -------- Subject: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call Date: Wed, 29 May 2013 21:08:56 +0000 From: Mankin, Allison &lt;amankin&lt; at &gt;verisign.com&gt; Reply-To: Mankin, Allison &lt;amankin&lt; at &gt;verisign.com&gt; To: ietf-announce&lt; at &gt;ietf.org &lt;ietf-announce&lt; at &gt;ietf.org&gt; CC: &lt;ietf&lt; at &gt;ietf.org&gt; &lt;ietf&lt; at &gt;ietf.org&gt; Sorry - my eye was on entering the reply-to field and then I forgot....apologies in advance for pain that may result from this lapse. On May 29, 2013, at 5:04 PM, "Mankin, Allison" &lt;amankin&lt; at &gt;verisign.com&gt; wrote: </pre> Martin Stiemerling 2013-06-04T08:47:34 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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.tsv-area