Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
Thank you very much, this was informative and helpful. As a non-native speaker it is indeed sometimes difficult to find the right tone. (I wrote this before I saw that the thread forked children.) | (Meta: we're discussing grammar nitpicks to a standards-track | update to an aspect of a protocol that's currently on life | support with a hack to get through NAT via UDP tunnelling to | try and get some installed base? When did the IETF jump the | shark?) | Even with that life support I would not expect a huge user base. A value exists somewhere else -- as a test platform for new algorithms. Thanks to the infrastructure developed by Arnaldo Carvalho de Melo there is a deployable DCCP implementation in a Linux kernel near you. It may help in developing algorithms for real problems, such as bufferbloat, or congestion control in mesh networks: testing with real prototypes instead of the over-used ns-2.
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
On 04/03/2011 15:26, Eddie Kohler wrote: Hi Gerrit, Lars is right, cannot is far more idiomatic, in written or spoken text. http://www.drgrammar.org/frequently-asked-questions#30 http://www.wsu.edu/~brians/errors/cannot.html Eddie This seems editorial, the authors will take advice from the RFC-Ed. Gorry
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
constructive: when, or *at least* after developing a protocol, think about deployment: why would people use it, how can we get them to use it, how can we make it easier for the protocol to pass through middle- boxes etc? destructive: when the perhaps most important work is done - thinking about actual deployment - call it a futile effort already. i wonder, what's the point of being destructive? michael On Mar 5, 2011, at 10:29 AM, l.w...@surrey.ac.uk l.w...@surrey.ac.uk wrote: On 5 Mar 2011, at 06:35, Lars Eggert wrote: On 2011-3-4, at 22:25, l.w...@surrey.ac.uk wrote: Please file a bug on that grammar checker. Feel free: http://www.languagetool.org/ Done. https://sourceforge.net/tracker/?func=detailaid=3200352group_id=110216atid=655717 Can we please focus on the technical discussion and not at grammar nit fixing? of DCCP? What's the point? Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
The point of asking the question? It's an economics argument, using terms from that discipline - the recognition of opportunity cost; that continued effort spent on e.g. improving DCCP specifications or doing DCCP-over-UDP could be going elsewhere to greater benefit and effect. Lots of important work was done on e.g. ATM adaptation layers or on the ISO OSI model. (Or on Adobe Flash.) But that doesn't mean that those sunk costs (the time and effort spent on the important work already done) have to continue to be maintained by further development if the benefits aren't there. Do the prospective benefits of a protocol that can't be deployed outweigh the sunk costs? Or is the problem of applications sending traffic without considering congestion control better solved by e.g. 'here's an open-source library that runs directly over UDP for your UDP-using application to implement its own endpoint congestion control'? Insofar as DCCP tests TFRC algorithms and acts as an example, it has some useful role for experimentation (rather than standards track) -- but wider deployment of TFRC, in whatever form, is what matters, while widespread DCCP deployment for applications to rely on appears to me to be a lost cause even with the kludging to make DCCP run over UDP. It's an algorithm deployment issue, not a protocol deployment issue. The goal is widespread TFRC use, and widespread DCCP deployment to get to widespread TFRC use is unlikely to happen. How best to get widespread adoption of TFRC itself? Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood/ -Original Message- From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Michael Welzl Sent: 05 March 2011 09:48 To: 'dccp' working group Subject: Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03 constructive: when, or *at least* after developing a protocol, think about deployment: why would people use it, how can we get them to use it, how can we make it easier for the protocol to pass through middle- boxes etc? destructive: when the perhaps most important work is done - thinking about actual deployment - call it a futile effort already. i wonder, what's the point of being destructive? michael
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
Well, TFRC is only one of DCCP WG's four chartered areas. DCCP implementation and deployment experience seems to show that rate-based protocols are simply harder to implement than ack-paced protocols. There are a lot of good implementation reasons for this. As a result, TFRC isn't a convincing algorithmic success, and praying for its deployment is weird. You shouldn't want TFRC, which is a means to an end. What end? Unreliable congestion control? DCCP is a mechanism for experimenting with TFRC and with potential alternatives -- different AIMD parameters, etc. I don't think I'll respond to another of your emails, however. Eddie On 3/5/11 4:20 AM, l.w...@surrey.ac.uk wrote: The point of asking the question? It's an economics argument, using terms from that discipline - the recognition of opportunity cost; that continued effort spent on e.g. improving DCCP specifications or doing DCCP-over-UDP could be going elsewhere to greater benefit and effect. Lots of important work was done on e.g. ATM adaptation layers or on the ISO OSI model. (Or on Adobe Flash.) But that doesn't mean that those sunk costs (the time and effort spent on the important work already done) have to continue to be maintained by further development if the benefits aren't there. Do the prospective benefits of a protocol that can't be deployed outweigh the sunk costs? Or is the problem of applications sending traffic without considering congestion control better solved by e.g. 'here's an open-source library that runs directly over UDP for your UDP-using application to implement its own endpoint congestion control'? Insofar as DCCP tests TFRC algorithms and acts as an example, it has some useful role for experimentation (rather than standards track) -- but wider deployment of TFRC, in whatever form, is what matters, while widespread DCCP deployment for applications to rely on appears to me to be a lost cause even with the kludging to make DCCP run over UDP. It's an algorithm deployment issue, not a protocol deployment issue. The goal is widespread TFRC use, and widespread DCCP deployment to get to widespread TFRC use is unlikely to happen. How best to get widespread adoption of TFRC itself? Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood/ -Original Message- From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Michael Welzl Sent: 05 March 2011 09:48 To: 'dccp' working group Subject: Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03 constructive: when, or *at least* after developing a protocol, think about deployment: why would people use it, how can we get them to use it, how can we make it easier for the protocol to pass through middle- boxes etc? destructive: when the perhaps most important work is done - thinking about actual deployment - call it a futile effort already. i wonder, what's the point of being destructive? michael
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
On 5 Mar 2011, at 15:30, Eddie Kohler wrote: Well, TFRC is only one of DCCP WG's four chartered areas. but it's the only one that doesn't treat DCCP as an (increasingly internally focused, imo) end in itself. DCCP implementation and deployment experience seems to show that rate-based protocols are simply harder to implement than ack-paced protocols. But that experience has also shown that newly-assigned protocol numbers are rather limited on the public Internet. (SCTP has the same problem, despite being rather older - but SCTP has history and installed base outside the public NATted Internet.) You shouldn't want TFRC, which is a means to an end. What end? Unreliable congestion control? Indeed, because congestion control and avoiding congestion collapse (but without massive reengineering of the underlying network) remains a significant concern. Well, a significant concern of the IESG. DCCP is a mechanism for experimenting with TFRC and with potential alternatives -- different AIMD parameters, etc. That we agree on. I don't think I'll respond to another of your emails, however. Oh no! he's killfiled Larry! Eddie On 3/5/11 4:20 AM, l.w...@surrey.ac.uk wrote: The point of asking the question? It's an economics argument, using terms from that discipline - the recognition of opportunity cost; that continued effort spent on e.g. improving DCCP specifications or doing DCCP-over-UDP could be going elsewhere to greater benefit and effect. Lots of important work was done on e.g. ATM adaptation layers or on the ISO OSI model. (Or on Adobe Flash.) But that doesn't mean that those sunk costs (the time and effort spent on the important work already done) have to continue to be maintained by further development if the benefits aren't there. Do the prospective benefits of a protocol that can't be deployed outweigh the sunk costs? Or is the problem of applications sending traffic without considering congestion control better solved by e.g. 'here's an open-source library that runs directly over UDP for your UDP-using application to implement its own endpoint congestion control'? Insofar as DCCP tests TFRC algorithms and acts as an example, it has some useful role for experimentation (rather than standards track) -- but wider deployment of TFRC, in whatever form, is what matters, while widespread DCCP deployment for applications to rely on appears to me to be a lost cause even with the kludging to make DCCP run over UDP. It's an algorithm deployment issue, not a protocol deployment issue. The goal is widespread TFRC use, and widespread DCCP deployment to get to widespread TFRC use is unlikely to happen. How best to get widespread adoption of TFRC itself? Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood/ -Original Message- From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Michael Welzl Sent: 05 March 2011 09:48 To: 'dccp' working group Subject: Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03 constructive: when, or *at least* after developing a protocol, think about deployment: why would people use it, how can we get them to use it, how can we make it easier for the protocol to pass through middle- boxes etc? destructive: when the perhaps most important work is done - thinking about actual deployment - call it a futile effort already. i wonder, what's the point of being destructive? michael Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
As an actual native English speaker on this thread, I would use 'cannot' for 'cannot obtain', as it indicates an impossibility, never a choice, but stay with 'can not' in the other cases. I cannot live forever; I don't get the choice. I can not care about this silly thread, but I choose to post regardless. (yes, there are multiple meanings in that one...) While running words together is very German, here that is not always appropriate. When these are choices that could somehow be done, rather than impossibilities, 'can not' is better - but as imo 'can not' can also covers the other case of impossibility where 'cannot' fits best, and the reverse is not true, 'can not' can be the safer choice - particularly for non-native speakers and technical documentation. (The can't contraction covers both.) So Gerrit's choice is best, though in those cases I'd reword the technical documenation and say something like 'is unable to' to be perfectly clear that there is no choice in the matter. That avoids can/may permission ambiguity and confusion as well. Some post-hoc rationale is at http://alexfiles.com/cannot.shtml http://www.wisegeek.com/what-is-the-difference-between-cannot-and-can-not.htm (Meta: we're discussing grammar nitpicks to a standards-track update to an aspect of a protocol that's currently on life support with a hack to get through NAT via UDP tunnelling to try and get some installed base? When did the IETF jump the shark?) -Original Message- From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Gerrit Renker Sent: 04 March 2011 11:55 To: Lars Eggert Cc: dccp@ietf.org group Subject: Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03 Lars, - | than 4 can not be determined: such samples have to be discarded. | | Nit: s/can not/cannot/ | I would like to ask if we could keep it as it is, the suggestion confuses me: can is a verb, not the negation, cannot is spoken language, the document is written text. I actually replace everywhere I see this the other way around, since I read somewhere that cannot in written text is not considered good style. If you can give a rule for the above, I am willing to be educated on the matter.
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
Hi Gerrit, Lars is right, cannot is far more idiomatic, in written or spoken text. http://www.drgrammar.org/frequently-asked-questions#30 http://www.wsu.edu/~brians/errors/cannot.html Eddie On 3/4/11 3:54 AM, Gerrit Renker wrote: Lars, - | than 4 can not be determined: such samples have to be discarded. | | Nit: s/can not/cannot/ | I would like to ask if we could keep it as it is, the suggestion confuses me: can is a verb, not the negation, cannot is spoken language, the document is written text. I actually replace everywhere I see this the other way around, since I read somewhere that cannot in written text is not considered good style. If you can give a rule for the above, I am willing to be educated on the matter.
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
idiomatic text should be avoided in technical writing. -Original Message- From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Eddie Kohler Sent: 04 March 2011 15:27 To: Gerrit Renker Cc: dccp@ietf.org group Subject: Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03 Hi Gerrit, Lars is right, cannot is far more idiomatic, in written or spoken text. http://www.drgrammar.org/frequently-asked-questions#30 http://www.wsu.edu/~brians/errors/cannot.html Eddie On 3/4/11 3:54 AM, Gerrit Renker wrote: Lars, - | than 4 can not be determined: such samples have to be discarded. | | Nit: s/can not/cannot/ | I would like to ask if we could keep it as it is, the suggestion confuses me: can is a verb, not the negation, cannot is spoken language, the document is written text. I actually replace everywhere I see this the other way around, since I read somewhere that cannot in written text is not considered good style. If you can give a rule for the above, I am willing to be educated on the matter.
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
Larry, Probably I should have said correct or common. Nevertheless, you are wrong; technical writing is itself an idiom (the language peculiar to a people or to a district, community, or class). Eddie On 3/4/11 7:41 AM, l.w...@surrey.ac.uk wrote: idiomatic text should be avoided in technical writing. -Original Message- From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Eddie Kohler Sent: 04 March 2011 15:27 To: Gerrit Renker Cc: dccp@ietf.org group Subject: Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03 Hi Gerrit, Lars is right, cannot is far more idiomatic, in written or spoken text. http://www.drgrammar.org/frequently-asked-questions#30 http://www.wsu.edu/~brians/errors/cannot.html Eddie On 3/4/11 3:54 AM, Gerrit Renker wrote: Lars, - | than 4 can not be determined: such samples have to be discarded. | | Nit: s/can not/cannot/ | I would like to ask if we could keep it as it is, the suggestion confuses me: can is a verb, not the negation, cannot is spoken language, the document is written text. I actually replace everywhere I see this the other way around, since I read somewhere that cannot in written text is not considered good style. If you can give a rule for the above, I am willing to be educated on the matter.
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
Ted, On 4 Mar 2011, at 16:43, Eddie Kohler wrote: Larry, who? Probably I should have said correct or common. Nevertheless, you are wrong; technical writing is itself an idiom (the language peculiar to a people or to a district, community, or class). That definition is for a dialect - which idiom can be a synonym for. Technical writing is, in general, the deliberate absence of idioms or colloquialisms where possible - and when they are used, they are often explicitly defined. Expressing a preference for the more idiomatic form goes against that. Eddie On 3/4/11 7:41 AM, l.w...@surrey.ac.uk wrote: idiomatic text should be avoided in technical writing. -Original Message- From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Eddie Kohler Sent: 04 March 2011 15:27 To: Gerrit Renker Cc: dccp@ietf.org group Subject: Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03 Hi Gerrit, Lars is right, cannot is far more idiomatic, in written or spoken text. http://www.drgrammar.org/frequently-asked-questions#30 http://www.wsu.edu/~brians/errors/cannot.html Eddie On 3/4/11 3:54 AM, Gerrit Renker wrote: Lars, - | than 4 can not be determined: such samples have to be discarded. | | Nit: s/can not/cannot/ | I would like to ask if we could keep it as it is, the suggestion confuses me: can is a verb, not the negation, cannot is spoken language, the document is written text. I actually replace everywhere I see this the other way around, since I read somewhere that cannot in written text is not considered good style. If you can give a rule for the above, I am willing to be educated on the matter. Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
On 4 Mar 2011, at 20:14, Lars Eggert wrote: On 2011-3-4, at 13:54, Gerrit Renker wrote: | than 4 can not be determined: such samples have to be discarded. | | Nit: s/can not/cannot/ This was flagged by the grammar checker that runs as part of my ID review script, and not by me personally. Please file a bug on that grammar checker. I'd separate out 'automatic' but-the-code-told-me-to-do-it parts of the review, and flag them as such. Since it's clearly a nit, I don't really care if you fix it at this time or not. (I am guessing the RFC Editor will change it later anyway.) Lars Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood
Re: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
On 2011-3-4, at 22:25, l.w...@surrey.ac.uk wrote: Please file a bug on that grammar checker. Feel free: http://www.languagetool.org/ I'd separate out 'automatic' but-the-code-told-me-to-do-it parts of the review, and flag them as such. The reviews produced by the script normally include the following header, but I think I cut it by mistake when forwarding: COMMENT: Note: Most comments marked as nits below have been automatically flagged by review scripts - there may be some false positives in there. Can we please focus on the technical discussion and not at grammar nit fixing? Lars smime.p7s Description: S/MIME cryptographic signature
