Matt,
-----Original Message-----
From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On
Behalf
Of Matthias Grossglauser
Sent: Monday, November 22, 2004 1:07 PM
To: psamp@ops.ietf.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. I
will
send 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?
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.
>>>
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 fall
into
to 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, but
it
could 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 be
communicated
! periodically, and upon change.
--- 1112,1118 ----
expected to be relatively static; they could be
communicated
! periodically, and upon change.
!
! SHOULD WE MAKE IT EXPLICIT THAT OBERSVATION POINT,
MEASUREMENT
! PROCESS AND EXPORTING PROCESS IDS SHOULD BE CONTAINED IN
EVERY
! PACKET REPORT?
Since an export packet may contain multiple packet reports, the
export
process 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 Export
Packet
drop 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 might
be
desirable 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 information
concerning the packet treatment being available at line rate for
selection
of packets. For example, the Selection Process may not be implemented
in
the fast path that is able to access routing state at line rate.
However,
when filtering follows sampling in a Composite Selector, the rate of
the
Packet 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 limit
it
to 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 filtering
In 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 even
if
there are ZERO Packet Reports pending, for this EP to act as a
heartbeat
packet to signal to the collector that connectivity is ok. This would
allow the collector to distinguish between an absence of traffic at
the
PSAMP 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 psamp-request@ops.ietf.org 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 psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>