Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP)

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

Hi Markus,

|My understanding was that the consent refreshes would need to be 
|sent quite frequently at all times. But are there situations where 
|a P2P association would be up, while yet consent refreshes would not
|flow? If so, PCP would indeed become handy for instance prolonging 
|the default 30 second UDP timeout to, say, 5 minutes. That would be
|basically the only way for a small battery powered device to keep
|that P2P connection up for hours without draining its battery.

Yes, there are situations where a P2P association would be up while consent refreshes wouldn't flow. This is where one of endpoints is only receiving traffic and not sending anything (or sending infrequently). Consent freshness is needed only when traffic is sent. When the endpoint is not sending traffic consent freshness is unnecessary.

Muthu

|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
|Sent: Tuesday, August 27, 2013 6:41 PM
|To: Tirumaleswar Reddy (tireddy); Ram Mohan R (rmohanr); [e-mail]
|Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control
|Protocol (PCP)
|
|Hi Tiru, Ram,
|
|This might be better asked on the RTCWEB or MMUSIC WG lists, but since it came up here:
|
|When thinking about WebRTC's P2P traffic flows (audio, video or data channel), the keepalive reduction
|becomes relevant only when there are long periods when no application traffic is being sent -- but
|still for some reason, such as responsiveness, it is not possible to tear down the P2P "association"
|for that period. There may be such cases even for audio or video streams, but it seems that the most
|realistic case is when only a data channel is up.
|
|My understanding was that the consent refreshes would need to be sent quite frequently at all times.
|But are there situations where a P2P association would be up, while yet consent refreshes would not
|flow? If so, PCP would indeed become handy for instance prolonging the default 30 second UDP timeout
|to, say, 5 minutes. That would be basically the only way for a small battery powered device to keep
|that P2P connection up for hours without draining its battery.
|
|But as said, often it might be a better design to tear the data channel down after a few minutes of no
|traffic and set it up ASAP when either end has something to send. In that case only the signaling
|connection (TLS/TCP) would need to stay up for long time, and for that PCP works nicely.
|
|Markus
|
|> -----Original Message-----
|> From: [e-mail] [mailto:[e-mail]] On Behalf Of
|> ext Tirumaleswar Reddy (tireddy)
|> Sent: 23 August, 2013 15:27
|> To: Ram Mohan R (rmohanr); [e-mail]
|> Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall
|> Keepalives Using Port Control Protocol (PCP)
|>
|> > -----Original Message-----
|> > From: Ram Mohan R (rmohanr)
|> > Sent: Tuesday, August 13, 2013 10:34 AM
|> > To: [e-mail]
|> > Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall
|> > Keepalives Using Port Control Protocol (PCP)
|> >
|> > I support adoption of this document.
|> >
|> > One comment that you can take care in the next revision- We can add
|> > some text on how this document will interact with consent messages
|> > that would be sent for webRTC flows
|>
|> Using PCP to increase the lifetime will be useful when not actively sending
|> traffic i.e. when consent is not used. Planning to update draft "PCP
|> Considerations for WebRTC Usage" http://tools.ietf.org/html/draft-penno-
|> rtcweb-pcp-00#section-3.6 with more details.
|>
|> --Tiru.
|>
|> >
|> > Ram
|> >
|> > >
|> > >
|> > >-----Original Message-----
|> > >From: Reinaldo Penno (repenno)
|> > >Sent: Monday, July 29, 2013 3:52 PM
|> > >To: [e-mail]
|> > >Subject: [pcp] WG Call for Adoption: Optimizing NAT and Firewall
|> > >Keepalives Using Port Control Protocol (PCP)
|> > >
|> > >Hello,
|> > >
|> > >This email starts a 2-week consensus call on adopting "Optimizing NAT
|> > >and Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item.
|> > >
|> > >     Title     : Optimizing NAT and Firewall Keepalives Using Port Control
|> > >Protocol (PCP)
|> > >     Author(s) : T. Reddy et al
|> > >     Filename  : draft-reddy-pcp-optimize-keepalives-01
|> > >     URL       :
|> > >http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01
|> > >
|> > >Please read the current revision and state you opinion either for or
|> > >against adoption in the mailing list.
|> > >
|> > >The call for adoption ends 12th August 2013.
|> > >
|> > >Thanks,
|> > >
|> > >Chairs
|> > >
|> > >
|> > >
|> >
|> >
|>
|> _______________________________________________
|> pcp mailing list
|> [e-mail]
|> https://www.ietf.org/mailman/listinfo/pcp
|_______________________________________________
|pcp mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/pcp