[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



Lars,

On 23 Aug 2007, at 15:31, Lars Eggert wrote:
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.

This looks fine to me - although you may want to give a reference to some of the techniques that allow an application to detect and/or modify the binding time-out (e.g. the STUN NAT control work, MIDCOM, etc.), so it can choose an appropriate keep-alive interval?


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



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