Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal

From: [email-masked]
Date: Wed, 2 Nov 2005 22:50:10 +0200

Henry,

It's not as simple as that. For instance the terms "mobile" and "device" are very broad, and in some cases there is absolutely no difference compared to any "fixed" Internet access scenario. The concern I'm having is valid when these conditions apply:
- Cellular radio technology, where power consumption is minimized whenever the device has nothing to send or receive. I believe technologies like GPRS/EDGE, WCDMA, CDMA (1X & EV-DO) fall into this category.
- Handheld size devices, where the battery capacity is limited. For instance the battery runs out after a few hours of circuit switched calling, or a few hours of *active* IP packet traffic.

To my understanding in that case a couple of things are not very feasible:
- Maintaining a constant NAT binding for UDP, assuming it requires sending packets every 15-30 seconds.
- Maintaining a large number of constant NAT bindings for TCP, since that will lead to about the same effect.

If we assume that the wireless access provider indeed uses NAT, and is not able/willing to do any specific configurations for them, the SIP UAs should probably do following type of things:
1. Use SIP over TCP. (Bad luck if the proxy only supports UDP...)
2. If using STUN and TURN, do the bindings only when needed. That is probably going to add some more delay in the call setup, depending how it's done (see the mails by Jonathan speculating how to do this in an intelligent way). If resource reservations are needed for medias, at least the simple optimizations don't work. 

What point 2. exactly means in terms of user experience is going to be decisive. If things can be implemented so that the users are happy, nothing new is needed. If not, there is going to be need for something which results in faster session setup times, perhaps resembling how today's SBCs work. As we know that has issues with e2e security, scalability and so on, and that is why I sent my original mail in the first place. Also it was to explain, why SBCs may gain some popularity in wireless environment.

I'm not trying to argue based on any particular beliefs about how good or evil SBCs or cellular radios are, I'm trying to see if there is a problem and whether there is anything to be done in the IETF about it.

Alternatively, batteries and/or radios can improve too and then we won't have to worry anymore...

Markus 

> -----Original Message-----
> From: ext Henry Sinnreich [mailto:[email-masked]]
> Sent: 02 November, 2005 18:25
> To: Isomaki Markus (Nokia-TP/Espoo); [email-masked]; [email-masked]
> Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal
> 
> 
> Markus,
> 
> I don't think you want to make the argument that mobile devices are so
> crippled that they can work only using SBCs?
> 
> Thanks, Henry
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Tuesday, November 01, 2005 2:32 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal
> 
> Hi,
> 
> A couple of points:
> - This is getting a bit outside the scope of SIP, but: in some radio
> technologies, the terminal can actually go into some sort of 
> dormant mode,
> where it only listens to some sort of paging/wake-up channel, and this
> consumes quite little energy. Even when the terminal only receives
> something, it has to switch from the dormant mode to active, 
> and if this
> happens every 15 sec., it most likely has some impact on the 
> battery life.
> In some other radios you don't have that type of operation at 
> all, i.e. they
> are actively receiving constantly. For them the impact of 
> just receiving
> packets is not that big, but in general the power consumption 
> of those type
> of radios is anyway much bigger. For laptops this is not 
> anymore such an
> issue, but it is still for handheld devices.
> - Hopefully some NAT expert can answer: Is inbound traffic 
> enough to keep a
> binding alive in all kinds of NATs, or are there also some where only
> outgoing packets actually refresh the binding?
> 
> Markus 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of ext Juha Heinanen
> > Sent: 01 November, 2005 12:23
> > To: [email-masked]
> > Subject: RE: [Sipping] Making SBCs more transparent for NAT 
> traversal
> > 
> > 
> > Juha Heinanen writes:
> > 
> >  > there is very little ietf can do about that.  if it is unfeasibly
> >  > expensive or power consuming to keep nat binding open by 
> > minimal size
> >  > udp packets @ every 15 sec, then there is something 
> wrong with the
> >  > pricing models and/or the technology.
> > 
> > i would just like to clarify that it is the proxy that sends the udp
> > packets send to keep the nat binding alive.  the mobile 
> terminal only
> > needs to RECEIVE them, not send anything unless there is real 
> > sip/media
> > traffic flow.
> > 
> > radio on my desk runs on same batteries for months and it even has
> > amplifier in it.  so there should be no power issue with mobile
> > terminals with the keepalives unless the their radio protocol 
> > is really
> > screwed up.
> > 
> > -- juha
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Wed, 2 Nov 2005 19:58:52 -0600

Markus,

You make good points about service providers using NAT and existing SIP UAs
that don't have ICE. This includes existing mobile devices. 
I am not sure if this is a standards task, but you already know or can
Google for the SER Media Proxy, since it works well for the above, without
having to sprinkle the "architecture" with SBCs as it seems 3GPP and TISPAN
are doing.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 02, 2005 2:50 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal

Henry,

It's not as simple as that. For instance the terms "mobile" and "device" are
very broad, and in some cases there is absolutely no difference compared to
any "fixed" Internet access scenario. The concern I'm having is valid when
these conditions apply:
- Cellular radio technology, where power consumption is minimized whenever
the device has nothing to send or receive. I believe technologies like
GPRS/EDGE, WCDMA, CDMA (1X & EV-DO) fall into this category.
- Handheld size devices, where the battery capacity is limited. For instance
the battery runs out after a few hours of circuit switched calling, or a few
hours of *active* IP packet traffic.

To my understanding in that case a couple of things are not very feasible:
- Maintaining a constant NAT binding for UDP, assuming it requires sending
packets every 15-30 seconds.
- Maintaining a large number of constant NAT bindings for TCP, since that
will lead to about the same effect.

If we assume that the wireless access provider indeed uses NAT, and is not
able/willing to do any specific configurations for them, the SIP UAs should
probably do following type of things:
1. Use SIP over TCP. (Bad luck if the proxy only supports UDP...)
2. If using STUN and TURN, do the bindings only when needed. That is
probably going to add some more delay in the call setup, depending how it's
done (see the mails by Jonathan speculating how to do this in an intelligent
way). If resource reservations are needed for medias, at least the simple
optimizations don't work. 

What point 2. exactly means in terms of user experience is going to be
decisive. If things can be implemented so that the users are happy, nothing
new is needed. If not, there is going to be need for something which results
in faster session setup times, perhaps resembling how today's SBCs work. As
we know that has issues with e2e security, scalability and so on, and that
is why I sent my original mail in the first place. Also it was to explain,
why SBCs may gain some popularity in wireless environment.

I'm not trying to argue based on any particular beliefs about how good or
evil SBCs or cellular radios are, I'm trying to see if there is a problem
and whether there is anything to be done in the IETF about it.

Alternatively, batteries and/or radios can improve too and then we won't
have to worry anymore...

Markus

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 3 Nov 2005 13:42:45 +0200

[email-masked] writes:

 > If we assume that the wireless access provider indeed uses NAT, and
 > is not able/willing to do any specific configurations for them, ...

markus,

since in mobile networks, NAT is most likely implemented in GGSN or
somewhere close to it, that NAT (since it is service provide controlled)
should be mobile network friendly by default and keep NAT bindings open
when receiving keepalives from the proxy.  

it could also be clever and not pass these keepalives to the mobile
terminal, thus saving battery power.  this works ok if there is no other
nat behind a mobile terminal, for example, when SIP application sits in
the mobile terminal itself.

so mobile operators, if they ever want to be SIP friendly (which may not
be the case) could have a separate access point name for mobile
terminals that actually terminate the traffic (as in the example above)
and a separate access point name for cases where there is a network
behind the mobile terminal.

in the latter case, keepalives would not be absorbed by the mobile
operator NAT, but that would be ok, because the mobile terminal that has
a network behind it most likely will have constant power available and
thus the power problem doesn't exist.

markus, you are free to pass this on to your product development
department :-).

-- juha