Subject: [BEHAVE] Moving draft-marjou-behave-app-rtp-keepalive to AVT

From: Colin Perkins <[email-masked]>
Date: Fri, 1 Jun 2007 18:15:23 +0100

There has been some private discussion on adopting the draft on  
Application Mechanisms for maintaining alive NAT mappings associated  
with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an  
AVT working group draft. This has previously been discussed in AVT,  
BEHAVE and MMUSIC. Opinions on whether this draft should become a  
working group draft, and on the appropriate home for it, are  
solicited by 8 June 2007.

Colin (as AVT co-chair)

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Jun 2007 11:09:16 -0700

> solicited by 8 June 2007.

We need a document that consolidates NAT keepalive mechanisms for
UDP-based protocols, most notably RTP (and, to a lesser extent,
SIP).  Currently this is spread in various documents and there
is no consolidated guidance to implementtors on the strength
or weakness of various approaches.  Section 4 of Xavier's 
document shows the current state of the art -- 7 different
keepalive techniques are in various levels of active use.

Most of the keepalive techniques apply to RTP, and thus AVT seems
the best home.  There are a few exceptions which don't fit into
AVT, such as the keepalive technique used by SIP Outbound 
(draft-ietf-sip-outbound), but I don't see the exceptions as
significant enough to resist making this an AVT WG item.  If we 
had an "RAIWG" (akin to TSVWG), it might fit best there, but we 
don't have one.  It doesn't quite fit into BEHAVE, as NATs only
care to see a UDP packet is occasionally sent to the peer and 
NATs don't care what sort of UDP packet is sent; however, the
receiving peer may very much care if it's a STUN packet, a
0-byte packet, or the 5 other types of packets described in
Xavier's document.

I support adding a milestone to AVT for keepalives, and adopting 
that document to meet that milestone.

-d

---

From: Lars Eggert <[email-masked]>
Date: Mon, 4 Jun 2007 10:38:39 +0300

On 2007-6-1, at 21:09, ext Dan Wing wrote:
> or weakness of various approaches.

I'm wondering if it'd make sense to add this guidance as a section in  
http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines?

Lars

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 Jun 2007 13:40:11 -0700

I think that the AVT WG has the right people to review and recommend  
way(s) to do keep alive for RTP flows - so if we are doing this work  
anywhere, AVT  would be my preferred WG to do it in. Now that Behave  
has published, RFC 4787, I think it is easy for the AVT group to  
ensure that whatever the recommendation is,  it will work with NATs  
that are compliant with BEHAVE. This helps resolve the issues of  
making sure that enough NAT people are involved with the discussion.

On Jun 1, 2007, at 11:09 AM, Dan Wing wrote:

> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 Jun 2007 13:54:29 -0700

> http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines?

I agree "send periodic UDP traffic" would be good in that
document.  REQ-6 of draft-ford-behave-app-05 may provide the 
beginnings of some useful text (CC'ing the authors of that 
document).

As with all applications on today's Internet, an RTP 
application needs to be robust and able to deal with whatever 
is sent to it, so perhaps you're right -- an application-
specific keepalive document may well be overly specific and
we should, rather, document what any UDP-based application
should do to prevent middleboxes (such as NATs) from 
clobbering a flow.

-d

---

From: "Xavier Marjou" <[email-masked]>
Date: Tue, 5 Jun 2007 09:22:47 +0200

If there was a consensus about using a very easy RTP-keepalive
mechanism that could even be re-used for other UDP protocols than RTP
itslef (eg: an empty UDP packet), I think it could be integrated in
the tsvwg-udp-guidelines document. However, there is no consensus on
such a mechanism and some of the possible mechanisms really need AVT
people expertise. So I would also be in favor of moving the draft to
AVT.

Xavier

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 5 Jun 2007 15:57:45 +0300

Hi,

I think that defining the keepalive for RTP that will not break RTP is
an important work and can be done in AVT. 
I read the draft and it looks like a good start. I support as having it
an AVT working group draft

Roni Even 

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Friday, June 01, 2007 8:15 PM
> To: IETF AVT WG; [email-masked]; mmusic
> Cc: Even, Roni; Tom Taylor; Dan Wing ((dwing)); Cullen Jennings; Joerg
> Ott; Xavier Marjou; Jean-Francois Mule; Magnus Westerlund
> Subject: Moving draft-marjou-behave-app-rtp-keepalive to AVT
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 5 Jun 2007 16:05:29 +0100

> should do to prevent middleboxes (such as NATs) from

The udp-guidelines draft should probably outline what sort of keep  
alive mechanism is needed, but the implementation is likely protocol  
specific, and should be done by the group designing that protocol, I  
think.

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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 5 Jun 2007 18:10:19 +0300

On 2007-6-5, at 18:05, ext Colin Perkins wrote:
> alive mechanism is needed, but the implementation is likely  
> protocol specific, and should be done by the group designing that  
> protocol, I think.

Makes sense to me.

Lars

---

From: Colin Perkins <[email-masked]>
Date: Fri, 8 Jun 2007 15:30:13 +0100

On 1 Jun 2007, at 18:15, Colin Perkins wrote:
> Application Mechanisms for maintaining alive NAT mappings  
> associated with RTP flows (draft-marjou-behave-app-rtp- 
> keepalive-01.txt) as an AVT working group draft. This has  
> previously been discussed in AVT, BEHAVE and MMUSIC. Opinions on  
> whether this draft should become a working group draft, and on the  
> appropriate home for it, are solicited by 8 June 2007.

There were several comments in favour of this proposal, and no  
objections. Accordingly, we will take this draft as an AVT work item.

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