[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 2007-7-23, at 19:20, ext Colin Perkins wrote:
On 9 Jul 2007, at 04:50, Internet-Drafts at ietf.org 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic