Re: [v6ops] Lars Eggert's No Objection on draft-ietf-v6ops-transition-comparison-03: (with COMMENT)

[Lars Eggert <[e-mail]>]

Hi,

On 2022-5-2, at 15:39, Gábor LENCSE <[e-mail]> wrote:
>>>    Often it is assumed that each user-device (computer, tablet,
>>>    smartphone) behind a NAT, could simultaneously use about 300 ports.
>>>    Typically, in the case of a residential subscriber, there will be a
>>>    maximum of 4 of those devices in use simultaneously, which means a
>>>    total of 1,200 ports.
>>> 
>> Is there a reference for these numbers? They seem awfully low.
> 
> Shin Miyakawa has performed detailed measurements. (In his paper, 270 ports per application was the maximum, thus our 300 is an upper bound.)
> We have cited his paper as follows:
>    According to [MIY2010], each user-device (computer, tablet,
>    smartphone) behind a NAT, could simultaneously use up to 300 ports.
>    In the case of a residential subscriber, there will be typically a
>    maximum of 4 of those devices in use simultaneously, which means a
>    total of 1,200 ports.

that paper was published in 2010, so the data is at least twelve years old. Should a recommendation in 2022 be based on it?

>>> 4.2.  Tradeoff between Port Number Efficiency and Stateless Operation
>>> 
>> I'm missing some text in this section that clearly describes the bad and hard to
>> debug consequences of assigning too few ports to an end user, and ideally a
>> recommendation to assign a conservatively large number of ports.
> 
> As far as I know, MAP-T has some significant deployments e.g. in Japan, thus operator experience should exist.
> 
> Is there anyone on the v6ops list, who has experience with MAP-T/E?
> 
> As far as I know, a port set size of 2048 is commonly used with MAP-T. E.g. it can be seen in this example: https://www.jool.mx/en/run-mapt.html
> 
> Therefore, I think that this size of port set does not cause any problem. (Otherwise, they would not use it.)
> 
> So I am not sure if it is right to add such text as recommended above. But I am ready to do so, if those, who have experience, can confirm it.

So clearly there can be issues when too few ports are assigned per user; the document even anecdotally summarizes the old Google Maps experiment. And since this section intends to describe the tradeoffs, it should discuss what happens if someone turns the know too aggressively.

That some configuration has picked a setting that seems to be ok is nice, but doesn't really help readers understand the tradeoff and how to spot problematic choices.

>> Section 5, paragraph 1, comment:
>> 
>>> 5.  Performance Comparison
>>> 
>> This section is entirely about future work, which could IMO be removed before
>> the RFC is published. (This should go into
>> I-D.lencse-v6ops-transition-benchmarking.)
>> 
> 
> I think removing Section 5 completely would be an easy solution, but not the best one. I am convinced that in some cases, performance can be an important decision factor for network operators. Therefore, I would like to draw the attention of the readers our our document for the importance of the performance characristics of the various implementations of the five IPv4aaS technologies and also provide them with a pointer to I-D.lencse-v6ops-transition-benchmarking.

But work on draft-lencse-v6ops-transition-benchmarking seems to have just started, and the -00 document (which already expired) is basically completely empty. So there really isn't anything to refer a reader to?

Thanks,
Lars