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

<Markus.Isomaki@nokia.com> Tue, 27 August 2013 13:11 UTC

Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF92011E8302 for <pcp@ietfa.amsl.com>; Tue, 27 Aug 2013 06:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.381
X-Spam-Level:
X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiT45buTxLlv for <pcp@ietfa.amsl.com>; Tue, 27 Aug 2013 06:11:24 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 33FA011E830B for <pcp@ietf.org>; Tue, 27 Aug 2013 06:11:23 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.49]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r7RDBK0s032072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 27 Aug 2013 16:11:21 +0300
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.88]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.03.0136.001; Tue, 27 Aug 2013 13:11:20 +0000
From: Markus.Isomaki@nokia.com
To: tireddy@cisco.com, rmohanr@cisco.com, pcp@ietf.org
Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP)
Thread-Index: AQHOjFORrIMjf8sOSUiRMwszh5KQt5mixnpAgAZq7iA=
Date: Tue, 27 Aug 2013 13:11:19 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A0906E0@008-AM1MPN1-041.mgdnok.nokia.com>
References: <913383AAA69FF945B8F946018B75898A1900F74A@xmb-rcd-x10.cisco.com> <E92E67B176B8B64D8D3A8F5E44E9D8F41EC91DC9@xmb-aln-x05.cisco.com> <913383AAA69FF945B8F946018B75898A19030F64@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A19030F64@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Imb/kNG8e5MBaAZCGWp2zCcmriI8lnVAfaV3+HkLL5QL0vdF69Z7XYn5GAjjV6RI9UB67e/BoNoOXYTiGPj5VJmDApl0RaDBWu7287tfJVrILsR5Dwm0Mm+M40rzp2zHrKTWcMFeptNvmWIRKM0u7hMBFFjF9kWgOHkJNz2+zN3DLJXhG2tCXj/Rap+FNYfqJmnY+xnLdm9OLCBmcjtcPzo7mPGVzXhEWPROcplGqWOGXdDXUOjsXY/My0yfrsOYeB2hFTSVMeSrE/iAGQ06PYCrvEQGZGgN655Fd6I3dhevKi35XSOvwA3YSzwwUkM+lQ==
x-originating-ip: [10.236.10.104]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 13:11:29 -0000

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: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> ext Tirumaleswar Reddy (tireddy)
> Sent: 23 August, 2013 15:27
> To: Ram Mohan R (rmohanr); pcp@ietf.org
> 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: pcp@ietf.org
> > 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: pcp@ietf.org
> > >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
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp