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.
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.
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.
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.
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?
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.
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.")
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.
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?
Thanks,
Lars
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
