Wednesday --------- agenda bashing for wed - add: maddogs change: static allocation from 226/8 to 233/8 add: pavlin mbonemap add: thaler - status of mzap change: multicast traffic monitoring from fenner to almeroth add: mark handley on mtu discovery agenda bashing for thurs thaler, multicast debugging handbook, 15 minutes maddogs ------- meyer: brief report on maddogs meeting, pointed to unofficial ietf web page, www.maoz.com/~maddogs described mboned-glob-bits draft, questioning assumption that they must be dynamically allocated, want to be able to bootstrap folks who want them now. talked about it in malloc, should it become a malloc document, yes, good suggestions, 233 not 226, add an explicit lifetime to the addresses allocated this way. get document back and written up, send it to malloc and ask for experimental status. ?? how to do inverse address mapping. thaler: what does that mean peter: get a name server or set of nameservers that serves 233, we know who owns an AS number, but no mapping to a computer. must be a manual process, ad hoc voluntary system with lifetime. mrm - kevin almeroth -------------------- multicast routing monitor protocol overview. router based implementation to help with debugging. last draft didnt make it out before deadline. protocol was proposed a couple of years ago, in development. big can of worms with management. chicken and egg problems. start efforts with mrm so folks in the real world will deploy/manage multicast. mrm allows you to source and receive traffic from multicast routers for testing. to replace the call your friends and test model. how do you administer this, what happens when you ask a router to source traffic, how to identify receivers, what to receive, how to send it back, etc. 3 components - mrm manager which controls everything. test manager aggregates and analyses data. test-sender sources data, test-receiver receives and reports what it sees. [get notes from kevin and tell him not to use green as a slide color.] uses for mrm: pre event testing - like at an ietf meeting, before the event occurs. company, ceo giving a talk (on future of multicast) wants to not be embarrased by demo. fault isolation if someone is not getting data. can you know before the phone rings, maybe with an active group that is for testing only. session monitor, like rtpmon but able to do it without an active group. maybe do sampling, on very large group so you can get a feel. fault logging. tell me when you see faults. especially if an isp has to refund $$ when fault occurs and user whines. details: use the rtpv2 packet format manager messages: sequence number, acked even for udp beacon messages, sent every minute, includes state info mgr to test-source messages total packets, rate, inter-arrival time address, etc. mrg to test-receiver messages stats to keep faults (thresholds) how to send back interface with existing tools (mtrace) security md5 messages for authentication how does it differ from existing tools snmp - not really designed for interactive dynamic stuff, scalability not very good rtcp - too restrictive, very useful, but not flexible enough mtrace - limited to active groups/sources, need to be able to say start sourceing traffic and tell me what you see. future work continue deployment, version 1 currently in experimental version of ios version 2 - add scalability, report suppression or aggregation add application level tools thaler: what scalability is in version 1. unicast or mulitcast reports. liming: scaling is a burden on the management software now thaler: version 1 can be done with snmp, except maybe scalability, snmp cant limit frequency of traps, multicast feedback is something that cant be done in snmp. traffic sourcing like ping mib. liming: want to develop mib for traffic sourcing, what kind of mib do we want. mrm is orthogonal to snmp, and more focussed. doesnt replace snmp. thaler: security is a big issue here, new protocol, can deal with that by folding into snmp, if you cant use snmp, then strongly justify why you cant. liming: make your snmp application able to use mrm and then you get security for free. monitoring of as1088 dvmrp infrastructure, fenner ------------------------------------------------- showed graph of dvmrp sources vs mbgp sources vs other sources. dvmrp 2x or 3x mbgp in september for s,g entries in forwarding tables. discovered a bug in ios's forwarding path stuff. scale went from 100 to 2000, due to stale entries. latest data thru january shows mbgp and dvmrp much closer, got really noisy data in mid january, maybe the heuristic to find the buggy cache entries is failing. want to find scope and interest of the two protocols, someday we hope dvmrp will go to 0 data shown in graphs is the number of sources at that point in time, it's worst case, not an average. dino: where are routes coming from, bill: about 600 /16 or /20 ish mbgp routes and about 2000 dvmrp routes. dino: longest match makes some of the s,g's go to dvmrp instead of mbgp. so someone is misconfigured if this happened. xxx: is there any way to get packet counts to see real sources from rtcp. fenner: already sort of does that in his bogus sources heuristic. started to do mbgp monitoring, see www.aciri.org/fenner/mcast/mbgp. sdr global session monitoring effort - kamil sarac (student of kevin almeroth) ------------------------------------------------------------------------------ monitoring sdr session announcements collect sdr caches from several participants (40 at present, ~25 active) sender script - 60 lines of tcl sdr monitor parser - collects it and archives it participants (senders) are mostly in us and europe, 1 in asia, 1 in australia functionality see if your session is getting out at all too far just right graphs of ttl vs announcements showing global, regional, local graphs of visibility (of sdr announcements) on long lived session some stable, some unstable probably due to local effects graph of global sessions - visible roughly 50% of the time conclusions - availability of sdr sessions poor and fluctuating a lot futures topology map of participants showing state of session relative to participants mtrace to participants to show where problems are please make suggestions need more participants, email ksarac@cs.ucsb.edu to join see http://imj.ucsb.edu/sdr-monitor mark: do you have any idea if the sdr data matches multicast data. since sdr announcements are bursty and some routers dont do bursty. meilor: how much of the visiblity is the problem of the first hop router. shutting it down today, starting it tomorrow morning. kamil/kevin: anwswer we fix stuff in the data. we keep a sequence number, so we notice that. use the first line in the cache entry, discard it if announcement was older than one day. mark: 1 day too long, 1 hour better. mantra - prashant rajvaidya --------------------------- tool for monitoring and analyzing multicast data from routers. want to give global picture of multicast traffic. this is a first cut collect data from 3 routers, data shown only from fixw-mbone expect scripts, once every hour get 3 views now, from the cisco commands: xxx, xxx, xxx data for the last four months mantra is a tool to analyze it and put results on the web interactive applets html tables demo - starting with empty screen x axis is time, by hour, have 3 months of data y axis you can choose #particpants, #groups, #sources, etc. can zoom time scale, no explanation of big fluctuations. mantra request server request only data you are interest in uses trend analysis as we get more data debugging tool to explain spikes futures need data from multiple routers mantra at multiple sites, so sites can run it locally if they dont want to share their data. develop system for intra or inter domain monitoring issues data collection expect scripts [not likely on other peoples routers!] snmp email ?? time granularity - scale, dont want to overwhelm busy routers dino: can you monitor rpf changes, additions and deletions. bill: hard to collect via a periodic sample, can get a big view, but granularity of changes is too small, need the router to tell you when they occur. router needs to have a counter to show rpf changes/rpf failures. dino: router has counter to do that anyway, so dino is asking for that to be collected and displayed, he and dave thaler arguing about whether the existing counters are enough. mzap - dave thaler ------------------ spec updated from orlando, port numbers assigned by iana, so going to working group last call mbone map, pavlin ----------------- www.isi.edu/scam/mbone.html map available fenner: how do you collect the data answer: might have been mrinfo query, couldnt hear. multicast mtu discovery, mark handley ------------------------------------- ask what is the size of the last fragment that you received then receiver can report back to the sender. dino: opaque pim message that captures population count and mtu to source. mark: can do it independent of routing protocol, couldnt do it with tunnels, with native you can. dino: if you know it's pim, can be more efficient. dave: routes on receiving end find out mtu mark: push it up to the application level thaler: nice to be independent of routing protocol at network or application layer (dino/mark) thaler: as a receiver joins mtu might change, should sender flip/flop everyone: NO steve casner: just say mtu is 1500 and be done with it. mark: may be more of an issue as we get more dialup access liming: is this multicast specific, same problem in unicast. use fixed value 576, mtu for entire network. ross: how hard is it to get the value from the tcp stack, ie windows 95, what hope is there. casner: there is a protocol for doing segmenetation and reassembly on ppp links, just use that instead of making all the packets so little. thaler: reluctant to say 576, local intranet may want much higher value. Thursday -------- review of wed meeting agenda, thurs anycast rp, dorian kim, sadp draft update/review challenges/solutions for multicast applications, quinn multicast debugging handbook sadp - nested scoping ttl scoping doesnt work for large scopes ttls not necessarily symmetric some hear request, some hear response, some hear both admin scoping better nested issues: ------- which scopes nest (mzap draft) how to distribute info (madcap draft) which addresses to use in various scopes (sadp draft) service increase scalability caches messages request mechanism to allowserver to cache multiple addresses in a session but client might not be willing to join to all dorian kim ---------- draft-ietf-mboned-anycast-rp-00 intradomain case using anycast benefits is not clear dmm - questions about benefits case of two AS, with rp's in each and connection between them. draft describes the benefits of connecting them dino: could you use anycast rp across domains. like across providers that they share, reduces number of msdp sessions. could do that, coordination issue if anything goes wrong. dino: rp cluster idea of a couple of years ago at ix'es. can we connect several providers thru the anycast rp. peter: reason we did it is to not depend on someone elses rp. dorian: need that info for deployment and support (that info = private address) hal alverstan: would like anycast reference. old craig partridge rfc on it. steve deering will do a bof at the next ietf to produce a document on anycast. dino: this anycast may be misnamed. we are doing shortest path routing, have two identical addresses. steve deering: yes, lets change the name here. bob quin, ip multicast applications, challenges and solutions draft. ------------------------------------------------------------------- how many have read it (1/3 of the room maybe) roadmap for newcomers, intro to applications and their requirements. avoid reinventing wheels avoid spinning wheels avoid running roughshod over the network focus purely application, assumption - scaling with the igmp model. changes in this revision - kevin almeroth added as co-author added to services: expedient joins and leaves, send without join added to service reqts synschronization. added the many to one category to the text. doesnt model network level multicast resource discovery data collections auctions polling juke box steve deering, multicasting to a group with only one member? next: some minor edits, last call by july. dave thaler, multicast debugging handbook ----------------------------------------- have two types of tools intra domain management, snmp mibs, mrm, route flap monitor, mview end-2-end management: mtrace, rtpmon why isnt multicast deployed, asked multicast summit attendees what they needed more tools or better tools understand how to read/use the current ones need to know: is it red or green, not pile of numbers need expert system to read mtrace output. handbook has debugging procedures problem referral, mtrace shows where problem is model where end user calls local help desk wont help referral big deal wrote troubled, never released server because of memory leaks. going to get kevins students to do it. common problems congestion no route to source route flapping route dumping (unicast injected into dvmrp tables) identify functional components multicast forwarder ... need health meter for ability of link to forward multicast traffic express health in terms of red/green scale has formulas for it question: how do you measure utilization. if you know bandwidth use that, or rate limit, etc. skeptical about ability to estimate capacity. thaler: right, sometimes you just have to estimate/guess. what to do if things are bad. congestion, what is causing it, tcpdump, netflow, etc. health problem, mtrace dependency graph of functional components, at transport, network and link level. troubled heuristic measures badness factor. had lots of formulas falling asleep, not doing a very good job, dmm, sorry. ran experiment using mtrace -d which listens to other mtraces. 12841 mtrace reports heard 106 alerts in 3 weeks for congestion problems 42 different as's debugged for 2 weeks, analyzed data for final week 21 confirmed congestion on links 4 for confirmed problems on routers peter: does this apply today, you are looking at the mbone as dvmrp tunneled architecture. what we are building now is mbgp, msdp. real problems are not congestion, state and configuration. whole new set of problems that are state related. need to have document to say here are todays problems and how to debug them. if we are going to redo the handbook today, we need to focus on these problems. dave: document configuration problems for a vendor. peter: document machinery to create forwarding state. not necessarily with a particular piece of equipment. thaler: yes, what are the most common problems and their solutions, who has the experience. give me feedback. snmp community waiting for snmp v3 to be done, then will work on whats next. end-2-end management was high on their list of todo's next. challenges - distinguish link loss vs router loss. assymetric routing makes mtrace from each direction not helpful. enumerate top users of link mcast traffic (vanograms) identify # routes learned from each neighbor (unicast routes flooding) same for # routing updates local any legal path (cant get a route to mtrace with) might need a database or routing registry, mwatch used to do this via mrinfo database bidirectional mtrace once the rp switches to the shortest path tree, but source is on the shared tree, mtrace may go to rp instead of source. need alarm generation from tools. http://www.eecs.umidh.edu/~thalerd/gdt/ draft ietf-mboned-mdh-*.txt troubled details for mbone, chapter 3 of thesis gdt protcol, draft-thaler-gdt-00.txt john stewart from crc technology in canada: make a red/green monitor, boss likes it, up for 6 months