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

[Brian E Carpenter <[e-mail]>]

Gábor,

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

I would guess that Lars is suggesting that 4 devices per household is too 
low these days. My household of two people routinely has 4 devices on line all day (two PCs and two Android phones), so it seems likely that assuming 4 is the "typical maximum" is risky today, especially with the marked 
trend towards WFH since the pandemic.

Regards
    Brian Carpenter

On 03-May-22 08:29, Gábor LENCSE wrote:
> 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
>>
>>
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>