Re: PSAMP framework open issues

[Andy Bierman <abierman@cisco.com>]

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

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