Re: [rtcweb] STUN for keep-alive

On 09/16/2011 11:04 AM, Dan Wing wrote:
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
>> Behalf Of Muthu Arul Mozhi Perumal (mperumal)
>> Sent: Wednesday, September 14, 2011 4:24 AM
>> To: Christer Holmberg; rtcweb@ietf.org
>> 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. +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:christer.holmberg@ericsson.com]
>> |Sent: Wednesday, September 14, 2011 3:59 PM
>> |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org
>> |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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>      
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>    

-- 

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