Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 PSAMP WGIETF, November 2003PSAMP WG PSAMP Framework Document draft-ietf-psamp-framework-04.txt Duffield, Greenberg, Grossglauser, Rexford: AT&T Chiou:

Similar presentations


Presentation on theme: "1 PSAMP WGIETF, November 2003PSAMP WG PSAMP Framework Document draft-ietf-psamp-framework-04.txt Duffield, Greenberg, Grossglauser, Rexford: AT&T Chiou:"— Presentation transcript:

1 1 PSAMP WGIETF, November 2003PSAMP WG PSAMP Framework Document draft-ietf-psamp-framework-04.txt Duffield, Greenberg, Grossglauser, Rexford: AT&T Chiou: Avici Claise, Marimuthu, Sadasivan: Cisco

2 2 PSAMP WGIETF, November 2003PSAMP WG Changes and Open Issues

3 3 PSAMP WGIETF, November 2003PSAMP WG Title  OLD: A Framework for Passive Packet Measurement  NEW: A Framework for Packet Selection and Reporting  Better reflects main contributions of psamp  Avoid “sampling”: suggests only statistical sampling

4 4 PSAMP WGIETF, November 2003PSAMP WG Packet Selection: Encrypted Packets  Packet encryption will make general PSAMP difficult,  the encryption key will not generally be available.  Default to packet selection based on non-encrypted parts  Sampling OK,  Other selectors difficult

5 5 PSAMP WGIETF, November 2003PSAMP WG Packet Selection Terminology  Use one type of sampling to implement another  Example: hash-based selection in place of random selection  OLD Terminology: Emulated Selection  Objection: quality of emulation can vary  Example: stronger hash function gives closer to random sampling some packet could evade sampling if hash function weak  NEW Terminology: Approximative Selection

6 6 PSAMP WGIETF, November 2003PSAMP WG Reporting  Motivation: probably 2 kinds of PSAMP capable devices 1.Low end, just do mandatory reporting, e.g., 1 in N sampling only 2.High end: big router, IPFIX capable  Mandatory Reporting  Input packet sequence numbers used by application to determine attained selection rate  Option to include some number of bytes from start of packet Probably don’t want to send if doing extended reporting  Extended Reporting  now a MAY  “If IPFIX is supported at the observation point, then in order to be PSAMP compliant, extended packet reports MUST be able to include all fields required in the IPFIX information model, with modifications appropriate to reporting on single packets rather than flows.”

7 7 PSAMP WGIETF, November 2003PSAMP WG Reporting Sequence Numbers  Role of sequence numbers:  Indicate absence of information  Export packet sequence numbers  Indicate rate of loss in transmission Attained_transmission_rate = diff_received_seqno/diff_export_seqno  Input packet sequence numbers  Indicate end-to-end sampling loss rate from observation to collection End_to_end_selection_rate = diff_received_seqno/diff_input_seqno  Used to renormalize measured bytes Estimated_actual_bytes = Samped_bytes / End_to_end_selection_rate  New Issue:  Include input sequence numbers in each packet report?  Or send periodically in report interpretation?

8 8 PSAMP WGIETF, November 2003PSAMP WG Export Terminology  OLD: measurement packets  NEW: export packet

9 9 PSAMP WGIETF, November 2003PSAMP WG Export Requirements: Confidentiality  Confidentiality: = option to encrypt export packets  Should availability of option be MUST or SHOULD?  WG Discussion  IETF 57: WG meeting favored MUST  Mailing list: some comments that MUST is too strong  Argument for encryption  Some initial part of payload may be included (unlike IPFIX)  IPFIX now a MUST after IESG review; same considerations apply to PSAMP  Arguments against mandatory ability to encrypt  Export will often take place over secure networks (e.g. within service provider)  Implementation cost Software / hardware  Need to reach WG consensus

10 10 PSAMP WGIETF, November 2003PSAMP WG Export Requirements: Timeliness  Motivation:  want to export packet reports “ASAP”  Source of delay:  resource contention, export buffering  Aim for draft:  State maximum delay based on application needs  SHOULD requirement (you’d better have good reason for breaking it)  Application:  Matching up reports on same packet from several observation points Passive measurement of loss, delay  Requirements: 1.Need to buffer reports at collector prior to matching Suggestion that 30 second delay tolerable 2.If no synchronized clocks at observation points, use collector timestamping More stringent export delay requirement: 1 second delay appropriate  Proposal:  Packets SHOULD suffer no more than 1 second delay between observation and export

11 11 PSAMP WGIETF, November 2003PSAMP WG The Export Protocol Conundrum  PSAMP Requirements  Congestion avoiding  Not onerous on PSAMP device  Reliability not required, avoid overhead (buffers, ack processing)  No existing transport protocol that fulfills requirements  Interim solution: TCP (ugh!)  Aim to supplement with one of  Collector based rate renegotiation (last resort, if all else fails)  Whatever unreliable transport protocol IPFIX chooses No consensus in IPFIX for adopting TCP as transport More support in IPFIX WG meeting vote for SCTP than TCP  Protocols in development (DCCP, SCTP-PR?) SCTP-PR RFC expected within two(?) months Several SCTP-PR implementations exist  Conclusion:  If we argue about this long enough the technology will have time to catch up

12 12 PSAMP WGIETF, November 2003PSAMP WG Actions  Resolve open items  Any further comments to mailing list  Proceed to final WG call


Download ppt "1 PSAMP WGIETF, November 2003PSAMP WG PSAMP Framework Document draft-ietf-psamp-framework-04.txt Duffield, Greenberg, Grossglauser, Rexford: AT&T Chiou:"

Similar presentations


Ads by Google