Subject: [Gen-art] Gen-ART review of draft-ietf-tsvwg-udp-guidelines-09

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Aug 2008 17:27:16 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tsvwg-udp-guidelines-09
Reviewer: Ben Campbell
Review Date:  12 Aug 2008
IESG Telechat date: 14 Aug 2008

Summary:

This draft is mostly ready for publication as a BCP. I have some  
primarily editorial comments that should be considered prior to final  
publication.

Comments:

IDNITS reports an outdated reference for draft-ietf-nsis-ntlp-15.

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.

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.

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.

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.

Section 3.4, paragraph 1:

I'm not sure what what the practical meaning of "a coding point of  
view" is in this context.

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

Section 3.5, last paragraph:

This first few sentences of this paragraph are redundant with previous  
text in this section.

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

Paragraphs 4 and 5:

Is there any guidance associated with these paragraphs?

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Lars Eggert <[email-masked]>
Date: Thu, 21 Aug 2008 19:32:03 -0700

Hi,

thanks for your comments!

On 2008-8-12, at 15:27, ext Ben Campbell wrote:
> I think this paragraph may be confusing to some implementors, in  
> that you suggest monitoring packet-loss to determine fair bandwidth  

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.

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

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

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

> view" is in this context.

Sloppy writing. What is meant is "coding theory". I'll change that.

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

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

> think the sentence would be clearer if you just removed the text "in  

Yes, that reads much better.

> 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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 22 Aug 2008 13:16:47 -0500

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

>> conflicts with the previous statement that applications  
>> implementing TFRC do not need to worry about the other  
>> recommendations in section 3.1.
>

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

> traffic that is *known* to not be congestion controlled. Is that not  

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

> Sloppy writing. What is meant is "coding theory". I'll change that.

That helps, thanks.

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

> Yup. We wanted to stress this point, this repetition is on purpose.

Okay.

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 22 Aug 2008 11:31:47 -0700

Hi,

On 2008-8-22, at 11:16, ext Ben Campbell wrote:
>>> guidelines in this section even if they implement TFRC? If so,  
>>> this conflicts with the previous statement that applications  
>> 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  
> _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*

>> 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?
>
> based traffic can be assumed to be congestion-controlled if it uses  
> a congestion-controlled transport protocol, or otherwise follows the  

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

> "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 (...)"

> 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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 22 Aug 2008 13:37:37 -0500

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:

>>> look at Sections 3.1, 3.1.1 and 3.1.2 again, and let me know if  
>>> you still think this is unclear.
>>
>> 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."
>
> 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:
>>>>
>>> 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?
>>