Subject: [Softwires] Non-extensible static port sets are necessary for direct CE-CE paths

From: Rémi Després <[email-masked]>
Date: Tue, 2 Aug 2011 11:35:03 +0200

Hi, all,

Several contributors have expressed, in the context of stateless solutions, wishes to add flexibility to static port set assignment.

But, where "stateless" has to mean "no per-customer state", this wish is self-contradictory.

Now:
- Some ISP's want _direct CE-CE paths_ . 
- For this each CE must know mapping rules for all other CE's.
- Mapping rules must therefore not depend on any per customer state.
- This doesn't permit dynamic increase of CE-assigned port sets.

If I missed something, please let me know.
If not, agreement on this point could facilitate the ongoing discussion.

Thanks,
RD

---

From: Qiong <[email-masked]>
Date: Wed, 3 Aug 2011 22:09:14 +0800

Hi, Remi,

This is just the question I would like to mention. Please see inline.

Several contributors have expressed, in the context of stateless solutions,
> wishes to add flexibility to static port set assignment.
>
[Qiong] : Agree. This is a good feature for stateless solution. But there
might be no big differences from stateful solutions when deploying CGN on
the edge of network, e.g. BRAS, etc.

> - For this each CE must know mapping rules for all other CE's.
[Qiong]: Agree, especially when applying the co-existence scenario for
exclusive-mode and shared mode. Given the fact the IPv4 prefixes are not
continuous anymore, there might be up to hundreds/thousands of rules for a
certain area.

Although I think that it would be not a big problem for stateless GW to
handle these rules, I would still doubt the possibility that a customer-side
CPE dealing with the same amount of IPv4 prefixes with network-side GW.

And another question, when should we announce these rules into CEs and BRs.
Since in CE-CE situation, a source should always send a packet with the
right destination port in the valid range of destinations. Is it has to been
guaranteed by individual applications ? Or does it have some kind of
limitations depending on applications ?

Thanks.

Best regards

Qiong Sun

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 3 Aug 2011 16:59:28 +0200

> [Qiong] : Agree. This is a good feature for stateless solution.

> But there might be no big differences from stateful solutions when deploying CGN on the edge of network, e.g. BRAS, etc. 

Depending on various factors, he bottom-line cost may be slightly or highly different.
One size may not fit all.

> [Qiong]: Agree, especially when applying the co-existence scenario for exclusive-mode and shared mode. Given the fact the IPv4 prefixes are not continuous anymore, there might be up to hundreds/thousands of rules for a certain area.

Thousands of rules seems to me a lot. 
(I keep doubts that, if CE's support statically shared addresses, keeping thousands of IPv4 prefixes would be needed to support IPv4 via IPv6.)
In any case, this can be among factors that differentiate which solution applies best to which network.

> 
> Although I think that it would be not a big problem for stateless GW to handle these rules, I would still doubt the possibility that a customer-side CPE dealing with the same amount of IPv4 prefixes with network-side GW. 

Adapting a CE to up to 1000 rules doesn't seem difficult to me, and with O(log n) matching this can be done with satisfactory performance. 
(More details would be private consultancy ;-)). 

> And another question, when should we announce these rules into CEs and BRs.

At the same time as other parameters (once in awhile to avoid lifetime expiry).

> Since in CE-CE situation, a source should always send a packet with the right destination port in the valid range of destinations. Is it has to been guaranteed by individual applications ? Or does it have some kind of limitations depending on applications ?

Applications that don't depend on well-known ports continue to do what they do behind NAT44's.
How applications get A+P addresses of peer applications is out of scope.

Hope it helps,

Regards,
RD

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 3 Aug 2011 15:11:31 -0700

Hi Remi, Qiong,

> (More details would be private consultancy ;-)). 

Thousands of rules sounds a lot to me as well. But I don't think it is difficult for CE to support such a number of rules. In fact, our implementation was tested under 10k rules in our lab.

Also, the rule consists of Domain IPv6 prefix/length, Domain IPv4 prefix/length, CE IPv6 prefix length and Domain IPv6 suffix/length. So, the total data size of these tuples is 40bytes roughly. So, if using 1000 rules, the total data size is roughly 40kbytes. So, I don't think the big chunk of memory is not required for storing all of rules in CE.

Thanks,
Tetsuya Murakami

---

From: Jacni Qin <[email-masked]>
Date: Thu, 04 Aug 2011 09:13:22 +0800

hi,

On 8/3/2011 10:59 PM, Rémi Després wrote:
> ...
> (I keep doubts that, if CE's support statically shared addresses, 
> keeping thousands of IPv4 prefixes would be needed to support IPv4 via 
> IPv6.)
>> Although I think that it would be not a big problem for stateless GW 
>> to handle these rules, I would still doubt the possibility that a 
>> customer-side CPE dealing with the same amount of IPv4 prefixes with 
>> network-side GW.
>
> Adapting a CE to up to 1000 rules doesn't seem difficult to me, and 
> with O(log n) matching this can be done with satisfactory performance.
In theory, the CE can be connected to multiple domains (1000?  with 
different rules), but in practice I guess that will not happen even in 
context of fragmented spaces where only the Access Gateway (ISP side) 
needs to maintain "1000.." rules of domains.

Cheers,
Jacni

---

From: Qiong <[email-masked]>
Date: Fri, 5 Aug 2011 09:40:49 +0800

Hi  Remi, Tetsuya,

Thank you for your reply. Please see inline.

> [Qiong]: Agree.

>
> Adapting a CE to up to 1000 rules doesn't seem difficult to me, and with
> O(log n) matching this can be done with satisfactory performance.

    [Tetsuya] Thousands of rules sounds a lot to me as well. But I don't
think it is difficult for CE to support such a    number of rules. In fact,
our implementation was tested under 10k rules in our lab.

    [Tetsuya] Also, the rule consists of Domain IPv6 prefix/length, Domain
IPv4 prefix/length, CE IPv6 prefix length and Domain IPv6 suffix/length. So,
the total data size of these tuples is 40bytes roughly. So, if using 1000
rules, the total data size is roughly 40kbytes. So, I don't think the big
chunk of memory is not required for storing all of rules in CE.

[Qiong]: I can fully understand that rule matching algorithm would not be
difficult to handle 1000 rules. But we should still keep in mind
that traditional CPEs are usually embedded systems with restricted
resources. The amount of NAT sessions it can handle is approximately about
2000~3000. When we add another 1000 rules to do prefix matching in CPE, I
think it would still cost more than before.

BTW, what's the output performance of your algorithm apart from memory
occupation and what's the configuration of your platform in your test ?

At the same time as other parameters (once in awhile to avoid lifetime
> expiry).
>
> [Qiong]: I think in this case, we would need another specification to
distribute this rules automatically.

Thanks

Best wishes

Qiong Sun

---

From: Tetsuya Murakami <[email-masked]>
Date: Thu, 4 Aug 2011 23:11:39 -0700

Hi Qiong,

On 2011/08/04, at 18:40, Qiong wrote:

>     [Tetsuya] Thousands of rules sounds a lot to me as well. But I don't think it is difficult for CE to support such a    number of rules. In fact, our implementation was tested under 10k rules in our lab.
> 
>     [Tetsuya] Also, the rule consists of Domain IPv6 prefix/length, Domain IPv4 prefix/length, CE IPv6 prefix length and Domain IPv6 suffix/length. So, the total data size of these tuples is 40bytes roughly. So, if using 1000 rules, the total data size is roughly 40kbytes. So, I don't think the big chunk of memory is not required for storing all of rules in CE.
> 
> 
> [Qiong]: I can fully understand that rule matching algorithm would not be difficult to handle 1000 rules. But we should still keep in mind that traditional CPEs are usually embedded systems with restricted resources. The amount of NAT sessions it can handle is approximately about 2000~3000. When we add another 1000 rules to do prefix matching in CPE, I think it would still cost more than before.  

Agreed. Some of traditional CPEs might not be able to handle a bunch of NAT sessions due to the resource limitation such as memory, cpu, etc. From the implementation point of view, I think the required resources for 4rd mapping rule is smaller than the resources for NAT session because usually NAT session contains many information.

> BTW, what's the output performance of your algorithm apart from memory occupation and what's the configuration of your platform in your test ? 

Did you asked about the forwarding performance? We used netbsd running on arm core cpu (400MHz). The accrual ratio of the latency is just 2 to 5 % under 4rd environment.

Thanks,
Tetsuya Murakami

> [Qiong]: I think in this case, we would need another specification to distribute this rules automatically. 
> 
> 
> Thanks
> 
> Best wishes
> 
> Qiong Sun 
>

---

From: Qiong <[email-masked]>
Date: Sat, 6 Aug 2011 13:51:42 +0800

Hi Tetsuya,

Thank you very much to provide your test results.  Please see inline.

Agreed. Some of traditional CPEs might not be able to handle a bunch of NAT
> sessions due to the resource limitation such as memory, cpu, etc. From the
> implementation point of view, I think the required resources for 4rd mapping
> rule is smaller than the resources for NAT session because usually NAT
> session contains many information.
>
> [Qiong]: Basically agree that '4rd mapping rule is smaller than the
resources for NAT session', but 4rd CEs would still do NAPT similar to
traditional CPE's NAPT (with restricted port range), right ?

> Did you asked about the forwarding performance? We used netbsd running on
> arm core cpu (400MHz). The accrual ratio of the latency is just 2 to 5 %
> under 4rd environment.
>

[Qiong]: Well, this latency is acceptable to me.

Thanks

Qiong Sun