One point in-line.
That's a good point. Selecting one of a small group of buffered packets seems like an interesting possibility. We should not disallow this within PSAMP, thus perhaps we should remove the Non-Contingency requirement.Matt,-----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] OnBehalfOf Matthias Grossglauser Sent: Monday, November 22, 2004 1:07 PM To: firstname.lastname@example.org Subject: Re: some comments on draft-ietf-psamp-framework-09.txt Folks, I think the document is in very good shape. A few comments below. Iwillsend a list of minor typos directly to the editor. Matt- page 11, Section 4.1: bullet "*" is missing in "Non-Contingency". Also, the term "non-contingency" seems a bit strange.A good term might be "causality".Or "adapted": borrowing from the terminology of stochastic processes we could say that selection is adapted to the packet stream, in the sense that selection of a given packet depends only on previous packets, if at all. I wonder now if this is too strong: it's conceivable one might, in some future selector not yet standardized, want to buffer a few packets before deciding which one of them to select, as long as resources are available to buffer. The strict adaptiveness might have been a good thing were psamp to have some mandatory selectors, but now it doesn't. Comments?
>>> Regarding the discussion of "attacks" against hash-based PSAMP by crafting packets, let me refer back to a comment a made a while ago: https://www.psg.com/lists/psamp/psamp.2002/msg00170.html Basically, if the attacker does not know which hash function in the family is active, then this provides *stronger* protection than if the attacker knows the hash function, but not the range it has to fallintoto get sampled. This might be worth pointing out. It is alluded to the in draft by saying that there can be a family of hash functions, butitcould perhaps be strengthened by pointing out that this provides additional robustness against crafted packets.See the proposed additional sentence from my response to Derek Chiou, i.e., "Privacy of hash selection range and hash function parameters (although not the hash function itself) obstruct subversion of the selector by packets that are crafted either to avoid selection or to be selected"****************** 1112,1114 **** expected to be relatively static; they could becommunicated! periodically, and upon change. --- 1112,1118 ---- expected to be relatively static; they could becommunicated! periodically, and upon change. ! ! SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT,MEASUREMENT! PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED INEVERY! PACKET REPORT?Since an export packet may contain multiple packet reports, theexportprocess id can be included once per export packet.Did we say anywhere that exporting process IDs are included? Note that this is important to enable the collector to estimate the ExportPacketdrop rate under unreliable transport to drive a congestion-control algorithm; the finer per-report IDs are not necessarily sufficient for this, I think. Of course, in most situations the underlying unreliable transport protocol would have sequence numbers already, but it mightbedesirable to have a transport-independent EP numbering for layer independence.I agree it would be good to make this explicit, and not assume export sequence numbers are provided by the transport layer.How about: Router architectural considerations may preclude some informationconcerning the packet treatment being available at line rate forselectionof packets. For example, the Selection Process may not be implementedinthe fast path that is able to access routing state at line rate.However,when filtering follows sampling in a Composite Selector, the rate ofthePacket Stream output from the sampler and input to the filter may be sufficiently slow that the filter could select based on routing state.The thinning could have happened through another filter also (e.g., based on a packet field), couldn't it? So perhaps we should not limititto sampling. How about "However, if in a Composite Selector, filtering based on routing state is preceded by at least one other Selector, the rate of the input to that filter may be...".See separate message on filteringIn order to limit delay in the formation of Export Packets, the Exporting Process must provide the ability to close out and enqueue for transmission any Export Packet during formation as soon as it includes one Packet Report.It may make sense to allow for an Export Packet to be generated evenifthere are ZERO Packet Reports pending, for this EP to act as aheartbeatpacket to signal to the collector that connectivity is ok. This would allow the collector to distinguish between an absence of traffic atthePSAMP device and loss of connectivity.Some transport protocols do this already, e.g. SCTP manages interface failover using heartbeats. But we can't assume transport provides it (e.g. if UDP is used), in which case PSAMP should. I can add a sentence on this. Nick-- to unsubscribe send a message to email@example.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/psamp/>-- to unsubscribe send a message to firstname.lastname@example.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/psamp/>