you rang? :)
I'll refrain from wider comment on the current revision of the document; I
think the authors continue to receive good feedback on its scope and structure,
and I'll have a look during next last call.
Section 2.2 seems to be lumping together three things which aren't necessarily
related: longitudinal studies of Internet traffic for operational and academic
purposes, traffic matrix generation (a specific operational measurement purpose
which has received a good deal of academic attention), and application
classification / aggregation by application-layer semantics. The first two of
these do use similar inputs (e.g. IPFIX data aggregated to the per-layer-4-flow
level at the finest), but require application-layer data only if they
additionally classify or aggregate traffic at the application layer.
For example, a simple traffic matrix might use IP packet and octet counts
aggregated by prefix, and requires only IP-layer data to generate. A matrix
focused on isolating transport-layer performance problems would need to
estimate TCP parameters for each flow or group of flows, using TCP headers
(typically TCP flags, sequence and acknowledgment numbers, as well as
timestamps if available) in addition to IP headers to generate loss,
retransmission, and RTT statistics. A more detailed matrix still could classify
traffic as belonging to a specific application through application-layer header
and payload inspection.
It's true that each layer you encrypt reduces the utility of passive
measurement to determine certain things. For example, a study trying to
estimate the amount of streaming video over a given link can do this much more
easily and with higher fidelity by inspecting HTTP headers than it can by
applying heuristics to the time-series of interpacket times and packet sizes.
It's true that the inferences made in a measurement will have to get more
clever as the amount of observable data decreases, and those inferences may be
so weak as to make a particular measurement useless. But it's not true that
these studies always need application-layer headers or payload, or even
transport layer headers for the simplest matrices.
One note on the text here: "CAIDA" isn't one data set, they run many projects,
many of which are active (e.g. Archipelago, which does various topology
measurements); the best-known passive facility, the CAIDA darkspace telescope,
surveys background radiation, and mainly catches backscatter. The
application-layer semantics of which are either necessarily in cleartext
(because there exists no cryptographic context to encrypt a backscatter reply
to garbage) or irrelevant, so increasing encryption shouldn't cause a problem
there.
Cheers,
Brian
On 02 May 2017, at 05:04, Randy Bush <randy(_at_)psg(_dot_)com> wrote:
For example, Section 2.2 talks about the importance of passive
monitoring for traffic surveys, but fails to discuss alternative means
possibly our friends from zürich have some ideas here
randy
signature.asc
Description: Message signed with OpenPGP using GPGMail