SSU: Update future work section

i2p2www/pages/site/docs/transport/ssu.html

@@ -1,6 +1,6 @@
 {% extends "global/layout.html" %}
 {% block title %}{% trans %}Secure Semireliable UDP{% endtrans %} (SSU){% endblock %}
-{% block lastupdated %}2022-05{% endblock %}
+{% block lastupdated %}2022-06{% endblock %}
 {% block accuratefor %}0.9.54{% endblock %}
 {% block content %}
 
@@ -625,6 +625,7 @@ If the router is hidden, '4' and '6' may be combined in a single address.
 </dl>
 
 <h1><a name="future">{% trans %}Future Work{% endtrans %}</a></h1>
+Note: These issues will be addressed in the development of SSU2.
 <ul>
 <li>{% trans -%}
 Analysis of current SSU performance, including assessment of window size adjustment
@@ -648,7 +649,7 @@ The protocol should be extended to exchange MTUs during the setup.
 {%- endtrans %}</li>
 
 <li>{% trans -%}
-Rekeying is currently unimplemented and may never be.
+Rekeying is currently unimplemented and will never be.
 {%- endtrans %}</li>
 
 <li>{% trans -%}
@@ -656,26 +657,12 @@ The potential use of the 'challenge' fields in RelayIntro and RelayResponse,
 and use of the padding field in SessionRequest and SessionCreated, is undocumented.
 {%- endtrans %}</li>
 
-<li>{% trans -%}
-Instead of a single fragment per packet, a more efficient
-strategy may be to bundle multiple message fragments into the same packet,
-so long as it doesn't exceed the MTU.
-{%- endtrans %}</li>
-
 <li>{% trans -%}
 A set of fixed packet sizes may be appropriate to further hide the data 
 fragmentation to external adversaries, but the tunnel, garlic, and end to 
 end padding should be sufficient for most needs until then.
 {%- endtrans %}</li>
 
-<li>{% trans -%}
-Why are introduction keys the same as the router hash, should it be changed, would there be any benefit?
-{%- endtrans %}</li>
-
-<li>{% trans -%}
-Capacities appear to be unused.
-{%- endtrans %}</li>
-
 <li>{% trans -%}
 Signed-on times in SessionCreated and SessionConfirmed appear to be unused or unverified.
 {%- endtrans %}</li>