Il giorno 27/apr/2015, alle ore 12:23, Toke Høiland-Jørgensen <[email protected]> ha scritto:
> Paolo Valente <[email protected]> writes: > >> 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. > > No, not unless the application tells you (by, for instance, > timestamping; depending on where in the network stack the timestamp is > applied, you can measure different instances of bloat). That’s exactly what I was thinking about. Actually it seems the only solution to me. What apparently makes things more difficult is that I am not allowed either to choose the applications to run or to interfere in any way with the flows (e.g., by injecting some extra packet). Any pointer to previous/current work on this topic? > Or if you know > that an application is supposed to answer you immediately (as is the > case with a regular 'ping'), you can measure if it does so even when > otherwise loaded. > A ping was one of the first simple actions I suggested, but the answer was, as above: no you cannot ‘touch' the network! > Of course, you also might not measure anything, if the bottleneck is > elsewhere. But if you can control the conditions well enough, you can > probably avoid this; just be aware of it. In Linux, combating > bufferbloat has been quite the game of whack-a-mole over the last > several years :) > Then I guess that now I am trying to build a good mallet according to the rules of the game for this company :) In any case, the target networks should be observable at such a level that, yes, all relevant conditions should be under control (if one does not make mistakes). My problem is, as I wrote above, to find out what information I can and have to look at. 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/ _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
