Re: [rtcweb] NAT behavior heuristics

[Randell Jesup <[e-mail]>]

On 8/2/2012 7:15 PM, Dan Wing wrote:
>> -----Original Message-----
>> From: Martin Thomson [mailto:[e-mail]]
>> Sent: Thursday, August 02, 2012 4:02 PM
>> To: Dan Wing
>> Cc: [e-mail]
>> Subject: Re: [rtcweb] NAT behavior heuristics
>>
>> I assume that this applies only to the NAT that doesn't exist yet and
>> that we will have to live with status quo (and the current keep-alive
>> recommendations) until PCP becomes bountiful.
>
> Yes.  PCP is new, somewhat like RTCWEB.
>
> There is an incentive for the existing CGNs, deployed by almost all
> 3G/LTE carriers around the world, to have their vendors add PCP
> support to those NATs, as it saves battery lifetime for their
> subscribers and reduces chatter on their network.  Incentives are
> well aligned for that to happen.
>
> I agree that home NATs, enterprise NATs, and enterprise firewalls
> do not have those same incentives.

And that's a rub, since in many/most cases, the 3G/LTE people will 
likely be talking to non-3G/LTE people, and if either side needs 
keepalives, then radio will be kept active.  Note we're talking 
long-term inactive media flows and an inactive (or rarely active) 
datachannel, such as a client using PeerConnection and DataChannels to 
keep a registration or empty conference alive, or various non-phone-like 
applications.

An alternative mechanism for keepalives might help - you can use 
short-TTL packets to prop the local router without letting the packet go 
all the way to the other end.  If the fixed-station PC uses this TTL 
trick, and the mobile unit uses PCP, the mobile unit can keep its radio off.

Short-TTL can be handy for reducing loads on servers, especially where 
the port needs to stay open with no real traffic for long periods (think 
SIP).

The local router is rarely more than 5-7 hops from a device, though 
there are pathological cases; this could be configured (and 
disableable).  There are also ways to do discovery on the local router; 
these might work better than discovery of UDP port binding time, which 
is known to not work.


-- 
Randell Jesup
[e-mail]