Re: [rtcweb] STUN for keep-alive

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Dzonatas Sol
> Sent: Friday, September 16, 2011 11:18 AM
> To: rtcweb@ietf.org
> Subject: 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. 

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

> +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>
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb