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

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Aug 2007 17:31:12 +0300

On 2007-7-23, at 19:20, ext Colin Perkins wrote:
> On 9 Jul 2007, at 04:50, [email-masked] wrote:
>> 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?

We discussed this in the hallways in Chicago, and I've become  
grudgingly convinced that for specialized uses of UDP, where  
communication disruptions due to disappearing middlebox state are  
highly problematic (e.g., media transmission), 15-second timeouts are  
probably needed. But I did want to make it clear that such timeouts -  
or even the use of keepalives in general - are not recommended for  
arbitrary UDP applications.

Below is the modified Section 3.5 from my working copy of -03 FYI.  
Please let me know what you think of the changes.

Lars

3.5.  Middlebox Traversal Guidelines

    Network address translators (NATs) and firewalls are examples of
    intermediary devices ("middleboxes") that can exist along an end-to-
    end path.  A middlebox typically performs a function that  
requires it
    to maintain per-flow state.  For connection-oriented protocols, such
    as TCP, middleboxes snoop and parse the connection-management  
traffic
    and create and destroy per-flow state accordingly.  For a
    connectionless protocol such as UDP, this approach is not possible.
    Consequently, middleboxes may create per-flow state when they see a
    packet that indicates a new flow, and destroy the state after some
    period of time during which no packets belonging to the same flow
    have arrived.

    Depending on the specific function that the middlebox performs, this
    behavior can introduce a time-dependency that restricts the kinds of
    UDP traffic exchanges that will be successful across the middlebox.
    For example, NATs and firewalls typically define the partial path on
    one side of them to be interior to the domain they serve, whereas  
the
    partial path on their other side is defined to be exterior to that
    domain.  Per-flow state is typically created when the first packet
    crosses from the interior to the exterior, and while the state is
    present, NATs and firewalls will forward return traffic.  Return
    traffic arriving after the per-flow state has timed out is dropped,
    as is other traffic arriving from the exterior.

    Many applications that use UDP for communication operate across
    middleboxes without needing to employ additional mechanisms.  One
    example is the DNS, which has a strict request-response  
communication
    pattern that typically completes within seconds.

    Other applications may experience communication failures when
    middleboxes destroy the per-flow state associated with an  
application
    session during periods when the application does not exchange any  
UDP
    traffic.  Applications SHOULD be able to gracefully handle such
    communication failures and implement mechanisms to re-establish  
their
    UDP sessions.

    For some applications, such as media transmissions, this re-
    synchronization is highly undesirable, because it can cause user-
    perceivable playback artifacts.  Such specialized applications MAY
    send periodic keep-alive messages to attempt to refresh middlebox
    state.  It is important to note that keep-alive messages are NOT
    RECOMMENDED for general use - they are unnecessary for many
    applications and can consume significant amounts of system and
    network resources.

    An application that needs to employ keep-alives to deliver useful
    service in the presence of middleboxes SHOULD NOT transmit them more
    frequently than once every 15 seconds and SHOULD strongly consider
    using longer intervals.  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.  However, empirical
    evidence suggests that a significant fraction of the deployed
    middleboxes unfortunately uses shorter timeouts.  The timeout of 15
    seconds originates with the Interactive Connectivity Establishment
    (ICE) protocol [I-D.ietf-mmusic-ice].

    It is important to note that sending keep-alives is not a substitute
    for implementing a robust connection handling.  Like all UDP
    messages, keep-alives can be delayed or dropped, causing middlebox
    state to time out.  In addition, the congestion control  
guidelines in
    Section 3.1 cover all UDP transmissions by an application, including
    the transmission of middlebox keep-alives.  Congestion control may
    thus lead to delays or temporary suspension of keep-alive
    transmission.

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