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@xxxxxxx> 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 >
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail