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

[Gábor LENCSE <[e-mail]>]

Dear Lars,

5/2/2022 3:14 PM keltezéssel, Lars Eggert írta:
> 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?

I tried to find some more up-to-date results, but Google Scholar gives 
my paper as the first hit for: "port number consumption"

G. Lencse, "Estimation of the Port Number Consumption of Web Browsing", 
/IEICE Transactions on Communications/, Vol. E98-B, No. 8. pp. 
1580-1588. DOI: 10.1587/transcom.E98.B.1580

Public full text is available: 
http://www.hit.bme.hu/~lencse/publications/e98-b_8_1580.pdf

It is from 2015, but I focused on web browsing only.

(If you want, I can cite it too, but I do not want to push my own 
papers. And the paper of Miyakawa is gold open access, mine is only green.)


The second hit is the paper of my students, who also did similar 
measurements using various browsers and operating systems:

S. Répás, T. Hajas and G. Lencse, "Port Number Consumption of the NAT64 
IPv6 Transition Technology", /Proceedings of the 37th International 
Conference on Telecommunications and Signal Processing (TSP 2014)/, 
(Berlin, Germany, 2014. July, 1-3.) Brno University of Technology, pp. 
66-72. DOI: 10.1109/TSP.2015.7296411

Public full text is available: 
http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf

None of us reached 270 ports, thus I think that [MIY2010] can still be a 
good upper bound.


The list of hits is somewhat suspicious for me, there are too many 
papers related to my group:
https://scholar.google.hu/scholar?hl=hu&as_sdt=0%2C5&q=%22port+number+consumption%22&btnG=

(The search without quotes gives a lot of unrelated papers using the 
words in their other meanings.)

So unfortunately, I cannot present significantly newer results or 
results from other researchers in this topic.


It would be so nice, if some network operators could share their 
experience! :-)


>>>> 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.

The consequence of assigning too few port numbers to an end user is 
already described in the draft as follows:

    On the one hand, the "lack of ports" situation may cause serious
    problems in the operation of certain applications.  For example,
    Miyakawa has demonstrated the consequences of the session number
    limitation due to port number shortage on the example of Google Maps
    [MIY2010  <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-comparison#ref-MIY2010>].  When the limit was 15, several blocks of the map were
    missing, and the map was unusable.  This study also provided several
    examples for the session numbers of different applications (the
    highest one was Apple's iTunes: 230-270 ports).

There is another sentence recommending the usage of enough port numbers:

    There may be several users behind a CE router, especially in the
    broadband case (e.g.  Internet is used by different members of a
    family simultaneously), so sufficient ports must be allocated to
    avoid impacting user experience.

In addition to that, what do you think of adding the following text 
(based on your suggestion)?

In general, assigning too few source port numbers to an end user may 
results in unexpected and hard to debug consequence, therefore, if the 
number of ports per end user is fixed, then we recommend to assign a 
conservatively large number of ports. E.g. the developers of Jool used 
2048 ports per user in their example for [MEX2022].

Where the reference is:

[MEX2022] https://www.jool.mx/en/run-mapt.html

It is not yet in the XML file, but I am happy to include it if you 
agree, and others do not oppose it.

> 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?

Unfortunately, I did not have time to deal with it until now. However, 
today I have added real content. The -01 version is available here: 
https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-benchmarking 


And I plan to add further content during the upcoming 2-3 years as soon 
as my team produces measurement results.

We need some time for developing RFC 8219 compliant special-purpose 
measurement programs for each technology and then to perform the rather 
time consuming measurements. This is why I started a separate draft for 
the performance measurement results to let 
draft-ietf-v6ops-transition-comparison published as an RFC.

Best regards,

Gábor

>
> Thanks,
> Lars
>
>