Re: IPv6 traffic percentages?
jokes aside, Its a hypothesis worth testing. It has qualities which make it plausible.
So please, between you, find a way to specify and test it!
although the hypothesis has some intuitive appeal, how to test it is far from obvious. and i note that, as a senior member of the measurement community, you're saying "you guys do it." thanks a lot. :) i considered rtt from a service such as goog to their querriers. there are the problems of their distributed caches, the politics of getting their data, and the eyeball bias. maybe find a platform with less of those biases. dns is far too biased in all sorts of dimensions. your add clicks? i have found no usable coffee here in nagoya, so i may be missing something obvious. randy
On Thu, Jan 21, 2016 at 09:48:19AM +0900, Randy Bush wrote:
jokes aside, Its a hypothesis worth testing. It has qualities which make it plausible.
So please, between you, find a way to specify and test it!
although the hypothesis has some intuitive appeal, how to test it is far from obvious. and i note that, as a senior member of the measurement community, you're saying "you guys do it." thanks a lot. :)
i considered rtt from a service such as goog to their querriers. there are the problems of their distributed caches, the politics of getting their data, and the eyeball bias. maybe find a platform with less of those biases. dns is far too biased in all sorts of dimensions. your add clicks? i have found no usable coffee here in nagoya, so i may be missing something obvious.
Looking at my employers network... We know the GPS coordinates for each BGP next-hop in the network, and traffic is sampled on ingress at the edge of the network and reported to pmacct (*flow), which also receives a RR-style BGP feed for correlation. We can know where (geographically) a packet enters the network, where it leaves the network and to what address family it belongs. However, this would be just one network's (biased) view on things.
We know the GPS coordinates for each BGP next-hop in the network, and traffic is sampled on ingress at the edge of the network and reported to pmacct (*flow), which also receives a RR-style BGP feed for correlation.
We can know where (geographically) a packet enters the network, where it leaves the network and to what address family it belongs.
i have only seen pmacct used for aggregated flow/traffic. you actually know where each packet enters and leaves? randy
On Thu, Jan 21, 2016 at 11:00:46PM +0900, Randy Bush wrote:
We know the GPS coordinates for each BGP next-hop in the network, and traffic is sampled on ingress at the edge of the network and reported to pmacct (*flow), which also receives a RR-style BGP feed for correlation.
We can know where (geographically) a packet enters the network, where it leaves the network and to what address family it belongs.
i have only seen pmacct used for aggregated flow/traffic. you actually know where each packet enters and leaves?
No, not each individual packet. That's too much data. (Taking into consideration that anything reported through flowbased telemetry to the pmacct instances is heavily sampled) You can configure pmacct to specify on which properties of the received flow data it should aggregate its output data, one could configure pmacct to store data using the following primitives: ($timeperiod, $entrypoint_router_id, $bgp_nexthop, $packet_count) Where $timeperiod is something like 5 minute ranges, and the post processing software calculates the distance between the entrypoint router and where the flow would leave the network ($bgp_nexthop). See 'aggregate' on http://wiki.pmacct.net/OfficialConfigKeys In short: you configure pmacct to throw away everything you don't need (maybe after some light pre-processing), and hope that what remains is small enough to fit in your cluster and at the same time offers enough insight to answer the question you set out to resolve. Kind regards, Job
You can configure pmacct to specify on which properties of the received flow data it should aggregate its output data, one could configure pmacct to store data using the following primitives:
($timeperiod, $entrypoint_router_id, $bgp_nexthop, $packet_count)
Where $timeperiod is something like 5 minute ranges, and the post processing software calculates the distance between the entrypoint router and where the flow would leave the network ($bgp_nexthop).
See 'aggregate' on http://wiki.pmacct.net/OfficialConfigKeys
In short: you configure pmacct to throw away everything you don't need (maybe after some light pre-processing), and hope that what remains is small enough to fit in your cluster and at the same time offers enough insight to answer the question you set out to resolve.
it's late here, so i am a bit slower than usual. but could you explain in detail how this tests the hypothesis? even of all your traffic entered on a bgp hop and exited on a bgp hop, and all bgp entries set next_hop (which i think you do), you would be ignoring the 'distance' the packet traveled from source to get to your entry and traveled from your exit to get to the final destination. randy
On Thu, Jan 21, 2016 at 11:44:34PM +0900, Randy Bush wrote:
You can configure pmacct to specify on which properties of the received flow data it should aggregate its output data, one could configure pmacct to store data using the following primitives:
($timeperiod, $entrypoint_router_id, $bgp_nexthop, $packet_count)
Where $timeperiod is something like 5 minute ranges, and the post processing software calculates the distance between the entrypoint router and where the flow would leave the network ($bgp_nexthop).
See 'aggregate' on http://wiki.pmacct.net/OfficialConfigKeys
In short: you configure pmacct to throw away everything you don't need (maybe after some light pre-processing), and hope that what remains is small enough to fit in your cluster and at the same time offers enough insight to answer the question you set out to resolve.
but could you explain in detail how this tests the hypothesis?
even of all your traffic entered on a bgp hop and exited on a bgp hop, and all bgp entries set next_hop (which i think you do), you would be ignoring the 'distance' the packet traveled from source to get to your entry and traveled from your exit to get to the final destination.
Yes, correct. This is why I mentioned before: "However, this would be just one network's (biased) view on things." With this I meant that I can measure something, but only within a subset of the entire path a packet might traverse. (just that one routing domain), so not end-to-end. And what might be true for us might not be true for others.
With this I meant that I can measure something, but only within a subset of the entire path a packet might traverse.
considering your original hypothesis was about length of paths, this seems a kind of dead end. you might get a modest improvement by turning off hot potato :)
so not end-to-end
which is the problem
And what might be true for us might not be true for others.
yes. but if it actually measured what we wanted, it would be a useful measurement. but it doesn't. randy
participants (2)
-
Job Snijders -
Randy Bush