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