[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Nick,

One point in-line.


duffield@research.att.com wrote:
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/>