RE: some comments on draft-ietf-psamp-framework-09.txt

[<duffield@research.att.com>]

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?



> 
>  >>>
> 
> 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/>