Hi,
The discussion so far and the proposed revisions address all of my
comments.
Thanks!
Ben.
On Aug 22, 2008, at 1:31 PM, Lars Eggert wrote:
Hi,
On 2008-8-22, at 11:16, ext Ben Campbell wrote:
Section 3.1.2, paragraph 1:
Should I take this to mean that implementing TFRC is insufficient
for low-volume applications, and that they should follow the
guidelines in this section even if they implement TFRC? If so,
this conflicts with the previous statement that applications
implementing TFRC do not need to worry about the other
recommendations in section 3.1.
Yes, TFRC is only effective for bulk transfers, and Section 3.1.1
is fairly clear about this. Section 3.1.2 is on low-datarate
applications, where different mechanisms are needed. Please take a
look at Sections 3.1, 3.1.1 and 3.1.2 again, and let me know if
you still think this is unclear.
It's a structure issue -- Paragraph 2 in 3.1.1 says that if an
application implements TFRC, it need not follow the remaining
guidelines in 3.1. 3.1.2 talks about a class of application for
which TFRC is not sufficient. If the reader interprets "remaining
guidelines in section 3.1" to be inclusive of 3.1 and it's
_subsections_, he may simply decide to implement TFRC and skip
reading the rest of 3.1--missing the warning about low volume
applications entirely.
Ah - I'll make it clear that with TFRC one need not follow the
remaining guideliens in 3.1.*1*
Section 3.1.3, numbered list:
Item 1 assumes all IP-based payloads are congestion-controlled,
while 2 explicitly calls out non-congestion controlled IP-based
payloads. I assume the intent was for item 1 to refer just to
congestion-controlled IP-based payloads.
Right. 1 is on IP traffic, and the general assumption is that any
IP traffic would be congestion controlled. 2 is on non-IP traffic
or IP traffic that is *known* to not be congestion controlled. Is
that not clear?
I am probably being pedantic, but I can see people interpreting
item one to state that all IP-based payload traffic can be assumed
to be congestion-controlled. Perhaps something to the effect of the
following would help:
"..., and the pay-load is congestion-controlled IP-based traffic.
IP-based traffic can be assumed to be congestion-controlled if it
uses a congestion-controlled transport protocol, or otherwise
follows the guidelines in this document."
I changed the beginning of item 1 to: "A tunnel generates UDP
traffic at a volume that corresponds to the volume of payload
traffic, and the payload traffic is IP-based and congestion-
controlled."
Section 3.5, paragraph 6, last sentence:
This advice seems counter to the idea that applications should be
designed to work on the internet at large, rather than for some
specific network configuration. Perhaps you meant to say "The
deployers of applications should investigate..."?
Sorry, which paragraph are you referring to here?
(The last sentence of paragraph 6 of Section 3.5 is the following,
which I can't bring in relation to the above comment: "It is
RECOMMENDED that applications apply slight random variations
("jitter") to the timing of keep-alive transmissions, in order to
reduce the potential for persistent synchronization between keep-
alive transmissions from different hosts.")
Sorry, I meant the second-to-last sentence, starting with
"Applications that operate in more controlled network
environments..."
Ah. I've changed that sentence to: "When applications are deployed
in more controlled network environments, the deployers SHOULD
investigate whether the target environment allows applications to
use longer intervals, or whether it offers mechanisms to explicitly
control middlebox state timeout durations (...)"
Paragraphs 4 and 5:
Is there any guidance associated with these paragraphs?
Some WG participants felt that the document should point out that
the socket API for UDP is subtly different than that for TCP,
which developers are more familiar with, and those two paragraphs
give some examples. I guess the guidance would be "pay attention
to that." Do you have a suggestion how we could make that more
clear?
No, it's okay. My initial reaction was that teaching the proper use
of the socket APIs for UDP in general was a bit odd for the purpose
of this document, but if the working group consciously chose to do
so then I have no objection.
We had exactly that discussion (how much of a sockets tutorial this
section should turn into) and the compromise was to give a few
examples. (Originally, the person who suggested this text wanted to
point out several additional differences.)
Thanks again for your comments! I'll shortly submit a revision.
Lars
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
