Subject: [MMUSIC] Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-udp-guidelines-02.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 23 Jul 2007 11:20:06 -0500

On 9 Jul 2007, at 04:50, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Transport Area Working Group  
> Working Group of the IETF.
>
>
>         Title           : UDP Usage Guidelines for Application  
> Designers
>         Author(s)       : L. Eggert, G. Fairhurst
>         Filename        : draft-ietf-tsvwg-udp-guidelines-02.txt
>         Pages           : 15
>         Date            : 2007-07-09
>
> The User Datagram Protocol (UDP) provides a minimal, message-passing
> transport that has no inherent congestion control mechanisms.
> Because congestion control is critical to the stable operation of the
> Internet, applications and upper-layer protocols that choose to use
> UDP as an Internet transport must employ mechanisms to prevent
> congestion collapse and establish some degree of fairness with
> concurrent traffic.  This document provides guidelines on the use of
> UDP for the designers of such applications and upper-layer protocols
> that cover congestion-control and other topics, including message
> sizes, reliability, checksums and middlebox traversal.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp- 
> guidelines-02.txt

Section 3.5 states:

    Applications MAY in addition send periodic keep-alive messages to
    attempt to refresh middlebox state.  Unfortunately, no common  
timeout
    has been specified for per-flow UDP state for arbitrary middleboxes.
    For NATs, [RFC4787] requires a state timeout of 2 minutes or longer,
    and it is likely that other types of middleboxes use timeouts of
    similar timescales.  Consequently, if applications choose to send
    periodic keep-alives, they SHOULD NOT send them more frequently than
    once every two minutes.  (Not that some deployed middleboxes use a
    shorter timeout value than 2 minutes, violating [RFC4787].)

which is fine, except that draft-ietf-mmusic-ice-17 suggests a 15  
second keep alive interval by default. Can we align these?

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic