Subject: Re: [Softwires] Port-set algorithm of MAP - what is it? Why so complex?

From: Rémi Després <[email-masked]>
Date: Wed, 7 Mar 2012 09:21:00 +0100

Ole,

I just discovered that my previous email didn't have, by mistake, the Softwire ML as destination.
Since the subject is clearly of common interest, and has nothing secret, I correct now the mistake.  

Comments in line.

2012-03-06 21:28, Ole Trøan:

> Remi,
> 
>> Trying to figure out what the MAP port-set algorithm is, I was confused:
>> (a) According to MAP dhcp-option-02, parameters are AFAIK:
>> - the PSID length (implicit, derived from ea-len and prefix4-len)
>> - excluded-ports
>> - offset
>> (b) According to MAP address-and-port-03 parameters are:
>> - Sharing ratio R 
>> - Maximum number of contiguous ports M
>> - an apparently fixed set of excluded ports (0-4095)
>> Could you clarify what is proposed?
> 
> sharing ratio can be derived from the PSID length. M can be derived from 16 - offset - PSID length.
> PSID length is derived from EA-bits length.

> the only specific to the algorithm that may be provisioned (it is optional) is the offset.
> and in theory the excluded ports.

"in theory" doesn't really clarify.
Is it a parameter?
- If yes, the MAP-address-and-port draft needs AFAIK an update
- If no, the MAP-dhcp-02 draft needs AFAIK to be modified

If I missed something, thanks for an explanation.

> my personal view, is that we should drop the optional parameters too.

Sees (*) below.

> the algorithm would still be the same though.

See (**) below

>> 2.
>> Detailed MAP examples you give have excluded ports 0-4095, offset=4, and no M.
>> This is exactly what 4rd has without needing any parameter, and with a trivial algorithm instead of the somewhat brain-teasing algorithm copied below.

>> Could you clarify which use cases you see that would justify such complexity?

(*) So, you don't personally see any use case than would justify a PSID-algorithm parameter.
We both agree on this.

> I think you misunderstand. what you see below is the 4rd algorithm.

??? (see below)

> please write an implementation of your version of the algorithm, and see if you don't end up with pretty much the same as is shown below.

(**) 4rd derives a port set from a PSID as shown in the picture below. I would implement it with masks and shifts rather than with multiplications and divisions and, in any case, without needing to think of any "Maximum number of contiguous ports" and a "Sharing ratio".

                         : 4 :    
                         +---+----+---------+
Ports in the CE port set |> 0|PSID|any value|
                         +---+----+---------+
                         :        16        :

Cheers,
RD

> 
>> Copied of your section 4.1:
>> The port number (P) of a given PSID (K) is composed of: P = R * M * j + M * K + i  Where: 
>> *  PSID: K = 0 to R - 1
>> *  Port range index: j = (4096 / M) / R to ((65536 / M) / R) - 1, if the well-known port numbers (0 - 4096) are excluded.
>> *  Contiguous Port index: i = 0 to M - 1"
> 
> cheers,
> Ole

---

From: Ole Trøan <[email-masked]>
Date: Wed, 7 Mar 2012 15:27:40 +0100

Remi,

> If I missed something, thanks for an explanation.

you are likely right, that there is some discrepancy between the two.
offset versus excluded ports may be an open issue. e.g an offset of 0, implies that the system ports are included. should we allow that also for offset > 0. (I would prefer not.)

> (*) So, you don't personally see any use case than would justify a PSID-algorithm parameter.

my personal preference is for fixed offset, and that the only way to assign system ports is by assigning a full IPv4 address. the design team reached a compromise on allowing the algorithm to be tunable though.

> (**) 4rd derives a port set from a PSID as shown in the picture below. I would implement it with masks and shifts rather than with multiplications and divisions and, in any case, without needing to…

ehem, "any value" is what we call "Maximum number of contiguous ports". that we chose to label the field, can hardly be an argument for it being more complex.
all shared IP address solution has a notion of sharing ratio.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 7 Mar 2012 16:32:03 +0100

> offset versus excluded ports may be an open issue. e.g an offset of 0, implies that the system ports are included. should we allow that also for offset > 0. (I would prefer not.)

Well, if offset=0, it depends the PSID length whether some of of the 0-1023 ports are distributed among several CEs (only one CE gets, for example, port 80, or all assigned to a single CE. 
This is a complexity for which, again, I cannot see a real use case. 

> my personal preference is for fixed offset, and that the only way to assign system ports is by assigning a full IPv4 address. the design team reached a compromise on allowing the algorithm to be tu…

A compromise between what and what?
Since there is no MAP-discussion archive, it's hard to guess what the issue has been.
Since we both believe no parameter is needed, can we consider this is the WG provisional as long as no significant use case is provided?

> ehem, "any value" is what we call "Maximum number of contiguous ports".

You explanation is still confusing:
- Maximum number of contiguous ports is of course NOT "any value".
- It should be AFAIK 2^(12 - PSID length).

I agree however that, with adequate parameter values, a non ambiguous Generalized Modulus Algorithm could create port of the PSID-derived port set above, but all the algorithmic complexity below (copied again since you deleted it from your response) is completely SUPERFLUOUS to specify this port set.

"The port number (P) of a given PSID (K) is composed of: P = R * M * j + M * K + i  Where: 
*  PSID: K = 0 to R - 1
*  Port range index: j = (4096 / M) / R to ((65536 / M) / R) - 1, if the well-known port numbers (0 - 4096) are excluded.
*  Contiguous Port index: i = 0 to M - 1"

BTW, j is very indirectly defined if excluded ports are different from 0-4096 (actually  0-4095).

Leaving this discussion at this point would be OK for me until a justification for a flexible algorithm is provided.
Cheers,
RD

> that we chose to label the field, can hardly be an argument for it being more complex.

---

From: <[email-masked]>
Date: Wed, 7 Mar 2012 16:59:32 +0100

Hi Rémi, all,

During the MAP discussion, we identified the following requirements:

   R-4:   MAP must allow service providers to define their own address
          sharing ratio.  MAP MUST NOT in particular restrict by design
          the possible address sharing ratio; ideally 1:1 and 1:65536
          should be supported.  The mapping must at least support a
          sharing ratio of 64, 1024 ports per end-user.

   R-7:   The MAP solution should support excluding the well known ports
          0-1023.

   R-8:   It MUST be possible to assign well known ports to a CE.

The offset has been proposed as a flexible means to meet the requirements above.

Cheers,
Med

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Rémi Després
> Envoyé : mercredi 7 mars 2012 16:32
> À : Ole Trøan
> Cc : Softwires WG
> Objet : Re: [Softwires] Port-set algorithm of MAP - what is 
> it? Why so complex?

> > 
> > my personal preference is for fixed offset, and that the 
> only way to assign system ports is by assigning a full IPv4 
> address. the design team reached a compromise on allowing the 
> algorithm to be tunable though.
> 
> Since we both believe no parameter is needed, can we consider 
> this is the WG provisional as long as no significant use case 
> is provided?

---

From: Rémi Després <[email-masked]>
Date: Wed, 7 Mar 2012 17:29:25 +0100

Hi Med,

I am, as you remember, well aware of these rules. 

But the fact is that, with the fixed PSID offset = 4 of 4rd-u (which could easily also apply to MAP), we have the following:
 R-4: sharing ratios are from 1 to 2048 (PSID length limited to 11 for odd-even pairs always be in port sets) => OK
 R-7: ports 0-1023 are excluded for sharing ratios 2 to 2048 => OK
 R-8: well-known ports can be assigned to CEs with sharing ratio 1 => OK

So far, this seems to me so completely sufficient.

Yet, if some ISP has a deployment plan where it is convincingly necessary to have more flexibility, that is of course worth discussing. 
But if there is none, time has come IMHO to simplify what can be simplified.

Cheers,
RD

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 15:51:13 +0100

Hi Rémi,

I have explained my views (which is shared by other WG members) about this point in this mailing list. Below a pointer to that discussion: 

http://www.ietf.org/mail-archive/web/softwires/current/msg02873.html

Cheers,
Med 

> De : Rémi Després [mailto:[email-masked]] 
> Envoyé : mercredi 7 mars 2012 17:29
> À : BOUCADAIR Mohamed OLNC/NAD/TIP
> Cc : Ole Trøan; Softwires WG
> But the fact is that, with the fixed PSID offset = 4 of 4rd-u 
> (which could easily also apply to MAP), we have the following:
>  R-4: sharing ratios are from 1 to 2048 (PSID length limited 
> to 11 for odd-even pairs always be in port sets) => OK
> Yet, if some ISP has a deployment plan where it is 
> convincingly necessary to have more flexibility, that is of 
> course worth discussing.

---

From: Rémi Després <[email-masked]>
Date: Thu, 8 Mar 2012 18:02:07 +0100

> http://www.ietf.org/mail-archive/web/softwires/current/msg02873.html

Thanks.
Please see my answer to Maoke:
- A Rule parameter to request "WKP Assignability" is IMHO an approach worth considering  (=> no PSID offset instead of the default offset).

Cheers,
RD

---

From: Xing Li <[email-masked]>
Date: Fri, 09 Mar 2012 15:36:45 +0800

Hi, Remi,

> (**) 4rd derives a port set from a PSID as shown in the picture below. I would implement it with masks and shifts rather than with multiplications and divisions and, in any case, without needing to…

Note that if the ratio is bitwise, the multiplications and divisions are 
shift operations, and the module is mask operation. Therefore, no 
computational complexity is introduced.

xing