[10:25:59] --- jishac has joined
[10:26:43] --- becarpenter has joined
[10:33:27] --- loughney has joined
[10:33:47] --- lars has joined
[10:40:39] --- hkruse has joined
[10:47:52] --- yushun has joined
[10:50:45] --- mlshore has joined
[10:55:59] --- weddy has joined
[10:57:23] --- Tom Phelan has joined
[10:57:59] <Tom Phelan> [i'll try jabber scribe]
[10:58:07] <Tom Phelan> coling perkins presenting on plea from avt
[10:58:32] <Tom Phelan> two drafts on rtp header compression over mpls
[10:58:41] <Tom Phelan> limited mpls expertise in avt
[10:58:46] <Tom Phelan> this might have wider scope
[10:58:55] <loughney> can someone post the agenda?
[10:59:06] <Tom Phelan> plea is to look at drafts if you're inreseted in compression or mpls
[10:59:14] <Tom Phelan> rtp profile for tfrc
[10:59:23] --- becarpenter has left: Replaced by new connection
[10:59:23] --- becarpenter has joined
[10:59:23] --- becarpenter has left
[10:59:26] <Tom Phelan> experiment with tfrc with small changes
[10:59:35] <Tom Phelan> more limited goals than dccp
[10:59:37] --- sakai has joined
[10:59:38] <jishac> AGENDA: http://www1.ietf.org/mail-archive/web/tsvwg/current/msg04815.html
[11:00:01] <jishac> [ but it has been changed/bashed -jishac ]
[11:00:01] <Tom Phelan> that's it, comments appreciated
[11:00:27] <Tom Phelan> matt mathias now on tcp estats mib
[11:00:28] --- becarpenter has joined
[11:00:53] <Tom Phelan> sure you would all like to hear about this mib in great detail [laughter]
[11:00:59] --- mallman has joined
[11:01:19] <Tom Phelan> tcp has ideal vantage point to see what problems are
[11:01:27] --- dinakar has joined
[11:01:41] <Tom Phelan> fundamental result of "hourglass" layer
[11:02:10] <Tom Phelan> app can't tell difference between broken leading edge net and last year's performance
[11:02:18] <Tom Phelan> per connection instrument groups
[11:02:34] <Tom Phelan> tcp state - flags options
[11:02:39] <Tom Phelan> traffic and throughput
[11:02:44] <Tom Phelan> abstract congestion
[11:02:47] <Tom Phelan> net path props
[11:02:52] <Tom Phelan> sender buffering
[11:02:56] <Tom Phelan> receiver window
[11:03:04] <Tom Phelan> about 135 instruments in 8 tables
[11:03:32] <Tom Phelan> triage system tells with subsytem to check for problems
[11:04:06] <Tom Phelan> are you processing ecn signals
[11:04:16] <Tom Phelan> history - dueling drafts
[11:04:32] <Tom Phelan> rfc2012-update - updated for ipv6
[11:04:46] <Tom Phelan> rfc2012-extension - detail per connection stats
[11:05:01] <Tom Phelan> update pulled back after -04
[11:05:12] <Tom Phelan> orphanded objects moved to -extension
[11:05:18] <Tom Phelan> recent progress
[11:05:31] <Tom Phelan> baking for while, matt would let it bake forever
[11:05:46] --- weddy has left
[11:05:46] <Tom Phelan> rumors of 3 implementations
[11:06:02] <Tom Phelan> time for closure
[11:06:24] <Tom Phelan> issues
[11:06:33] <Tom Phelan> about 2 dozen closed
[11:06:40] <Tom Phelan> 9 outstanding
[11:06:53] <Tom Phelan> snmp/smi issues, but matt's a tcp geek
[11:07:08] <Tom Phelan> status page http://www.web100.org/mib/
[11:07:17] <yushun> \\\
[11:08:48] <Tom Phelan> paritioning issues
[11:09:12] <Tom Phelan> q: back off if mib processing to great?
[11:09:29] <Tom Phelan> matt: most stats are side effect of processing
[11:09:59] <Tom Phelan> end presentation
[11:10:26] <Tom Phelan> side comment: in avt: need to address performance or it won't be used
[11:12:01] --- admcd has joined
[11:12:30] <Tom Phelan> francois la fauchuer on aggregation of rsvp over tunnels
[11:12:40] <Tom Phelan> rfc3175 defines rsvp aggregation
[11:13:03] <Tom Phelan> how to aggregate end-to-end reservations into fat reservations
[11:13:05] --- mankin has joined
[11:13:19] <Tom Phelan> one mode for integrating intserv and diffserv
[11:14:03] <Tom Phelan> lots of smartness located in receiver
[11:14:13] <Tom Phelan> - deaggregator
[11:15:04] <Tom Phelan> 3175 notes that agg resvs can use an mpls tunnel, but doesn't go into details
[11:15:46] <Tom Phelan> new reqs for te/ds-te tunnels (traffic engineering/diffserv-aware te
[11:16:08] <Tom Phelan> se, now's the time to work out the details
[11:16:28] <Tom Phelan> mpls te puts brains at head end
[11:16:41] <Tom Phelan> procs from 3175 need to be adjusted
[11:16:57] --- lars has left
[11:17:14] <Tom Phelan> no new protocol extensions, just modified procedures
[11:17:31] <Tom Phelan> target app - class 4 voice trunking
[11:17:51] --- cgn has joined
[11:18:18] <Tom Phelan> could be per-call resvs, or "trunk" resvs instantiated ahead of need
[11:18:37] <Tom Phelan> you get per-call voice call admisssion in a scalable way
[11:18:59] <Tom Phelan> should there be localized rsvp behavior
[11:19:19] <Tom Phelan> should edge node provide proxy control and just turn around the rcvp messages
[11:19:35] <Tom Phelan> that might be proposed as optional behavior
[11:20:02] <Tom Phelan> can't handle some situations (asymetric codecs), but most of the time good enough
[11:20:27] <Tom Phelan> problem - mpls used penultimate hop popping
[11:20:48] <Tom Phelan> but you might loose proper processing of path message
[11:21:13] <Tom Phelan> same problem of mpls tunnels within tunnels
[11:21:20] --- loughney has left
[11:21:34] <Tom Phelan> current draft simpler than 3175, assumes tunnels are pre-established
[11:21:53] <Tom Phelan> is dynamic tunnel needed?
[11:21:59] --- loughney has joined
[11:22:29] <Tom Phelan> but mostly today there's stuff that needs to be configured for each tunnell anyway
[11:22:40] <Tom Phelan> next stesp - progress
[11:23:07] <Tom Phelan> qoi (??): what are scaling factors when you add tunnels, when you handle large number of calls?
[11:23:27] <Tom Phelan> franc: solution pretty scalable in core, but what about edge?
[11:23:38] <Tom Phelan> edge maintains per end-to-end state
[11:23:51] <Tom Phelan> edge resvs don't have to be per call, can be per trunk
[11:24:33] <Tom Phelan> second order answer, sure edges need per-resvs state, but lot's of edge, further you push agg, less resvs per box
[11:25:14] <Tom Phelan> wittiger ?: didn't read drafts, but, support both services of intserv?
[11:25:31] <Tom Phelan> franc: not specific in spec, but can support both
[11:25:41] <Tom Phelan> w: what's intended for implementation?
[11:26:07] <Tom Phelan> franc: [confused] how to we solve intserv to diffserv - discussed in intserv over diffserv
[11:26:54] <Tom Phelan> bruce davie: difficulties supporting garaunteed service, but know how to do basic mapping for tspecs
[11:27:24] <Tom Phelan> allison: what's the difference between this and tunneling rsvp?
[11:27:44] <Tom Phelan> franc: look hard at the doc, reused parts
[11:27:51] <Tom Phelan> a: what's more in here?
[11:28:39] <Tom Phelan> bruce: diff is, tried to figure out every last detail in ingress versus egress
[11:28:54] <Tom Phelan> tunnel rfc doesn't tell everything you need for tunnel entry
[11:29:20] <Tom Phelan> b: tunnel rfc talks about 3 types of tunnels, this is one of the 3 types in detail
[11:30:15] <Tom Phelan> allison: taking hum on acceptance
[11:30:25] <Tom Phelan> hum if you'd review
[11:30:30] <Tom Phelan> a: pretty stong
[11:30:39] <Tom Phelan> hum support taking into tsv
[11:30:49] <Tom Phelan> a: take that into consideration, pretty good support
[11:31:16] <Tom Phelan> james polk: rcvp bandwidth reduction
[11:32:04] <Tom Phelan> rcvp sets up recvs based on many things, including bandwidth
[11:32:16] <Tom Phelan> 3175 tells how to aggregate,
[11:32:28] <Tom Phelan> 2205 talks about preempting
[11:32:54] <Tom Phelan> here's rub: entire flow or aggregate needs to be torn down to preempt
[11:33:05] <Tom Phelan> reduction scenarios [animated slide]
[11:33:15] <Tom Phelan> interface at capacity
[11:33:23] <Tom Phelan> a > b priority
[11:33:40] <Tom Phelan> new flow added to a, must preempt all of b
[11:34:04] <Tom Phelan> add to resverr to tell b how much bandwidth it could have
[11:34:19] <Tom Phelan> resverr reduce instead of resverr preempt
[11:35:05] <Tom Phelan> open issues:
[11:35:32] <Tom Phelan> source and dest has mismatch in size of resv
[11:35:49] <Tom Phelan> slight change to 2205, recvtear message go to source also
[11:36:08] <Tom Phelan> what happens when reduce message sent, but no reduction seen?
[11:36:29] <Tom Phelan> should text talk about individual flows - text uses aggregates as examples
[11:36:36] <Tom Phelan> new rev soon
[11:36:46] <Tom Phelan> tsvwg work item?
[11:36:58] <Tom Phelan> q [who]: do you measure?
[11:37:50] <Tom Phelan> j: ressv setup at certain bw
[11:38:03] <Tom Phelan> q: you're talking about resvs, i'm talking about real traffic
[11:38:35] <Tom Phelan> j: [confused, q trying to explain himself]
[11:39:07] <Tom Phelan> bruce davie: assumption in draft is parameter based rather than measurement
[11:39:41] <Tom Phelan> q: asking because in draft mention, can send ecn?
[11:39:51] <Tom Phelan> j: don't think i have ecn anywhere in draft
[11:40:01] <Tom Phelan> [mumbles from audience in aggreement]
[11:40:14] <Tom Phelan> q: how to select flow to reduce?
[11:40:17] <Tom Phelan> j: local policy
[11:40:52] <Tom Phelan> maury ??: in model router 9, how select target to reduce?
[11:41:01] <Tom Phelan> j: not clarified in draft
[11:41:13] <Tom Phelan> said, agg a > b
[11:41:22] <Tom Phelan> not dealing with multipath
[11:41:39] <Tom Phelan> maury: some computation issues
[11:41:57] <Tom Phelan> franc: agg to take bw from, local decision, no need for standard
[11:42:08] --- yushun has left: Disconnected
[11:42:33] <Tom Phelan> f: you should do something smart, whole range of policies, but not proper for standardization
[11:42:41] <Tom Phelan> j: could put non-normatice examples
[11:43:04] <Tom Phelan> new q (name?): resv tear goes to r9
[11:43:18] <Tom Phelan> j: recvtear starts at r9, we want to hold it off
[11:43:22] --- Jukka Manner has joined
[11:43:36] <Tom Phelan> q: flow deleted on one side not necessarily same as deleted on other side
[11:43:45] <Tom Phelan> j: yes, plan to tackle this in new rev
[11:43:59] <Tom Phelan> q: like to see ladder diagram and handling of error cases
[11:44:53] <Tom Phelan> subrah (co-author): resvtear as open issue is immediate tear or not, to inform intermediate routers, discuss how sync happening
[11:45:17] <Tom Phelan> steve casner: use cases for this: how often are you actually allocating the entire bw?
[11:45:54] <Tom Phelan> j: you're right, most nets not come near this, but i know of one us-gov net with oc-3s where they should have oc-12s, and five priorities for communications
[11:46:08] <Tom Phelan> this is for times of emergency, should make clear in doc.
[11:46:19] <Tom Phelan> [questions cut off due to lack of time]
[11:47:32] <Tom Phelan> congestion ntofication process for real-time traffic - jozef babiarz
[11:47:41] <Tom Phelan> measurement-based for admission control
[11:48:08] <Tom Phelan> motivation, simple traffic condition notification
[11:48:36] <Tom Phelan> chair: confine remarks to diffs from previous
[11:48:44] <Tom Phelan> function performed by router
[11:48:55] <Tom Phelan> flow measurement per service class
[11:49:00] <Tom Phelan> func perf by app
[11:49:22] <Tom Phelan> pick outgoing marking, react to incoming mark
[11:49:47] <Tom Phelan> receiver notifies sender, sender stops setting up new sessions
[11:50:10] <Tom Phelan> example: [diagram in slide]
[11:50:24] <Tom Phelan> test flow before admission
[11:50:45] <Tom Phelan> don't need to monitor in every router, just where admin sees potential chokepoints
[11:51:27] <Tom Phelan> usage: cac for real-time flow
[11:51:41] <Tom Phelan> next steps: explore alternative ecn semantics
[11:52:03] <Tom Phelan> need comments on ecn for real-time udp flows
[11:52:17] <Tom Phelan> char: changes from last version of doc?
[11:52:43] <Tom Phelan> restruct, reword, closer to structure of [something else]
[11:52:49] <Tom Phelan> mechanisms still the same
[11:53:20] <Tom Phelan> sally floyd: talked with authors monday, 3 suggestions
[11:53:36] <Tom Phelan> doc says ecn just for tcp, but not true
[11:53:54] <Tom Phelan> others are wording, not showstoppers
[11:54:20] <Tom Phelan> nos not erased when congestion set, think a little about routers cheating
[11:54:55] <Tom Phelan> maury: interested in this approach, one issue, how to provide redundant route?
[11:55:29] <Tom Phelan> j: draft talks about mechanism, could expand to app examples, open to input
[11:55:51] <Tom Phelan> new q: like general idea, appreciate if this gets official support
[11:56:39] <Tom Phelan> alison: number of same comments last time, to make wg doc, have people follow up on list, is solid enough idea for wg doc?
[11:57:05] <Tom Phelan> sally: not arguing against (or for) wg doc, on record that there are issues
[11:57:15] <Tom Phelan> sally: think progess is being made
[11:57:26] <Tom Phelan> witt: didn't say like the doc, just the concept
[11:57:41] <Tom Phelan> allison: volunteer reviewers?
[11:58:03] <Tom Phelan> q: like measurement based admission control
[11:58:13] <Tom Phelan> allison: you're declining to revierw?
[11:58:29] <Tom Phelan> j: rev before review?
[11:58:40] <Tom Phelan> a: yes, do it and annouce to mailing list
[11:59:06] <Tom Phelan> sumitha: ltcp - layering technique
[11:59:24] <Tom Phelan> tcp window increases 1/rtt, decrease by havf
[11:59:36] <Tom Phelan> sub-optimal perf in highspeed nets
[11:59:59] <Tom Phelan> ltcp: layer approach increasing parallel tcp flows
[12:00:12] <Tom Phelan> general framework and one possible design
[12:00:17] --- cgn has left
[12:00:29] <Tom Phelan> meant to illustrate effectivemess, final solution open
[12:01:34] <Tom Phelan> jonathan: get to discussion about placement soon
[12:01:47] <Tom Phelan> framework: 2 dimension control
[12:01:56] <Tom Phelan> conclusion:
[12:02:01] <Tom Phelan> convergence ensured
[12:02:10] <Tom Phelan> consider as experimental rfc?
[12:02:33] <Tom Phelan> jon: ours, yours
[12:02:38] --- cgn has joined
[12:02:49] <Tom Phelan> q: option3 - no
[12:03:17] <Tom Phelan> sally: other things in this space, highspeed tcp, fast tcp, scalable tcp, decision about this should be same as thos
[12:03:35] <Tom Phelan> jon: decisions on those made before tcpm
[12:03:52] <Tom Phelan> sally: highspeed tcp might not be only contender
[12:04:28] <Tom Phelan> allison: any tcp tackles highspeed go together, some tcps change the tcp friendliness question
[12:04:44] <Tom Phelan> just highspeed goes to tcpm, changes friendliness stays here
[12:05:01] <Tom Phelan> sumitha: this design stays aimd
[12:05:18] <Tom Phelan> new a: maybe aimd, but not all aimds same
[12:05:50] <Tom Phelan> broader issue needs to be considered by ads, changes to tcp itself belong to tcpm, but broader changes belong here
[12:06:11] <Tom Phelan> is this ready for that decision?
[12:06:23] <Tom Phelan> round of feedback needed before decision
[12:06:23] <jishac> [ that's Joe Touch -jishac ]
[12:06:44] <Tom Phelan> mark handley: something that changes congestion control dynamics should stay here
[12:06:49] <Tom Phelan> this changes dynamics
[12:07:07] <Tom Phelan> allision: another vote for that missing congestion control wg [laughter]
[12:08:06] <Tom Phelan> [thanks jishac, hard to recognize people from behind]
[12:08:20] <Tom Phelan> [who is presenter?]
[12:08:28] <Tom Phelan> sctp bakeoff summary
[12:08:34] <jishac> R. Stewart
[12:08:38] <Tom Phelan> list of drafts tested
[12:08:42] <Tom Phelan> results
[12:08:49] <Tom Phelan> 11 implementations by 9 orgs
[12:08:58] <Tom Phelan> all but one scored over 200 points
[12:09:17] <Tom Phelan> interop with all other imps gets 140 points
[12:09:24] <Tom Phelan> many advance features tested
[12:09:42] <Tom Phelan> all base features tested, except hostname address
[12:09:56] <Tom Phelan> had indirect socket api test
[12:10:09] <Tom Phelan> half imps did socket api
[12:10:32] <Tom Phelan> summary
[12:10:45] <Tom Phelan> two minor wording clarifications in imps guide
[12:10:55] <Tom Phelan> results show stable imps
[12:11:16] <Tom Phelan> all major os covered, although windows covered by third party
[12:11:57] <Tom Phelan> michael tuxen: auth chunks for sctp
[12:12:38] <Tom Phelan> goals: address reconfig chunks are sent from real peer
[12:12:42] <Tom Phelan> don't rely on pki
[12:12:57] <Tom Phelan> don't restrict to address reconfig, if possible
[12:13:12] <Tom Phelan> diffs 00-01
[12:13:18] <Tom Phelan> changed encap
[12:13:35] <Tom Phelan> mech to agree on shared secret
[12:13:48] <Tom Phelan> mech to exchange chunk types to be authed
[12:14:03] <Tom Phelan> mech to derive sctp association from endpoint secret
[12:14:36] <Tom Phelan> encap of authed chunks changed to simplify implementation
[12:14:53] <Tom Phelan> everything after auth chunk authed
[12:15:10] <Tom Phelan> use diffy-helman for endpoint shared secret
[12:15:38] <Tom Phelan> must deal with replay attacks
[12:16:40] <Tom Phelan> message flow for preshared secret
[12:17:24] <Tom Phelan> message flow, no preshared secret
[12:17:51] <Tom Phelan> computation expense for this in userland, not kernel
[12:18:27] <Tom Phelan> q: confused about endpoints and associations
[12:18:50] <Tom Phelan> m: we can tear it down and setup another one, for replay protection
[12:19:23] <Tom Phelan> q: comments more on terminolgy, less misleading if called per-pair-endpoints
[12:19:46] <Tom Phelan> m: [confused], suggesting different terms?
[12:19:56] <Tom Phelan> no problem with renaming
[12:20:12] <Tom Phelan> tls has master secrets and pre-master secrets, but didn't want to steal
[12:21:05] <Tom Phelan> localized rsvp - [that isn't jukka, is it?]
[12:21:35] <Tom Phelan> end-to-end qos rarely available
[12:21:44] <Tom Phelan> often not needed in backbone
[12:22:09] <Tom Phelan> bottleneck often in access networks
[12:22:11] <Tom Phelan> solution:
[12:22:19] <Tom Phelan> small enhancement to rsvp
[12:22:29] <Tom Phelan> designed way before nsis
[12:22:36] <Tom Phelan> coexists with standard rsvp
[12:22:48] <Tom Phelan> can setup diffserv marking
[12:22:54] <Tom Phelan> what is "small"?
[12:23:04] <Tom Phelan> use 2 unused buts
[12:23:13] <Tom Phelan> 2 new messages (no new structures)
[12:23:22] <Tom Phelan> 2 flags and 2 function calls
[12:23:32] <Tom Phelan> one router running rsvp proxy
[12:23:50] <Tom Phelan> slide diagram
[12:24:32] <Tom Phelan> lrsvp proxy terminates and answers local messages
[12:24:45] <Tom Phelan> designed for a wireless access network
[12:25:04] <Tom Phelan> trigger the proxy to start standard rsvp exchange towards source host
[12:25:14] <Tom Phelan> new message tag request
[12:26:28] <Tom Phelan> what next?
[12:27:00] <Tom Phelan> q: 50 i-ds require a friend in network, need to start talking to each other
[12:27:22] <Tom Phelan> mobile home agent, other proxies, good idea to find different strategies for finding friend
[12:27:39] <Tom Phelan> lots of apps can use, how to you find proxy?
[12:28:02] <Tom Phelan> presenter: rsvp will send along path, and if proxy there it'll find it eventually
[12:28:46] --- faultylink has joined
[12:29:13] <Tom Phelan> bruce davie: looks like something people have been looking for for a long time
[12:29:32] <Tom Phelan> other drafts have been close to this, i've done similar things in cable environment
[12:29:47] <Tom Phelan> looks like to good design, progress to experimental
[12:30:00] --- cgn has left
[12:30:21] <Tom Phelan> melinda shore: need for this kind of thing, but not crazy about sending message in forward direction, wouldn't it be better to install message in forward direction?
[12:30:31] --- reh has joined
[12:31:09] <Tom Phelan> presenter: doesn't it do the same thing?
[12:31:19] <Tom Phelan> still have same addressing problems
[12:31:33] <Tom Phelan> m: refering sending request to proxy to send path message
[12:31:46] --- becarpenter has left: Replaced by new connection
[12:31:55] --- becarpenter has joined
[12:32:07] <Tom Phelan> presenter: changes rsvp behavior significantly
[12:32:10] --- cgn has joined
[12:32:10] <Tom Phelan> m: yes
[12:32:42] <Tom Phelan> present: some filtering to determine downstream, but sounded pretty complex. simple trigger message
[12:32:49] <Tom Phelan> m: but not simple:
[12:33:06] <Tom Phelan> sumitha: see need, but not crazy about solution
[12:33:18] <Tom Phelan> maybe some combination of flags
[12:33:30] <Tom Phelan> than new messages
[12:33:51] <Tom Phelan> present: tried to keep standard rsvp as intact as possible
[12:34:56] <Tom Phelan> francois: suggestion, didn't seem to nice to send directed message, using path in forward direction doesn't work with asymetric message, something hop-by-hop to trigger re-path
[12:35:24] <Tom Phelan> present: have some routing for path req and path, which ip address in destination, don't need to know address of proxy
[12:35:43] <Tom Phelan> jon: good cause for more discussion
[12:36:37] <Tom Phelan> allison: diffserv basic classes, had reviewers, start with their reviews first, some reviewers not here,
[12:37:04] --- cgn has left
[12:37:05] <Tom Phelan> discussion of reviews after that
[12:37:33] <Tom Phelan> david black: see draft early, liked it alot, really good and necessary thing
[12:37:40] <Tom Phelan> diffserv as toolkit
[12:37:46] <Tom Phelan> draft is a project plan
[12:38:00] <Tom Phelan> long overdue addition to diffserv
[12:38:44] <Tom Phelan> suppose protocol draft didn't think of, which class?
[12:38:52] <Tom Phelan> some sumary and structure work
[12:39:35] <Tom Phelan> allison: do you recommend changes?
[12:39:43] <Tom Phelan> d: yes, send to mailing list
[12:39:50] --- faultylink has left: Replaced by new connection
[12:39:50] --- faultylink has joined
[12:39:56] <Tom Phelan> brian carpenter:
[12:40:27] <Tom Phelan> this does least damage to diffserv architecture
[12:40:33] --- sakai has left
[12:41:05] <Tom Phelan> little bit worrying, some clueless isps may assume that they must implement all of the classes
[12:41:26] <Tom Phelan> not realize it's a menu, and pick what you want
[12:41:45] <Tom Phelan> other thing, there's a lot of MUSTs
[12:41:52] <Tom Phelan> most of them should be SHOULDs
[12:42:14] <Tom Phelan> more about making people realize that there are some optioins
[12:42:33] <Tom Phelan> one that should be a MUST, service MUST be engineered for sufficient ef capacity
[12:42:44] <Tom Phelan> other places are not quite that MUST
[12:43:32] <Tom Phelan> witt: side with brian, too many MUSTs
[12:43:50] <Tom Phelan> also mentioned multiple ef queues, ef says there's only one ef
[12:44:18] <Tom Phelan> brian: af draft refers to four af classes, no reason there can't be multiple efs
[12:45:35] <Tom Phelan> bruce davie: pretty sure that is allows multiple ef queues, most people implement it as priority queue, so ther can't be multiple of those, but you can implement with wfq or similar, and then you could have more
[12:45:53] <Tom Phelan> brian: made mistake allocating multiple dscps for af and only one for ef
[12:46:04] <Tom Phelan> [missed question]
[12:46:35] <Tom Phelan> jozef: characterize endpoint behavior not performance
[12:47:00] <Tom Phelan> on ef issue, specify additional ef should use wfq
[12:47:24] --- loughney has left: Disconnected
[12:47:57] <Tom Phelan> allison: question to reviewers: you were thinking how it works in with diffserv architecture, but for apps, like telephony apps should use X, did you think in terms of app users when you read, do we need app reviewers?
[12:48:23] <Tom Phelan> brian: yes, should someone who knows about video streaming look to see if right class is recommended?
[12:48:48] <Tom Phelan> if apps stick codepoint in and expect the network to magically perform?
[12:48:59] <Tom Phelan> jon: if sip it says you should use this
[12:49:09] <Tom Phelan> b: there should be app review
[12:49:28] <Tom Phelan> allison: review has been from net arch level, now we need app level
[12:50:33] <Tom Phelan> dave black: looked from point-of-view of netadmin, number of classes for signaling traffic, that view that there are administratively different traffic flows in useful
[12:50:45] <Tom Phelan> [too fast to get next title and author]
[12:50:59] <Tom Phelan> issues from other reviewers
[12:51:22] <Tom Phelan> [oh - we're still in diffserv classes]
[12:51:46] <Tom Phelan> basically have agreed with reviewers comments
[12:51:55] <Tom Phelan> major changes from -02
[12:52:06] <Tom Phelan> sect 1 restuctured for better flow
[12:52:27] <mankin> right, this is kwok ho chan speaking about the 03 draft of diffserv classes
[12:52:30] <Tom Phelan> sect 2,3,4 single phb per service class
[12:52:40] <Tom Phelan> added new service classed
[12:52:59] <Tom Phelan> added figure indicated behavior of service classes
[12:53:21] <Tom Phelan> next steps
[12:53:32] <Tom Phelan> generate open issues list
[12:53:35] <Tom Phelan> new version
[12:53:41] <Tom Phelan> maintain open issues list
[12:53:52] <Tom Phelan> setup schedule for completion
[12:54:47] <Tom Phelan> jon: rev planned now, wg consensus as wg item, solicit app review
[12:55:06] <Tom Phelan> get more review before decision about progress
[12:55:24] <Tom Phelan> with this much attention progression gets progressively likelier
[12:55:50] <Tom Phelan> allison: opsec document give similar prescriptions for security, ended up being info with lot of MUSTs and SHOULDs
[12:56:02] <Tom Phelan> lots of specific info that people found useful
[12:56:09] <Tom Phelan> but took lots of review
[12:56:25] <Tom Phelan> wasn't clear in the end whether it could have standard status, because so many stakeholders
[12:56:41] <Tom Phelan> if standard might miss new discoveries
[12:56:52] <Tom Phelan> think we might find ourselves going down that path
[12:57:01] <Tom Phelan> clear that this doc has lot of interest
[12:57:15] <Tom Phelan> present: how do we get app level review?
[12:57:29] <Tom Phelan> allision: avt and sip wgs, yes, avt and sip chairs?
[12:57:40] <Tom Phelan> jon: ask the chairs if they can find resources
[12:58:32] --- jishac has left
[12:58:49] <Tom Phelan> allison: multiple addresses in transport -for discussion
[12:59:28] <Tom Phelan> counting on group to have attention drawn and go onto deeper thoughts
[12:59:50] <Tom Phelan> hosts have gotten multiple addresses in more ways that is obvious
[13:00:01] --- reh has left
[13:00:06] <Tom Phelan> ipv3 - private realm and nat'ed global
[13:00:17] <Tom Phelan> sometimes it knows about global address, sometimes doesn't
[13:00:40] <Tom Phelan> multiple global addresses due to multi-homing
[13:01:09] <Tom Phelan> ipv6 site-local [sic, she meant link-local], global
[13:01:37] <Tom Phelan> addresses of addditional interfaces (e.g. SIGTRAN)
[13:02:28] <Tom Phelan> transports have handled this:
[13:02:30] <Tom Phelan> tcp - not
[13:02:44] <Tom Phelan> sctp - carefully, multiple address
[13:03:05] <Tom Phelan> dccp - moved to extension, probably experimental
[13:04:13] <Tom Phelan> sctp and dccp have different approaches, neither have gone into nat traversal, whole issue not looked at by either group
[13:04:23] <Tom Phelan> session protocols
[13:04:53] <Tom Phelan> sip: SDP ANAT, one ipv4 and one ipv6 offered
[13:05:14] <Tom Phelan> ICE: finds global address for UDP
[13:05:55] <Tom Phelan> nsis: nat/fw app considering multi-address model
[13:07:08] --- faultylink has left: Disconnected
[13:07:57] <Tom Phelan> crux of discussion
[13:08:07] <Tom Phelan> multiple approches
[13:08:15] <Tom Phelan> multi6 and HIP
[13:08:28] <Tom Phelan> tens of proposals with tens of goals
[13:08:56] <Tom Phelan> major goal is scaling routing system
[13:09:34] <Tom Phelan> not fault-tolerance
[13:09:58] <Tom Phelan> NOID: id is one global ipv6 address
[13:10:05] --- sarolaht has joined
[13:10:08] <Tom Phelan> HIP/WIMP: id is internal app only
[13:10:19] <Tom Phelan> all mask locators from the session layer
[13:11:22] <Tom Phelan> use transport work more?
[13:11:32] <Tom Phelan> id work compatible with transport, session goals?
[13:11:47] <Tom Phelan> transport select source address?
[13:11:56] <Tom Phelan> which layer rules? why?
[13:12:16] <Tom Phelan> comments? [big rush for mic]
[13:12:50] <Tom Phelan> [forgot name]: some people think connection in internet should be like connection in telephone
[13:13:00] <Tom Phelan> changing transport to do this is bad idea
[13:13:12] <Tom Phelan> if we had one mech (like a library) maybe,
[13:13:15] <Tom Phelan> but too much cruft
[13:13:29] <Tom Phelan> don't confuse ids with security
[13:13:38] <Tom Phelan> allisino: security out of discussion for now
[13:13:56] <Tom Phelan> jon rosenberg: layers are confusing at this level
[13:14:08] <Tom Phelan> happens at bottom of app layer, top of session, other?
[13:14:39] <Tom Phelan> clear diff between where you have some session info already, but how to get started from scracth?
[13:14:52] <Tom Phelan> once i have session up, other stuff not helpful
[13:15:13] --- sarolaht has left: Disconnected
[13:15:30] <Tom Phelan> when you said session, thats diff between ice and sctp and multi6
[13:15:57] <Tom Phelan> melinda shore: just beacuse its a problem at transport layer, it isn't necessarily for transport layer to solve
[13:16:13] --- mallman has left
[13:16:17] --- hkruse has left: Disconnected
[13:16:18] <Tom Phelan> the nsis thing sounds a little wierd, operating independent of routing
[13:16:47] <Tom Phelan> brian carpenter: could probaly talk to half hour, ipv6 not interested in nat traversal, questions about this mess of upper layer stuff
[13:16:57] <Tom Phelan> question not same to transport and app people
[13:17:09] <Tom Phelan> lot of people who just use tcp and don't understand multiple address
[13:17:25] <Tom Phelan> other extreme are app writers who can do path opt as part of app
[13:17:49] <Tom Phelan> have id that looks like ipv6 address and magic happens in layer 3.5
[13:18:05] <Tom Phelan> what are goals that we aim to support in the multi6 shim
[13:18:14] <Tom Phelan> allision: shounds like we'll give something like that
[13:18:50] <Tom Phelan> [new speaker at mic]: if transport only handles id as opaque tokens, can replace things underneath
[13:19:15] --- mlshore has left
[13:19:18] <Tom Phelan> [new speaker, no name]: important to have multiple address for multiple reasons
[13:19:37] <Tom Phelan> in sigtran, reason for redundancy is high availability
[13:20:04] <Tom Phelan> witt: decopule sessions from transport is good idea
[13:20:25] <Tom Phelan> qos signaling simplified with session id
[13:20:59] <Tom Phelan> aaron falk: dividied up hip - picking with locator moved
[13:21:25] <Tom Phelan> [new speaker from hip wg]: getting actual locator in research group
[13:21:45] <Tom Phelan> aaron: interest in passing hints about which address to use, should coordinate with hip
[13:22:00] <Tom Phelan> allison: final word is coordinate, need more of us to be more involved
[13:22:01] --- becarpenter has left
[13:22:04] <Tom Phelan> reached end of time
[13:22:09] --- mankin has left: Disconnected
[13:22:10] <Tom Phelan> all done
[13:22:17] --- Tom Phelan has left
[13:23:08] --- admcd has left
[13:23:11] --- Jukka Manner has left
[13:33:39] --- dinakar has left: Replaced by new connection
[13:33:39] --- dinakar has joined
[13:33:40] --- dinakar has left