Subject: [Tsvwg] udp guidelines draft: small comments

From: Mark Allman <[email-masked]>
Date: Tue, 03 Jul 2007 08:45:29 -0400

Gorry, Lars-
 
I read through the UDP guidelines draft yesterday.  Overall I think it
is in good shape and to me it seems like it is getting close to ready to
forward.  I flagged some small things, which I list below.  No
showstoppers, IMO.

I hope this is helpful.

allman

Sec 1: "unreliable, message-passing" -> "unreliable, best-effort,
message-passing"

Sec 3: spell out "PMTU" on first use

Sec 3.1: The first paragraph is a bit fuzzy, I think.  In particular,
you are advocating that all traffic to a "destination" be controlled
together.  This brings to mind two questions.  First, what is a
"destination"?  A host?  A host+port?  Second, this isn't how the
nominal congestion controller (TCP) does things.  I.e., you say that if
multiple processes are forked then CC should be performed across all of
them (assuming their traffic is going to the same "destination").  That
seems to be different from what TCP might do in this case.  I would like
to see this guidance be more crisp and concrete.  (That said, I am
sitting here at a sort of loss for how to do it.  Maybe I just need more
coffee.)

Sec 3.1.1: "SHOULD consider implementing TCP-friendly" -> "SHOULD
implement TCP-friendly"  (i.e., get rid of the "consider" wiggle word)

Sec 3.1.1: "in Section 3.1," -> "in Section 3.1 because TFRC naturally
addresses them,"

Sec 3.1.2: You note that apps will not benefit from CC if they only send
a small amount of data.  I am not sure I think the key point is
application benefit.  I think of the key point as the network seeing no
benefit from such applications implementing CC.

Sec 3.2: "not to do so SHOULD NOT" -> "not to adapt the packet size
SHOULD NOT" 

Sec 3.3: "send order" -> "transmission order"

Sec 3.4: "includes a 16-bit" -> "includes an optional 16-bit"

Sec 3.4: "where appropriate" -> something clearer   I.e., you might note
that not "where appropriate", but "where data integrity is important" to
scope it to the actual benefit gained by using a stronger check.

Sec 3.5: "typically perform a" -> "typically performs a"

---

From: Lars Eggert <[email-masked]>
Date: Tue, 3 Jul 2007 16:09:08 +0300

Hi,

thanks for the feedback. I'll fix the nits you have identified, but  
there is one issue that the WG should discuss some more:

> sitting here at a sort of loss for how to do it.  Maybe I just need  

The motivation for this text came from seeing a number of request- 
response protocols, where a client shoots off many parallel requests  
to the same server, maybe from different threads or processes. UDP  
has no connections and so it's easy to say "well, it's just one  
request and one response per (application-level) connection, so  
there's no way to do CC", which is inaccurate. Some of these  
protocols initially talked about allowing hundreds of parallel  
requests, at which point CC over the aggregate becomes very desirable.

I agree that the definition of "destination" is weak. If "destination  
IP address + port", that might create some UDP traffic aggregate  
comparable to a TCP flow, if TCP was used by the application. (If  
"destination IP address" only, that might end up looking like  
something that TCB sharing or the Congestion Manager would have  
created, had they seen deployment.)

I'd be very happy to make this more clear in the text, but first the  
WG should come to consensus on whether we want to keep the  
recommendation to perform CC on aggregate traffic to a destination or  
not.

Lars