Telechat Review of draft-ietf-manet-credit-window-07
review-ietf-manet-credit-window-07-tsvart-telechat-scharf-2016-12-14-00

Hi,

I've reviewed this document as part of TSV-ART's ongoing effort to review key
IETF documents. These comments were written primarily for the transport area
directors, but are copied to the document's authors for their information and
to allow them to address any issues raised. When done at the time of IETF Last
Call, the authors should consider this review together with any other last-call
comments they receive. Please always CC tsv-art@ietf.org if you reply to or
forward this review.

This draft is on the right track but has open issues, described in the review.

TSV-ART review comments:

* Page 2: "The capacity of an Ethernet link is normally far superior to that of
the wireless medium... " That statement is not generally true, e.g., certain
wireless technologies can outperform Fast Ethernet (100 Mbps). This sentence
should probably be rephrased to something like "This document focuses on
deployments in which the link between a router and a modem has always a higher
capacity than the wireless medium".

* Page 3 and 4: It is unclear why the flow control MUST be used in both
directions between a router and modem. An explanation on this design choice
would make a lot of sense. Specifically, I don't understand why flow control
for the traffic direction from the modem to the router is really needed in all
cases, e.g., if the wireless medium is the bottleneck.

* Page 5: "The number of credits needed for a given transmission is the length
of the data portion of the packet at the MAC layer." This statement is vague.
Implementers of the protocol in the router and in the modem would have to
exactly agree how to consume credits. So, what is exactly meant by "data
portion"? One example how to improve this section would be to explain this at
the example of Ethernet MTU, as one example for a MAC layer.

* Page 7: "Operational credit mismatches can occur due to (data) packets in
transit on the wire, or sequencing of sending and receiving packets". I believe
that mismatch can also occur if packets get lost, e.g., because of corruption
or because of (unexpected) congestion on the link between the router and the
modem. That situation may be infrequent but still has to be taken into account
at least as a corner case.

Other comments:

* It is a bit surprising that the document does not discuss potential
challenges and downsides of the flow control scheme. For instance, if the RF
link capacity rapidly changes, what is the benefit of this flow control? In
this case, it will be challenging e.g. for a modem to calculate a credit grant.
If the credit grant is too high, packets may be dropped at the modem, but this
would happen without flow control, too. If the credit grant is too low, the
capacity may not be fully utilized. Also, if the credits are granted at a time
scale of the transport protocol congestion control (e.g., TCP), interactions
between the DLEP flow control and the congestion control could occur. Problems
can probably be avoided if the credit mechanism operates at a time scale much
below the end-to-end RTT seen by the transport protocol. This sort of issues
does not necessarily affect the protocol specification itself, though.

* Somehow related, the benefits of using the flow control defined in the
document could also be better explained. For instance, as long as the bandwidth
on the wireless link is not fluctuating too much, end-to-end congestion control
(e.g., in TCP) should avoid overloading the wireless link. An additional flow
control may not necessarily be needed in such case. There may be benefits in
other cases, maybe e.g. for multicast traffic, but all in all the document does
not motivate well why this DLEP protocol extension is really needed.

* Page 3 and later. The references to the IANA registries defined in
draft-ietf-manet-dlep-25 seem not fully consistent. For instance, page 12
states: 'This specification defines three (3) new entries in the repository
entitled "Data Item Type Values for the Dynamic Link Exchange Protocol
(DLEP)"'. It seems that this registry is named "Data Item Values" in
draft-ietf-manet-dlep-25.

Nits:

* Page 4: "reciver"

* Pae 7: "synchrnoization"

Thanks

Michael