[11:44:54] --- bob has joined
[11:45:00] --- bob has left
[11:50:23] --- tom5760@gmail.com has joined
[11:52:45] --- jlcjohn has joined
[11:54:43] --- jeffa has joined
[11:58:09] --- kakima has joined
[11:58:50] --- UlrichHerberg has joined
[11:59:36] --- badamson has joined
[11:59:58] --- jronan has joined
[12:03:33] --- teco has joined
[12:04:06] <badamson> If anyone on Jabber has questions, I am close to the mic and can relay. I'm acting as "Jabber Scribe".
[12:04:13] --- tclausen has joined
[12:08:47] --- sommer@jabber.cc has joined
[12:12:19] --- soyoung has joined
[12:15:01] --- soyoung has left
[12:16:15] --- swb has joined
[12:17:50] <swb> I don't see any messages after your first one. Is the room quiet?
[12:18:36] <jeffa> yes
[12:21:29] <badamson> Is the audio working for remote participants? Presentations are underway.
[12:21:44] <swb> I'm in another WG meeting so can't use audio
[12:22:07] <swb> I know the agenda, I'd be interested in hearing a summary of discussion about presentations
[12:23:03] <badamson> The SMF draft update is now being presented. The document was updated significantly. Material added but non-spec material removed so document only increased in size by one page. Security considerations beefed up.
[12:23:24] <badamson> Now presenting a couple of possible attacks against DPD based forwarding and candidate solutions.
[12:24:39] <badamson> For I-DPD, a private "internal hash" value might be used by forwarders to avoid spoofing attacks that would cause denial-of-service against valid packet flows.
[12:25:12] <badamson> I-DPD plus simple "internal hash" would likely be less computationally complex than a cryptographically strong H-DPD approach.
[12:26:10] <badamson> Im going to present now, so if someone can continue summarization ...
[12:26:16] <tclausen> I'll try
[12:26:38] <tclausen> BAdamson: update of implementation to reflect changes to NRL SMF implementation....
[12:27:30] <tclausen> Overview: user-space IP multicast forwarding, other components for neigborhood discovery, relay set selection
[12:28:00] <tclausen> Multiple interface / gateway support manet-nonmanet interfaces, multi-hoped operation. Tests with sparse-mode PIM in lab.
[12:28:16] <tclausen> Considerable use in simulation, emulation and field tests....
[12:28:26] <tclausen> Recent updates: table-based IDPD
[12:28:47] <tclausen> ...change from window-based due to security worries.
[12:29:02] <tclausen> Added support for hash-based DPD
[12:29:18] <tclausen> ...fragmentation, IPSec.
[12:29:47] <tclausen> Gotten code to work within the past few months, currently running testing -- on performance, also on-chip performance.
[12:30:01] <tclausen> Wants to look at things such as TTL based solutions re. wormhole attacks.
[12:30:22] <tclausen> Expect this to not cause a lot of unnecessary duplicates, but want to verify this.
[12:31:04] <tclausen> Discussion on nrlsmf commands (I suppose, for running their software) for different DPD mechanisms, hashing algorithms, .....
[12:31:26] <tclausen> User-guide available on their download site.
[12:31:47] <tclausen> Option for ttl rescoping (!)
[12:31:54] <tclausen> Now, onto graphs showing stff.....
[12:32:36] <tclausen> Memory usage: window-based consumes a constant amt of memory, whereas CRC and md5 are linear in pkt/sec.
[12:32:50] --- junghoon.jee has joined
[12:32:58] <tclausen> CPU usage, initial tests but not on the point where they have calculated detailed CPU usage.
[12:33:34] <tclausen> Table-based I-DPD and H-DPD have similar lookup and mem costs.....
[12:33:46] --- john.zhao has joined
[12:33:57] <tclausen> Hash-computation may be substantial if one goes with cryptographically strong hash algorithm....
[12:35:04] <tclausen> Next steps: look at diff light-weight algorithms for internal hash
[12:35:09] --- apetrescu has joined
[12:35:16] <tclausen> Implement ttl-based solution for wormhole attack.
[12:35:51] <tclausen> Not on slide: may want to add some additional group filtering capability.
[12:36:01] <tclausen> To only forward or deny forwarding certain groups.
[12:36:22] <tclausen> Joe Kapena: use SMF heavily for researhc and deployed projects
[12:36:42] <tclausen> JK: Nice to see the spec develop towards something more stable. Nice evolution from previous version
[12:36:58] <tclausen> JK: Relay set algorithms should be included in I-D since it's good to have.
[12:37:03] <tclausen> JK: Very excited about hashing
[12:37:25] <tclausen> JK: concerned about CPU resource consumptions -- less about memory.
[12:37:40] <tclausen> JK: might be ok to trade off collisions for faster hashing
[12:37:54] <tclausen> BA: identifying light-weight hashing is a goal...
[12:38:08] --- tom5760@gmail.com has left
[12:38:29] <tclausen> Chales Perkins: you can really quantify the CPU drain of the algorithm.....
[12:38:36] <tclausen> BA: trying to collect that...
[12:39:01] <tclausen> CP: Simplified MD5 turns out to be practically no CPU effort at all....
[12:39:24] <tclausen> BA: yes, for pda-type platforms we need to be aware that we not use any more CPU than we have
[12:40:16] <tclausen> BA: if concerned by security, probably need a fairly strong cryptographic hash...
[12:40:26] <tclausen> CP: did you ever see a worm-hole attack in the field?
[12:40:41] <tclausen> JM: It's just so easy to do -- not really a matter if we've seen it yet in tests.
[12:40:58] <tclausen> BA: this is a low-cost, high-gain attack, so needs to be done....
[12:41:32] <tclausen> BA: worried about DoS -- the nature of DPD based forwarding introduces new vulnerabilities. So we need to deal with those issues.
[12:41:55] <tclausen> I'll leave the follow-up scribing to BA
[12:43:09] <swb> thank you both
[12:43:32] <badamson> Thomas Clausen - NHDP and OLSRv2 update
[12:44:18] <badamson> No published changes since last IETF, but team has congregated this week to work on updates
[12:44:46] <badamson> PacketBB and jitter (to some extent) update impact to be addressed.
[12:44:52] <badamson> For NHDP specifically:
[12:44:55] --- ruri_hiromi@chat.gizmoproject.com has joined
[12:45:05] --- ruri_hiromi@chat.gizmoproject.com has left
[12:45:29] <badamson> Identify recently-used-own-address, avoid polluting 2-hop set,
[12:46:17] --- intvelt has joined
[12:46:26] <badamson> Removed "Local Interface Block" and OTHER_IF_TLV, replaced with LOCAL_IF_TLV in single NHDP address block ... packet size savings in the most common cases (e.g. single local address)
[12:46:41] <badamson> Document will be released by end of the week.
[12:48:11] <badamson> For OLSRv2, same changes to NHDP, local addr block removed, etc
[12:48:25] <badamson> Added missing section ensuring set consistency.
[12:48:35] <badamson> Also hope to get this updated version submitted this week.
[12:50:25] <badamson> Thomas summarizing remaining issues: metrics, etc that aren't addressed in this pending update ... but think these remaining issues are orthogonal to current document.
[12:50:47] <badamson> Joe Macker: Can we instigate a discussion on the list on metrics, etc ...
[12:50:56] <badamson> Thomas: yes.
[12:51:20] <badamson> Justin Dean: W/ NHDP, OLSR, etc, some mods may be needed depending on the MANET ID TLV discussion
[12:51:46] <badamson> Chris Dearlove: These matters are likely a broader issue that would _not_ be adddressed in these documents, but separately.
[12:52:22] <badamson> Loop Detection Discussion:
[12:52:52] <badamson> Yasunori Owada presenting ...
[12:54:09] <badamson> Motivation: every routing protocol is not loop free, radio resources are wasted by unnecessary looped packets ... looped packets should not be forwarded.
[12:55:31] <badamson> Loop detection: if nextHopMac == lastHopMac, loop is detected and discard traffic ... no previous packet state needed.
[12:56:53] <badamson> Other loop detection: same as duplicate packet detection (DPD) used in SMF
[12:57:23] <badamson> Actions on loop detection: discard looped packet, notify routing protocol of loop existence.
[12:58:11] <badamson> Simulation results based on nOLSRv2 (Niigata University implementation)
[12:58:34] <badamson> Joe Macker: Which NHDP?
[12:58:45] <badamson> Answer: NHDP based on -02 NHDP draft
[12:59:56] <badamson> Link layer notification, mid-loop detection (mac addr based), post-loop detection (DPD based)
[13:00:36] <badamson> Chris Dearlove: You should _not_ get looping w/ OLSRv2 in a static topology as indicated (sim scenario was static, no mobility)
[13:00:46] <badamson> Joe Macker: agree, should not have loops
[13:01:35] <badamson> Ian Chakares: Graph shows little/no loops for OLSR, but with Link Layer Notification, there are loops ...
[13:01:52] <badamson> Chris Dearlove: This does not reflect our experience w/ OLSR
[13:02:25] <badamson> Joe Macker: While no mobility, perhaps there is packet loss ... so loop might be possible ...e.g., w/ significant congestion. Was there congestion?
[13:02:36] <badamson> Owada: not clear
[13:04:22] <badamson> Thomas Clausen: Looking at sim parameters, 5 CBR streams ... hard to see how it could be congested ... there might be temporary loops from startup ... loops might be due to initialization effects if timer intervals are relatively long ... but can't see how long term, persistent looping would be present ...
[13:05:06] <badamson> Joe Macker: From practice, you shouldn't treat routing control as best effort ... should give higher precedence to control messages.
[13:05:23] <badamson> Justin Dean: If not time, temp loops could cause congestion ...
[13:06:18] --- john.zhao has left: Computer went to sleep
[13:07:05] <badamson> Thomas Clausen: reacting to link layer notification (LLN) would perhaps lead to results seen ... result of random removal of information from protocol ... undefined operating condition depending upon how LLN is implemented ... could be done incorrectly ... not following the spec here makes it hard to interpret results wr2 given protocol
[13:07:11] --- john.zhao has joined
[13:07:33] <badamson> Owada: LLN information was signaled ...
[13:07:57] <badamson> Thomas: not clear LLN is done per spec
[13:09:37] <badamson> Teco Boot: random traffic highly influence other links ... so there can be loops in static scenarios ...
[13:10:05] <badamson> Joe Macker: agree ... in radio environment there can be dynamics without mobility (e.g. due to fading, etc)
[13:10:46] <badamson> Mobility results slide: show less packet loss w/ loop detection .
[13:11:28] <badamson> Mid/Post performance about the same, so most loops can be detected w/ macAddr approach.
[13:13:57] <badamson> Key points: loop detection, discard of looped packets improve total performance, technique is routing independent
[13:14:14] --- junghoon.jee has left: Lost connection
[13:14:23] <badamson> Brian Adamson: looping may cause congestion? leading to control packet loss and more looping as well as data packet loss?
[13:14:36] <badamson> Justin Dean: agrees this may be possible.
[13:15:35] --- soyoung has joined
[13:15:40] <badamson> Joe Macker: could we look at this with router control packets getting priority ... temporary loops are a fact of life in a dynamic environment ... important to do experiments correctly to understand this better.
[13:18:26] --- junghoon.jee has joined
[13:18:29] <badamson> Thomas Clausen: has not detected this as an important problem ... loops tend to disappear but there are some things that worry me .. interaction of loops observed due to incorrect usage of LLN ... doubt problem is of magnitude presented ... has seen loops but not of this magnitude. Reducing loops good, but would like to see if this is a "real" problem, before we start injecting mechanisms to deal with this ... rather small issue that might be addressed by giving control traffic priority, proper implementation, etc
[13:19:07] <badamson> Charlie Perkins: don't agree that routing loops are a "fact of life" ... e.g., DSR (source routing) would not have loops ...
[13:19:55] <badamson> Joe Macker: In a distributed routing protocol in dynamic environment loops can occur, but yes, in DSR, there would not be loops, so such statements do need to be qualified.
[13:20:18] <badamson> Chakares: needs to be more discusion on simulation config, etc
[13:20:27] --- intvelt has left
[13:21:17] <badamson> Ron In' t Velt: Impact of MAC layer collisions on SMF Goodput presentation
[13:22:20] <badamson> 8 node experiment using "nrlsmf", 802.11 in IBSS mode, w/ attenuator-based physical layer connectivity emulator. Configured for "Classic Flooding" operation
[13:22:54] <badamson> One node originates traffic w/ 6 forwarders to a final destination ... 1 pkt/sec transmission rate
[13:24:33] <badamson> Results: Did collisions cause packet loss ... for TTL == 5, everything looks good ... sent 301 packets, 299 packets made it to the destination ... only a few packets loss, but ...
[13:26:26] <badamson> For TTL == 4 (just enough TTL to make it), only 95 packets received? ... implication is packets are taking a longer than expected route to make it ... so it appears that typically, redundancy of flooding and radio "capture effect" have significant impact ... so "jitter" might help reduce collisions and help.
[13:26:42] <badamson> Concerned that current Jitter I-D is "control plane" only
[13:26:49] <badamson> More experimental work to be done.
[13:27:19] <badamson> Justin Dean: would like to see how reduced relay set works ... expects to see less collisions
[13:27:41] <badamson> Ron: agree, but expect phenomena will still be present.
[13:28:40] <badamson> Thomas Clausen: interaction between jitter and upper layer protocols is not well-understood, further experiments and better understanding needed ... but that is why Jitter I-D limited to control traffic where impact of jitter is better understood .
[13:28:52] <badamson> Ron: Hopefully others can help perform added experiments.
[13:32:05] <badamson> Chris Dearlove: Hard to know how much jitter to add to data trafffic.
[13:32:34] <badamson> Joe Macker: result that shortest path TTL may not be always sufficient is interesting
[13:32:54] <badamson> Perkins: does this lead us to consider adding some reliability to multicast forwarding?
[13:33:07] <badamson> Ian Chakares: MANET ID TLVs Presentation
[13:33:58] --- swb has left
[13:34:17] <badamson> Motivation: looking for a way to administratively label routing control message/information to enable protocols to restrict dissemination/processing
[13:35:06] <badamson> Problems: how to allow multiple routing topologies, how to administratively limit control message dissemination/processing ... idea is to "label" it
[13:35:33] <badamson> E.g, OSPF "Area ID" and OSPF "Instance ID" ... so a similar concept may be useful for MANET
[13:36:11] <badamson> Draft specifies packet/message/address TLVs for "MANET ID" to identify or "label' information
[13:36:29] <badamson> Open mic to questions/problems/comments/etc ... big queue at mic!
[13:37:14] <badamson> Justin Dean: latest SMF draft has an "algorithm type" TLV that might be merged with this concept? Value in this sort of TLV ... so different protocols using them (e.g. NHDP) ...
[13:37:19] --- sommer@jabber.cc has left
[13:37:37] <badamson> Ian Chakares: We need to clearly identify the semantics of what labeling information might mean.
[13:39:20] <badamson> Chris Dearlove: I think that the TLV shouldn't be the "beginning" of this discussion ... the question is over different protocols using NHDP and how they interact, some spread to autoconf (work could be done filtering on addresses, etc) ... it should be more "problem statement" now instead of jumping to the solution ... These are extensions and don't need to be part of the current documents ...
[13:39:53] <badamson> Ian Chakares: concerned about separate documents/issues ... Ian thinks there are some things we may need to put into protocol specs now and can't later
[13:40:06] <badamson> Chris Dearlove: don't think it will be the case, but understand the point
[13:40:12] --- intvelt has joined
[13:42:20] <badamson> Clausen: in SMF, there are several algorithms possible and can now communicate which algorithm is used etc, then there is the issue of running SMF/OLSR concurrently within range of each other, but with each using different relay set algorithms, then concurrent unicast routing (e.g. DYMO/OLSR), etc ... there is enough motivation for understanding this problem thoroughly .... one way to distinguish these things to have each autonomous domain be identified ... or tagging approach.
[13:43:09] --- igarashi has joined
[13:43:24] <badamson> Clausen: Can use component of address as discriminator ... for tagging, what do you tag, addresses or messages, etc ... there are interactions ... what happens at the border of a MANET? What is a border? What is the expected behavior, etc?
[13:45:08] <badamson> Clausen: Do you inject routing state from one domain to another, etc? These issues are somewhat orthogonal, but also related ... we don't know how to do this correctly yet. Agree that it is probably "problem statement" time ... we could spec protocols as they are w/ a disclaimer that we look at this later (e.g. once we develop "BGP for MANET" ;-)), we then specify this added ...
[13:45:54] <badamson> Fred Templin: may be overlapping Thomas ... comes to questions of "What is a MANET?", "What is a site?" ... Even if we have a TLV, do we know at this point to put in the value?
[13:46:54] <badamson> Hwe Ten (SP?): added an ID and encrypted it ... prefer area based instead of address-based ...
[13:47:33] <badamson> Joe Kopena: draft by itself innocuous and non-controversial, but how to use that TLV is less so
[13:48:14] --- anthonyschoofs@jabbernet.eu has joined
[13:48:54] <badamson> Joe Kopena: Opposed to combining SMF algorithm and this ... so it is possible that nodes in a common area might run different algorithms ...
[13:49:06] <badamson> Chakares: agree, what is the real semantic of this ...
[13:49:34] <badamson> Kopena: restricting TLV to be not used in address block idea was floated on list, but there may be uses for this ...
[13:50:14] <badamson> Chakares: context of tag in packet/message/addr block is different.
[13:50:57] <badamson> Justin Dean: one problem ... NHDP for both SMF(S-MPR) and OLSR ... messages would look the same.
[13:51:16] <badamson> Chris Dearlove: there are problems, but there is not yet a problems statementd
[13:52:03] --- xiaohunhun has joined
[13:52:23] <badamson> Dearlove: the question of authentication TLVs is related? permissive hooks are right, but actual mechanisms not appropriate for current documents.
[13:52:42] <badamson> Perkins: features required before DYMO/OLSRv2 done?
[13:53:01] <badamson> Chakares: it is not clear that this won't impact current protocol documents.
[13:53:27] <badamson> Perkins: hope this is not required ... there is probably a year-long discussion to get it right here.
[13:53:51] <xiaohunhun> Hwe Ten (SP?) Hui Deng (China Mobile)
[13:54:07] --- yowada has joined
[13:54:19] <badamson> Clausen: put permissive hooks into protocols in short term, but agree putting in actual mechanisms out of scope of current OLSR/DYMO/etc specs
[13:54:53] <badamson> Joe Macker: Agree ... we've jumped ahead a little bit ...
[13:57:02] <tclausen> I'd just add that I said on the mike that the problem is not only interfacing an SMF domain and an OLSRv2 domain -- but also, an OLSRv2 domain with another OLSRv2 domain.....
[13:57:03] <badamson> Sue Hares: In reality, if you are considering redistribution between protocols ... then you go back to the body of redistribution work and would be in "BGP land" ... there are mobile network problems where autonomous systems and admin domains don't remain constant ... the question is if this germain current drafts ... will delay drafts/specs otherwise
[13:57:29] <badamson> Chakares: Are there suggest hooks you have we can put in the current spec? (to Sue)
[13:57:58] <badamson> Sue hares: there is a good body of work ... and this work should be mined.
[13:58:13] --- soyoung has left
[13:59:06] <badamson> Joe Macker: what Sue said is important ... we've resisted bring this cross-domain issues, etc into this working group ...is there a simple tag we need to add that can then be used by these other bodies of work ... bringing all of that into the MANET WG will be complex!
[13:59:30] <badamson> Sue Hares: Some kind of general metric, etc might cover 80% of the problems.
[14:00:14] <badamson> AC Lindem: it's hard to specify these TLVs without knowing what these are for ... trying to do it in one shot won't work because of the ambiguity
[14:00:38] <badamson> Chakares: there is alot of different semantics that might be attached .....
[14:01:17] <badamson> AC: there might be 2 that can be used ambiguously ...
[14:01:52] <badamson> Dearlove: relay set selection issue brought up needs to be addressed more OLSR/SMF, etc?
[14:02:22] <badamson> Name? Agree that a problem statement is needed first
[14:03:07] <badamson> Perkins: is this a solution to problem that different nodes use different CDS, admin differences, version differences, etc ... not so clear what this would solve
[14:03:51] <badamson> Chakares: There are alot of semantics that people may wish to administratively convey? Needs to be more discussion on what those might be, don't want this to delay deliverables.
[14:05:18] <badamson> Macker: We're agreeing this is a problem ... we're overloading this TLV on many different levels ... let's backoff this on the protocol level ... but there is an architectural issue here. Don't like the idea of overloading this
[14:05:19] --- junghoon.jee has left: Replaced by new connection
[14:05:19] --- junghoon.jee has joined
[14:05:20] --- junghoon.jee has left
[14:05:35] <badamson> Chakares: So if there is an identifiier, it should be clear what the identifier is for
[14:06:01] <badamson> Dearlove: There are some issues that need to be considered together, but they may separate to separate TLVs, etc
[14:07:28] <badamson> Clausen: there are well-defined semantics for OSPF area, etc ... if I define an area or autonomous system, then I would have defined routing policies/algorithms for this area ... so a "mix" of implications from the "ID" may be acceptable ...
[14:08:39] <badamson> Clausen: we need to be clear about what we mean ... before we start saying this is not necessary ... we may want to put a "label" on a "cloud" that implies multiple semantics/policies, etc ...
[14:09:39] <badamson> Clausen/Macker: saying similar things in different ways?
[14:10:33] <badamson> Teco Boot: in a wireless infrastructure, it is different ... not as isolated/controlled as wired interfaces are wr2 defining domains ... a problem statement is needed.
[14:11:44] <badamson> Sue Hares: suggest caution in your terms. RFC 1136? (on admin. domains) ... you're mixing metaphors in your "domains" ... Can have multiple "routing domains" within an "administrative domain", etc ... BGP draws a
[14:13:32] <badamson> Sue hares cont'd": policy boundary ... had prev. worked out some ideas/signalling for how domains break apart, come back together ... need to be careful not "scramble" these domains ... WG needs to tighten up notion of domains ... may not change protocols, etc much ... much of this may be "deployment guidelines", etc not impacting protocols so much
[14:14:13] <badamson> AC: Take one "ID" at a time ... e.g. "packet level" at top of hierarchy ... and then address other ID levels (message/addr blk) separately
[14:14:28] <badamson> Dearlove: Message level may be as important as packet level ...
[14:14:44] <badamson> Chakares: any more questions on this topic?
[14:15:59] <badamson> Perkins: 2 topics: PacketBB ... read last revision ... 3 day last call ... do think that wording could benefit from being more specific about "ordering of TLVs" ... could this be taken into account if draft is revised.
[14:16:42] --- junghoon.jee has joined
[14:18:08] <badamson> Perkins: On NHDP and general ... larger packet sizes than needed ... PacketBB compromise between modular functionality and packet size ... OK, but NHDP may still have a bigger packet size than desired for some systems ... needs a statement that NHDP may not be answer for systems needing minimal message sizes ... it does matter on performance ...
[14:18:58] <badamson> Perkins: On multicast forwarding, reliability signaling seemed useful, but in simulations the added packet size impacted performance so expects it matters ...
[14:19:08] <badamson> Teco Boot: Metrics discussion?
[14:19:50] <badamson> Macker: we can discuss
[14:20:09] <badamson> Teco Boot: we should discuss metrics _today_ to impact OLSR, etc
[14:20:36] <badamson> Justin Dean: Metric TLV draft to include metrics has not been updated yet, but will so comments are encouraged.
[14:20:51] --- junghoon.jee has left
[14:21:31] <badamson> Clausen: Teco's comment was appropriate ... should have discussion, but not a good idea to do one version and then soon do another version (OLSR) w/ metrics added ...
[14:22:20] <badamson> Clausen: making self available for discussion on this for the rest of the week and if chairs feel appropriate, araise mailing list discussion, etc .... also busy w/ NHDP revision.
[14:22:44] <badamson> Teco Boot: important to discuss putting effort into metrics for OLSR, etc.
[14:23:48] <badamson> Clausen: happy to drink a beer w/ Teco ... agree w/ Teco but important to know if we _can_ do this first ... given limited time remaining in meeting, suggest post-meeting discussion of interested parties.
[14:24:35] <badamson> Satoh: standardization process is very slow .... standardize first before addressing metrics ... metrics for wireless is difficult
[14:25:25] --- anthonyschoofs@jabbernet.eu has left
[14:25:49] <badamson> Macker: like to see a metric container in the current spec ...we are going to want it later even if it is used differently. Define the container, but not yet to define what we do with it. So would like to see the container in there.
[14:27:15] <badamson> Dearlove: torn between standardize and putting metrics in ... there is compatibility issue if we standardize now, metrics later ... need more than just a container ... we know how to do it technically ... issue in specifying precisely, implementing it, etc ... decisions need to involve people that are going to do something.
[14:27:40] <badamson> Justin Dean: the "container" approach would get us moving forward.
[14:27:56] <badamson> Macker: need to have a "default" use of the container specified
[14:28:43] <badamson> Perkins: should not try to specify everything right now if it will require new field, etc ... is it 8, 16, 32, etc bits ... we don't the answers enough right now
[14:28:50] --- igarashi has left: Computer went to sleep
[14:29:49] <badamson> Teco Boot: still not consensus on whether to proceed or metrics ... we can define an algorithm, define some stuff and make it "upgradable" ... we need to make a choice here.
[14:30:40] <badamson> Perkins: important subject ... should work on it ASAP ... there are metrics that have been used that help (non hop count) ... but question if we put them in the existing specs ... and then have an important/timely effort immediately after.
[14:30:47] <jronan> right.. outta here...
[14:30:48] --- kakima has left
[14:30:54] --- tclausen has left: Logged out
[14:30:54] <badamson> Chakares: we need to decide which way to go
[14:30:58] --- UlrichHerberg has left
[14:30:59] --- jronan has left
[14:31:00] <badamson> Meeting closed.
[14:31:13] --- yowada has left
[14:31:25] --- jeffa has left
[14:31:53] --- badamson has left
[14:32:03] --- intvelt has left
[14:35:14] --- john.zhao has left
[14:40:19] --- xiaohunhun has left
[14:46:51] --- apetrescu has left: Replaced by new connection
[14:48:57] --- teco has left
[15:51:59] --- teco has joined
[16:04:21] --- soyoung has joined
[16:04:28] --- jlcjohn has left
[16:04:54] --- soyoung has left
[18:06:02] --- teco has left