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

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

Dear Lars Eggert,

Thank you for your review and I am sorry for my late response. (Now, I 
perform the changes in the XML file and submit the new version after 
being ready with processing the comments of the other reviewers, too.)

Please see my answers inline.


4/20/2022 2:08 PM keltezéssel, Lars Eggert via Datatracker írta:
> Lars Eggert has entered the following ballot position for
> draft-ietf-v6ops-transition-comparison-03: No Objection

[...]

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 3.4, paragraph 1, comment:
>>     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.


>
> Section 4.2, paragraph 1, comment:
>> 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.

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

As for my arguments, let me copy here my answer to Roman:

---
Yes, this section is a stub. The performance analysis of the most 
important free software implementation of the IPv4aaS technologies is in 
progress, but it would need about 2-3 more years, and we decided not to 
wait for such a long time, but rather publish the current draft as an 
RFC to assist the operators with a stable document.

However, I still believe that performance can be an important issue. As 
a illustration, perhaps very few people are aware of the fact that the 
de facto industry standard BIND DNS server is lagging behind the 
performance of Knot DNS or NSD. They 10 times outperfomed BIND in 
authoritative DNS performance, when really LARGE zone files were used:

G. Lencse, "Benchmarking Authoritative DNS Servers", /IEEE Access/, vol. 
8. pp. 130224-130238, July 2020. DOI: 10.1109/ACCESS.2020.3009141
https://ieeexplore.ieee.org/document/9139929 (open access)

Similar differences may exist in the performance of the IPv4aaS 
implementations. And performance may be a decision factor. So I would 
like to make people aware of this issue now and give the readers a 
pointer for the measurement results to be published later.

Unfortunately, draft-lencse-v6ops-transition-benchmarking has been 
expired, because I did not have time to deal with it, but I hope to be 
able to publish the 01 version with some actual results in a few weeks.

---

> The datatracker state does not indicate whether the consensus boilerplate
> should be included in this document.

I have no idea. Perhaps the WG chairs can do it.

> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language  for background and more
> guidance:
>
>   * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
>     "intrinsic", "original"
>
> Thanks to Dan Romascanu for their General Area Review Team (Gen-ART) review
> (https://mailarchive.ietf.org/arch/msg/gen-art/0LD7N9OxJR4KupJKbaISQ9518ng).
Unfortunately, I am not a native speaker of English. (Neither Jordi is, 
who did the previous revision.)

> -------------------------------------------------------------------------------
>
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (viahttps://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives.

Thank you very much for disclosing this tool. It will be useful for 
other drafts, too! :-)

> There is no need to let me know what you
> did with these suggestions.
>
Of course, I have corrected them. :-)

Once again, thank you for your review and suggestions!

Best regards,

Gábor Lencse