[12:02:03] --- LOGGING STARTED
[17:39:21] --- spencerdawkins has joined
[17:39:28] --- lars has joined
[17:41:32] --- ron_kehno has joined
[17:42:05] --- weddy has joined
[17:48:20] --- falk has joined
[17:50:42] --- sarolaht has joined
[17:50:53] <spencerdawkins> many BOFs in this space requested over period of years, some approved, some not, and more coming now
[17:51:20] <spencerdawkins> want to have a non-WG-forming BOF, but didn't happen (still the right choice)
[17:51:38] <spencerdawkins> people in the community interested in doing a BOF in the future?
[17:52:01] <spencerdawkins> proposals keep coming, into both INT and TSV, there is energy, should channel this
[17:52:21] <spencerdawkins> layering is good, hide details, this is good.
[17:52:37] --- jugi has joined
[17:53:35] <spencerdawkins> users of network-layer abstraction have made additional assumptions about it
[17:54:37] <spencerdawkins> stable IP addresses, roughly stable paths and path characteristics, connectivity rarely disrupted - new network layer mobility layers violate these
[17:55:07] <spencerdawkins> not just mobility, link characteristics are different
[17:55:35] <spencerdawkins> most optimization proposals have been band-aids
[17:55:51] <spencerdawkins> all were interesting, but not generally useful - point solutions
[17:56:22] <spencerdawkins> not currently a BOF proposal - important to remember
[17:56:39] <spencerdawkins> extend communication abstraction?
[17:57:22] <spencerdawkins> independent of network-layer extensions, link technologies, deployment scenarios
[17:58:04] <spencerdawkins> provide additional information? was TRIGTRAN approach
[17:58:16] <spencerdawkins> new transport mechanisms to act on this information
[17:59:02] <spencerdawkins> is information about going UP from network layer helpful?
[17:59:19] <spencerdawkins> won't restrict to up or down
[17:59:28] <spencerdawkins> quickstart went both ways
[18:00:03] <spencerdawkins> not new ideas - goes all the way back to ICMP source quench, unreachables
[18:01:34] <spencerdawkins> should IETF work in this space? what technical approach, sub-spaces that are low-hanging fruit, architectural consistencey, how to manage?
[18:01:55] <spencerdawkins> consensus to form a team for next IETF?
[18:02:11] <spencerdawkins> good thing for IETF to think about this
[18:02:50] <spencerdawkins> all ADs are new, didn't know how to break down into WG-able parts
[18:02:58] <spencerdawkins> there is research here
[18:03:17] <spencerdawkins> IETF may not be good at architecture
[18:03:24] <spencerdawkins> (usually aren't)
[18:03:49] <spencerdawkins> Quickstart picked a specific problem, but that's not what we want to do in the general case
[18:05:06] <spencerdawkins> problem space reaches lower than IETF is smart about (Ethernet switch technology)
[18:05:48] <spencerdawkins> tunnels matter, too - where does architecture happen? deliberately?
[18:06:16] <spencerdawkins> IEEE, 3GPP/IMS...
[18:07:06] <spencerdawkins> how to propose an interface lower-level SDOs would accept?
[18:08:09] <spencerdawkins> we have interaction problems between INT and TSV that we ignore now
[18:08:43] <spencerdawkins> experience with XCP made me leery of "good news" from the network, but "bad news" is OK
[18:09:50] <spencerdawkins> write an ID on IETF history in this space?
[18:10:03] <spencerdawkins> bernard's link draft is helpful
[18:11:51] <spencerdawkins> network layer to transport layer - MIP knows about subnet moves before TSV knows
[18:12:26] <spencerdawkins> what to do when your IP address changes? what does TSV do?
[18:12:36] <spencerdawkins> provide link characteristics?
[18:13:44] <spencerdawkins> concern about signaling link characteristics end-to-end - how does that help you?
[18:14:45] <spencerdawkins> mobility is primarily an access problem, if you switch network types drastically, things should change, but that doesn't mean that nothing else changes
[18:15:26] <spencerdawkins> by the time you discover your end-to-end path, have things already changed?
[18:16:35] <spencerdawkins> in quickstart, just try to do the whole and work out from there
[18:17:49] <spencerdawkins> lots of hints possible - make a list?
[18:18:23] <spencerdawkins> some things are interesting from one link, some things from all the links
[18:18:52] <spencerdawkins> also SOME of the links
[18:19:28] <spencerdawkins> not just mip technologies, no clear winners
[18:19:57] <spencerdawkins> work with all of the technologies?
[18:20:35] <spencerdawkins> two categories - mobility and congestion control/corruption, and there is overlap
[18:21:44] --- mallman has joined
[18:21:59] <spencerdawkins> what to do after we leave this room?
[18:22:04] <mallman> drink beer
[18:22:24] --- weddy has left
[18:22:49] <spencerdawkins> many ways to change a route (OSPF, MIP, HIP, SHIM6, 802.17...)
[18:23:31] <spencerdawkins> TSV either takes at least an RTT or sends information in less than an RTT
[18:24:22] <spencerdawkins> sending a probe, adding a header in some or all packets, ...
[18:24:32] <spencerdawkins> pathchar options header?
[18:24:35] --- jugi has left
[18:24:47] <spencerdawkins> broader version of ECN
[18:24:53] <spencerdawkins> XCP is one example
[18:25:53] <spencerdawkins> not doing anything specific to MIP - mechanism needs to be "generic enough"
[18:26:05] <spencerdawkins> use MIP signaling that has to happen anyway?
[18:27:35] <spencerdawkins> hop-by-hop header in IPv6 four years ago
[18:27:48] <spencerdawkins> signaling is there, need to know what parameters are meaningful
[18:27:50] --- Jukka has joined
[18:28:10] <spencerdawkins> TSV needs to design the response mechanisms
[18:28:24] <spencerdawkins> two interfaces or one?
[18:30:13] <spencerdawkins> where does this fit in the IETF? In the architecture area...
[18:30:36] <spencerdawkins> university in japan (kyoto) looking at the TSV/INT interface
[18:30:51] <spencerdawkins> need to rethink entire interface when you multihome
[18:32:26] <spencerdawkins> TSV doesn't want to choose routes, it wants to avoid problems with the current routes
[18:33:12] <spencerdawkins> hosts start participating in route selection and traffic engineering
[18:33:31] <spencerdawkins> some of this is obviously IRTF work
[18:34:09] <spencerdawkins> (where were the IAB participants for this?)
[18:34:31] <spencerdawkins> we need stuckees for anything to happen
[18:34:53] <spencerdawkins> ADs don't want to drive this (for various good reasons, like cycles)
[18:35:29] <spencerdawkins> call this a team, looking for a team chair?
[18:35:47] <spencerdawkins> is this a design team, small and closed to make progress?
[18:36:04] <spencerdawkins> if not, this could be IRTF activity
[18:36:26] <spencerdawkins> in the MOBOPTS group? They're looking at this now
[18:36:50] <spencerdawkins> suggest taking point solutions and then abstracting
[18:36:58] <spencerdawkins> MOBOPTS has energy now
[18:37:27] <spencerdawkins> not sure we have enough definition for its own RG now
[18:38:04] <spencerdawkins> some of this is OFFPATH material
[18:38:34] <spencerdawkins> keep seeing BOF proposals with issues
[18:38:51] <spencerdawkins> need architectural thinking before something can really happen
[18:39:27] <spencerdawkins> like making a list, like doing the history - concrete steps first
[18:39:41] <spencerdawkins> have open mailing list
[18:40:21] <spencerdawkins> need to go build systems as part of research
[18:41:10] <spencerdawkins> TSV and INT research community disconnected, too
[18:41:55] <spencerdawkins> any researchers with funding to work on this problem?
[18:42:07] --- stewrtrs has joined
[18:42:18] <spencerdawkins> vendors and operators care about this because it makes their stuff work better
[18:45:39] <spencerdawkins> there are a small number of people who can write the history - BOFs that don't become WGs are not well documented, BOFs that are not approved even more so
[18:46:32] <spencerdawkins> there are canonical known landmines now - security, network state, complexity of advisory triggers/guidance, etc. - how long to wait before we think about these things?
[18:47:11] <spencerdawkins> limited to congestion control, or broadening to include requesting alternate routes?
[18:47:36] <spencerdawkins> approaching OFFPATH (but OFFPATH doesn't have the TSV view, either)
[18:48:02] <spencerdawkins> OFFPATH signaling transport paths, but would this include TSV considerations?
[18:48:18] <spencerdawkins> Most of Mark Handley's talk was about ON-PATH...
[18:49:33] <spencerdawkins> should be a way to identify things that COULD be done
[18:50:13] <spencerdawkins> mobility makes no sense without this work ...
[18:51:00] <spencerdawkins> mobility should give better service, but it doesn't - "just do slow start"
[18:52:00] <spencerdawkins> not just research, but architecture - some pieces you can standardize earlier than others?
[18:52:53] <spencerdawkins> could provide transport-layer mobility - we have two TSV protocols that could provide this.
[18:54:52] <spencerdawkins> is it better to expose this stuff to TSV or not?
[18:55:35] <spencerdawkins> some of this is in Bernard's draft, hard to know what is a SIGNIFICANT path change (TTL + 1?)
[18:55:57] <spencerdawkins> hard to know what you care about
[18:56:29] <spencerdawkins> can insert instability if you react and guess wrong
[18:56:49] <spencerdawkins> some link layers are congestively unstable all by themselves
[18:57:35] <spencerdawkins> carve off the definition of path change and do this in the IETF soon - it's pressing now
[18:58:56] <spencerdawkins> nothing is ever as simple as it looks in this space
[18:59:29] <spencerdawkins> getting more abstract makes things harder - that's what we learned in OFFPATH
[19:00:11] <spencerdawkins> this requires architecture, we don't do architectures in WGs well
[19:00:46] <spencerdawkins> doing a careful draft is a way to make progress - thought DNA was easy, but turned out to be hard to get right
[19:02:31] <spencerdawkins> corruptions change routing decisions, and this is hard, because you don't see corruption if you're not sending
[19:03:01] <spencerdawkins> some things are ready for real world but not for research community - is this one of them?
[19:05:13] <spencerdawkins> do some experimental RFC and let people play with this - is that low-hanging fruit?
[19:06:06] --- Jukka has left
[19:06:21] <spencerdawkins> don't know how to get link layer that makes packet corruption visible - 802.16 can indicate broken packets to higher layers
[19:07:35] <spencerdawkins> wasn't there discussion of link-down on enqueuing mechanisms (someplace)?
[19:08:10] <spencerdawkins> remember caching packets and sending them when link comes up
[19:08:56] <spencerdawkins> view is that TCP shouldn't tear down connections when links fail, but what SHOULD it do?
[19:09:26] <spencerdawkins> freeze timers, etc
[19:10:20] <spencerdawkins> could get generic indication of link-down/link-up, but links damp, etc. not always good...
[19:11:13] <spencerdawkins> wasn't this PILC? Who were the co-chairs? :-)
[19:11:41] <spencerdawkins> would love to get standardized indication, whether you trust it or not
[19:11:55] <spencerdawkins> DNA defining link up, but it's for their purposes
[19:12:55] <spencerdawkins> can we look more than one hop in? seems dangerous - link far away is a route flap, may or may not matter
[19:14:27] --- weddy has joined
[19:14:35] <spencerdawkins> have this problem in mesh as well - host knows there is no route
[19:16:23] <spencerdawkins> some discussion of one-hop-away failure - bluetooth or ethernet to 802.11 one hop away
[19:17:10] <spencerdawkins> this is deeply connected to routing
[19:17:31] <spencerdawkins> path change is sub-event of routing change
[19:18:25] <spencerdawkins> why treat a two-hop-away failure differently
[19:20:40] <spencerdawkins> do we want to think about network layer that spans hosts? question is how indications propagate
[19:22:12] <spencerdawkins> routing changes due to frame errors don't make it to hosts unless hosts are participating in routing, and TCP may not react, anyway
[19:23:40] <spencerdawkins> routes are to end destinations, right? it's when you have no route that matters to transports
[19:23:53] --- falk has left
[19:24:10] --- falk has joined
[19:24:21] <spencerdawkins> any protocol that propagates these notifications is a routing protocol
[19:24:47] <spencerdawkins> and has all the implications of routing protocols, including security
[19:25:21] <spencerdawkins> could be on-demand routing protocol
[19:26:29] <spencerdawkins> we're also talking about interactions between RTG and TSV...
[19:27:50] <spencerdawkins> lots of research experience in this space - meshes, etc. with various timescales - hard to generalize? have to know what it means to not have a route
[19:28:33] <spencerdawkins> knowing when to stop timers and when to let them run...
[19:28:43] <spencerdawkins> stopping timers or decaying timers?
[19:29:05] <spencerdawkins> this turns into disconnected network applications
[19:29:20] <spencerdawkins> this is a local routing table issue
[19:29:44] --- falk has left
[19:29:58] <spencerdawkins> and information can go two ways - TSV may know something that RTG doesn't know yet. Randall has a rant on his website about this
[19:30:32] <mallman> what is rrs' web site?
[19:30:44] <spencerdawkins> routes going away, or also large changes in metrics?
[19:30:53] <stewrtrs> www.sctp.org
[19:31:05] <stewrtrs> I think my rant is under downloads.. but I am not sure :-D
[19:31:07] <spencerdawkins> "relavant path changes"
[19:31:51] <spencerdawkins> can you learn faster than observing transport behavior?
[19:32:03] <spencerdawkins> have to get to "near-certainty"
[19:32:03] <stewrtrs> My rant is
[19:32:05] <stewrtrs> http://www.sctp.org/what_is_alt_route
[19:32:33] <spencerdawkins> want path changes that will still matter an RTT later
[19:33:20] <spencerdawkins> what if it was predictable congestion and is now predictable static-related loss?
[19:33:42] <spencerdawkins> start with most basic, black-and-white things - can't send anything period
[19:34:11] <spencerdawkins> start easy (which will be hard) and work to hard (which will be impossible)
[19:34:17] <spencerdawkins> do we want a mailing list?
[19:34:38] <spencerdawkins> ternli@ietf.org already exists
[19:36:09] --- stewrtrs has left
[19:36:33] --- weddy has left
[19:36:38] --- sarolaht has left
[19:36:43] --- ron_kehno has left: Logged out
[19:38:33] --- mallman has left
[19:40:19] --- lars has left
[19:58:48] --- spencerdawkins has left