Il giorno 27/apr/2015, alle ore 12:10, Paolo Valente <[email protected]> 
ha scritto:

> 
> Il giorno 27/apr/2015, alle ore 11:57, Toke Høiland-Jørgensen <[email protected]> 
> ha scritto:
> 
>> Paolo Valente <[email protected]> writes:
>> 
>>> a network-monitoring company got curious about bufferbloat issues and
>>> asked me to investigate a little bit the following issue (quite
>>> interesting in my opinion). Is it possible to detect, from outside a
>>> node, if the node is bufferbloated? In particular, the only action
>>> allowed would be to observe the packets entering and leaving the node
>>> (plus, of course, their timing).
>> 
>> Sure. Just measure the timing when the network is unloaded and compare
>> it to when it is loaded to capacity. We do that all the time.
>> 
>> The details of course depend on what you define by a 'node', what role
>> it plays in the network (does it forward or originate packets?), and
>> what control you have over the traffic flowing through it. :)
>> 
> 
> Let us consider, for example, a host with a VoIP call and a large-file 
> transfer in progress. My concern is: from inside the host, we can measure the 
> delays experienced by the VoIP application, but, form outside, how can we 
> detect that the application is experiencing a high latency, or, indirectly, 
> that there is bufferbloat and hence that the application is likely to be 
> experiencing a high latency? (Of course, I am also about to read the 
> documents suggested by Neil.)
> 

I am sorry, but I realized that what I said was incomplete. The main cause of 
my concern is that, from outside the node, we do not know whether a VoIP packet 
departs ad a given time because the application wants it to be sent at that 
time or because it has waited in the buffer for a lot of time. Similarly, we do 
not know how long the VoIP application will wait before getting its incoming 
packets delivered.

Of course, if a bufferbloated state can be measured by other external 
measurements, then we can infer the problem indirectly.

Are there flaws in my above considerations?

Thanks,
Paolo

> Thanks,
> Paolo
> 
>> -Toke
> 
> 
> --
> Paolo Valente                                                 
> Algogroup
> Dipartimento di Fisica, Informatica e Matematica              
> Via Campi, 213/B
> 41125 Modena - Italy                                    
> homepage:  http://algogroup.unimore.it/people/paolo/


--
Paolo Valente                                                 
Algogroup
Dipartimento di Fisica, Informatica e Matematica                
Via Campi, 213/B
41125 Modena - Italy                                      
homepage:  http://algogroup.unimore.it/people/paolo/

_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat

Reply via email to