Subject: [MMUSIC] Pacing of STUN packets in ICE

From: "Alfred E. Heggestad" <[email-masked]>
Date: Mon, 12 Nov 2007 13:34:26 +0100

Hi

I have been looking at the pacing mechanism of connectivity checks
in ICE, when sending STUN packets at a given rate to "simulate"
RTP traffic.

I am not convinced that the current mechanism will work (ice-19)
and will propose an alternative that is more robust.

ICE-19 chapter 16.1 states:

   For each media stream i:
     Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime

this formula is used to calculate which rate to send the STUN
packets, so that the traffic pattern will "look" like RTP traffic.

Calculating the exact value is not hard to do, except that the
size of the STUN packet is different depending on if a Binding
Request is used or a Allocate Request. My guess is that most
implementors will skip this step, and use a hardcoded value.

One problem of this approach is that STUN packet are not the
same length as RTP packets, and even if they are sent with the
same bitrate, the traffic pattern is not the same. I suspect
that some NAT boxes will treat them differently.

For example, let us say that a UA wants to send RTP packets
which are ~1400 bytes large. Using ICE the UA finds a good
"path" for the media using small STUN packets (20 bytes).
When the real media starts to flow, all packets are fragmented
and dropped by the router.

My proposed solution to these two problems, is to send STUN
connectivity checks with the exact same packet size as the
RTP packets. The PADDING attribute (defined in
draft-ietf-behave-nat-behavior-discovery-01) can be used to
send STUN packets of any given size. This attribute should
therefore be moved to the core STUN specification.

Using the above solution, the formula for Ta_i becomes:

     Ta_i = rtp_ptime

Comments are welcome

/alfred

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Nov 2007 21:20:04 -0500

Responses below:

> and will propose an alternative that is more robust.

Well, as folks may have noticed ICE is approved and is in rfc-editor 
queue. So at this point, unless its an honest-to-goodness bug, which can 
be fixed in auth48, there isn't really scope to change it unless the WG 
wants to yank it from rfc-ed queue.

> implementors will skip this step, and use a hardcoded value.

Very likely, yes.

> that some NAT boxes will treat them differently.

Do you have any empirical evidence here?

> and dropped by the router.

ICE is not supposed to be doing path MTU validation. If the media is 
being sent as 1400 bytes and that exceeds the MTU, the media 
implementation is broken. It should either do path MTU discovery or use 
a smaller message size.

> Using the above solution, the formula for Ta_i becomes:

This is not unreasonable, I'm just not sure it really changes anything. 
I'm unconvinced on the MTU issue. If you have evidence that there is 
some kind of NAT processing difference based on packet size, please 
elaborate.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Fri, 16 Nov 2007 14:17:48 +0100

> wants to yank it from rfc-ed queue.

ok I agree

> Do you have any empirical evidence here?

I do not have any empirical evidence on this. I just know that
since the traffic pattern is different it is not guaranteed that
the working "flow" will actually work.

say:

  RTP traffic: 160 bytes every 20ms -> 64000 bit/s
  STUN traffic: 20 bytes every 20ms ->  8000 bit/s

the formula in 16.1 will in most cases give a value of Ta=20ms.
(rtp_ptime=20ms, rtp_packet_size=160, stun_packet_size=20)
for one media stream that is Ta_0=2.5ms -> Ta = MAX(20ms, 2.5ms) = 20ms

if the NAT box at the time of connectivity check is able to
handle 8kbit/s, it is not guaranteeed that it will handle 64kbit/s

also the algorithm is only considering upstream bandwidth, since
the size of STUN response is unknown..

> implementation is broken. It should either do path MTU discovery or use 

Ok I agree this is probably pushing it too far..

> some kind of NAT processing difference based on packet size, please 

I think the current solution is "good enough". But we could make future
enhancements of ICE by sending and receiving STUN packets that are
exactly the same size and ptime as RTP by adding padding to the STUN
packets. For example if we can move the STUN Attribute "PADDING"
from nat-behaviour-discovery to the Core STUN spec, it might be
possible do create a new spec after the core ICE spec is out.

/alfred