Re: [Bloat] my backlogged comments on the ECT(1) interim call
Hi Jake, Thanks for the notes. Very useful. The other issue with the meeting was that the virtual mic queue control channel was the WebEx Meeting chat that does not exist in WebEx Teams. So, I had to switch to Meetings and lost some pieces of the discussion. Yes there might be a terminology difference. Elastic traffic is usually used in the sense of bandwidth sharing not just to define variable bit rates. The point is that there are incentives to cheat in L4S. There is a priority queue that my application can enter by providing as input ECT(1). Applications such as on-line meetings will have a relatively low and highly paced rate. This traffic is conformant to dualQ L queue but is unresponsive to congestion notifications. This is especially true for FEC streams which could be used to ameliorate the media quality in presence of losses(e.g. Wi-Fi) or increased jitter. That was one more point on why using ECT(1) as input assumes trust or a black list after being caught. In both cases the ECT(1) as input is DoSable. On Tue, Apr 28, 2020 at 7:12 PM Holland, Jake wrote: > Hi Luca, > > > > To your point about the discussion being difficult to follow: I tried to > capture the intent of everyone who commented while taking notes: > > https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tsvwg-03 > > > > I think this was intended to take the place of a need for everyone to > re-send the same points to the list, but of course some of the most crucial > points could probably use fleshing out with on-list follow up. > > > > It got a bit rough in places because I was disconnected a few times and > had to cut over to a local text file, and I may have failed to correctly > understand or summarize some of the comments, so there’s chances I might > have missed something, but I did my best to capture them all. > > > > I encourage people to review comments and check whether they came out more > or less correct, and to offer formatting and cleanup suggestions if there’s > a good way to make it easier to follow. > > > > I had timestamps at the beginning of each main point of discussion, with > the intent that after the video is published it would be easier to go back > and check precisely what was said. It looks like someone has been making > cleanup edits that removed the first half of those so far, but my local > text file still has most of those and I can go back and re-insert them if > it seems useful. > > > > @Luca: during your comments in particular I think there might have been a > disruption--I had a “first comment missed, please check video” placeholder > and I may have misunderstood the part about video elasticity, but my > interpretation at the time was that Stuart was claiming that video was > elastic in that it would adjust downward to avoid overflowing a loaded > link, and I thought you were claiming that it was not elastic in that it > would not exceed a maximum rate, which I summarized as perhaps a semantic > disagreement, but if you’d like to help clean that up, it might be useful. > > > > From this message, it sounds like the key point you were making was that > it also will not go below a certain rate, and perhaps that quality can stay > relatively good in spite of high network loss? > > > > Best regards, > > Jake > > > > *From: *Luca Muscariello > *Date: *Tuesday, April 28, 2020 at 1:54 AM > *To: *Dave Taht > *Cc: *tsvwg IETF list , bloat > > *Subject: *Re: [Bloat] my backlogged comments on the ECT(1) interim call > > > > Hi Dave and list members, > > > > It was difficult to follow the discussion at the meeting yesterday. > > Who said what in the first place. > > > > There have been a lot of non-technical comments such as: this solution > > is better than another in my opinion. "better" has often been used > > as when evaluating the taste of an ice cream: White chocolate vs black > chocolate. > > This has taken a significant amount of time at the meeting. I haven't > learned > > much from that kind of discussion and I do not think that helped to make > > much progress. > > > > If people can re-make their points in the list it would help the debate. > > > > Another point that a few raised is that we have to make a decision as fast > as possible. > > I dismissed entirely that argument. Trading off latency with resilience of > the Internet > > is entirely against the design principle of the Internet architecture > itself. > > Risk analysis is something that we should keep in mind even when > deploying any experiment > > and should be a substantial part of it. > > > > Someone claimed that on-line meeting traffic is elastic. Th
Re: [Bloat] my backlogged comments on the ECT(1) interim call
--- Begin Message --- Hi Luca, To your point about the discussion being difficult to follow: I tried to capture the intent of everyone who commented while taking notes: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tsvwg-03 I think this was intended to take the place of a need for everyone to re-send the same points to the list, but of course some of the most crucial points could probably use fleshing out with on-list follow up. It got a bit rough in places because I was disconnected a few times and had to cut over to a local text file, and I may have failed to correctly understand or summarize some of the comments, so there’s chances I might have missed something, but I did my best to capture them all. I encourage people to review comments and check whether they came out more or less correct, and to offer formatting and cleanup suggestions if there’s a good way to make it easier to follow. I had timestamps at the beginning of each main point of discussion, with the intent that after the video is published it would be easier to go back and check precisely what was said. It looks like someone has been making cleanup edits that removed the first half of those so far, but my local text file still has most of those and I can go back and re-insert them if it seems useful. @Luca: during your comments in particular I think there might have been a disruption--I had a “first comment missed, please check video” placeholder and I may have misunderstood the part about video elasticity, but my interpretation at the time was that Stuart was claiming that video was elastic in that it would adjust downward to avoid overflowing a loaded link, and I thought you were claiming that it was not elastic in that it would not exceed a maximum rate, which I summarized as perhaps a semantic disagreement, but if you’d like to help clean that up, it might be useful. From this message, it sounds like the key point you were making was that it also will not go below a certain rate, and perhaps that quality can stay relatively good in spite of high network loss? Best regards, Jake From: Luca Muscariello Date: Tuesday, April 28, 2020 at 1:54 AM To: Dave Taht Cc: tsvwg IETF list , bloat Subject: Re: [Bloat] my backlogged comments on the ECT(1) interim call Hi Dave and list members, It was difficult to follow the discussion at the meeting yesterday. Who said what in the first place. There have been a lot of non-technical comments such as: this solution is better than another in my opinion. "better" has often been used as when evaluating the taste of an ice cream: White chocolate vs black chocolate. This has taken a significant amount of time at the meeting. I haven't learned much from that kind of discussion and I do not think that helped to make much progress. If people can re-make their points in the list it would help the debate. Another point that a few raised is that we have to make a decision as fast as possible. I dismissed entirely that argument. Trading off latency with resilience of the Internet is entirely against the design principle of the Internet architecture itself. Risk analysis is something that we should keep in mind even when deploying any experiment and should be a substantial part of it. Someone claimed that on-line meeting traffic is elastic. This is not true, I tried to clarify this. These applications (WebEx/Zoom) are low rate, a typical maximum upstream rate is 2Mbps and is not elastic. These applications have often a stand-alone app that is not using the browser WebRTC stack (the standalone app typically works better). A client sends upstream one or two video qualities unless the video camera is switched off. In presence of losses, FEC is used but it is still non elastic. Someone claimed (at yesterday's meeting) that fairness is not an issue (who cares, I heard!) Well, fairness can constitute a differentiation advantage between two companies that are commercializing on-line meetings products. Unless at the IETF we accept "law-of-the-jungle" behaviours from Internet applications developers, we should be careful about making such claims. Any opportunity to cheat, that brings a business advantage WILL be used. /Luca TL;DR To Dave: you asked several times what Cisco does on latency reduction in network equipment. I tend to be very shy when replying on these questions as this is not vendor neutral. If chairs think this is not appropriate for the list, please say it and I'll reply privately only. What I write below can be found in Cisco products data sheets and is not trade secret. There are very good blog posts explaining details. Not surprisingly Cisco implements the state of the art on the topic and it is totally feasible to do-the-right-thing in software and hardware. Cisco implements AFD (one queue + a flow table) accompanied by a priority queue for flows that have a certain profile in rate and size. The concept
Re: [Bloat] my backlogged comments on the ECT(1) interim call
Hi Dave and list members, It was difficult to follow the discussion at the meeting yesterday. Who said what in the first place. There have been a lot of non-technical comments such as: this solution is better than another in my opinion. "better" has often been used as when evaluating the taste of an ice cream: White chocolate vs black chocolate. This has taken a significant amount of time at the meeting. I haven't learned much from that kind of discussion and I do not think that helped to make much progress. If people can re-make their points in the list it would help the debate. Another point that a few raised is that we have to make a decision as fast as possible. I dismissed entirely that argument. Trading off latency with resilience of the Internet is entirely against the design principle of the Internet architecture itself. Risk analysis is something that we should keep in mind even when deploying any experiment and should be a substantial part of it. Someone claimed that on-line meeting traffic is elastic. This is not true, I tried to clarify this. These applications (WebEx/Zoom) are low rate, a typical maximum upstream rate is 2Mbps and is not elastic. These applications have often a stand-alone app that is not using the browser WebRTC stack (the standalone app typically works better). A client sends upstream one or two video qualities unless the video camera is switched off. In presence of losses, FEC is used but it is still non elastic. Someone claimed (at yesterday's meeting) that fairness is not an issue (who cares, I heard!) Well, fairness can constitute a differentiation advantage between two companies that are commercializing on-line meetings products. Unless at the IETF we accept "law-of-the-jungle" behaviours from Internet applications developers, we should be careful about making such claims. Any opportunity to cheat, that brings a business advantage WILL be used. /Luca TL;DR To Dave: you asked several times what Cisco does on latency reduction in network equipment. I tend to be very shy when replying on these questions as this is not vendor neutral. If chairs think this is not appropriate for the list, please say it and I'll reply privately only. What I write below can be found in Cisco products data sheets and is not trade secret. There are very good blog posts explaining details. Not surprisingly Cisco implements the state of the art on the topic and it is totally feasible to do-the-right-thing in software and hardware. Cisco implements AFD (one queue + a flow table) accompanied by a priority queue for flows that have a certain profile in rate and size. The concept is well known and well studied in the literature. AFD is safe and can well serve a complex traffic mix when accompanied by a priority queue. This prio-queue should not be confused with a strict priority queue (e.g. EF in diffserv). There are subtleties related to the DOCSIS shared medium which would be too long to describe here. This is available in Cisco CMTS for the DOCSIS segment. Bottleneck traffic does not negatively impact non-bottlenecked-traffic such as an on-line meeting like the WebEx call we had yesterday. It is safe from a network neutrality point-of-view and no applications get hurt. Cisco implements AFD+prio also for some DC switches such as the Nexus 9k. There is a blog post written by Tom Edsal online that explains pretty well how that works. This includes mechanisms such as p-fabric to approximate SRPT (shortest remaining processing time) and minimize flow completion time for many DC workloads. The mix of the two brings FCT minimization AND latency minimization. This is silicon and scales at any speed. For those who are not familiar with these concepts, please search the research work of Balaji Prabhakar and Ron Pang at Stanford. Wi-Fi: Cisco does airtime fairness in Aironet but I think in the Meraki series too. The concept is similar to what described above but there are several queues, one per STA. Packets are enqueued in the access (category) queue at dequeue time from the air-time packet scheduler. On Mon, Apr 27, 2020 at 9:24 PM Dave Taht wrote: > It looks like the majority of what I say below is not related to the > fate of the "bit". The push to take the bit was > strong with this one, and me... can't we deploy more of what we > already got in places where it matters? > > ... > > so: A) PLEA: From 10 years now, of me working on bufferbloat, working > on real end-user and wifi traffic and real networks > > I would like folk here to stop benchmarking two flows that run for a long > time > and in one direction only... and thus exclusively in tcp congestion > avoidance mode. > > Please. just. stop. Real traffic looks nothing like that. The internet > looks nothing like that. > The netops folk I know just roll their eyes up at benchmarks like this > that prove nothing and tell me to go to ripe meetings instead. > When y'all talk about "not looking foolish for not mandating ecn now", >
