Subject: [AVT] RTP and ARP

From: Bodo Rueskamp <[email-masked]>
Date: Wed, 6 Mar 2002 15:46:39 +0100 (CET)

Hi,

Our company is working on set-top-box software.
We transmit MPEG-2 program streams (RFC 2250) over RTP.
The operating system is FreeBSD.

We found an interesting effect with ARP:

FreeBSD drops expired ARP entries after 20 minutes. This should be
okay. But: during the following ARP request of the MPEG-2 sender host
some packets get dropped because the ARP reply from the receiving
system is not fast enough to keep the 10 Mbit/s stream from dropping
packets because of the pending ARP request. FreeBSD keeps only the
last packet for a pending ARP request.

We could patch the FreeBSD kernel to do a DHCP-like RENEW of the
ARP entry before it expires. But this would work only if the sender
and the receiver are on the same network.

It seems that the standard ARP algorithm can make a high-bandwidth
RTP stream (e.g. 10 Mbit/s DVD MPEG-2) loose packets if the ARP
response isn't faster than the RTP packet rate and reliable.

Is this a bug in FreeBSD? Is this a bug in RTP?

; Bodo

-- 
Bodo Rüskamp, <[email-masked]>
Communications Laboratories GmbH, R & D Center Münster
Fon: +49-251-6184-139, Fax: +49-251-9619182

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

---

From: Orion Hodson <[email-masked]>
Date: Wed, 06 Mar 2002 12:23:42 -0800

Bodo

This is really FreeBSD specific, but interesting nonetheless.

There is a quick and untested hack that attempts to change FreeBSD's arping 
behaviour at:
	http://people.freebsd.org/~orion/if_ether.c.1.64.2.17.arp-patch
	http://people.freebsd.org/~orion/if_ether.c.RELENG_4_5.patch

The intended behaviour is to have arp requests sent if data is arriving from a 
host that is about to time out.  The request interval is the same as the 
initial arp request interval.  If after a number of retries, no response has 
been heard, the arp table entry is flushed as normal.

After testing, I'll see about whether we can get this or something like it 
committed to the FreeBSD tree.

It's curious that this hasn't been fixed sooner: it's been reported before and 
a similar solution proposed:
	http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/25517

Interesting problem, thanks for bringing it up.
- Orion

/-- Bodo Rueskamp wrote:
| Our company is working on set-top-box software.
| We transmit MPEG-2 program streams (RFC 2250) over RTP.
| The operating system is FreeBSD.
| 
| We found an interesting effect with ARP:
| 
| FreeBSD drops expired ARP entries after 20 minutes. This should be
| okay. But: during the following ARP request of the MPEG-2 sender host
| some packets get dropped because the ARP reply from the receiving
| system is not fast enough to keep the 10 Mbit/s stream from dropping
| packets because of the pending ARP request. FreeBSD keeps only the
| last packet for a pending ARP request.
| 
| We could patch the FreeBSD kernel to do a DHCP-like RENEW of the
| ARP entry before it expires. But this would work only if the sender
| and the receiver are on the same network.
| 
| It seems that the standard ARP algorithm can make a high-bandwidth
| RTP stream (e.g. 10 Mbit/s DVD MPEG-2) loose packets if the ARP
| response isn't faster than the RTP packet rate and reliable.

---

From: Bodo Rueskamp <[email-masked]>
Date: Wed, 6 Mar 2002 22:29:05 +0100 (CET)

Orion,

> 	http://people.freebsd.org/~orion/if_ether.c.RELENG_4_5.patch

Thanks, we'll check that out...

> been heard, the arp table entry is flushed as normal.

Is this a host requirement? We browsed the RFCs but didn't find
anything that recommends other behaviour.

RFC 1122 (Host Requirements) states that an ARP entry of a host
should be refreshed if an ARP request is received from that host.
This can be triggered by RTCP receiver reports, but there is still
a gap of some seconds.

> Interesting problem, thanks for bringing it up.

Your patch doesn't fix the problem if there is a third-party router
between the two FreeBSD boxes that implements the same algorithm.

MPEG-2 at maximum DVD rate is 1231 RTP packets per second. We loose
packets if the ARP reply takes longer than .8 msec.

; Bodo

---

From: [email-masked]
Date: Wed, 06 Mar 2002 15:54:54 -0800

/-- Bodo Rueskamp wrote:
| > The intended behaviour is to have arp requests sent if data is arriving fro
| m a 
| > host that is about to time out.  The request interval is the same as the 
| > initial arp request interval.  If after a number of retries, no response ha
| s 
| > been heard, the arp table entry is flushed as normal.
| 
| Is this a host requirement? We browsed the RFCs but didn't find
| anything that recommends other behaviour.

It's not a host requirement.  RFC1122 says a mechanism to prevent ARP flooding 
must be included - the maximum recommended rate is 1 per second.  We're just 
shifting when ARP requests are made relative to the entry being removed from 
the table.  It's unlikely we'll have any impact on this.
 
| RFC 1122 (Host Requirements) states that an ARP entry of a host
| should be refreshed if an ARP request is received from that host.
| This can be triggered by RTCP receiver reports, but there is still
| a gap of some seconds.
| 
| > Interesting problem, thanks for bringing it up.
| 
| Your patch doesn't fix the problem if there is a third-party router
| between the two FreeBSD boxes that implements the same algorithm.

I considered this when thinking how to address the problem this morning, but 
didn't mention it in the email.  I think it addresses this:

RFC826 says that a host that receives an ARP packet (any type) directed to it, 
it should update it's pre-existing cache entry regarding the sender of the 
packet.  So if the router is deficient in it's ARP implementation it should 
update it's entry for the (fixed) FreeBSD host when it receives an ARP request 
from the FreeBSD host.

The last three paragraphs of RFC826 suggest something very similar to what 
we've discussed so I don't think there is anything controversial here.  I 
think the patches can be restructured in a more intuitive way, once that and 
testing are done I'll raise it with the appropriate fbsd people.

Anyway, if you or anyone else on the list have alternative suggestions, they 
are decidely welcome.  A fix would be a good thing however it is achieved.

Kind Regards
- Orion

---

From: Orion Hodson <[email-masked]>
Date: Wed, 06 Mar 2002 17:35:46 -0800

/-- Bodo Rueskamp wrote:

It's not a host requirement.

Kind Regards
- Orion