Re: [rtcweb] STUN for keep-alive

[Dzonatas Sol <[e-mail]>]

On 09/16/2011 12:34 PM, Dan Wing wrote:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Dzonatas Sol
>> Sent: Friday, September 16, 2011 11:18 AM
>> To: [e-mail]
>> Subject: Re: [rtcweb] STUN for keep-alive
>>
>> On 09/16/2011 11:04 AM, Dan Wing wrote:
>>      
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Muthu Arul Mozhi Perumal (mperumal)
>>>> Sent: Wednesday, September 14, 2011 4:24 AM
>>>> To: Christer Holmberg; [e-mail]
>>>> Subject: Re: [rtcweb] STUN for keep-alive
>>>>
>>>> |Well, it depends on the amount of outgoing media traffic,
>>>> |but in cases where you only receive media you would still
>>>> |need to send keep-alives.
>>>>
>>>> If you are not sending anything the NAT binding in that direction
>>>>          
>> will
>>      
>>>> likely timeout. On the other hand, if you are operating in a
>>>>          
>> controlled
>>      
>>>> environment ICE already allows you to set the STUN keepalive
>>>>          
>> duration
>>      
>>>> to
>>>> the longest duration possible in your environment, so it is already
>>>> flexible.
>>>>
>>>>          
>>> PCP can allow the client to know and control the NAT's UDP timeout,
>>> http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3.
>>>
>>> -d
>>>
>>>        
>> NAT64 doesn't have to worry about UDP content or timeouts like in IPv4
>> when set up correctly, yet we can' expect everybody to use such
>> configuration we consider correct.
>>      
> There are two types of NAT64:  stateless (which has the characteristic
> you describe) and stateful (which would require keepalive traffic
> for all the reasons today's NAPT44 devices require keepalives).  I
> don't know what is meant by "when set up correctly".
>
> -d
>    


We call those "which would require keepalive traffic" simply battery 
systems (in simulation-only context).

Chakra and aha (no AI, no artificial entropy)! Is there an additional 
"signaling" when SIP throws 402? Within the box we first assume the 
battery is the source. In physical simulations, we consider the ground 
is the source ("historic").

I think JSON can send-on its own port and not constantly munge with XML 
ports that forces an option to show. JSON could be the default for 
websockets.


>    
>> +1 for OAuth MAC for this reason.
>>
>>
>>
>>      
>>>        
>>>> However, it mandates STUN keepalives to be used when an agent is a
>>>>          
>> full
>>      
>>>> ICE implementation and is communicating with a peer that supports
>>>>          
>> ICE
>>      
>>>> (lite/full). Are you saying it should allow a different UDP
>>>>          
>> keepalive
>>      
>>>> method because it can possible have a lesser performance impact?
>>>>
>>>> Muthu
>>>>
>>>> |-----Original Message-----
>>>> |From: Christer Holmberg [mailto:[e-mail]]
>>>> |Sent: Wednesday, September 14, 2011 3:59 PM
>>>> |To: Muthu Arul Mozhi Perumal (mperumal); [e-mail]
>>>> |Subject: RE: [rtcweb] STUN for keep-alive
>>>> |
>>>> |
>>>> |Hi,
>>>> |
>>>> |>|Because, eventhough the keep-alives messages aren't
>>>>          
>> authenticated,
>>      
>>>> and
>>>> |>|do not trigger responses, a gateway would still have to
>>>> |>|process them, and since a gateway typically would serve a large
>>>> number of browser
>>>> |>|clients, that could have quite big performance impact (the number
>>>>          
>> of
>>      
>>>> |>|STUN keep-alives sent per session of course depend on how much
>>>>          
>> other
>>      
>>>> |>|media traffic there is, but still).
>>>> |>
>>>> |>STUN keepalives are required by ICE only in the absence of
>>>> |>media traffic.
>>>> |
>>>> |Yes. That's what I meant with the:
>>>> |
>>>> |	"(the number of STUN keep-alives sent per session of course
>>>> depend on how much other media
>>>> |traffic there is, but still)"
>>>> |
>>>> |...statement :)
>>>> |
>>>> |>Here are the snip from RFC 5245:
>>>> |>
>>>> |><snip>
>>>> |>10.  Keepalives
>>>> |>
>>>> |>If there has been no packet sent on the candidate pair ICE is
>>>> |>using for a media component for Tr seconds (where packets
>>>> |>include those defined for the component (RTP or RTCP) and
>>>> |>previous keepalives), an agent MUST generate a keepalive on
>>>> |>that pair.  Tr SHOULD be configurable and SHOULD have a
>>>> |>default of 15 seconds.  Tr MUST NOT be configured to less
>>>> |>than 15 seconds.
>>>> |></snip>
>>>> |>
>>>> |><snip>
>>>> |>20.2.3.  Keepalives
>>>> |>
>>>> |>STUN keepalives (in the form of STUN Binding Indications) are
>>>> |>sent in the middle of a media session.  However, they are
>>>> |>sent only in the absence of actual media traffic. In
>>>> |>deployments that are not utilizing Voice Activity Detection
>>>> |>(VAD), the keepalives are never used and there is no increase
>>>> |>in bandwidth usage.  When VAD is being used, keepalives will
>>>> |>be sent during silence periods.  This involves a single
>>>> |>packet every 15-20 seconds, far less than the packet every
>>>> |>20-30 ms that is sent when there is voice.  Therefore,
>>>> |>keepalives don't have any real impact on capacity planning.
>>>> |></snip>
>>>> |>
>>>> |>Do you think there is still a problem?
>>>> |
>>>> |Well, it depends on the amount of outgoing media traffic, but in
>>>>          
>> cases
>>      
>>>> where you only receive media
>>>> |you would still need to send keep-alives.
>>>> |
>>>> |Regards,
>>>> |
>>>> |Christer
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>          
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>>        
>>
>> --
>>
>> ---
>> <i>The wheel.</i metro-link=t dzonatasolyndra>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>      
>
>    


-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>