REVIEWER C
----------

Review of the manuscript titled "Improved Bandwidth estimation using the IPv6 hop-by-hop extension header”, authored by M. Crocker, et al 

The goal of the paper is to describe a method to accurately and efficiently determine the available network bandwidth on a path that uses IPv6 protocol. 

The paper is well-written and very easy to read. It does a good job of presenting a complete piece of work. Adding timestamp option to IPv6 and using the algorithm proposed in the paper will help in estimating available and bottleneck bandwidth. However, one thing that author did not consider is that several routers will process IPv6 packets with options as exceptions and therefore they might be slower than normal traffic. This might result in errors in bandwidth estimations. Authors did mention that this is a problem with IPv4 options but they did not discuss why they don’t think this will be an issue for IPv6.  In particular, IPv6 option processing is designed for off-fast-apth handling of such a traffic. Secondly, creating a complete new IPv6 option is a big change, especially, when IPv6 is already deployed in several places. Even if the option is approved by IETF, its adoption might be very limited.

Section II A definitions – bottleneck bandwidth is the “minimum” bandwidth and not the “maximum” bandwidth

Section II B and C  – for the related work, authors do not explain why they think these methods do not work well. Simply saying “none of the methods currently in use can consistently and accurately ..” is not enough. They do account for statistical variations and errors, so what is missing in them? 

Section II C – the figure needs to have an arrow going into the router before one goes out


Section III A – reality is that, very few packets in today’s IPv4 networks get fragmented as some measurement studies have shown 

Again, a very qualitative assertion is made about improved bandwidth estimation in an IPv6 networks. Was this verified by doing some comparisons in simulations or otherwise?

Bottleneck bandwidth estimation – this scheme cannot guarantee back-to-back queuing. In that case, an undetermined number of repeated test must be done before two packets are sent back-to-back – however, did you do some experimental study to verify your assumptions? 

The description of “resolution” in page 9 seems to be incorrect. It should be “For a low resolution where the timestamp is in units greater than 1 ms, then G=0 and the timestamp is divided by resolution to get the timestamp in units of ms”.

Recommendation – I would give this paper a “weak accept” – I am not sure the changes suggested for IPv6 and ICMP are quite difficult to be adopted in general practice.