Subject: [Tsvwg] Fwd: draft-ietf-tsvwg-udp-guidelines-05

From: Lars Eggert <[email-masked]>
Date: Wed, 13 Feb 2008 17:02:02 +0200

Hi,

we've received the following comments on the -05 revision from Alfred  
Hoenes (forwarded with permission). I wanted to forward them now so  
the group can take a look; the authors will probably not be able to  
respond to his review before next week.

Lars

Begin forwarded message:

> From: "ext Alfred HÎnes" <[email-masked]>
> Date: February 13, 2008 15:30:52 GMT+02:00
> To: [email-masked], [email-masked]
> Subject: draft-ietf-tsvwg-udp-guidelines-05
>
> Hello,
> after studying the Internet-Draft authored/edited by you,
>            draft-ietf-tsvwg-udp-guidelines-05,
> I'd like to submit a few comments, mostly addressing textual
> flaws I found in that memo.
>
> Generally, I agree with the technical content and the
> recommendations in that memo, but I am concerned with
> the timing recommendations stated in section 3.1.2.
> Taken literally, many uses of DNS or similar porotocols
> would violate these recommendations, because they cannot
> "establish a statistically accurate RTT estimate" -- due to
> the lack of enough samples to gain *statistical* relevance.
>
> I guess that this was not the intent of the memo.
>
> Perhaps, it would make sense to introduce another sub-class
> of UDP applications: those operating in lock-step fashion.
>
> In these cases, there's at most one packet outstanding at any
> time, and the observed delay between the transmission of a
> query and the receipt of a response corresponds to a sample
> of the RTT plus the time needed by the server for processing
> the request -- which may include the time for secondary
> network transactions needed by the server (e.g. DNS, LDAP).
> Thus, the observed delay is a realistic lower bound on the
> pure network RTT, although it does not have any statistical
> significance.
> I suggest that the memo should allow such samples explicitely
> as a replacement for a "statistically relevant" RTT estimate.
>
> Furthermore, in multiprocessing environments with layered
> client-server components, statistically uncorrelated requests
> will arrive at intermediary functions that need to make
> subordinate request via UDP.  It seems to be overly restrictive
> to require such transactions to not overlap, or even to apply
> the 3 second delay between them.
> It might be more appropriate, and sufficient for the aims of the
> draft, to request that lock-step protocols do not send more than
> one packet to the same destination *on average* over time.
> Not doing so might cause undue delays for the primary requests,
> eventually causing application timeouts and (otherwies unnecessary)
> retries, which effectively would even *increase* the overall
> network traffic.
>
>
> Recommendations regarding further textual issues I found:
>
>
> (1)  Section 3.1.3, last paragraph
>
> Please change:
>
>   Designing tunneling mechanism requires ...
>
> to either:
>
>   Designing a tunneling mechanism requires ...
>             ^^
> or:
>
>   Designing tunneling mechanisms requires ...
>                                ^
>
> (2)  Section 3.2, last paragraph
>
> The draft says:
>
>   Applications that do not send messages that exceed the effective  
> PMTU
> |  of IPv4 or IPv6 need not implement any of the above mechanisms.   
> Note
> |  that the presence of tunnels can cause fragmentation even when
> |  applications send messages that do not exceed the effective PMTU,  
> so
> |  implementing PMTU discovery will still be beneficial in some cases.
>
> IMO, this is grossly misleading.
> The PMTU (*Path* MTU) determination includes the restrictions
> imposed by all IP hops on the path, may they be physical link
> layers or virtual links (tunnels).
> Thus, a packet not exceeding the effective PMTU should never need
> fragmentation by an on-path tunnel.
>
> I suggest to either drop the second sentence entirely, or replace
> it by:
>
>   Note that the presence of tunnels can cause additional reductions
>   of the effective PMTU, beyond those enforced by physical link
>   layers and additional end-to-end protocol headers.
>
>
> (3)  Section 3.4.1, last paragraph
>
> I suggest to change there:
>
>      "partial-coverage" --> "partial coverage" .
>              ^                      ^
>
> (4)  Section 3.6, 5th paragraph
>
> The draft says:
>                       [...].  Binding a socket also allows configuring
>   options that affect the UDP or IP layers, for example, use of the  
> UDP
> |  checksum or IP source routing.  [...]
>
> IMO, the mentioning of 'source routing' is questionable.
> Source Routing is in the process of being phased out due to
> very serious security concerns, cf. RFC 5095 for IPv6 and
> draft-reitzel-ipv4-source-routing-is-evil-00 for IPv4.
> To make the example much more relevant, I suggest to mention
> the much more useful and common IP Time Stamp Option instead.
>
>
> (5)  Section 3.6, 6th paragraph
>
> The draft says:
>
>   UDP provides no flow-control.  This is another reason why UDP-based
>   applications need to be robust in the presence of packet loss.  This
>   loss can also occur within the sending host, when an application
>   sends data faster than the line rate of the outbound network
>   interface.  It can also occur on the destination, where receive  
> calls
> |  fail to return data when the application issues them too frequently
> |  (i.e., when no new data has arrived) or not frequently enough  
> (i.e.,
>   such that the receive buffer overflows).  Robust flow control
>   mechanisms are difficult to implement, which is why applications  
> that
>   need this functionality SHOULD consider using a full-featured
>   transport protocol.
>
> I cannot see why and how issuing read requests
>   "too frequently (i.e., when no new data has arrived)"
> can cause packet loss.
> In the socket API, 'probing' to read (under the NODELAY socket option)
> is a common alternative to the use of select(), and it does no harm,
> neither to the operating system nor to the application.
>
>
> (6)  Section 3.6, last (7th) paragraph
>
> Please insert the missing "be" to say:
>
>     ... need to be robust in this case.
>                ^^^^
>
> (7)  Section 4, 4th paragraph
>
> Please remove the replication:
>
>      s/GSS-API GSS-API/GSS-API/
>               ^^^^^^^^
>
> Kind regards,
>  Alfred HÎnes.
>
> -- 
>
> +------------------------ 
> +--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.- 
> Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax:  
> -18         |
> | D-71254  Ditzingen     |  E-Mail:  ah@TR- 
> Sys.de                     |
> +------------------------ 
> +--------------------------------------------+
>