On Aug 21, 2008, at 9:32 PM, Lars Eggert wrote:
Hi,
thanks for your comments!
On 2008-8-12, at 15:27, ext Ben Campbell wrote:
Section 3.1.1, paragraph 3:
I think this paragraph may be confusing to some implementors, in
that you suggest monitoring packet-loss to determine fair bandwidth
competition with UDP. A few worlds elaborating on how packet-loss
relates to fair use of bandwidth would be helpful. An example would
help even more.
The text in that section is actually taken from RFC3551 Section 2,
which has a bit more more detail. I could add a sentence that refers
to that RFC, instead of copying (more of) the text.
Ah, somehow I did not connect the 3551 reference in the previous
sentence to the sentence starting "Packet loss is considered
acceptable...". My mistake--I think it's fine as is.
Note, however, that there is no easy answer, because essentially
what needs to be done is building a custom congestion control scheme
- far from trivial. That's why the draft strongly recommends to use
an existing scheme. There is no easy example that can be given,
because the task is fairly complex.
Understood.
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.
Paragraph 3:
The few sentences seem redundant with previous paragraph. Given
that they are about pre-determined initial intervals, I assume they
fit better in this paragraph than the previous.
There is some similar text, because the initialization of the
intervals is the same in both cases. But paragraph 3 (and 4) are
about applications that can't maintain an RTT sample (for various
reasons), so there is a key difference.
I could remove the duplicate text and say something like "the
initial timeout is set to the same values as in the previous
paragraph", but I don't believe that'd be much clearer.
Okay.
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."
Section 3.4, paragraph 1:
I'm not sure what what the practical meaning of "a coding point of
view" is in this context.
Sloppy writing. What is meant is "coding theory". I'll change that.
That helps, thanks.
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..."
Section 3.5, last paragraph:
This first few sentences of this paragraph are redundant with
previous text in this section.
Yup. We wanted to stress this point, this repetition is on purpose.
Okay.
Section 3.6, paragraph 3, first sentence:
Sentence is ambiguous as to whether "with an IP source address..."
refers to the received datagram or the one being sent in response.
I think the sentence would be clearer if you just removed the text
"in reply...UDP datagrams".
Yes, that reads much better.
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.
Thanks!
Ben.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
