[09:45:44] --- herve.prigent@jabber.org has joined
[09:45:50] --- herve.prigent@jabber.org has left
[09:59:23] --- pete.stpierre@gmail.com has joined
[10:02:33] --- badamson has joined
[10:03:30] --- florent.parent has joined
[10:03:40] --- florent.parent has left
[10:04:27] --- keyajima has joined
[10:04:48] --- igarashi has joined
[10:06:06] --- alexpetrescu has joined
[10:11:26] --- herve.prigent@jabber.org has joined
[10:12:00] --- yowada@jabber.org has joined
[10:12:32] --- alexpetrescu has left: Replaced by new connection
[10:13:55] --- alexandru.petrescu@gmail.com has joined
[10:15:55] <alexandru.petrescu@gmail.com> some slides are at http://www3.ietf.org/proceedings/07jul/slides/ search for 'manet'
[10:17:01] <badamson> Charlie Perkins at the mic
[10:18:08] --- fp has joined
[10:18:17] <alexandru.petrescu@gmail.com> 'Jitter' slides at http://www3.ietf.org/proceedings/07jul/slides/manet-5.pdf
[10:18:37] <alexandru.petrescu@gmail.com> Thomas Clausen presenting
[10:20:27] <alexandru.petrescu@gmail.com> PacketBB slides at http://www3.ietf.org/proceedings/07jul/slides/manet-4.pdf
[10:20:34] <alexandru.petrescu@gmail.com> Thomas Clausen presenting
[10:20:44] <alexandru.petrescu@gmail.com> slide: Status
[10:22:59] <alexandru.petrescu@gmail.com> Ian Chakeres: CP if you want to talk packetbb is now
[10:23:11] <alexandru.petrescu@gmail.com> Charles Perkins is CP, Ian Chakeres is IC
[10:23:40] <alexandru.petrescu@gmail.com> CP: short comment, thanks invited, thinks unaggregated addresses, get around this by puttin a single bit in a tlv block, 1bit is not terrible hard price to pay
[10:23:48] <alexandru.petrescu@gmail.com> CP: let me send that to list later today
[10:24:12] <alexandru.petrescu@gmail.com> TC: unaggregated addresses right? (yes), how many addresses for translation?
[10:24:29] <alexandru.petrescu@gmail.com> CP: if I remember 50% overhead with these kinds of IPv4 addresses, per-address
[10:24:54] <alexandru.petrescu@gmail.com> TC: sure? I suspsetct representing these addresses in a single block, there's no mandate to have these... not necessary 3 components.
[10:25:00] <alexandru.petrescu@gmail.com> TC: fixed overhead in this case.
[10:25:40] <alexandru.petrescu@gmail.com> CP: addresses in address block are semantically associated somehow in the multivalue tlv that follows, associated that way... we could make a new TLV, containing 'magic' or 'spread' addresses
[10:25:46] <alexandru.petrescu@gmail.com> CP: counter overhead this way.
[10:25:53] <alexandru.petrescu@gmail.com> CP: multiple tlv...
[10:26:00] <alexandru.petrescu@gmail.com> TC: collection of associated addresses?
[10:26:05] <alexandru.petrescu@gmail.com> IC: make sure you talk both same thing
[10:26:21] <alexandru.petrescu@gmail.com> IC: your issue is that overhead of representing addresses not compressing well in the same block?
[10:26:25] <alexandru.petrescu@gmail.com> CP: yes
[10:26:52] <alexandru.petrescu@gmail.com> IC: TC says even if they dont compress well then... different tlv, even if fixed overhead, not necessarily overhead with each address.
[10:26:54] <alexandru.petrescu@gmail.com> CP: right
[10:27:03] <alexandru.petrescu@gmail.com> CP: multiple address blocks with ...
[10:27:06] <alexandru.petrescu@gmail.com> TC: why do that?
[10:27:27] <alexandru.petrescu@gmail.com> CP: I hope be more articulate on mailing list; but here tail bites dog. You talk all space of proto design.
[10:27:46] <alexandru.petrescu@gmail.com> TC: address blocks... associate tlvs with...
[10:28:07] <alexandru.petrescu@gmail.com> TC: collect addresses minimum overhead possible (and not one address by address block), organize addresses inside...
[10:28:20] --- keyajima has left
[10:28:52] <alexandru.petrescu@gmail.com> TC: dont think there's any tail wagging the doc, just a way of representing addresses. Yes, true, could go away, could check DYMO.OLSR and transmit inefficient packets or messages.
[10:29:19] <alexandru.petrescu@gmail.com> TC: we not imposing a way to use this format.
[10:29:27] <alexandru.petrescu@gmail.com> TC: I cant predict all ways to use that.
[10:29:54] <alexandru.petrescu@gmail.com> CP: very abstract layer we stay in, in the sense what's required you're designing a packet format presuming to be very strongly sugested to future manet designs.
[10:30:40] <alexandru.petrescu@gmail.com> CP: on another hand you say you cant imagine a ... my understanding address blocks are blocks of addresses, multi=value tlv, has a range of descriptors being defined,
[10:30:50] <alexandru.petrescu@gmail.com> CP: I dont subscribe to this necessarily.
[10:30:55] <alexandru.petrescu@gmail.com> IC (Ian Chakeres)
[10:31:39] <alexandru.petrescu@gmail.com> IC: both of you say there may be a need, maybe have a recommendation how to take the information contained, expanded format, address and adttributes and how you might recommend it to be more efficiently represented - would you agree some timype of representation is useful?
[10:31:41] <alexandru.petrescu@gmail.com> CP: agrees but.
[10:31:44] <alexandru.petrescu@gmail.com> Joe Macker is JM
[10:32:00] <alexandru.petrescu@gmail.com> JM: packetbb doesnt provide a design example, and nhdp probably does.
[10:32:18] <alexandru.petrescu@gmail.com> JM: it would be useful to see that, because some people may misunderdtsand how you can use it...
[10:32:37] <alexandru.petrescu@gmail.com> JM: reason to do this is to be flexible, one of our choices, how much of desig n really is.
[10:32:46] <alexandru.petrescu@gmail.com> JM: in some cases we reduce overhead in some other case not.
[10:32:59] <alexandru.petrescu@gmail.com> JM: I dont get to that till I see nhdp, or a reall protocol trying t.
[10:33:06] <alexandru.petrescu@gmail.com> JM: nhdp is a good example to start with.
[10:33:07] --- keyajima has joined
[10:33:13] <alexandru.petrescu@gmail.com> TC: example is in the appendix.
[10:33:24] <alexandru.petrescu@gmail.com> JM:... five address or something.
[10:33:38] <alexandru.petrescu@gmail.com> TC: we go back to were in Paris 2005. re-iterate this whole process?
[10:33:56] <alexandru.petrescu@gmail.com> JM: lot of overhead not giving an example. Until we dont see an example we dont see.
[10:34:02] <alexandru.petrescu@gmail.com> JM: relative discussion is not useful
[10:34:08] <alexandru.petrescu@gmail.com> TC: simple: if one address ...
[10:34:21] <alexandru.petrescu@gmail.com> JM: understand but CP is saying it would be nice to see it.
[10:34:30] <alexandru.petrescu@gmail.com> JM: give us an example we can really discuss it.
[10:34:39] <alexandru.petrescu@gmail.com> JM: cant judge until I see a clear example.
[10:34:44] <alexandru.petrescu@gmail.com> TC: relatively quickly
[10:34:51] <alexandru.petrescu@gmail.com> TC: we have already spent lots of time
[10:34:56] <alexandru.petrescu@gmail.com> JM: agree, vaguely agree.
[10:35:14] <alexandru.petrescu@gmail.com> TC: if comments, we try to get those squared away this week, next week, next couple of weeks..
[10:35:18] <alexandru.petrescu@gmail.com> Justin Dean is JD
[10:35:39] <alexandru.petrescu@gmail.com> JD: echo in, having examples and guidelines how to build protocols, best practices of using them in dymo and nhdp.
[10:36:08] <alexandru.petrescu@gmail.com> JD: mailing list recently go, somebody wanted, how would you transmit a network and netmask with packetbb, the examples were completely wrong.
[10:36:15] --- jishac has joined
[10:36:18] <alexandru.petrescu@gmail.com> TC: JD sit with me this week get this done.
[10:36:36] <alexandru.petrescu@gmail.com> CP: reason of using single address blocks vs collective address blocks?
[10:36:39] <alexandru.petrescu@gmail.com> CP: abstract
[10:36:46] <alexandru.petrescu@gmail.com> CP: possible single address blocks are useful.
[10:37:11] <alexandru.petrescu@gmail.com> CP: to make a specific example that needs to design a protocl fitting in the contended space of packetbb, I'll try to do that but not today.
[10:37:34] <alexandru.petrescu@gmail.com> CP: another possibliity, if by design this requires that aggregation, would that indicate a different multi-value dscriptor?
[10:37:40] <alexandru.petrescu@gmail.com> TC: not understand what you say
[10:37:51] <alexandru.petrescu@gmail.com> TC: we talked together about collecting addresses together but
[10:37:53] <alexandru.petrescu@gmail.com> TC:...
[10:38:00] <alexandru.petrescu@gmail.com> TC:...
[10:38:17] <alexandru.petrescu@gmail.com> TC:I dont see why a new multivalue tlv descriptor is required
[10:38:23] <alexandru.petrescu@gmail.com> TC: sounds to me...
[10:39:04] <alexandru.petrescu@gmail.com> CP: collecting together n addresses, multi value tlv work, this is blue, green and yellow. It might not be the case that one is blue and the other is fast, or one is green and the other is secure.
[10:39:22] <alexandru.petrescu@gmail.com> CP: somehting else to that thick? 32bit floating point numbers associated with some addresses but with the others.
[10:39:37] <alexandru.petrescu@gmail.com> TC: if you want to say something about first 5 addresses then you won't put them...
[10:39:41] <alexandru.petrescu@gmail.com> TC: but in a ...
[10:39:45] <alexandru.petrescu@gmail.com> TC: a TLV
[10:40:01] <alexandru.petrescu@gmail.com> TC: TLV single addresses or all addresses in the same block.
[10:40:18] <alexandru.petrescu@gmail.com> TC:...
[10:41:25] <alexandru.petrescu@gmail.com> IC: comes back to the suggestion of how you take the informaiton yo u want to transmit or share and comapct it in a way that's efficient.
[10:41:37] <alexandru.petrescu@gmail.com> IC: which is the most compact way of representing - actually up to implementations.
[10:41:48] <alexandru.petrescu@gmail.com> IC:kind of an open question of what's the best or most efficient
[10:42:17] <alexandru.petrescu@gmail.com> IC: you could if you wanted to have ... even if there is a possiblity of some tiype of aggregation of addresses in address blocks... there could be a recommendation of assisiting in making good decisions
[10:42:21] <alexandru.petrescu@gmail.com> CP: think this is a puzzle
[10:42:49] <alexandru.petrescu@gmail.com> CP: there's more clever and less clever designs that are motivated byu the sides of the box. You m oved the overhead froom the address blok description into the tlv overhead.
[10:42:56] <alexandru.petrescu@gmail.com> CP: but not easy to give perfect examples.
[10:43:01] <alexandru.petrescu@gmail.com> TC: I will exmapnd on that.
[10:43:19] <alexandru.petrescu@gmail.com> TC: one of the signed constraints in this spec was to allow a flexibility not present in aodv, dsr.
[10:43:39] <alexandru.petrescu@gmail.com> TC: we'll have to rewrite the packet format, parser. We wanted to allow a generic way to allow express an attribute.
[10:44:05] <alexandru.petrescu@gmail.com> TC: flexibility comes with the price...
[10:44:12] <alexandru.petrescu@gmail.com> TC: probably encode a very few bits.
[10:44:29] <alexandru.petrescu@gmail.com> TC: french good of these things, committee, academy.
[10:44:49] <alexandru.petrescu@gmail.com> TC: advantageous of packetbb useful for dymo, for olsr, carrying metrics.
[10:44:56] <alexandru.petrescu@gmail.com> TC: maybe useful for many other great things.
[10:45:09] <alexandru.petrescu@gmail.com> TC: comes to a cost of course.
[10:45:22] <alexandru.petrescu@gmail.com> TC: ...
[10:47:04] <alexandru.petrescu@gmail.com> CP: youll never find a statement by me that disallows address agregation, that's not the point. I had a suggestion, I hope it won't be discarded.
[10:47:16] <alexandru.petrescu@gmail.com> IC: in the next week at least able to initiate discussion?
[10:47:25] <alexandru.petrescu@gmail.com> CP: last night I tried but social.
[10:47:33] <alexandru.petrescu@gmail.com> TC: social at breakfast
[10:49:42] <alexandru.petrescu@gmail.com> IC: any comments on time tlv?
[10:49:51] <alexandru.petrescu@gmail.com> TC: short document actually
[10:51:03] --- alexandru.petrescu@gmail.com has left
[10:51:14] --- apetrescu has joined
[10:51:21] <apetrescu> SMF slides at http://www3.ietf.org/proceedings/07jul/slides/manet-0.pdf
[10:51:32] <apetrescu> slide: changes -04 to -05
[10:58:04] <apetrescu> slide: IPv6 Hop-by-hop Header Option
[10:58:21] <apetrescu> slide: Reduced Relay Set Interaction Cases
[10:59:28] <apetrescu> Philippe JAcquet PJ
[10:59:51] <apetrescu> PJ: cross-layer implementation, a MPR flooding we made, we used seqno source numbers
[11:00:03] <apetrescu> PJ: src no of last hop were very useful to detect...
[11:00:15] <apetrescu> PJ: braodacsting, then no longer possibliity to detect link failure
[11:00:32] <apetrescu> PJ: having failure in the seq of packets received helps you to increase the speed of detecting link change
[11:00:48] <apetrescu> JM: you say if you do, 2nd thing , unicast implementation...
[11:01:01] <apetrescu> JM: you say, layer 2 triggers, the seq values van help you do that
[11:01:11] <apetrescu> JM: sensing capability of neighbors?
[11:01:14] <apetrescu> PJ: yes
[11:01:22] <apetrescu> PJ: I can try to find back where we list
[11:01:25] <apetrescu> JM: to list?
[11:01:27] <apetrescu> PJ: yes
[11:01:42] <apetrescu> PJ: yes, was public, worked by Anislau (sounds so).
[11:01:57] <apetrescu> slide: Types of Relay Set Interactions
[11:03:08] <apetrescu> TC: pruposue of NHDP is provide only 1hop information
[11:03:14] <apetrescu> TC: usage for applications...
[11:03:22] <apetrescu> JM: designers were responsible.
[11:03:29] <apetrescu> JM: that's what he said it occured.
[11:05:10] <apetrescu> slide: Document Strategy Plan
[11:05:41] <apetrescu> CD: fundamental funciton of smf is flood...
[11:05:47] <apetrescu> CD: multicasting take out from manet
[11:05:58] <apetrescu> CD: that's caoably sort of doing it in the future.
[11:06:03] <apetrescu> CD: discussion rough consensus
[11:06:14] <apetrescu> JM: let me say why that's the case: w do have pim working on.
[11:06:18] --- fp has left
[11:06:21] <apetrescu> JM: multiple ways to do that that work.
[11:06:31] <apetrescu> JM: wiht the gateway thing we'd like people to know that.
[11:06:36] <apetrescu> CD: trechnically I agre.
[11:06:42] <apetrescu> JM: document confusoing?
[11:06:51] <apetrescu> CD: yes, to a peolple inmplementing it.
[11:07:21] <apetrescu> JM: reason why thtat text is there, is because people thought you couldn't interoperate or gate this stuff. Previously a co-author would expand that, historically it hanged on.
[11:07:36] <apetrescu> CD: appendix is right solution for that.
[11:07:36] <apetrescu> JM: see I'll try to organize
[11:07:37] <apetrescu> CD: router removing
[11:07:44] <apetrescu> CD: take it a bit later which is.
[11:07:53] <apetrescu> CD: two big areas: one is duplicate detection, one is of relay sets.
[11:07:58] --- jishac has left
[11:08:00] <apetrescu> CD: these are mutually interoperaate.
[11:08:22] <apetrescu> CD: in a sense smf is a family of these many options, of protocols. If you and I have to write a smf implementations that interoperates.
[11:08:26] <apetrescu> JM: header options are ok.
[11:08:34] <apetrescu> JM: may not implement hashing. But that's ok.
[11:08:42] <apetrescu> JM: scds thing is a little fuzzy.
[11:09:00] <apetrescu> JM: early on in this design, it is possible to have different with difference cds's and it may work.
[11:09:25] <apetrescu> JM: in a sense, one lowenergy device, and one... implement, one is more intelligent. That needs to bre preserved.
[11:09:29] --- herve.prigent has joined
[11:09:30] <apetrescu> CD: duplicate detection back to.
[11:09:39] <apetrescu> CD: also feel necessary to hash the situation.
[11:09:46] <apetrescu> C:D a whole bunch of policy decisions
[11:09:57] --- herve.prigent@jabber.org has left
[11:10:00] <apetrescu> CD: you got, SMF is _not_ _a_ protocol but a family of protocols.
[11:10:14] <apetrescu> JM: for experimental puproses, managing that area is not a.
[11:10:27] <apetrescu> JM: hear your point, but this is Internet-wide protocol and it would be very serious if.
[11:10:53] <apetrescu> CD: have a section: right, if you and I want to use SMF we'll have to agree on the folloiwng things, and make that explicit. Even better, agree on this things, then form this list.
[11:11:02] <apetrescu> CD: one option is not to say, other option is...
[11:11:08] <apetrescu> JM: cross-based routing is as well.
[11:11:17] <apetrescu> CD: think the discussion is we agree.
[11:11:24] <apetrescu> CD: list of decision we have to make.
[11:11:33] <apetrescu> JM: SMF is not telling you have to do this or that
[11:11:46] <apetrescu> IC: CD make a recommendation on the list, how different devices, how it works.
[11:11:48] <apetrescu> CD: yes.
[11:12:09] <apetrescu> TC: read both versions, I want to compliment you and co-authors on very good job of cleaning up, well done.
[11:12:13] <apetrescu> JM: and now the slaughter
[11:12:41] <apetrescu> TC: CD say, I second, I agree there are many good considerations on smf, I read it a no of times, whether or not is got a little still scoped should it be.
[11:13:00] <apetrescu> TC: WG help me a bit, if you say _the_ smf protocol then I can expect something I can go implement you too.
[11:13:16] <apetrescu> TC: that may not quite be so because there are a number of things which are optional.
[11:13:20] <apetrescu> JM: to me it's experimental.
[11:13:23] <apetrescu> TC: let me finish
[11:13:41] <apetrescu> TC: second part a number of options, seq numbers, hashing, dpd, smpr, whatever.
[11:13:43] <apetrescu> TC: hum
[11:13:54] <apetrescu> TC: assuming I wanted to deploy smf, I take a protocol.
[11:14:07] <apetrescu> TC: important you make this and this decision. Important to know conditions.
[11:14:17] <apetrescu> TC: difficult o me as a deployer to make decisions.
[11:14:22] <apetrescu> JM: I can go out some text.
[11:14:35] <apetrescu> JM: we thought threats for hasing vs seq-based.
[11:14:49] <apetrescu> JM: somebody reading it thinks whow I have that threat so I use this.
[11:14:52] <apetrescu> JM: some things.
[11:14:55] <apetrescu> JM: experimental.
[11:15:02] <apetrescu> TC: expand of metrics.
[11:15:06] <apetrescu> TC: change the title of document
[11:15:19] <apetrescu> TC: this is not _the_ smf protocol, this is multicast considerations for manets.
[11:15:31] <apetrescu> TC: would it be possible to say these are multicast considerations for manets.
[11:15:35] <apetrescu> TC: experimental.
[11:15:42] <apetrescu> JM: heaering you.
[11:15:47] <apetrescu> JM: not that.... my IMHO.
[11:15:52] <apetrescu> TC: document is fine.
[11:15:59] <apetrescu> JM: implemented and working.
[11:16:03] <apetrescu> TC: not interoperanle
[11:16:17] <apetrescu> JM: its very easy, not large more than20-30 nodes.
[11:16:21] <apetrescu> TC:/...
[11:16:31] <apetrescu> JM: if somebody messes up or doesn't have hashes.
[11:16:41] <apetrescu> JM: cds question work on previous dt work.
[11:16:51] <apetrescu> JM: different cds algorithms on different nodes.
[11:16:59] <apetrescu> JM: I'd ask that back: do people want that? I want it.
[11:17:07] <apetrescu> TC: not say I don't want it, but there are different ...
[11:17:15] <apetrescu> JM: an informational would that be.
[11:17:19] <apetrescu> TC: get to point.
[11:17:24] <apetrescu> JM: tore this stuff out?
[11:17:35] <apetrescu> TC: no, still many options left in document that are left as exercise
[11:17:42] <apetrescu> JM: total removal of them? tutorial?
[11:17:47] <apetrescu> TC: 01 02
[11:17:50] <apetrescu> JM: that's practices
[11:17:52] <apetrescu> TC:...
[11:18:05] <apetrescu> TC: accompany that by an instance saying.
[11:18:12] <apetrescu> IC: take this particular conversation to list.
[11:18:18] <apetrescu> IC: TC you make this rec to list.
[11:18:22] --- fp has joined
[11:18:23] <apetrescu> CP: two comments.
[11:18:36] <apetrescu> CP: you said this is only intended to only 20-30 nodes?
[11:18:38] <apetrescu> JM: yes
[11:18:45] <apetrescu> JM: idea make sure it's scope.
[11:18:52] --- pete.stpierre@gmail.com has left
[11:18:52] <apetrescu> JM: flooding approach is not great in huge network.
[11:19:02] <apetrescu> JM: read smf is not indendet for...
[11:19:03] <apetrescu> JM:
[11:19:23] <apetrescu> CP: flooding of route discovery, why want to have cds in first place? Tends to improve more the number of nodes you have.
[11:19:32] <apetrescu> CP: shouldn't make a restriction that cds is restricted.
[11:19:38] <apetrescu> CP: should do a lot better.
[11:19:47] <apetrescu> JM: not restricted populations, reading the doc doesn't say that.
[11:19:54] <apetrescu> JM: initial target was stub networks.
[11:20:00] <apetrescu> JM: initial scope was that.
[11:20:18] <apetrescu> JM: is it efficient, is it effective. Does it survice the scrutiny of implementers?
[11:20:27] <apetrescu> JM: WG does next step.
[11:20:30] <apetrescu> JM: people are
[11:20:41] <apetrescu> JM: do we finish that?
[11:21:08] <apetrescu> CP: summarizing: my point was that cds algorithms tend to operate better and better. And your point is that we need it anyways... experimental..
[11:21:12] <apetrescu> JM: control plane is fine.
[11:21:24] <apetrescu> JM: lots of data plane start flooding anywhere. Diminished returns.
[11:21:29] <apetrescu> JM: group-based filtering.
[11:21:35] <apetrescu> JM: depends on application.
[11:21:42] <apetrescu> CP: different quetions.
[11:22:05] <apetrescu> CP: relay set you have de[ends on the structure of the multicast groups you have, different trees. Not that's why I came to talk about.
[11:22:09] <apetrescu> JM: is relevant though,
[11:22:15] <apetrescu> JM: smf doesnt build groups.
[11:22:20] <apetrescu> trees is that
[11:22:32] <apetrescu> CP: intention of doc is single relay set construction for all possible multicast groups?
[11:22:36] <apetrescu> CP: you can say no
[11:22:38] <apetrescu> JM: no
[11:23:06] <apetrescu> CP: different nodes to operate different cds selection algorith,s. We want to allo, but not completely free decision, I'll give example...
[11:23:09] <apetrescu> J: I agree
[11:23:24] <apetrescu> CP: ex: if we do publish a wg document on relay set selection then that may constrain future designs.
[11:23:31] <apetrescu> CP: (continues example)
[11:23:40] --- kakima has joined
[11:23:40] <apetrescu> JM: absolutely true.
[11:23:46] <apetrescu> JM: hopefully....
[11:23:51] <apetrescu> Fred Templin is FT
[11:23:54] <apetrescu> FT: on DPD stuff
[11:23:59] <apetrescu> FT: rerunning re...
[11:24:04] <apetrescu> JM: next slide actually
[11:24:15] <apetrescu> JM: can I finish the strategy, then we'll definitely get to that
[11:25:30] <apetrescu> slide: Some Open Issues
[11:26:01] --- jpc has joined
[11:26:06] --- manet has joined
[11:26:26] <apetrescu> FT: can you say why IPv4 fragmentation is problematic in this context?
[11:26:31] <apetrescu> JM: implementatin-problematic
[11:26:35] <apetrescu> JM: ID field
[11:26:53] <apetrescu> JM: present design, 791 doesnt really say what when it's not a fragment; consisdtetnt
[11:27:03] <apetrescu> FT: fragment a packet, presumably.
[11:27:05] --- manet has left: Logged out
[11:27:12] <apetrescu> JM: dont know where the fragment is?
[11:27:19] <apetrescu> FT: if net frags the packet then id.
[11:27:22] <apetrescu> JM: you say...
[11:27:33] <apetrescu> FT: reassmbles the receiver does.
[11:27:42] <apetrescu> FT: same idea in the packets but different.
[11:27:49] <apetrescu> JM: we could but we dont want to
[11:27:58] <apetrescu> FT: can not control, and prevent using the f bit.
[11:28:03] <apetrescu> FT: if that source.
[11:28:07] <apetrescu> JM: understandintg.
[11:28:19] <apetrescu> FT: last time the possiblity of ip encapsulation.
[11:28:28] <apetrescu> FT: dont think the interactions are really that bad.
[11:28:40] <apetrescu> FT: maybe some discussion on the list about IP and IP iencapsulations.
[11:28:43] <apetrescu> JM: soudns good.
[11:28:55] <apetrescu> JM: encapsulaiton is what people talk about many years ago.
[11:29:01] <apetrescu> JM: it's an idea, I dont like it.
[11:29:12] <apetrescu> FT: benefit of encapsulation is tagger id.
[11:29:16] <apetrescu> JM: true but not like.
[11:29:22] <apetrescu> Teco Boot is TB
[11:29:31] <apetrescu> TB: official spec, protocol is takne into account
[11:29:35] <apetrescu> TB: 791rfc
[11:29:45] <apetrescu> TB: id field for fragmentation is for source dst and protocol.
[11:29:49] <apetrescu> TB: is not for
[11:29:58] <apetrescu> JM: not true, smf is narrow, protocol is always the same.
[11:30:00] <apetrescu> TB: assumme
[11:30:05] <apetrescu> JM: protocol is implicit
[11:30:24] <apetrescu> TB: assume its pgm and udp, same multicast group simultaneously, smf uses of IP Id and official IPv4.
[11:30:28] <apetrescu> JM: dont follow
[11:30:33] <apetrescu> TB: I could post it on the list
[11:30:42] <apetrescu> TB: I see the difference in the specificaition of IP ID field.
[11:30:47] <apetrescu> TB: specified differently
[11:30:57] <apetrescu> JM: in the end its specified for fragmentation only
[11:31:03] <apetrescu> JM: not consistent
[11:31:06] <apetrescu> JM: put 0 in
[11:31:16] <apetrescu> TB: IP fragment is document, other methods to fill in this field
[11:31:32] <apetrescu> JM: if other people do it, not a problem. Problem is if it doesnt make sense.
[11:31:45] <apetrescu> JM: not written down what to do it with it when not fragmentin.
[11:31:57] <apetrescu> TB: I think you want to supprot fragmentation in the future.
[11:32:02] <apetrescu> JM: ...
[11:32:13] <apetrescu> TB: why not taking rtcp protocol, is there a reason?
[11:32:18] <apetrescu> TB: dont udnerstandt, restate
[11:32:30] <apetrescu> JM: for now it's only src and dst, not protocol.
[11:32:39] <apetrescu> (last two lines reverse authors)
[11:32:41] <apetrescu> ...
[11:32:54] <apetrescu> FT: I agree TB, protocol field is not necessarily always going to be indicated.
[11:33:07] <apetrescu> FT: you say you dont break 791, but I think ... (yes)
[11:33:14] <apetrescu> JM: lets get this to list
[11:33:25] <apetrescu> TB: if you write down it's experimental then fine, but for future.
[11:33:35] <apetrescu> JM: we need to decide whether v4 approach is good or not.
[11:34:00] <apetrescu> FT: final point of this being an experiment, this potentiall... throw away in the future.
[11:34:04] <apetrescu> JM: fair enough.
[11:34:14] <apetrescu> JM: I've slammed it myself tons myself.
[11:34:22] <apetrescu> JM: not a fan of fragment in multicast situations.
[11:34:34] <apetrescu> CP: heard reqriting IP-ID field? Doesint work...
[11:34:40] <apetrescu> CP: can't control...
[11:34:50] <apetrescu> JM: winner's implementaiont, never reqriting.
[11:35:04] <apetrescu> JM: read the document, it explains different kernels, ...
[11:35:08] <apetrescu> JM: 791...
[11:35:26] <apetrescu> JM: in practice you don't have that field, linux always puts it to 0, not know people...
[11:35:39] <apetrescu> TB: IP-ID fields is it written already?
[11:35:44] <apetrescu> JM: repeat that
[11:36:05] <apetrescu> IC:if the IP ID field is probably written it could be left alone, the recommendation with gw or multile gws may differ.
[11:36:21] <apetrescu> IC: point is that if the src is filled in the manner consistent with spec then no need to specify.
[11:36:27] <apetrescu> TB: but then problem with sequence
[11:36:42] <apetrescu> JM: sure, might have a different technique, a quick lookup; but if there's a unique id, then sequence...
[11:36:54] <apetrescu> JM: it's there, we noticed in ietf, other WGs ran into this before.
[11:37:00] <apetrescu> IC: speedup, finish the presentation.
[11:37:08] <apetrescu> IC: if short comment please do it, otherwise.
[11:37:15] <apetrescu> Brian Adamson BA
[11:37:23] <apetrescu> BA: multihomed, all kernels implement.
[11:37:38] <apetrescu> BA: high speed on one interface nlow speed on another, you can spread your traffic.
[11:37:44] <apetrescu> FT: there's an rfc on that now.
[11:37:53] <apetrescu> FT: rfc talks wrapping up an ip id field.
[11:38:00] <apetrescu> JM: need more list dicussion,
[11:40:42] <apetrescu> IC: Joe go to last slide
[11:40:52] <apetrescu> IC: more discussion oht n the list
[11:41:01] <apetrescu> slide: Ongoing Prototyping/Testing
[11:42:29] --- kakima has left
[11:42:30] --- kakima has joined
[11:43:48] --- apetrescu has left: Replaced by new connection
[11:43:54] --- apetrescu has joined
[11:44:12] <apetrescu> TC: most important thing in this doc is to list necessities of interoperating two smf implementations
[11:44:23] <apetrescu> TC: also france vacationign august so better do lc before
[11:44:30] <apetrescu> FT: talk more about IPv4 DPD
[11:44:44] <apetrescu> JM: right, can we do that quickly, people willing work with me real soon?
[11:44:49] <apetrescu> FT: an experimental.
[11:45:05] <apetrescu> JM: often we design v4 design.
[11:45:10] <apetrescu> JM: this or separate doc?
[11:45:17] <apetrescu> FT: how quickly want to do it best?
[11:45:23] <apetrescu> JM: these things pretty clean
[11:45:31] <apetrescu> JM: v4 works, but never been prey.
[11:45:42] <apetrescu> JM: would it be something where you want to put somewhere else?
[11:46:01] <apetrescu> IC:solution is to discuss on the list and in the document contain some text possible issues with existing experimental step.
[11:46:05] <apetrescu> IC: FT has
[11:46:23] <apetrescu> IC: would you be satisfied if in the doc we explain limit case challeneges in the future with v4
[11:46:30] <apetrescu> IC: have people be aware of that a possible issue.
[11:46:38] <apetrescu> FT: take it to list and have more discussion there.
[11:46:41] <apetrescu> JM: quickly
[11:46:52] <apetrescu> JM: we had a must and now go on vacation? but take more?
[11:47:05] <apetrescu> TC: dont worry about taking coupel of months, we take 10 years for...
[11:47:10] <apetrescu> TC:
[11:47:20] <apetrescu> JM: way forward, a strategy, not need detail ansewers.
[11:47:35] <apetrescu> TC: if what we need to do this doc is 3 months then so be it.
[11:47:41] <apetrescu> JM: been around a couple of years.
[11:47:48] <apetrescu> TC: live with satisfied with.
[11:47:56] <apetrescu> TC: not today, but discuss and ...
[11:48:06] <apetrescu> IC: still a week before Europeans take vacation so.
[11:48:53] <apetrescu> TC presents NHDP slides at http://www3.ietf.org/proceedings/07jul/slides/manet-7.pdf
[11:49:08] <apetrescu> slide: Status
[11:54:00] <apetrescu> slide: "made explici that everything can change"
[11:55:29] <apetrescu> JD: comment after rereading, discussiong with Brian it's clear once you undertastand what's going on , but first reading is...
[11:55:34] <apetrescu> JD: we can improve in that area.
[11:55:45] <apetrescu> TC: we talked about that well
[11:56:08] <apetrescu> CP: want to follow up on discussion of yesterday, message size.
[11:56:36] <apetrescu> CP: example in appendix was 50bytes, I compared to an alternative layout message data, 14bytes, both address tlv, I think there is a really long way to go towards reducing message size overhead.
[11:56:55] <apetrescu> CP: some point wondering whether or not this drives to satisfy two imcompatible goals,
[11:57:12] <apetrescu> CP: simplest possible programming techniques for parsing, while other group is smallest possible message size.
[11:57:34] <apetrescu> CP: and NHDP has a distinguished position because in manet the topology is distinguished with nhdp.
[11:57:49] <apetrescu> CP: situations like this it could the significant trash of network congestion could be from nhdp.
[11:58:03] <apetrescu> CP: crucial to optimize for those apps and devices where power matters.
[11:58:23] <apetrescu> IC: there was discussion about lets look at some packets we have vision for today and look at how well we can compact them
[11:58:34] <apetrescu> IC: just discuss on list in terms of how efficient the format is.
[11:58:52] <apetrescu> TC: efficiency of programming this thing, remember vancouver we had a very restrivtie set
[11:59:08] <apetrescu> TC: reduce or remove we could do other things you want to do, this is not only nhdp issue, it's packetbb
[11:59:22] <apetrescu> TC: modularity options in packetbnbb were introduced exactly fro,,,
[11:59:30] <apetrescu> TC: 2nd thing, I'll take example of .
[11:59:47] <apetrescu> TC: one ways this is possible to do is because packetbb allows for flexibility or extensibiility.
[11:59:51] <apetrescu> TC: doesn touch
[12:00:18] <apetrescu> TC: I have this flexivilitiy and if I wanted to add link metric issues, plug htis right in, use this, yes price to pay, impossible to encode all
[12:00:27] <apetrescu> TC: 200pages document, 10000lines of code.
[12:00:49] <apetrescu> TC: probably discussion, I do think its worth considering, 4 different sets of requirement of this document
[12:01:24] <apetrescu> TC: one is easy to test, one is flexible, one issave every single bit, finally one is one group of people we've worked on this 10yr yesterday is better now even better.
[12:01:30] <apetrescu> TC: compromiose yes.
[12:01:52] <apetrescu> TC: came to a compromise, changes reasnably to acoommmodate is should be minimal.
[12:01:56] <apetrescu> TC: packet bb
[12:02:09] <apetrescu> CP: really thank we can get a satisfactory conlcusion.
[12:02:18] <apetrescu> CP: message likely to congestion in network
[12:02:22] <apetrescu> TC: not correct
[12:02:40] <apetrescu> TC: in a mobile network type of network the source of congestion is flooding, not this.
[12:02:52] <apetrescu> TC: overhead imposed by header lists is noise compared to TC messages.
[12:02:58] <apetrescu> TC: dont say incorrect
[12:03:04] <apetrescu> TC: upsetting me
[12:03:07] <apetrescu> CP: sorry offending you
[12:03:20] <apetrescu> CP: if you turn out hello messages, huge deterioration of performance;
[12:03:39] <apetrescu> IC: you both adamantly agree that reducing flooding is very good, your statement is a 2nd order after that
[12:03:51] <apetrescu> IC: this may be hello messages, could be a message that comes often
[12:03:58] <apetrescu> TC: several orders of magnitut.de
[12:04:13] <apetrescu> CP: register a difference of oppinion, hello messages was pretty low noise to us.
[12:04:21] <apetrescu> CP: pretty important to reduce size of message
[12:04:28] <apetrescu> TC: size of message and freq of message
[12:04:39] <apetrescu> TC: once you send, 1, 2 3 octents more doesnt make sense
[12:04:51] <apetrescu> TC: essentially you end oup with ending up with it.
[12:05:00] <apetrescu> TC: whether or not is the right optimization to make
[12:05:07] --- jpc has left
[12:05:09] <apetrescu> IC: take how we can work more efficiently to the list
[12:05:36] <apetrescu> JM: we agree from manet, there are other scenarios, we did find measure, flooding is not aproblem this off
[12:06:00] <apetrescu> JM: it's important to remember nhdp is flexible timings capabilities provides, newer possibliity to save energy and do itntersting things previously hard to do
[12:06:28] <apetrescu> JM: another way to build energy-efficine protocols, I'm excited by that, hopefully, I did remember when we discuss time-tlv, leading to define an infinity value
[12:06:32] <apetrescu> JM: regards that
[12:06:38] <apetrescu> JM: excited to use time to time
[12:06:50] <apetrescu> JM: make a reactive protocol more proactive (or vice versa he said)
[12:07:05] <apetrescu> FT: this is different subject line, CD did a good job on my comments on the list
[12:07:18] <apetrescu> FT: one think I want to see addressed and definition of link
[12:07:29] <apetrescu> FT: rt area and internet area need more an dmore this
[12:07:43] <apetrescu> TC: yes, discuss that, show up tomorrow to autoconf WG
[12:07:58] <apetrescu> FT: opportunity of harminization of link definition between rt and int area
[12:08:07] <apetrescu> FT... with respect to that optimization
[12:08:33] <apetrescu> IC presents DYMO slides at http://www3.ietf.org/proceedings/07jul/slides/manet-1.pdf
[12:08:45] <apetrescu> slide: DYMO-10 Document Updates
[12:09:46] <apetrescu> slide: DYMO-11
[12:10:46] <apetrescu> TC: encourage keep in mind when we discuss metric issue at next next presentation, a potential area of encourage
[12:11:01] <apetrescu> IC: if any dymo issue talk now, not a lot of changes, not a lot of comments
[12:11:15] <apetrescu> slide: Open Discussion
[12:11:51] <apetrescu> CD presents OLSRv2 slides at http://www3.ietf.org/proceedings/07jul/slides/manet-9.pdf
[12:12:03] <apetrescu> IC: CD or JD will also present metrics
[12:12:08] <apetrescu> slide: Status
[12:13:22] <apetrescu> slide: Link Metrics for OLSRv2
[12:13:28] <apetrescu> slide: Status and Purpose
[12:14:58] <apetrescu> slide: Motivation
[12:16:45] <apetrescu> slide: Future Extension?
[12:16:48] <apetrescu> slide: Link Metrics
[12:18:01] <apetrescu> CP: some of the proposed characteristics, about directional, if you have a bidirectional typical ink, you say now...
[12:18:08] <apetrescu> CD: different metrics, yes, but next slide
[12:18:22] <apetrescu> CP: that word _not_ out there, a lot of people don't see it.
[12:18:29] <apetrescu> CD: yes, apsolutely
[12:18:37] <apetrescu> CD: red on blue not good
[12:18:46] <apetrescu> slide: Why directional
[12:21:09] <apetrescu> slide: how are link metrics reported?
[12:21:32] --- herve.prigent has left
[12:22:39] <apetrescu> slide: MPRs
[12:23:52] <apetrescu> slide: Routing
[12:24:44] <apetrescu> slide: Key Points
[12:27:13] <apetrescu> IC: enough to adjust, JD just does two slides and then come see
[12:27:33] <apetrescu> JD presents slides are at http://www3.ietf.org/proceedings/07jul/slides/manet-8.pdf
[12:27:51] <apetrescu> slide: Metric Issues for MANET
[12:28:28] <apetrescu> slide: Ho are metrics to ebe...
[12:28:38] <apetrescu> slide: TLV subtype usage
[12:29:46] <apetrescu> slide: Is this useful?
[12:29:56] <apetrescu> slide: Metric Issues for MANET
[12:30:20] --- badamson has left
[12:30:23] <apetrescu> IC: sorry run out of time for your presentation, but this slide says what needs to do, his piece addresses middle one, CD's addresses for OLSRVv2
[12:30:48] <apetrescu> IC: what are the modifcations to documents we alreayd have, identifies where we have missign documents, more informational discussion ... needs to more discusion on this
[12:30:52] <apetrescu> IC: 2-3 minutes
[12:31:22] <apetrescu> CP: q short, it was stated, to emphasize, true for many link metrics, two different kinds of links then impossible to use metrics to compare, do you agree?
[12:31:40] <apetrescu> JD: CD will get into that more, this document would not geneerate or compare, eg TC will...
[12:31:48] <apetrescu> CP: symmetric is one inbound and outbound
[12:32:07] <apetrescu> CP: interested for a long time in link metrics, this is targeted only at olsrv2 but we need to recognize applicability to dymo
[12:32:17] <apetrescu> JD: this doc no protocol in mind (other than packetbb)
[12:32:27] <apetrescu> JP Vasseur is JPV
[12:32:34] <apetrescu> JPV: we did this in context of lowe power networks, link layer
[12:32:46] <apetrescu> JPV: try to keep in touch maybe something we can owrk together
[12:33:13] <apetrescu> TB: work was done before in ospf and is-is and free examples and three different formats, and this is another one, and I'd like to converge to a single for future work.
[12:33:22] <apetrescu> TB: metric is from below layer, it's not an IP thing
[12:33:34] <apetrescu> JD: specific about document is that it conforms to packetbb tlv spec.
[12:33:43] <apetrescu> TB: suggestion to look in ietf for converged formats for metrics
[12:33:53] <apetrescu> TB: check for ospf or is-is who will enact to define the metric
[12:34:06] <apetrescu> TB: there must be a reason for doing another metric, otherwise it's just gamblinh.
[12:34:13] <apetrescu> CD: wise, strip
[12:34:33] <apetrescu> CD: CP's main point, codestination selection of metrics, if different people select metrics in different ways that's not good.
[12:34:38] <apetrescu> CD: legal, loops.
[12:34:47] <apetrescu> CD: if youd lile to support implementatio
[12:34:48] --- fp has left
[12:35:02] <apetrescu> CD: but that's outside scope of specific olsrv2 iteslf, it will be a correct current practice
[12:35:12] <apetrescu> CD: not actually pbroken if you dont
[12:35:39] <apetrescu> TC: ask a simple q, it is more that we diveide: do we affect ... in routing protocol, in link, and do w e figure out.
[12:35:41] <apetrescu> TC: ...
[12:35:45] <apetrescu> TC: olsrv2 includes?
[12:35:50] <apetrescu> TC: and then leave TB
[12:35:57] <apetrescu> TC: question we need to answer.
[12:36:06] <apetrescu> TC: nice has value, value is applicable.
[12:36:16] <apetrescu> TC: OLSRv2 needs to be prepared in advance
[12:36:23] <apetrescu> TC:...
[12:36:38] <apetrescu> JM: heard somewhere Phil said metric comes from L2, cost-based routing, sometimes from management point
[12:36:43] <apetrescu> JM: cost of certain links.
[12:36:57] <apetrescu> JM: this spec shouldnt include any of that, notwhat gets in there, but the container.
[12:37:04] <apetrescu> JM: not really ...
[12:37:10] <apetrescu> JM: this is a generic container right?
[12:37:12] <apetrescu> JD: yes
[12:37:27] <apetrescu> Joe Kopena JK
[12:37:36] <apetrescu> JK: my group uses signficnatly olsr, two quick comments
[12:37:50] --- keyajima has left
[12:37:58] <apetrescu> JK: in our experience, biggest preformance problems is if using hopcount as a metric in olsr. better link cohoice is if ...
[12:38:10] <apetrescu> JK: directional metrics and ... metrics are easy to produce
[12:38:24] <apetrescu> JK: but for 802.11 unicast traffic is not as broadcast traffic.
[12:38:33] <apetrescu> JK: that metrics need to account for that.
[12:38:49] <apetrescu> IC: thanks, look forward for people committed to send email to list to do it. Thank you
[12:38:52] <apetrescu> (adjourned)
[12:38:52] --- igarashi has left
[12:38:55] --- apetrescu has left
[12:39:07] --- kakima has left
[12:39:26] --- yowada@jabber.org has left