Re: PSAMP framework open issues

[Maurizio Molina <molina@ccrle.nec.de>]

Andy Bierman wrote:

> At 09:17 PM 11/12/2003, duffield@research.att.com wrote:
>  
>
> > Hi,
> >
> > Here are the remaining open issues for the framework draft. Please send
> > comments to the list by December 5.
> >
> > Thanks,
> >
> > Nick
> >
> > ----
> >
> > FW-1 Encryption for export
> >  . Problem: what is the conformance level?
> >  . Proposed Solution: mandatory to implement and optional to use. This
> >
> >    was required by the IESG for IPFIX. PSAMP requirements at least as
> >
> >    strong, due to possibility of payload fragments in reports.
> >    
>
> agreed
>
>
>  
>
> > FW-2 Timestamps
> >  . Problem: should PSAMP require certain resolution or accuracy?
> >  . Proposed Solution: require microsecond resolution (as for IPFIX);
> >    no requirement for accuracy, but it should be reported. 
> >    
>
>
> How about:
>   SHOULD require microsecond resolution
>   MUST report clock attributes
>    -- the IPPM-REPORTING-MIB has some good MIB objects for clock
>       attributes. 
>   
>
>  
>
> >  . Question: How should it be reported (e.g., numerical accuracy,
> >    synchronization method, ...)?
> >    
>
> How about:
>    MUST export parameters via IPFIX (with PSAMP info model)
>    SHOULD export parameters via SNMP
>    MAY allow configuration via SNMP
>
>
>  
>
> > FW-3 Selecting Encrypted Packets
> >  . Problem: Encryption key is not generally available. Content
> >    dependent selection problematic since encrypted fields lose
> > meaning.
> >    How should selection of encrypted packets be modified, if at all?
> >  . Question: what forms of encryption can be detected from packet?
> >  . Proposed Solution:
> >    - for filtering and content dependent sampling: option to
> >      ignore encrypted packets (if detectable ...)
> >    
>
> How about:
>    MAY skip encrypted packets during sample selection
>    MUST export value via IPFIX
>    SHOULD export value via SNMP
>    MAY allow configuration via SNMP
Andy,
I don't understand if you propose this requirement subdivision for all 
the parameters defined in the info model or not.
If yes, I'd have a problem with the SHOULD for exporting values also 
through SNMP, when these values are packet samples (i.e. values that 
would fit in an IPFIX data flow record). I think that in this case a MAY 
is more appropriate.
If these values are configuration parameters (i.e. values that would fit 
in an IPFIX options data record) I have a less stronger opinion, but I'd 
prefer a MAY anyway.
Maurizio

>  
>
> >  . Comments:
> >    - not needed for content-independent sampling 
> >    - not needed for hash-based selection ( it emulates /
> >      approximates content-independent sampling) unless trajectory 
> >      sampling with encryption taking place at point between      
> >      observation points) 
> >    
> >
> > FW-4 Reporting Input Sequence Numbers
> >  . Problem: should the sequence numbers be in every report, or just 
> >    sent periodically in report interpretation?
> >  . Proposed Solution: send in every report (probably yields more 
> >    information for diagnosis under high load conditions with packets)
> >    
>
> Agreed -- send in every report if requested by the IPFIX template
>
>
>  
>
> > FW-5 Timeliness  
> >  . Problem: some applications (e.g. some security
> >    applications) will need to receive packet reports within a few
> >    seconds of observation rather than (say) a minute afterwards. How
> >    to specify this in the protocol? Can't easily control delay due to
> >    resource contention e.g. if users chose to run at routers at high
> >    load (although possible). More control over buffering delay.
> >  . Proposed Solution: 
> >    - mandatory ability to set maximum buffering delay in forming
> > export          packets (including 0, meaning one packet report per
> > export packet)
> >    - mandatory ability to set maximum export buffer delay in transport
> >
> >      protocol (else discard; it appears that SCTP-PR can provide this)
> >    
>
> both proposals sound good
>
>
>
>
>  
>
> > --
> > 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/> 
> >    
>
> Andy
>
>
> --
> 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/>