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