Official mailing list for the IETF working group on the Datagram Congestion Control Protocol

Lars Eggert | 4 Mar 2011 10:00

Picon

AD review: draft-ietf-dccp-tfrc-rtt-option-03

Hi,

below is my AD review for draft-ietf-dccp-tfrc-rtt-option-03. Basically, the document is ready to
progress, modulo a few minor issues. Mostly, they are about using more RFC2119 terms in Section 3 to
clarify operation. Check if that makes sense, and also check if there are other instances where a similar
rewording would add clarity.

Lars

INTRODUCTION, paragraph 3:
> Abstract

  The draft header indicates that this document updates RFC4342/RFC5622,
  but the abstract doesn't seem to mention this, which it should.

Section 10.3, paragraph 0:
>    than 4 can not be determined: such samples have to be discarded.

  Nit: s/can not/cannot/


Section 10.3, paragraph 4:
>    for example, uses a fixed value of 1 second when it can not obtain an

  Nit: s/can not/cannot/


Section 2.2.2., paragraph 1:
>    Since a loss event is defined as one or more lost (ECN-marked) data
>    packets in one RTT ([RFC5348], 5.2), the receiver needs accurate RTT

(Continue reading)

Gerrit Renker | 4 Mar 2011 12:54

Picon

Picon

Re: 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.

L.Wood | 4 Mar 2011 13:28

Picon

Re: 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?)

(Continue reading)

Gerrit Renker | 7 Mar 2011 12:46

Picon

Picon

Re: 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.

Eddie Kohler | 4 Mar 2011 16:26

Re: 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.

L.Wood | 4 Mar 2011 16:41

Picon

Re: AD review: draft-ietf-dccp-tfrc-rtt-option-03

idiomatic text should be avoided in technical writing. 

> -----Original Message-----
> From: dccp-bounces <at> ietf.org [mailto:dccp-bounces <at> ietf.org] On 
> Behalf Of Eddie Kohler
> Sent: 04 March 2011 15:27
> To: Gerrit Renker
> Cc: dccp <at> 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

(Continue reading)

Eddie Kohler | 4 Mar 2011 17:43

Re: 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.Wood <at> surrey.ac.uk wrote:
> idiomatic text should be avoided in technical writing.
>
>> -----Original Message-----
>> From: dccp-bounces <at> ietf.org [mailto:dccp-bounces <at> ietf.org] On
>> Behalf Of Eddie Kohler
>> Sent: 04 March 2011 15:27
>> To: Gerrit Renker
>> Cc: dccp <at> 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
>>
>>

(Continue reading)

L.Wood | 4 Mar 2011 19:18

Picon

Re: 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.Wood <at> surrey.ac.uk wrote:
>> idiomatic text should be avoided in technical writing.
>> 
>>> -----Original Message-----
>>> From: dccp-bounces <at> ietf.org [mailto:dccp-bounces <at> ietf.org] On
>>> Behalf Of Eddie Kohler
>>> Sent: 04 March 2011 15:27

(Continue reading)

Gorry Fairhurst | 5 Mar 2011 09:59

Picon

Picon

Re: 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

Lars Eggert | 4 Mar 2011 21:14

Picon

Re: AD review: draft-ietf-dccp-tfrc-rtt-option-03

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.
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

Attachment (smime.p7s): application/pkcs7-signature, 4367 bytes

L.Wood | 4 Mar 2011 21:25

Picon

Re: 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.Wood <at> surrey.ac.uk
http://sat-net.com/L.Wood

Lars Eggert | 5 Mar 2011 07:35

Picon

Re: AD review: draft-ietf-dccp-tfrc-rtt-option-03

On 2011-3-4, at 22:25, L.Wood <at> 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

Attachment (smime.p7s): application/pkcs7-signature, 4367 bytes

L.Wood | 5 Mar 2011 10:29

Picon

Re: AD review: draft-ietf-dccp-tfrc-rtt-option-03


On 5 Mar 2011, at 06:35, Lars Eggert wrote:

> On 2011-3-4, at 22:25, L.Wood <at> surrey.ac.uk wrote:
>> Please file a bug on that grammar checker.
> 
> Feel free: http://www.languagetool.org/

Done.
https://sourceforge.net/tracker/?func=detail&aid=3200352&group_id=110216&atid=655717

> Can we please focus on the technical discussion and not at grammar nit fixing?

of DCCP? What's the point?

Lloyd Wood
L.Wood <at> surrey.ac.uk
http://sat-net.com/L.Wood

Michael Welzl | 5 Mar 2011 10:47

Picon

Picon

Re: 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.Wood <at> surrey.ac.uk>  
<L.Wood <at> surrey.ac.uk> wrote:

>
> On 5 Mar 2011, at 06:35, Lars Eggert wrote:
>
>> On 2011-3-4, at 22:25, L.Wood <at> surrey.ac.uk wrote:
>>> Please file a bug on that grammar checker.
>>
>> Feel free: http://www.languagetool.org/
>
> Done.
> https://sourceforge.net/tracker/?func=detail&aid=3200352&group_id=110216&atid=655717
>
>> Can we please focus on the technical discussion and not at grammar  
>> nit fixing?
>
> of DCCP? What's the point?

(Continue reading)

L.Wood | 5 Mar 2011 13:20

Picon

Re: 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.Wood <at> surrey.ac.uk
http://sat-net.com/L.Wood/

> -----Original Message-----
> From: dccp-bounces <at> ietf.org [mailto:dccp-bounces <at> ietf.org] On 
> Behalf Of Michael Welzl
> Sent: 05 March 2011 09:48

(Continue reading)

Eddie Kohler | 5 Mar 2011 16:30

Re: 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.Wood <at> 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'?
>

(Continue reading)

L.Wood | 5 Mar 2011 16:59

Picon

Re: 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!

(Continue reading)

Gerrit Renker | 9 Mar 2011 12:34

Picon

Picon

Re: AD review: draft-ietf-dccp-tfrc-rtt-option-03

Thanks a lot for the review.

We have revised the document with regard to the points listed below.
The updated document has been uploaded, please see the detailed list
of changes below.

| From: Lars Eggert <lars.eggert <at> nokia.com>
| Date: Fri, 4 Mar 2011 11:00:59 +0200
| Subject: [dccp] AD review: draft-ietf-dccp-tfrc-rtt-option-03
| 
<...> 

| INTRODUCTION, paragraph 3:
| > Abstract
| 
|   The draft header indicates that this document updates RFC4342/RFC5622,
|   but the abstract doesn't seem to mention this, which it should.
| 
---
The abstract has been rewritten to clarify this point and to define 
abbreviations used by the document (which previously was not done).

 
| Section 10.3, paragraph 0:
| >    than 4 can not be determined: such samples have to be discarded.
| 
|   Nit: s/can not/cannot/
| 
| 
---

(Continue reading)

Return

Return to gmane.ietf.dccp.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane