SSU data packet ACK bitfield notes

Transport notes

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

@@ -913,6 +913,14 @@ the message ID must be an actual random number.
 Because there are no sequence numbers, there is no way to be sure an ACK was received.
 The current implementation routinely sends a large amount of duplicate ACKs.
 Duplicate ACKs should not be taken as an indication of congestion.
+</li><li>
+ACK Bitfield notes:
+The receiver of a data packet does not know how many fragments are in the message unless it has
+received the last fragment. Therefore, the number of bitfield bytes sent in response may be less or
+more than the number of fragments divided by 7.
+For example, if the highest fragment the receiver has seen is number 4, only
+one byte is required to be sent, even if there may be 13 fragments total.
+Up to 10 bytes (i.e. (64 / 7) + 1) may be included for each message ID acked.
 </li></ul>
 
 

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

 {% extends "global/layout.html" %}
 {% block title %}{% trans %}Transport Overview{% endtrans %}{% endblock %}
-{% block lastupdated %}{% trans %}December 2013{% endtrans %}{% endblock %}
-{% block accuratefor %}0.9.9{% endblock %}
+{% block lastupdated %}{% trans %}September 2014{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.15{% endblock %}
 {% block content %}
 <h2>{% trans %}Transports in I2P{% endtrans %}</h2>
 
@@ -39,6 +39,7 @@ Reliable delivery of <a href="{{ i2np }}">I2NP</a> messages.
 Transports support I2NP message delivery ONLY.
 They are not general-purpose data pipes.
 {%- endtrans %}</li>
+<li>{% trans %}In-order delivery of messages is NOT guaranteed by all transports.{% endtrans %}</li>
 <li>{% trans -%}
 Maintain a set of router addresses, one or more for each transport,
 that the router publishes as its global contact information (the RouterInfo).
@@ -80,6 +81,10 @@ These addresses constitute the advertised contact points, and are published by t
 Addresses may also contain an arbitrary set of additional options.
 {%- endtrans %}</p>
 
+<p>{% trans -%}
+Each transport method may publish multiple router addresses.
+{%- endtrans %}</p>
+
 <p>{% trans %}Typical scenarios are:{% endtrans %}
 <ul>
 <li>{% trans %}A router has no published addresses, so it is considered "hidden" and cannot receive incoming connections{% endtrans %}</li>
@@ -145,6 +150,7 @@ Additional transports may be developed, including:
 <ul>
 <li>{% trans %}A TLS/SSH look-alike transport{% endtrans %}</li>
 <li>{% trans %}An "indirect" transport for routers that are not reachable by all other routers (one form of "restricted routes"){% endtrans %}</li>
+<li>{% trans %}Tor-compatible pluggable transports{% endtrans %}</li>
 </ul>
 
 <p>{% trans -%}