Subject: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

From: <[email-masked]>
Date: Mon, 5 Sep 2011 18:44:48 +0200

Dear all,

We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms.

This is a call for review. In particular, we invite authors of the following proposals to review their section:

   o  [I-D.boucadair-behave-ipv6-portrange]
   o  [I-D.xli-behave-divi]
   o  [I-D.murakami-softwire-4v6-translation]
   o  [I-D.murakami-softwire-4rd]
   o  [I-D.despres-softwire-4rd-addmapping]

Questions, suggestions, corrections and contributions are more than welcome.

Thank you.
Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 5 septembre 2011 18:33
À : [email-masked]
Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Analysis of Port Indexing Algorithms
	Author(s)       : Mohamed Boucadair
                          Nejc Skoberne
                          Wojciech Dec
	Filename        : draft-bsd-softwire-stateless-port-index-analysis-00.txt
	Pages           : 25
	Date            : 2011-09-05

   This document analyzes various algorithm proposals for building port
   sets.  These algorithms are used to encode the range of ports in an
   IPv6 address and prefix in the context of stateless solutions.  The
   ultimate goal of this analysis is to converge on one or a set of
   algorithms to be used by all stateless solutions.

   This is a companion document to
   [I-D.boucadair-softwire-stateless-rfc6052-update].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Jacni Qin <[email-masked]>
Date: Tue, 06 Sep 2011 17:29:55 +0800

hi Med, all,

Thanks for writing this, it helps.
A couple of quick comments below,

*) Is the focus of the document (properties used) on the whole address 
architecture/format, or just on the algorithms to build port sets?  As 
in some proposals, for example 4rd, the port indexing algorithm can be 
an independent part and decoupled from the address format.

*)
    o  Multiple Port Ranges: Capability to assign multiple contiguous
       port ranges to a single PRD

Jacni>: I guess this only applies to "portrange" which offers contiguous 
port-set. So, I would suggest removing this property.

*) For "despres-4rd",
Differentiated Port Sets  Supported, through different piece of rules, 
delegated CPE prefixes of different length.
IPv4 traffic Isolation   supported
Prefix Aggregation   supported, since the IPv6 address planning is not 
affected.

I'll come back to you later if I get more.

Cheers,
Jacni

On Tuesday, September 06, 2011 12:44:48 AM, 
[email-masked] wrote:
>
> Dear all,
>
> We have just submitted an I-D analysing the port set algorithms we 
> have on the table. A set of properties are used to characterize the 
> port set algorithms.
>
> This is a call for review. In particular, we invite authors of the 
> following proposals to review their section:
>
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> [email-masked]
> Objet : I-D Action: 
> draft-bsd-softwire-stateless-port-index-analysis-00.txt
>
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: GangChen <[email-masked]>
Date: Wed, 7 Sep 2011 00:10:24 +0800

Hello Authors,

I think the draft did really good analysis on several mapping
algorithm, especially properties evaluation part.

One question for clarification:
I saw several properties are COMPLEXITY related.
Just wondering to know what kind of criteria you adopt to judge
different levels(i.e. Low, Medium, High) ?
I guess it would be beneficial if you could take some words to
describe the criteria.

Many thanks

Gang

2011/9/6, [email-masked]
<[email-masked]>:
> Dear all,
>
> We have just submitted an I-D analysing the port set algorithms we have on
> the table. A set of properties are used to characterize the port set
> algorithms.
>

---

From: <[email-masked]>
Date: Wed, 7 Sep 2011 07:22:43 +0200

Hi Jacni,

Please see inline.

Cheers,
Med

________________________________
De : Jacni Qin [mailto:[email-masked]]
Envoyé : mardi 6 septembre 2011 11:30
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Wojciech Dec; [email-masked]
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

hi Med, all,

*) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets?  As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format.
[Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format.

*)

Jacni>: I guess this only applies to "portrange" which offers contiguous port-set. So, I would suggest removing this property.
[Med] Ok.

*) For "despres-4rd",
Differentiated Port Sets  Supported, through different piece of rules, delegated CPE prefixes of different length.
[Med] the concern is more on the border router side, can you please check if the operations are still stateless at the border side? BTW, I'm envisaging having two properties here:

(1) Differentiated Port Sets (network level)
(2) Differentiated Port Sets (bound to the same shared address)

IPv4 traffic Isolation   supported
[Med] Ok. This is supported by assigning two prefixes.

Prefix Aggregation   supported, since the IPv6 address planning is not affected.
[Med] Ok.

Cheers,
Jacni

On Tuesday, September 06, 2011 12:44:48 AM, [email-masked]<mailto:[email-masked]> wrote:

Dear all,

Thank you.
Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : lundi 5 septembre 2011 18:33
À : [email-masked]<mailto:[email-masked]>
Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt

[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 7 Sep 2011 07:35:54 +0200

Dear Gang,

As per the following property:

   o  Complexity: Complexity level of the algorithm

I agree this can be split into several sub items but in -00 we used it to reflect the level of complexity to understand the algorithm and to configure it. I know Nejc had some experience in configuring for instance Murakami's 4rd implementation. He found that it was much more complex to understand than the portrange algorithm and the modulo algorithm. 

The text will be clarified.

Cheers,
Med

-----Message d'origine-----
De : GangChen [mailto:[email-masked]] 
Envoyé : mardi 6 septembre 2011 18:10
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]; Wojciech Dec
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hello Authors,

Many thanks

Gang

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 7 Sep 2011 16:02:53 +0900

Hi Med,

> The text will be clarified.

Interesting discussion.
It would be nice if you and us clarify that the complexity for what,
and for who.

cheers,
--satoru

---

From: <[email-masked]>
Date: Wed, 7 Sep 2011 09:28:11 +0200

Hi Satoru,

What I have done is I clarified the text as follows:

"
   o  Complexity: Reflects the complexity level of understanding the
      algorithm and the expected complexity to configure an
      implementation.
"

Is this fine or you think we need to elaborate further?

Cheers,
Med

-----Message d'origine-----
De : Satoru Matsushima [mailto:[email-masked]] 
Envoyé : mercredi 7 septembre 2011 09:03
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : GangChen; [email-masked]; Wojciech Dec
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Med,

Interesting discussion.

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 7 Sep 2011 16:55:24 +0900

Hi Med,

> Is this fine or you think we need to elaborate further?

I'm not sure that who should understand the algorithm, those who is ordinary customer, operator, implementer, etc., 
And from my experience, none of configuration complexity for 4rd implementations. These don't require any complicated configuration to generate port-set from port-set ID.

cheers,
--satoru

---

From: Jacni Qin <[email-masked]>
Date: Wed, 07 Sep 2011 16:11:35 +0800

Hi Med,

More inline please,

On 9/7/2011 1:22 PM, [email-masked] wrote:
> [Med] All port indexing schemes are independent of the address format 
> itself, but we included some properties to reflect some design choices 
> made my the authors of these solutions on the address format. FWIW, we 
> will submit soon a list of requirements to be followed by stateless 
> address/prefix format.

Ok, and just FYI, there are some "design objectives" discussed in 
http://tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-00#page-5 
which may be useful to you.

> [Med] the concern is more on the border router side, can you please 
> check if the operations are still stateless at the border side?

Yes, actually the multiple rules ([IPv6 DomPref, IPv4 DomPref] pairs) 
are used to accommodate fragmented IPv4 address spaces.

> BTW, I'm envisaging having two properties here:

Not necessary, for encapsulation, the next header can be used to 
distinguish the traffic. In addition, a special IID is defined, which 
can be used in the translation context.

Cheers,
Jacni

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 7 Sep 2011 01:23:57 -0700

Hi Mohamed,

I am a developer of 4rd which is used by Nejc. From my perspective, the complexity is not coming from the algorithm itself but I think the complex is depend on the implementation as well. So, I don't think it is good to make a conclusion with a given implementation only. In fact, I have already improved my 4rd implementation. Nejc is using the old version. I think I could improve 4rd configuration in the latest version of my implementation. So, I think we should clarify the complexity from clear cannon which should be coming from many perspective such as algorithm, implementation, etc.

Thanks,
Tetsuya Murakami

---

From: Rémi Després <[email-masked]>
Date: Wed, 7 Sep 2011 11:01:54 +0200

Le 7 sept. 2011 à 09:55, Satoru Matsushima a écrit :
> ...

+1 (in addition to my personal comments)

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 7 Sep 2011 11:02:06 +0200

Med,

More comments in line.

Le 7 sept. 2011 à 07:35, <[email-masked]> <[email-masked]> a écrit :

> I agree this can be split into several sub items but in -00 we used it to reflect the level of complexity to understand the algorithm and to configure it.

These are two different subjects.

"Difficulty to understand" can be due to insufficient quality of explanations.
In this respect, I know what I have written in the past was quite perfectible.
I expect the 4rd-addmapping draft to be clearer on several points, but it certainly can be clarified further. Questions raised in the WG are helpful for that.

"Difficulty to configure" is rather minimal with solutions that are completely stateless.
Having "High" complexity for 4rd-addmapping can therefore be misleading.

(The Complexity criterion is also commented in my previous mail.)

Cheers,
RD

> I know Nejc had some experience in configuring for instance Murakami's 4rd implementation. He found that it was much more complex to understand than the portrange algorithm and the modulo algorithm. 
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 7 Sep 2011 11:02:21 +0200

Hi Med,

Thank you for the detailed analysis of our draft.
Please see some first comments in line.

> [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address fo…

IMHO, separating port-set indexing and IPv6 address format would be a clarification.
Here is a tentative contribution in this direction. 
 
Major criteria to evaluate port-indexing methods:
a) Fairness (no CPE gets well-known ports 0-1023)
b) RTP/RTCP compatibility
c) Stateless BR support of multiple CPE-port-set sizes 
d) UPnP friendliness (interleaved port sets)
e) Support of differentiated sharing ratios without per-CPE states in BRs

Major criteria to evaluate IPv6 address formats of CPEs:
i) Compatibility with IPv4 routes between CPEs as direct as IPv6 routes. (This implies A+P->IPv6 derivation without per-CPE state)
j) No impact on the assignment plan of IPv6 prefixes to CPE's. (This excludes in particular full IPv4 addresses in CPE IPv6 prefixes.) 
k) Optional support of CPE cascades (the suffix field of the 4rd mapping proposals, explained in the 4rd-addmapping draft)

OTOH, complexity comparisons, although worth keeping in mind at this stage, are premature (largely subjective before optimized codes have been worked on for stabilized methods). So far, making sure all methods have AFAIK O(1) complexity should IMHO be be sufficient. When clear about other criteria, thin optimization can become relevant. 

> [Med] the concern is more on the border router side, can you please check if the operations are still stateless at the border side?

Yes, still stateless. 
The BR doesn't need to know the length of a CPE prefix to build an address that starts with the CPE prefix.
It may have bits beyond the CPE prefix, but the CPE ignores them.

Kind regards,
RD

> [Med] Ok. This is supported by assigning two prefixes.

IPv4 traffic is recognized by the fact that Interface ID is a 4rd IID (sec 5.3)
> On Tuesday, September 06, 2011 12:44:48 AM, [email-masked] wrote:
>> 
>> Dear all,
>>

---

From: Rémi Després <[email-masked]>
Date: Wed, 7 Sep 2011 14:06:17 +0200

Oops, 
e) to be deleted from the list below (same feature as c))

---

From: <[email-masked]>
Date: Wed, 7 Sep 2011 14:20:51 +0200

Re-,

Please see inline.

Cheers,
Med

Envoyé : mercredi 7 septembre 2011 10:12

Hi Med,

More inline please,

On 9/7/2011 1:22 PM, [email-masked]<mailto:[email-masked]> wrote:

Ok, and just FYI, there are some "design objectives" discussed in http://tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-00#page-5 which may be useful to you.
[Med] The document is now online, could you please check the list available at: http://tools.ietf.org/html/draft-boucadair-softwire-stateless-rfc6052-update-00#section-3. Do you see additional requirements to be inspired from the pointer you provided? thanks.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 07 Sep 2011 08:47:30 -0400

>       algorithm and the expected complexity to configure an

A subjective criteria is not very useful for comparing algorithms.

Here's a suggestion: configuration complexity could be measured in terms of the
number of parameters necessary. This is an objective criteria.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 08:01:13 +0200

Dear Tetsuya,

I see your point and it is fair but IMHO we need to reflect the "easiness of usability" of an algorithm (this is exactly what we do when select a tool for planning or advanced traffic engineering, etc.). This is very important from an operator standpoint, particularly for operational teams who will dimension/design/rationalize the A+P space.

Does this make sense to you?

I would even appreciate if you can review other algorithms and share your evaluation with us.

Cheers,
Med

-----Message d'origine-----
De : Tetsuya Murakami [mailto:[email-masked]] 
Envoyé : mercredi 7 septembre 2011 10:24
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Tetsuya Murakami; GangChen; [email-masked]; Wojciech Dec
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Mohamed,

Thanks,
Tetsuya Murakami

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 08:05:53 +0200

Hi Rémi,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : mercredi 7 septembre 2011 10:56
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : GangChen; [email-masked]; Wojciech Dec
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Med,

More comments in line.

Med: This is IMHO an important aspect for the operational teams who are in charge of dimensioning the A+P space. Easiness of usability is important.

Med: Not all the port indexing schemes on the table have the same complexity level. As I mentioned earlier, we need to depict this somehow. I would really appreciate if you can evaluate other port algorithms and share your evaluation.

Cheers,
RD

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 08:18:23 +0200

Hi Rémi,

Please see inline.

Cheers,
Med

________________________________
De : Rémi Després [mailto:[email-masked]]
Envoyé : mercredi 7 septembre 2011 14:06
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Jacni Qin; Softwires-wg; Wojciech Dec
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Oops,

Hi Med,

Le 7 sept. 2011 à 07:22, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Jacni,

Please see inline.

Cheers,
Med

Cc : Wojciech Dec; [email-masked]<mailto:[email-masked]>

hi Med, all,

[Med] OK, I will do.

Major criteria to evaluate port-indexing methods:
[Med] In fact we are not evaluating the algorithm at this stage but only characterizing them with a set of properties.

a) Fairness (no CPE gets well-known ports 0-1023)
[Med] We indicate whether this range is excluded or not in the properties table. But, this can be seen also as a loss of port utilization efficiency.

b) RTP/RTCP compatibility
c) Stateless BR support of multiple CPE-port-set sizes
[Med] As I mentioned in another e-mail, I added two properties in the table:

   o  Differentiated Port Sets (Network Level): Capability to assign
      port sets of different sizes to customers attached to the same
      network.
   o  Differentiated Port Sets (same IP address): Capability to assign
      port sets of different sizes to customers assigned with the same
      IPv4 address.

d) UPnP friendliness (interleaved port sets)
[Med] I guess you are referring to IGD:1. Difficult to assess for at least two reasons: (1) IGD:1 is broken and (2) implementations adopt several behaviour (incremental or random).

---

From: Rémi Després <[email-masked]>
Date: Thu, 8 Sep 2011 10:11:39 +0200

...
>> ... criteria to evaluate port-indexing methods:

OK, just a vocabulary ambiguity.
We share the same objective.

>> [Med] We indicate whether this range is excluded or not in the properties table. But, this can be seen also as a loss of port utilization efficiency.  

Yes, it has to be considered.
Now:
- Giving 15 ports, as proposed in the two 4rd variants, where 16 ports can be given by relaxing the fairness constraint isn't a big deal.
- After a recent exchange of information with Christian Huitema, I understand that excluding only the well-known ports 0-1023 is enough.
Then the port-set-size reduction due to fairness can become 1/64 instead of 1/16, which is even more negligible. 
  
>> [Med] I guess you are referring to IGD:1. Difficult to assess for at least two reasons: (1) IGD:1 is broken and (2) implementations adopt several behaviour (incremental or random).

I-D.draft-deng-v6ops-aplusp-experiment-result is IMHO a useful reference on this subject.

Having read it, I now share the view that if a port set is abundantly scattered, version 1 of UPnP will work better.
This is useful because, I have been told, this version of UPnP is significantly deployed.
If this is wrong, please let me know.
 
If despite the above, the final consensus would be that IETF doesn't care about this feature, the latest 4rd address mapping can easily be simplified accordingly.

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 8 Sep 2011 10:19:31 +0200

Le 8 sept. 2011 à 08:05, <[email-masked]> <[email-masked]> a écrit ...
> Med: This is IMHO an important aspect for the operational teams who are in charge of dimensioning the A+P space.

> Easiness of usability is important.

Same view on this.

> Med: Not all the port indexing schemes on the table have the same complexity level. As I mentioned earlier, we need to depict this somehow. I would really appreciate if you can evaluate other port…

In my understanding, all proposed algorithms are, once understood, sufficiently easy to program. 
All can be executed in a time bounded by a small constant, but one whose value depends on code optimization.

IMHO, it is more effective to analyze first functional characteristics and their individual motivations.

This avoids to spend time, at this stage, on detailed discussions on how to optimize code for all analyzed solutions. (This can be done in a second phase for the retained solution(s)).

Cheers,
RD

---

From: GangChen <[email-masked]>
Date: Fri, 9 Sep 2011 00:18:49 +0800

> A subjective criteria is not very useful for comparing algorithms.

+1

> number of parameters necessary. This is an objective criteria.

Criteria should be as objective as possible, especially for "Guessing
Complexity of a Valid Port" ....
Not sure whether there are some mathematical guidance could help to
evaluate computational complexity? Maybe time complexity is a
candidate

BRs

Gang

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 8 Sep 2011 09:29:54 -0700 (PDT)

>>  A subjective criteria is not very useful for comparing algorithms.

Complexity analysis is quite known in fact. 
There is space complexity and time complexity, maybe here we are talking about time complexity.

The algorithm could be exponential which is not desired.
A linear algorithm is ideal but difficult to get.
Logarithmic algorithm is usually the compromise.

All you need to do is to express the computations involved in some algorithmic form and then analyze.

Sounds familiar?

Behcet

> 
> +1
> 
>>  Here's a suggestion: configuration complexity could be measured in 
> terms of
>>  the

---

From: <[email-masked]>
Date: Fri, 9 Sep 2011 08:06:34 +0200

Dear Gang,

The logic we adopted for guessing complexity of a valid port and for the whole range is as mentioned in http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysis-00#section-2:

"  In each analyzed port derivation algorithm, an attacker may implement
   a redirection loop to detect a significant amount of allowed ports.
   For all monotonously scattered schemes, the whole Port-Set may be
   deduced by extrapolation while this is not applicable for contiguous
   port ranges (because no information about port bounds is leaked in
   the IPv4-translatable IPv6 address)."

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de GangChen
Envoyé : jeudi 8 septembre 2011 18:19
À : Simon Perreault
Cc : [email-masked]
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

+1

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 Sep 2011 12:01:10 +0200

Hi Med,

Here is an update concerning 4rd-addmapping in this draft (sec 2.1.6): 

   +-------------------------------------------+---------------------+
   |                                  Property | Value               |
   +-------------------------------------------+---------------------+
   |                                Complexity | --                  |
   |                     Address Sharing Ratio | 1:2^p,  p up to 14  |
   |             Number of ports in a Port-Set | 2^p * 15/16         |
   |       Guessing Complexity of a Valid Port | --                  |
   | Guessing Complexity of the whole Port-Set | --                  | 
   |                            Excluded ports | 0-4095, to be 0-1023|
   |                     Minimal Sharing Ratio | 1:1                 |
   |                     Maximal Sharing Ratio | 1:16K               |
   |                        Multiple Port Sets | Supported           |
   |                  Differentiated Port Sets | Supported           |
   |                       DomPref Flexibility | Supported           |
   |                    IPv4 traffic Isolation | Supported           |
   |                        Prefix Aggregation | Preserved           |
   |            Encode Routing Bits in 64 bits | Supported           |
   |                  Compliancy with RTP/RTCP | Compliant           |
   +-------------------------------------------+---------------------+

The line on Multiple Port Sets has been kept, but you announcement that it will be deleted is understood and approved.

It is also understood that you intend to distinguish Differentiated port set sizes "Per-customer" from  "Per customer class" (a clarifying distinction)

A suggestion is to also distinguish between "Per-customer with PRR states" from "Per customer without PRR states".
(The new 4rd has been designed to support the latter, which is useful for direct CPE-CPE routes. This isn't the case of all proposals.)

Another criterion that differentiates proposals is whether the port set derivation depends on Domain-specific parameters, or is purely algorithmic without parameter.

As we discussed, I also work on tables listing differentiating features of proposed solutions.
They distinguish functional features of:
- port-set specifications 
- IPv6 address formats of CPEs and AFTRs
- Packet formats for IPv6-domain traversal
They are intended to be easily modifiable, so as to be a temporary tool to facilitate discussion. 

FYI, Alain having expressed interest in having them in draft form before the meeting, I plan to edit the draft this week.

Cheers,
RD

...

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 16:18:08 +0200

Hi Rémi,

Thank you for this input. 

As for the differentiated port sets, I'm planning to add the following properties to -01 of draft-bsd-* (need to be discussed with my co-authors):

   o  Differentiated Port Sets (Bound to the same IP address):
      Capability to assign port sets of different sizes to customers
      assigned with the same IPv4 address.
   o  Differentiated Port Sets (Network Level): Capability to assign
      port sets of different sizes to customers attached to the same
      network.

These properties aim to assess the ability of the solution to define different classes of customers having distinct port usage needs. This feature can be supported by dedicating distinct IPv4 address pools but this impacts route aggregation. 

To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals:

(1) Differentiated port sets bound to distinct IPv4 address
* Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1
* Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2

(2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16))
* Port sets of 4096 ports assigned to n  CPEs
* Port sets of 1024 ports assigned to m CPEs

Thanks.
Cheers,
Med

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : lundi 12 septembre 2011 12:01
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg; Wojciech Dec
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Med,

Cheers,
RD

...

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 Sep 2011 17:04:55 +0200

> To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are li…

With 4rd-addmapping, of port-set sizes are directly derived from lengths of delegated IPv6 prefixes.
Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the port set of B is 2^k times smaller than that of A.

Besides that, IPv6 prefixes are assigned without any constraint coming from IPv4. 

> * Port sets of 1024 ports assigned to m CPEs

First, note that, because of privileged-port exclusion for fairness, port-set sizes of 4rd are 15/16 * 2^k.

For (1):
- POOL_IPv4@_1 has IPv6 prefixes having 4-bit Port-set IDs (and have 15/16*4096=3840 ports per CPE).
- POOL_IPv4@_1 has IPv6 prefixes having 6-bit Port-set IDs (and have 15/16*1024=960 ports per CPE).

For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of length L+2 to m CPEs.

OK?

Cheers,
RD

---

From: <[email-masked]>
Date: Tue, 13 Sep 2011 18:08:55 +0200

Hi Rémi,

Thank you or your answer but my question was not on the CPE side but the operations at the border router side. 

Cheers,
Med

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : lundi 12 septembre 2011 17:05
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

For (1):

OK?

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 13 Sep 2011 19:42:06 +0200

> Thank you or your answer but my question was not on the CPE side but the operations at the border router side.

The point is that, with the new 4rd, an AFTR that sends an IPv4 packet to a CPE doesn't need to know the length of the CPE IPv6 prefix  of that BR.
This is a major difference with the old 4rd where this length was a rule parameter. (It is now a parameter only with the CPE-cascade option, to be ignored for this discussion.)

As detailed in Figure 2, the BR includes in the subnet prefix of the IPv6 address L bits from the A+P port. 
This length L is 14 bits unless it has to be limited for this prefix to fit into 64 bits. 

The result can be a subnet prefix that typically differs from the CPE IPv6 prefix, with some extra port bits after the CPE IPv6 prefix. 
However, because the subnet prefix does start with the CPE IPv6 prefix, the packet reaches the CPE. 
There, the 4rd IID is enough for the packet to be recognized as a 4rd packet.

Is this, now, the explanation you were looking for?

Cheers,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 14 Sep 2011 12:28:36 +0900

Hi Remi-san, I have one question.

> This length L is 14 bits unless it has to be limited for this prefix to fit into 64 bits. 

Regarding the 4rd CEs are not cascaded, do you assume that the BR imply 64 bits length for all CE's prefix length if the absence of CE IPv6 prefix length configuration?

cheers,
--satoru

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 07:40:02 +0200

Hi Rémi, 

I didn't get my answer yet. I'm looking for the explanation about the behaviour of an 6/4 interconnection node receiving IPv4 packets destined to CPEs assigned with port sets of different sizes. What is the configuration of that node?

Cheers,
Med

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : mardi 13 septembre 2011 19:42
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 14 Sep 2011 08:20:42 +0200

Hi Satoru-san,

Thank you for your question.
Answer below.

> Regarding the 4rd CEs are not cascaded, do you assume that the BR imply 64 bits length for all CE's prefix length if the absence of CE IPv6 prefix length configuration?

The AFTR doesn't need to imply any CPE prefix length to build the right DST subnet prefix (64 bits).

Let's take the example of sec. 6 (A), namely:  

   +--------------------+--------------------+-------------------------+
   | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) |
   +--------------------+--------------------+-------------------------+
   |     192.32../12    |    2001:db0::/28   | 2001:db0:aaaa:aaaa::/64 |
   +--------------------+--------------------+-------------------------+

   +-------------------------+--------------+------------------+-------+
   | CPE IPv6 prefix         | CPE IPv4     | Port-set bit     | Nb of |
   |                         | address      | pattern          | ports |
   +-------------------------+--------------+------------------+-------+
   | 2001:db1:1111:/48       | 192.33.17.17 | NA               | 64K   |
   | 2001:db2:2222:2000::/52 | 192.34.34.34 | yyyyxxxxxxx0100x | 3840  |
   +-------------------------+--------------+------------------+-------+

Let's assume that the AFTR has A+P packets to send to CPE IPv4 addresses 192.33.17.17 and 192.34.34.34 respectively, and both with dst port 0x4445.

The L port bits to be included in subnet prefixes are then 2888::/15 (reversed order port bits 0-14).

Destination subnet prefixes then comprise:
- The Domain IPv6 prefix 2001:db0::/28 
- 32 - 12 = 20 rightmost bits of IPv4 addresses, 1111:1000::/20 and 2222:2000::/20 respectively
- 2888::/15
- One padding bit set to 0 

They are:
- 2001:db1:1111:2888::/64 
- 2001:db2:2222:2888::/64

Each one starts with the CPE IPv6 prefix of the right dst CPE, which is enough to reach it.

Hope it clarifies.

Kind regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 14 Sep 2011 08:32:43 +0200

Hi Med,

Le 14 sept. 2011 à 07:40, <[email-masked]> a écrit :
...
> I didn't get my answer yet. I'm looking for the explanation about the behaviour of an 6/4 interconnection node receiving IPv4 packets destined to CPEs assigned with port sets of different sizes. Wh…

Please see my answer to Satoru-san.
Copy enclosed below.

Cheers,
RD

------------------

They are:

Hope it clarifies.
-----------------

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 14 Sep 2011 17:04:57 +0900

Remi-san,

> Let's take the example of sec. 6 (A), namely:  

If I understand your algorithm correctly, the port number of the example should be '0x4449'.

> The L port bits to be included in subnet prefixes are then 2888::/15 (reversed order port bits 0-14).

Also, should it be '0x2444'?

> - 32 - 12 = 20 rightmost bits of IPv4 addresses, 1111:1000::/20 and 2222:2000::/20 respectively

Now I understand how your algorithm works.
The CEs which comply your algorithm, almost address spaces are consumed for 4rd except /64 prefixes which last bit of prefix is set. Is it correct?

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 14 Sep 2011 17:18:40 +0900

Med,

> I didn't get my answer yet. I'm looking for the explanation about the behaviour of an 6/4 interconnection node receiving IPv4 packets destined to CPEs assigned with port sets of different sizes. Wh…

If I correctly understand his algorithm, the size of port sets depend on delegated IPv6 prefix length to each CE.
As the example in his mail, a CE gets /48, then it uses whole IPv4 address, another CE gets /52, then it uses an IPv4 address with restricted to 3840 ports.

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Wed, 14 Sep 2011 15:25:57 +0200

> If I understand your algorithm correctly, the port number of the example should be '0x4449'.

Oops, you are right.
Sorry for the mistake.

> Also, should it be '0x2444'?

Indeed.

Thanks.

> The CEs which comply your algorithm, almost address spaces are consumed for 4rd except /64 prefixes which last bit of prefix is set. Is it correct?

Difficult to understand what you mean.
If you rephrase it differently, I will try to confirm or not.

Cheers,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 Sep 2011 08:32:09 -0700 (PDT)

Hi Med,

  Thanks for the analysis. 
I have a small question: 
Compliance with RTP/RTCP applications
what does this mean?

(BTW this is what my spell checker gave :-) )

Regards,

Behcet

> Objet : Re: [Softwires] Analysis of Port Indexing Algorithms 
> (draft-bsd-softwire-stateless-port-index-analysis)
> 
> 
> Le 12 sept. 2011 à 16:18, <[email-masked]> 
> <[email-masked]> a écrit :
>>  ... 
>>  To double check the ability of 4rd-addmapping algo to support 
> differentiated port sets without any state on the BR, could you please provide 
> some examples to show this behaviour? FWIW, below are listed some configuration 
> proposals:
> 
> Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the 
> port set of B is 2^k times smaller than that of A.
> 
>>  (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 
> range is excluded, (n+1)*4096 + m*1024 = 2^16))

---

From: <[email-masked]>
Date: Wed, 14 Sep 2011 19:24:23 +0200

Hi Behcet,

This property aims to assess if the proposed algorithms:

   1.  Preserve the port parity as discussed in Section 4.2.2 of
       [RFC4787].

and 

   2.  Preserve port contiguity as discussed in Section 4.2.3 of
       [RFC4787] (i.e., RTCP=RTP+1).

An elaboration is also provided in: http://tools.ietf.org/html/draft-boucadair-softwire-stateless-requirements-00#section-2:

   REQ#8:  Applications requiring even/odd and port contiguity (e.g.,
           RTP/RTCP) SHOULD NOT be broken due to the port set assignment
           scheme.

                   Traditionally the voice/video applications that use
                   RTP and RTCP would specify only the RTP port that the
                   application would use for streaming the RTP data.
                   The inherent assumption is that the RTCP traffic will
                   be sent on the next higher port.  Even though RFC3605
                   defines a new attribute for explicitly specifying the
                   RTCP attribute for the SDP-based applications, but
                   since it is not a MUST to use this attribute, there
                   are still applications that are not compliant with
                   this RFC.  There are also non-SDP based applications
                   that use RTP/RTCP like H323, that make the assumption
                   that RTCP streaming will happen on RTP+1 port.

Cheers,
Med

________________________________________
De : Behcet Sarikaya [[email-masked]]
Date d'envoi : mercredi 14 septembre 2011 17:32
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Med,

  Thanks for the analysis.
I have a small question:

Regards,

Behcet

---

From: Francis Dupont <[email-masked]>
Date: Wed, 14 Sep 2011 19:35:45 +0200

In your previous mail you wrote:

=> a pair of even/odd succeeding port number. The reason is some
bad RTP/RTCP software expect to get an even port number for RTP
and use the following (odd) port number for RTCP... Silly but
common in the real world.

Regards

[email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 Sep 2011 13:13:34 -0700 (PDT)

Hi Med,
  But RTCP streaming is not used much because HTTP streaming is used.
Maybe that's why RFC 6346 does not mention this constraint.

Regards,

Behcet

> An elaboration is also provided in: 
> http://tools.ietf.org/html/draft-boucadair-softwire-stateless-requirements-00#section-2:
> 
>>  First, note that, because of privileged-port exclusion for fairness, 
> port-set
>>  sizes of 4rd are 15/16 * 2^k.
>> 
>>  For (1):
>>  For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of 
> length
>>  L+2 to m CPEs.
>> 
>>  OK?
>> 
>>  Cheers,
>>  RD
>> 
>> 
>>

---

From: <[email-masked]>
Date: Thu, 15 Sep 2011 07:46:00 +0200

Hi Behcet,

This is mainly used for the VoIP (Voice over IP) (e.g., SIP-controlled communications). In a SIP context, the SDP offer/answer may not include "a=rtcp" attribute, so endpoints assumes the RTCP port is RTP one + 1.

Cheers,
Med 

-----Message d'origine-----
De : Behcet Sarikaya [mailto:[email-masked]] 
Envoyé : mercredi 14 septembre 2011 22:14
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: RE : [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Med,

Regards,

Behcet

---

From: <[email-masked]>
Date: Thu, 15 Sep 2011 14:15:53 +0200

Hi Rémi,

I checked draft-despres-softwire-4rd-addmapping again and you reverse only the L bits identifying the PSID. This is why I'm puzzled how it is possible to support differentiated port sets (which means distinct PSID of distinct length e.g., 4 and 6).  

Cheers,
Med 

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : mercredi 14 septembre 2011 08:33
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Med,

Cheers,
RD

------------------

They are:

Hope it clarifies.
-----------------

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Sep 2011 14:46:14 +0200

> I checked draft-despres-softwire-4rd-addmapping again and you reverse only the L bits identifying the PSID. This is why I'm puzzled how it is possible to support differentiated port sets (which mea…

Length L used by AFTRs to build IPv6 addresses is in general longer than the (unknown) PSID of the destination CPE.
Unless some truncation is needed, in order to the DST subnet prefix to exceed 64 bits), it is L = 14 (top of page 12).

BTW, the next version of 4rd-addmapping should include significantly simpler and clearer port-set algorithm. 
Following in particular your own comments, this algorithm will no longer be influenced by the controversial UPnP friendliness objective.

Cheers,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 15 Sep 2011 13:11:47 -0700 (PDT)

Hi Gang,
In your draft Fig. 1, I don't understand H1, H2 and H3 that you have?
The connections to the UE, what are they? 

It seems like you are depicting the UE as a WLAN AP?

Also on page 6, you have a reference to RFC 6035, I think it should be 6052.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 16 Sep 2011 08:02:10 -0700 (PDT)

Hi Med,

Another question:
On page 19, you have:
The limit of 0-4095 ports appears rather arbitrary and represents a
   likely waste of ports, if not more that an operator may be interested
   in utilizing.

Why? Shouldn't they be excluded?

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 14 Sep 2011 11:51:01 -0700 (PDT)

Hi Med,

Regards,

Behcet

---

From: GangChen <[email-masked]>
Date: Sat, 17 Sep 2011 16:29:13 +0800

Dear Med,

> The logic we adopted for guessing complexity of a valid port and for the
> whole range is as mentioned in
> http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysis-00#section-2:

It seems same criteria applied for these two properties. But why would
you get different complexity level for each property targeting to same
algorithm? (e.g. For portrange judgment,  Guessing Complexity of a
Valid Port is low; Guessing Complexity of the whole Port-Set is
Medium)

For me, the statement is more proper for whole Port-Set prediction. I
guess we need to add texts for valid Port prediction?

Many thanks

Gang

---

From: GangChen <[email-masked]>
Date: Sat, 17 Sep 2011 16:36:59 +0800

Hello Behcet,

Thanks for the comments.

> It seems like you are depicting the UE as a WLAN AP?

In the fig.1, UE takes the role of CPE with wireless modem use 3GPP
access as uplink. It's double stack capable. Thereby, three kinds of
IP devices could connect to such UE.
i.e. IPv4-only(H1), IPv6-only(H2) and dual-stack(H3)

> Also on page 6, you have a reference to RFC 6035, I think it should be 6052.

Yes. that is typo. I will correct that at next update

many thanks

Gang

---

From: Satoru Matsushima <[email-masked]>
Date: Sun, 18 Sep 2011 18:11:16 +0900

Mohamed, all,

First, thanks for the analysis draft. It sounds good. Let me try to bring my thought.

An interesting point is here. In the algorithms which define offset to exclude ports such as 1024, 4096 whatever, the efficiency of port utilization is decreased, which algorithm is 4rd, and complexity of calculation are increased, which algorithm is dIVI's modulo, when the number of CEs which share an address exceed the number of excluded ports.

For example, in the case of that someone uses modulo with excluding under 1024 port, port-set ID is always placed at last 9 bits in a port if the number of CEs which share one address isn't exceed 1024. But when the number of CEs exceed 1024, complexity of modulo operation will be increased to calculate port set ID from port number at BR and CE. In the case of 4rd, which exclude under 4096 port, if CEs over 4096, which CEs share one address, 8K, 16K, 32K of ports are unusable respectively.

To keep simple implementation and operation, I think that offset port and the maximum address sharing ratio should be same. So the question is what is the number. 1024 is small a little. 2048 or 4096? I think that first nibble of port to utilize offsetting is helpful for implementation and is easy to read in hex. So In my opinion, 4096 is adequate for both offset port and maximum sharing ratio. If it would be applied to 4rd, a following figure could be depict. Port-set ID is always placed on right after the first nibble. CE's NAT needs to maintain just only fifteen port ranges, and BR and CE just remove first nibble to pick a port set ID from port number in a packet.

                               1 1 1 1 1 1
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Port-set |h h h h|x x x x x x x x|       |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |<head> |<-Port-set ID->|<-tail->
           4bits       max 12bits
         (0x1-0xF) 

Second, I think that the character differences of these analyzed algorithms come from where is port-set ID in a port number. Each algorithms is a result of labor to define where are port-set ID bits. I agree with last paragraph in section 2 that says 'the whole Port-Set may be deduced by extrapolation', so it would be predictable port set regardless of which analyzed algorithm generates.

If I add one point to the analysis, that is 'Complexity of CE side NAT ports pool configuration and management', which NAT is already distributed to the fields. Several contiguous port ranges are helpful to configure and manage NAT ports pool. On the other hand, scattered scheme increases complexity of configuration and management as the number of ports in port set increased.

So I think that having unique port set derivation for each stateless address sharing domain is important.To make variation of port-set indexing, port-set ID mask option could be helpful. As I'm inspired by a discussion with Xiaohong, the port-set ID mask is used for which bits indicate port-set ID. That bits are fully configurable by each operator's domain. In terms of port-set ID mask configuration, the default port indexing is just one of configuration variation. Please see a following figure.

                               1 1 1 1 1 1
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Port-set |h h h h|  x   x x   x x   x x  |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |<head> |  ^   ^ ^   ^ ^   ^ ^
           4bits     |   | |   | |   | |
         (0x1-0xF)   |   | |   | |   | |
                     |   | |   | |   | |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Port-set |0 0 0 0|0 1 0 1 1 0 1 1 0 1 1 0|
 ID mask  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Option   <------> <---------------------->
            must       Port-set ID mask
             be    (‘1’ indicates port-set ID bits)
            zero

I have no draft for that yet, but I'd like to discuss at the interim meeting.
Have a good weekend, hope to see you in Beijing, next week.

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Sun, 18 Sep 2011 14:40:20 +0200

Hi Satoru-san,

Le 18 sept. 2011 à 11:11, Satoru Matsushima a écrit :

> To keep simple implementation and operation, I think that offset port and the maximum address sharing ratio should be same. So the question is what is the number. 1024 is small a little. 2048 or 4096? I think that first nibble of port to utilize offsetting is helpful for implementation and is easy to read in hex. So In my opinion, 4096 is adequate for both offset port and maximum sharing ratio.

Same view.

> If it would be applied to 4rd, a following figure could be depict. Port-set ID is always placed on right after the first nibble. CE's NAT needs to maintain just only fifteen port ranges, and BR and CE just remove first nibble to pick a port set ID from port number in a packet.
> 
> 
>                              1 1 1 1 1 1
> So I think that having unique port set derivation for each stateless address sharing domain is important.

Same view.

> To make variation of port-set indexing, port-set ID mask option could be helpful. As I'm inspired by a discussion with Xiaohong, the port-set ID mask is used for which bits indicate port-set ID. That bits are fully configurable by each operator's domain. In terms of port-set ID mask configuration, the default port indexing is just one of configuration variation. Please see a following figure.
> 
>                              1 1 1 1 1 1

The next version of the 4rd-addmapping draft will document the following as Port-set pattern (still working on it): 

|       |                      1|
|0      |4                     5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x|     PSID    |x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ^  :             :    ^
    |  :<max 12 bits >    |
    |                     |
any value > 0           any value  

It was discussed with mark last Wednesday, Sept 14, and he expressed great interest.

Cheers,
RD

---

From: <[email-masked]>
Date: Mon, 19 Sep 2011 09:21:45 +0200

Dear Gang,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : GangChen [mailto:[email-masked]] 
Envoyé : samedi 17 septembre 2011 10:29
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Simon Perreault; [email-masked]
Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Dear Med,

Med: For a contiguous port range, if you know port N it is easy to guess the next port. This is why we indicated "Low" but since the port range bounds are not leaked in the port itself, it is not easy to guess the whole port (hence the "Medium"). But still the loop vector above applies for all port set allocation algorithms and under some conditions the server may by itself detects the whole port set. 

Med: any text proposal is welcome.

---

From: <[email-masked]>
Date: Mon, 19 Sep 2011 09:38:19 +0200

Hi Behcet,

Excluding 0-4095 range is not justified in those documents. Excluding by default this range may be considered by some service providers as waste of ports.

Excluding 0-1023 range may be understood by "port utilisation fairness" but still be considered as an inefficiency if it is excluded by the algorithm and not let to the taste of service providers to assign or not that range.

Sharing the 0-1023 between several users may be useless (e.g. is valid scenario to assign port 80 without port 443?).

Cheers,
Med

-----Message d'origine-----
De : Behcet Sarikaya [mailto:[email-masked]] 
Envoyé : vendredi 16 septembre 2011 17:02
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: RE : [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Med,

Another question:
On page 19, you have:

Regards,

Behcet

---

From: <[email-masked]>
Date: Wed, 21 Sep 2011 07:54:11 +0200

Hi Behcet,

It is part of the service provider business to offer services which rely on the 0-1023 range even in a shared address environment (e.g., host an FTP server, etc.). Because statically not all subscribers use these features, the whole 0-1023 range may be assigned only to few subscribers (whether this is on-demand or during the service subscription, is out of scope of what we are doing here). As such, the ability to assign or not that port range should be left to each SP and not excluded by default.

We analyzed two types of algorithms in draft-bsd:
* algorithms which exclude by construction that range.
* algorithms which leave excluding that range to the SP: i.e., the algorithm allows to generate a port range including the 0-1023 but the SP may decide to not assign it to any requesting user. This should be part of the SP policies.

Cheers,
Med

________________________________
De : Behcet Sarikaya [mailto:[email-masked]]
Envoyé : mardi 20 septembre 2011 08:36
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: RE : [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Med,
  I thought excluding well known ports is good idea because all nodes need it.
Below you seem to agree that sharing them may be useless.

Why is it service provider issue? It seems like address sharing changes the basic characteristic of the port number space :-).
Regards,

Behcet

On Mon, Sep 19, 2011 at 2:38 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Behcet,

Cheers,
Med

-----Message d'origine-----
De : Behcet Sarikaya [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : vendredi 16 septembre 2011 17:02
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: RE : [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Med,

Another question:
On page 19, you have:

Regards,

Behcet

---

From: <[email-masked]>
Date: Wed, 21 Sep 2011 08:46:26 +0200

Re-,

The port sets should not overlap; this is a trivial assumption of this work.

Cheers,
Med

Envoyé : mercredi 21 septembre 2011 08:42

Hi Med,
I think that exclusion in draft-murakami means exclusion from sharing. All nodes have access to ports 0-4095 plus the port range assigned.

Two nodes with the same address using the FTP port, would that work?
These things are very confusing :-).

Regards,

Behcet

On Wed, Sep 21, 2011 at 12:54 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Behcet,

Cheers,
Med

________________________________
De : Behcet Sarikaya [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 20 septembre 2011 08:36

Hi Med,

Behcet

Cheers,
Med

-----Message d'origine-----
De : Behcet Sarikaya [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : vendredi 16 septembre 2011 17:02
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Softwires-wg
Objet : Re: RE : [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)

Hi Med,

Another question:
On page 19, you have:

Regards,

Behcet

---

From: Rémi Després <[email-masked]>
Date: Wed, 21 Sep 2011 09:24:10 +0200

Hi Med,

> * algorithms which exclude by construction that range.

Any solution that permits to assign exclusive addresses to some customers does permit to assign ports 0-1023 to them.

It is only for restricted port sets of shared addresses that, for fairness and simplicity, avoiding to assign any WK port exclusion to any customer is proposed.

Cheers,
RD

> On Mon, Sep 19, 2011 at 2:38 AM, <[email-masked]> wrote:
> Hi Behcet,
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 21 Sep 2011 11:45:50 -0500

> doing here). As such, the ability to assign or not that port range should be
> left to each SP and not excluded by default.

+1. 

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Wednesday, September 21, 2011 1:54 AM
> To: [email-masked]
> Cc: Softwires-wg
> Subject: Re: [Softwires] RE : Analysis of Port Indexing Algorithms (draft-bsd-
> softwire-stateless-port-index-analysis)
> 
> Hi Behcet,
> 
> It is part of the service provider business to offer services which rely on
> the 0-1023 range even in a shared address environment (e.g., host an FTP
> server, etc.). Because statically not all subscribers use these features, the
> whole 0-1023 range may be assigned only to few subscribers (whether this is
> on-demand or during the service subscription, is out of scope of what we are
> doing here). As such, the ability to assign or not that port range should be
> left to each SP and not excluded by default.
> 
> * algorithms which leave excluding that range to the SP: i.e., the algorithm
> allows to generate a port range including the 0-1023 but the SP may decide to
> not assign it to any requesting user. This should be part of the SP policies.
> 
> Cheers,
> Med
> 
> Why is it service provider issue? It seems like address sharing changes the
> basic characteristic of the port number space :-).
> Regards,
> 
> Behcet
> 
> 
> 	Excluding 0-4095 range is not justified in those documents. Excluding by
> default this range may be considered by some service providers as waste of
> ports.
> 
> 	Excluding 0-1023 range may be understood by "port utilisation fairness"
> but still be considered as an inefficiency if it is excluded by the algorithm
> and not let to the taste of service providers to assign or not that range.
> 
> 	Sharing the 0-1023 between several users may be useless (e.g. is valid
> scenario to assign port 80 without port 443?).
> 
> 
> 	Cheers,
> 	Med
> 
> 
> 	Objet : Re: RE : [Softwires] Analysis of Port Indexing Algorithms