Re: [pcp] comments for draft "Analysis of Port Control P0rotocol in Mobile Network"

[GangChen <[e-mail]>]

2013/5/7, Tirumaleswar Reddy (tireddy) <[e-mail]>:
> Hi Gang,
>
> Please see inline
>
>> -----Original Message-----
>> From: GangChen [mailto:[e-mail]]
>> Sent: Monday, May 06, 2013 2:37 PM
>> To: Tirumaleswar Reddy (tireddy)
>> Cc: [e-mail]
>> Subject: Re: comments for draft "Analysis of Port Control P0rotocol in
>> Mobile
>> Network"
>>
>> Hi Tiru,
>>
>> Thanks for the deep and detailed review.
>> I apology for my late reply.
>> In order to easy the discussion, I excerpt your comments and add the
>> replies as below.
>>
>> Section 2.1
>> Would FW as network service be offered to all  Mobile subscribers or
>> based on some premium paid to some subscribers only ?
>>
>> [cg] FW would offer to all subscribers as a basic service
>>
>> where will the Firewalls be located in the Mobile Network when  SIPTO
>> is taken into consideration?
>>
>> [cg] Each entry has their-own FW. In SIPTO case, there are two FWs
>> located in differnet data paths
>>
>> How is this problem different from let's say Firewall offered by SP ?
>>
>> [cg] The discussion is more focused on issues in mobile networks.
>> I guess the issue is orthogonal to the FW in SP or NP.
>> SP could take mobile network as a access path. Therefore, the benefits
>> could also applicable to SP.
>
> If the use-case is applicable to other networks, I would suggest to
> explicitly state that to avoid confusion.

Ok.We will update to clarify applicable cases

>>
>> There are various modes in which Firewalls operate as explained in
>> http://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01;
>> [1] you may want to clarify that you are referring to a firewall
>> configuration which "Block all outside-initiated traffic, allow all
>> inside-initiated
>> Traffic"
>>
>> [cg]  I would add clarification texts in the next update. The FW in
>> the networks falls into the Category I
>
> Ok.
>
>>
>> [2] will the subscriber be allowed to modify the Firewall configuration ?
>>
>> [cg]  Subscriber can't modify configuration. It's only allowed using
>> administrator account.
>>
>> [3] what is the Firewall capability offered by the Mobile Network -
>> Layer 4 and/or Layer 7 ?
>>
>> [cg]  Only Layer4. Going upper layer requires DPI which is not widely
>> deployed.
>>
>> PCP messages are required to refresh the mapping. Further application
>> keep-alive would still be required to refresh the server state.
>> For more details refer to
>> http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01#section-3.4
>>
>> [cg]  I made following revision.
>>
>> ==Old==
>> thus would not need to be using keep-alive to keep the Firewall session
>> open.
>>
>> ==New==
>>
>> thus would lighten the traffic flow of keep-alive by reducing the
>> number of sending packets
>>
>>
>>
>> Section 2.2/2.3
>>
>> The problems of 2.2 and 2.3 seem to be also valid if the MN is using
>> Wifi in a Hot spot, Home Network etc. Why is this specific to 3GPP
>> network ?
>>
>> [cg] Section 2.2 is specific to 3GPP network, since there are
>> different channels using for control messages and actual data trasport
>> in 3GPP network.
>> Those beacon messages are occupy the data channels so as to congest
>> voice calls. This issue would not occur in wifi case.
>> We may need to clarify this in next version.
>
> Yes, that would help.
>
>>
>> [cg] Section 2.3 may applicable to wifi case. But there is different
>> state-changes in 3GPP networks. We may clarify that?
>>
>> BTW, we don't want to differentiate 3GPPP and wifi. Because wifi is
>> also a part of mobile network.
>>
>> Section 4
>>
>> How will MN receive any other information that is provided by DHCP server
>> ?
>>
>> [cg]  MN usually receive the information through PCO
>>
>> Will these techniques solve the IPv4 problem ?
>>
>> [cg] Those are potential solutions. I guess the document is more
>> targeted to the discovery of specific issues.
>> We may add comments on those solutions in the next.
>>
>> Section 5
>>
>> Some time back there was discussion in the netext WG that - Mobile
>> Networks should move away from the model
>> of building application specific APN's and consolidate them into a
>> single home network.
>> For more details refer to
>> http://tools.ietf.org/html/draft-gundavelli-netext-multiple-apn-pmipv6-01
>>
>> [cg]  This work is triggered by integration of 3GPP networks and Wifi
>> networks. PMIPv6 based S2a can't is restricted
>> with a single APN/home network. Therefore, the consolidation of
>> multiple APN feed this requirement.
>> However,this may not be a trend in a pure 3GPP environment.
>> At least, 3GPP doesn't discuss the APN aggregation and multiple APN
>> still widely used.
>
> Ok.
>
>>
>> Section 6
>>
>> This is a problem with any protocol using UDP. Retransmission is a
>> case of error;
>> With both PCP client and server in the same network - will
>> retransmission of PCP request be frequent because of packet loss ?
>>
>> This is a implementation problem on the Mobile Device and not a
>> protocol problem;
>> PCP client could either be implemented in the kernel or each
>> application could be using its own PCP client.
>>
>>
>> [cg]  Compared to packet loss, we are more concerning about the roaming
>> case.
>> MN with PCP-client may roam to a network where there is no PCP-server
>> available.
>> Subsribers may easily find their MN running into outage when they are
>> on business trips.
>> That is not a protocol problem. We also not intend to change protocol
>> or impede the retransmission.
>> However, it's desirable to notice this potential consumption and
>> configure optimal value to each parameter in order to optimize radio
>> link usage.
>> That may easy mobile-operator's life to deploy PCP.
>>
>>
>> Section 7
>>
>> I am not sure how NAT/Firewall would do this when rebooted ?
>> Are you referring they need persistence storage ?
>>
>> [cg] I'm referring to using HA with hot-standby
>
> clarify that.
>
>>
>> Unsolicited responses could also be sent for other PCP requests like MAP.
>>
>> [cg] Would you point me the description in PCP-base document?  I may miss
>> that.
>
> It's explained in the following section
> http://tools.ietf.org/html/rfc6887#section-14.2

thanks


>
>>
>>
>> Section 8
>>
>> Please clarify the procedure the PCP client must follow - Delete the
>> Mappings on the old PCP server;
>> before sending PCP requests to the new PCP server ?
>>
>> [cg]  that is a good suggestion. I will add the procedure at next udpate.
>>
>> TOF and NAT are co-located, so what is the problem in using RAB ID ?
>> SIPTO rules could be different per subscriber ;
>> so the PCP proxy needs to determine that the PCP request is coming
>> from a specific client
>> to pick the associated SIPTO rules for the subscriber so as to
>> determine if the request is to be processed locally or forwarded to
>> the PCP server in the EPC
>>
>> [cg] The issue could refer to
>> http://www.3gpp.org/ftp/Specs/html-info/23060.htm.
>> In the TS 23.060 V10.0.0, the description of "SIPTO with Traffic
>> Offload Function" states:
>> "TOF inspects the NAS and RANAP messages to build the local UE context
>> and local session context.
>> When a RAB is requested to be set up and should be offloaded, ..."
>>
>> Therefore, the offloaded IP flow is identified with RAB-ID, other than
>> IP 5-tuples.
>> If the intention is to adopt PCP-proxy with advanced functions in the
>> case of multiple PCP servers, PCP proxy must understand RAB-ID.
>> Additional mapping function may be required.
>
> I thought there are multiple techniques, the other one is :
>
> The new NAT would be informed about the UE point-of-attachment by the Home
> Node B Management System (HNS) (HNS is updated by the Node B (cell tower)).
> The new NAT is updated with the traffic offload policy rules for the
> subscriber by the HNS.
>
> Does this also require using RAB-ID ?

As far as I know, NAT-based technique was documented in TR 23.829
(http://www.3gpp.org/ftp/Specs/html-info/23829.htm). It doesn't
involve RAB-ID. However, this solution can't be accepted as TS
(Technical Specification) level. TR 23.829 only stands for
"informational" level.

BRs

Gang


> Regards,
> Tiru.
>
>>
>>
>> Section 9
>>
>>
>> Both NAT/Firewall and AAA are in the same administrative domain in the
>> Mobile Network
>> and that would be the same problem with NAT/Firewall in the Enterprise
>> Network.
>> Please clarify how is this problem unique to 3GPP networks only ?
>>
>> [cg]  We will make futher revision for this section. More
>> clarification will be added.
>>
>> Best Regards
>>
>> Gang
>>
>> 2013/4/27, Tirumaleswar Reddy (tireddy) <[e-mail]>:
>> > Hi Gang,
>> >
>> > As per the discussion during the interim; attached my comments for the
>> > draft.
>> >
>> > Regards,
>> > --Tiru.
>> >
>