Subject: [Tsvwg] Comment on draft-ietf-tsvwg-udp-guidelines-01

From: Philip Matthews <[email-masked]>
Date: Tue, 19 Jun 2007 12:13:57 -0400

The document draft-ietf-tsvwg-udp-guidelines-01 contains the  
following text:

    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.

Three comments:
1) RFC 4787 recommends 2 minutes for NATs, but many NATs today  
implement shorter timeouts.
Hopefully this will change in the future, but I would not recommend  
that an application designer today
assume a 2-minute timeout.
2) Even if all NATs implemented a 2-minute timeout, I think an  
application should send keep-alives
more frequently than every 2 minutes. The rule I have seen in IETF  
protocols that I am familiar with is to send at 3 times
the timeout rate, to account for lost packets. Consider OSPF for  
example, where the time to declare
your neighboring router dead is 45 seconds by default, and keep- 
alives are sent every 15 seconds by default.
3) The ICE protocol, which has gotten quite a bit of study by NAT  
experts, is recommending sending
keep-alives every 15 seconds.

I apologize if this has already been discussed. I searched the  
archives, but didn't find anything.
Also, I am not subscribed to this mailing list, to please reply  
directly to me if you want me to see your message.

- Philip

---

From: Lars Eggert <[email-masked]>
Date: Mon, 25 Jun 2007 20:14:38 +0300

Hi,

thanks for the feedback!

That section is new in -01 and hasn't been discussed by the WG yet.  
(Similarly, the section on checksums was new in the -00 WG document,  
and needs some WG review.)

> assume a 2-minute timeout.

I'm fine with adding a sentence that at the time of writing, NATs  
deployed in the wild have been known to not follow the IETF  
recommendation and use shorter timeouts.

> keep-alives every 15 seconds.

I understand the desire for short keepalive intervals, but on the  
other hand, I'm not comfortable recommending that all UDP  
applications should send 15-second keepalives. That seems awfully  
short. For ICE, which has arguable focused on supporting media  
transmission or at least started out that way, loss of NAT state is a  
bigger issue, because resynchronizing the connection causes  
interruptions in media delivery. Many other applications, however,  
can deal fine with the occasional resynchronization handshake, or  
have bursty communication patterns where keepalives end up eating  
much more resources (bandwidth but also power - think mobile devices)  
than the actual application traffic.

I'd be interested in hearing suggestions from folks on what we should  
recommend here!

> directly to me if you want me to see your message.

What did you think of the rest of the document, by the way?

Thanks,
Lars

---

From: Philip Matthews <[email-masked]>
Date: Mon, 25 Jun 2007 13:44:13 -0400

> thanks for the feedback!

You are welcome.

>> Hopefully this will change in the future, but I would not  
>> recommend that an application designer today

Sounds good to me.

> transmission or at least started out that way, loss of NAT state is  
> a bigger issue, because resynchronizing the connection causes  
> much more resources (bandwidth but also power - think mobile  
> devices) than the actual application traffic.
>
> I'd be interested in hearing suggestions from folks on what we  
> should recommend here!

I see your point, but I don't know what to recommend.
I would suggest asking the question on the P2P hackers mailing list,  
which is popular amongst implementors of P2P systems.
http://lists.zooko.com/mailman/listinfo/p2p-hackers
I think this may be a case where some research is required before a  
solid recommendation can be made, and it you want to advance your  
draft quickly, you might have to leave this as an open question.

> What did you think of the rest of the document, by the way?

Generally, I think it is a good draft. I think it reminds people of  
what they need to do.

Perhaps you should discuss more WHY people want to use UDP.
I suspect that, in many applications, people are inventing their own  
transport protocol because they need some semantics other than TCP   
semantics, and then they run it over UDP. Perhaps give a better  
discussion of when running directly over UDP is appropriate, and   
when running over DCCP or SCTP (perhaps encapsulated over UDP) is  
more appropriate.

- Philip

---

From: Lars Eggert <[email-masked]>
Date: Mon, 25 Jun 2007 21:34:20 +0300

On 2007-6-25, at 20:44, ext Philip Matthews wrote:
> I would suggest asking the question on the P2P hackers mailing  
> list, which is popular amongst implementors of P2P systems.

Doing some background research on this is a good idea - thanks for  
the pointer to that list!

FYI, I see no need to rush this document. I'd much rather get as many  
people as possible to look at it, esp. from outside the transport  
area. A BCP on this topic that doesn't have broader consensus it  
pretty useless. Ideally, we'd come to a rough consensus in the TSV  
community first, and then advertise it more widely.

>>> Generally, I think it is a good draft. I think it reminds people  
>>> of what they need to do.
>
> I suspect that, in many applications, people are inventing their  
> own transport protocol because they need some semantics other than  
> TCP  semantics, and then they run it over UDP. Perhaps give a  
> better discussion of when running directly over UDP is appropriate,  
> and  when running over DCCP or SCTP (perhaps encapsulated over UDP)  
> is more appropriate.

Hm. That's an interesting question, but I wonder if this is the right  
document for it. In my mind, this document is about "if you use UDP,  
here's some things to keep in mind." What you describe might be a  
different document on the topic of "have application, need transport,  
what do I choose?"

Lars