Throughput rule Download Time is zero

[Yanev research]

Hi,

 I have been experimenting with dash.js 4.0.0 and 3.1.3 and in both I have observed behaviour that I cannot explain w.r.t. the download time calculation.

I can see that the download time is calculated by taking the difference between when the first and last bytes of the response were received. My issue is that the browser (firefox 90.0.2) will sometimes get identical timestamps for those two, i.e., httpRequest._tfinish.getTime() - httpRequest.tresponse.getTime() 

will be 0. Leading to an artificially high throughput estimate for this video chunk.

I have also been running tcpdump while this was happening and I can see that the first and last bytes were not received at the same time and have different timestamps. I understand that tcpdump reports timestamps as the kernel sees the packets and the browser's timestamps are when the kernel releases those packets to the user space. In all cases there is a difference between the two, but mostly that difference is the same for both the first and last bytes.... With the exception of when the browser sees them at the same time.

So my questions are:

1. Is this behaviour known/expected?
2. Is there a way to prevent it? I see that the source has a sanity check part where it will make the download time = 1 if it happened to be reported to be 0. I thought that this was there for small segments on a fast link or otherwise if the whole chunk could fit within one packet. Was the motivation behind this piece of code that or is it the issue I have encountered now?
3. I know the throughput value that is used to determine the next chunk quality is smoothened by applying data for the previous X segments, but would it be better if such unrealistic outliers were dropped from the throughput history altogether?

Misc:
Details of my setup are as follows:

1. Server and client are nodes within a Mininet network emulator.
2. There is a bottleneck link between the client and the server: capacity - 145 Mbps, RTT: 40ms
3. Streamed video is encoded in four representations with 0.44 2.64 4.82 12.96 Mbps demands respectively.
4. There is no other traffic on the network

Mihail