ippm@conference.ietf.jabber.com - 2003/03/18
[09:09] %% logger has arrived.
[14:24] %% Isomer has arrived.
[16:51] %% mrose has arrived.
[17:00] %% Isomer has left.
[17:01] %% Isomer has arrived.
[17:04] %% jishac has arrived.
[17:13] * jishac has changed the subject to: Agenda Bashing
[17:15] %% eblanton has arrived.
[17:15] %% sleinen has arrived.
[17:20] %% alex has arrived.
[17:22] <Isomer> is anyone going to scribe for this room?
[17:25] <sleinen> I hope there's a scribe for the meeting, but apparently not in Jabber. Are you trying to listen in remotely? If so I can try to transcribe what is being said.
[17:25] <sleinen> Stanislav Shalunov on draft-ietf-ippm-owdp-06.txt
[17:26] <Isomer> yeah, I'm in New Zealand
[17:26] <Isomer> :)
[17:26] <sleinen> I see. Sorry for starting late, Stanislav is done already.
[17:26] <sleinen> Up next: Al Morton on packet reordering.
[17:26] <Isomer> oh, no problem :)
[17:26] <Isomer> I'm just curious :)
[17:27] <sleinen> draft-ietf-ippm-reordering-02.txt
[17:28] <sleinen> New unifying draft with 5 co-authors:
[17:28] <sleinen> Al Morton, Len Ciavattone, Gomathi Ramachandran, Stanislav Shalunov, Jerry Perser
[17:28] <sleinen> There was an individual submission also, but none of the authors seems to be in the room (on reordering density)
[17:29] <sleinen> Short show of hands - a few people have read the draft
[17:29] <sleinen> Introduction to the problem of reordering
[17:30] <sleinen> Attempt to make the metric orthogonal to loss
[17:30] <sleinen> Shows example sequence of reordered packets
[17:30] <sleinen> 1,2,3,7,8,9,5,6,7,10,11
[17:31] <sleinen> Both 7,8,9, and 5,6,7, are special in the world of order
[17:31] <sleinen> Packets 7,8,9 are called "early"
[17:31] <sleinen> Packets 4,5,6 are "late".
[17:31] <sleinen> There is *no* reordering until late packets arrive
[17:31] <sleinen> # of early packets -> reordering extend
[17:31] <sleinen> extent!
[17:32] <sleinen> Receivers must perform work on all Late packets to restore order
[17:32] <sleinen> 1,2,3,7,8,9,10,4,5,6,11,12
[17:32] <sleinen> 7,8,9,10: Buffered
[17:32] <sleinen> 4,5,6: Reordered
[17:32] %% The Saint has arrived.
[17:32] <sleinen> Packet 6 releases all ot 7,8,9,10.
[17:33] <sleinen> Changes in -02 version of ippm-reordering draft
[17:33] <sleinen> ?#!@! merger of different metrics in section 4.2 (reordering extent)
[17:33] <sleinen> (not considered very successful)
[17:33] <sleinen> * Emphasized need for orthogonality
[17:33] <sleinen> * Unified notation
[17:33] <sleinen> * Specified handling for duplicate packets
[17:33] <sleinen> * More references to earlier work
[17:34] %% eblanton has left.
[17:34] <sleinen> * Added a Gap metric - distance between Reordering Events.
[17:34] <sleinen> Gap exmple:
[17:34] <sleinen> 1, 2, 4, 5, 3, 6, 7, 9, 10 11, 8, 12
[17:35] <sleinen> -> packets 4 and 9 are the "beginning" of reordering events
[17:35] <sleinen> -> Gap is the distance between them.
[17:36] <sleinen> QUestion (Matt? - definitively not Zekauskas): How do you handle cases of Nested Reordering?
[17:36] <sleinen> Happens in real networks when you have slight reordering and then some rare events make some packets real late.
[17:37] <sleinen> In the example, nested reordering would occur if 3 arrived after 8.
[17:37] <sleinen> [That was all still the question.]
[17:38] <sleinen> Discussion between Jon Bennet and Al Morton about requirement to keep state when measuring gaps
[17:38] <sleinen> Al Morton: always more work to do...
[17:38] <jishac> [At the very begining of the presentation and in the document, there is an attept to distinguish between loss and reordering... or at least that's what I took away from it. My question is, how do you seperate those? Ex: in TCP lost packets are retransmitted and so would show up late... is that considered reordering?]
[17:38] <sleinen> Framework for ippm-reordering-03
[17:39] <sleinen> * Problem statement
[17:39] <jishac> [and is it a problem is it is, isn't]
[17:39] <sleinen> 1. Determine whether or not packet order is maintained (and which packets are reordered)
[17:40] <sleinen> 2. Quantify the extent of change (this wil have many useful solutions)
[17:40] <sleinen> -> section 4 - Metrics that lean to Network Characterization
[17:40] <sleinen> + fequency
[17:40] <sleinen> + Distance metrics
[17:40] <sleinen> + Metrics for multiple events (Gap)
[17:40] <sleinen> -> Section 5 - Metrics rimarily for receiver assessment
[17:40] <sleinen> + n-reordering (NewReno TCP)
[17:40] <sleinen> + possibly a modified version of Reordering Density.
[17:41] <sleinen> Question(?): When we are talking about reordering distance, are we talking about distributions, average etc/
[17:41] <sleinen> Answer: Depends on whether you are talking about singleton metrics or statistics
[17:41] <sleinen> Question: I'm assuming we have multiple samples
[17:42] <sleinen> Stanislav: You need a whole distribution and then you can present it e.g. as averages etc.
[17:42] <sleinen> Matt Zekauskas: Talking about reordering density... you may be too inclusive here.
[17:43] <sleinen> Al Morton continues to present slides
[17:43] <sleinen> Resolve Reordering Extent in -03
[17:43] <sleinen> * Section 4 - Metrics that lean to Network Characterization
[17:43] <sleinen> + Distance metrics: Position, Time and Bytes
[17:43] <sleinen> + Beignning of Events; Reodering Gap
[17:43] <sleinen> * The Fix:
[17:43] <sleinen> Definition 1:
[17:44] <sleinen> Receivefd packet i (n < 1 <= l) is called n-reordered
[17:44] <sleinen> IFF for any j such that i-n <= j < i (was ALL)
[17:44] <sleinen> we have s[j] < s[i]
[17:44] <sleinen> Now we can use this beautiful formalization that Stanislav came up with.
[17:44] <sleinen> * Need results of section 3 to enable this test
[17:45] <sleinen> -> if limited storage for packets, Reordered status tells whether reordering is greater than stored set.
[17:45] <sleinen> Question (Gred Woodhouse): Wondering what it is you're trying to quantify
[17:46] <sleinen> Look like Hamming distance in code lengths
[17:46] <sleinen> Are you looking at how much has to be done to restore order?
[17:46] <sleinen> Answer (Al Morton): No. A friend had called me with "what about this Kendall(?) metric". Mot of these don't work well in combination with loss.
[17:47] <sleinen> Greg: Different concepts of metrics might correspond to different concepts of work that has to be done to process message.
[17:47] <sleinen> Al: Memory can be expressed e.g. in bytes and we could do that as well [queue memory,]
[17:48] <sleinen> Stanislav: One answer to your questions: The percentage of packets that would have to be considered as lost for certain types of applications (e.g. TCP)
[17:49] <sleinen> Remark (someone?): Noticed that example from VoIP/jitter buffer is no longer in latest version of draft.
[17:49] <sleinen> Stanislav: Must have been removed accidentally. It was a valid example.
[17:49] <sleinen> Al Morton is finished with his talk.
[17:50] <sleinen> Matt Zekauskas: Are there any concerns of going forward with this? [Don't seem to be.]
[17:50] <sleinen> Up next: IPPM Reporting MIB
[17:50] <sleinen> ietf-ippm-reporting-mib-02.txt
[17:51] <sleinen> Jess Jewitt (work with Emile Stephan)
[17:51] <sleinen> There's a working prototype of this agent.
[17:51] <sleinen> Simplification and Clarification
[17:51] <sleinen> * Make use of MIB object indentation
[17:51] <sleinen> * Corrected TYPO errors
[17:51] <sleinen> * Ran SMILINT with -s -16
[17:52] <sleinen> (some name lengths exceeded 32 characters.)
[17:52] <sleinen> zero errors and warnings from smilint now.
[17:52] <sleinen> That had been per Andy Bierman's request...
[17:52] <sleinen> * Time unit textual convention (time units)
[17:52] <sleinen> * Clarify CLearHistory and ClearReport definition:
[17:52] <sleinen> OnReportDeliveryClearHistory vs. OnReportDeliveryClearReport
[17:53] <sleinen> * TypeP redefined as a SnmpAdminSting instead of a raw OCTET STRING
[17:53] <sleinen> e.g. '0800000800000000011020000'H -> "ip.ipip4"
[17:53] <sleinen> [the left hand side is not correct.]
[17:54] <sleinen> * Added scalars ippmOnReportFullAction and ippmOnHistoryFullAction:
[17:54] <sleinen> To take action when the tables are full.
[17:54] <sleinen> Open for suggestions on what to do when tables are full.
[17:54] <sleinen> * PointOfMeasure
[17:54] <sleinen> changed to InetAddress'es
[17:55] <sleinen> * Took out default PointofMeasure address
[17:55] <sleinen> motive: default address not realistic scenario
[17:55] <sleinen> * Added ippmSynchronization... (use stratum metric)
[17:55] <sleinen> * ippmHistoryIndex added in history table to differentiate result index from test pcket order
[17:55] <sleinen> * ippmReportIndex added in report table - to differentiate result index from test packet order
[17:56] <sleinen> * ippmAggregatedMeasureStatus removed - status of row managed in measure table
[17:56] <sleinen> ( IppmNetworkMeasureEntry
[17:56] <sleinen> * Notifications
[17:56] <sleinen> added timestamps to all notification types
[17:56] <sleinen> * Added ippmReportSetupNotification in the report setup
[17:56] <sleinen> * Conformance section
[17:56] <sleinen> essentially rewritten to be more standards-compliant
[17:57] <sleinen> Problem: changes names of top-level objects - you need to make changes to existing agent implementations.
[17:57] <sleinen> Open Issues:
[17:57] <sleinen> * FOr TypeP textual convention, do we need to indicate number of parameters of the protocol identifier "ip.ipip4.2" or "ip.ipip4"?
[17:57] <sleinen> * Potential parameter with spaces inside for TypePaddress?
[17:58] <sleinen> Andy Bierman: Some of your changes aren't consistent wrt SnmpAdminString, OwnerString...
[17:58] <sleinen> Answer: What we did in the compliance part was to not make these mandatory
[17:59] <sleinen> Andy Bierman: remove them completely. Owners, e-mail addresses are all fine. Indexing by owner is also fine.
[17:59] <sleinen> Andy still thinks it's a very heavyweight MIB to implement. Not something that just runs in the background on a card that does monitoring. More like RMON MIB.
[18:00] <sleinen> Andy: There's an index on the history liimited to 65K. You should study how fast this will wrap with various metrics. Seems like a lot for a history, but some people have ideas of days or weeks long histories.
[18:01] <sleinen> Jess: Curious whether you find the suspend/resume options useful.
[18:01] <sleinen> Andy: Probably not if this creates gaps in the history.
[18:01] <sleinen> Andy: Beyond suspend/resume, would need capability to clear out parts of the history[?]
[18:02] <sleinen> Andy: It doesn't seem useful to specify a low theoretical limit for these indexes.
[18:03] <sleinen> Official agenda is done.
[18:03] <sleinen> Presentation on the current state of the metrics registry.
[18:03] <sleinen> Emile Stephan
[18:03] <sleinen> Changes since -01 version
[18:03] <sleinen> * Registration rules simplified
[18:03] <sleinen> * Draft subtree removed.
[18:04] <sleinen> * Loss pattern metrics oRFC3357 added
[18:04] <sleinen> ...
[18:04] <sleinen> Registry has only 2 root branches
[18:04] <sleinen> * RFC metrics
[18:04] <sleinen> * other metrics
[18:04] <sleinen> Only one rule to manage registry "when a draft is considered mature"...
[18:04] <sleinen> Chair will provide metric identifier.
[18:05] <sleinen> Too few people in the room seem to have read this to judge sense of the room.
[18:05] <sleinen> Andy Bierman notices that the I-D has been cleaned up significantly.
[18:05] <sleinen> Matt: Will send this to Last Call shortly.
[18:05] <sleinen> Meeting ends.
[18:07] %% alex has left.
[18:07] %% The Saint has left.
[18:07] %% sleinen has left.
[18:15] %% jishac has left.
[19:11] %% Isomer has left.
[19:26] %% mrose has left.