[10:54:51] pierrick seite joins the room [10:59:14] gorryf joins the room [11:00:22] I'm taking Jabber notes - if you are remote and want me to echo things to the mic, please prefix by "mic:" [11:00:51] This is Multimob - next slides: Chairs Administrativia [11:04:07] Slide:Agenda [11:06:09] Slide: IETF Note Well [11:06:29] Slide: Qin MLD Tuning [11:06:46] geir joins the room [11:06:54] mab joins the room [11:08:21] [11:08:31] Slide 1: draft-wu-multimob-igmp-mld-tuning-02 [11:08:38] Slide 2 [11:09:16] DCN-2C060BED2B9 joins the room [11:09:30] slide 3 [11:09:54] Slide 4 [11:10:49] Side 5 [11:11:19] DCN-2C060BED2B9 leaves the room [11:11:31] Slide 6 [11:13:33] Slide 7 [11:15:35] Slide 8 [11:17:15] Slide 9: [11:18:06] Hitoshi: [11:18:26] Seil Jeon joins the room [11:18:39] Are you required to install a box to do explicit tracking for MLD/IGMP? [11:18:59] - This is a role of the proxy. Current standard does not say how to do this,. [11:19:33] Hitroshi: I'm not sure if this is an IGMP proxy... or not... Is this a required component to do the tuning? [11:19:37] - It is optional. [11:19:48] Hitoshi: OK [11:19:52] Sldie 10 [11:21:16] Slide 11 [11:22:43] Hitoshi: This seems a good idea. This seems impossible without changing the protocol. tehre is only one timer [11:24:35] SLIDE 12: [11:25:34] Gorry (question on previous slide) - I didn't see in the draft what to do when you loose the initial Join messages from a client. To me, it was not clear whether general queries were always sent? [11:25:52] - General queries are always sent. [11:26:14] Gorry: OK agree, I didn't see that when I read the draft. [11:26:43] Next presenter: Hitoshi MLD Tuning [11:27:01] Using a different slide set to that uploaded. [11:27:48] At Slide 2 [11:28:23] behcet.sarikaya joins the room [11:28:58] See draft-asaeda-mboned-explicit-tracking-00 when uploaded to IETF archive. [11:29:33] Wu: Explicit tracking can be used by routers - does it have to know the type of application? [11:29:48] - No, it is not application dependent. [11:30:59] Wu: This feature is appropriate for wireless mobile environment. [11:31:56] - The network is not discussed in this particular draft. [11:32:02] Gorry: Is the draft about explicit router tracking or proxy tracking and is there a difference? [11:32:11] - It covers both. [11:32:18] Gorry: Are they the same? [11:32:31] - both are described in same way [11:32:42] Slide: Simulation Scenario [11:34:12] [11:34:12] behcet.sarikaya leaves the room [11:34:37] Thomas Schmidt: What the axes? [11:35:09] - X-axes is a 2 hours multicast channel, duration not important. Y-axes is no. of queries. [11:35:22] behcet.sarikaya joins the room [11:35:32] - Actually only one packet every 125 secs [11:35:41] [11:36:20] To remote attendees: is audio OK? [11:36:28] - With no query, the router generates a source-specific query [11:36:38] yes, audio is excelent [11:36:59]

[11:37:18] - still on extra slides he did not upload - [11:37:58] Hitoshi wants to keep some slides not in public domain [11:38:31] Thomas: What is the bin size? [11:38:50] i.e. how do you account for messages at near the same time? [11:39:15] - I do not understand [11:39:49] von Carlos: the lowest axes is minutes... what is the criteria for setting these values? [11:40:45] vC: I still don't understand the time scale. [11:40:47] geir leaves the room [11:40:59] ... why is 25 seconds a specific value? [11:41:13] - It is not important [11:41:42] Thomas: Y-axes shows messages. Does a value of 28 indicate all messages in one second [11:42:06] - This is a minute. One line is one second. [11:44:10] - It is clearer if you zoom in. [11:44:16] Gorry: I think the bin-size method is maybe clearer, so you can see exactly how many messages per fixed period of time on average. [11:45:13] Slide 12 of new slide set [11:45:25] Slide 15 [11:46:26] Mathias: Why are the simulations appropriate, can you comment on the scenario? [11:46:30] - This is an example [11:46:53] M: Are you deriving an upper or lower bound, example, or what? [11:47:08] Behcet: why are these simulations relevant? [11:47:22] - So we can see the functions [11:47:39] - This is a "random scenario: [11:48:03] M: There are various reasons for somulations to analyse the solution space. [11:48:06] OK [11:48:22] Slide 19 (original slide 5( [11:48:57] Original slide 6 [11:49:36] Slide 7 [11:50:18] pierrick seite leaves the room: Replaced by new connection [11:50:18] pierrick seite joins the room [11:51:18] brian.bnsmith joins the room [11:53:24] Gorry: Should seems quite strong for a recommendation NOT be more than 2. [11:53:43] - It seems to add congestion at layer 2 with no benefit. [11:54:23] - but if this is thought to be too string we could say recommended in cases where this could aggrevate congetsion [11:55:32] WG Chair discussion of the future direction for the draft [11:55:56] Thomas: There does not appear to be a clear recommendation in either draft on what the tuning is. [11:56:54] Wu: There are requirements in the charter - one sections summarises this. A number of solutions are proposed. There may be no single solution, and you may need to combine different sets of functions to satisfy the needs. [11:57:46] Hitsohi: This clearly is describes in my draft. I think the requirement is kwown. In Phase 2, we more clearly define the values for tuning. [11:58:45] ... The user scenarios in the 2nd presenarion - did this talk of mobile routers? [11:58:55] Hitsohi: Not mobile routers [12:00:33] ... If so the time values for the frequency of the initial report may not be short enough, because the host sends MLD unsol, join etc - later messages can not take place. [12:00:45] Hitoshi: I'll think about this. [12:01:23] Mobile IPv6 uses ms values for mobility handoff [12:01:52] Rajeev: What is the status of the drafts [12:02:03] Stig: Info or BCP [12:02:38] Rajeev: is the purpose to characterise the problem for wireless links. Is this an optimisation problem or a recommendation problem. [12:03:05] Stig: What params are needed for packet loss; specific wireless links. [12:03:17] Rajeev: this is very specific to wireless linls [12:03:24] Stig: yes. [12:03:55] Rajeev: In this case, it should be clear - you need data to make recomendations that are useful [12:04:16] Thomas: What you are saying continues the discussion for Hiroshma [12:04:31] Network characteristics vary. [12:05:11] Rajeev: In other words, what bad things happen if you don't do the consensus calls today? - My suggestion is to wait for more data [12:05:49] Behcet: I think for some link types we will get no values. 802.11 is widely used; cellular values can vary, how long do we wait? [12:05:59] Rajeev: What does this mean? [12:06:15] Behcet: It is difficult to get concrete answers [12:06:48] Stig: In some cases, you can say that if you have "these" characteristics, do this. [12:06:55] Rajeev: this seems fine. [12:07:54] .... For wireless links, I have measured lots, it depends on what we want to measure. [12:09:25] Stig: Should we continue the graphs? [12:11:52] Hitoshi: It's hard work to set specific targets [12:13:14] Gorry: What I'd really like to see is that the document clearly says there is a specific consideration, not that people shoudl use 135 instead of 120 for a specific param. I'd prefer to see the "problem" and the "suggested remedy" and let the operator decide if they have the problem. [12:13:26] Hum for adopting one or two documents. [12:13:32] [12:13:53] Hum for wating for a later revision [12:13:57] [12:14:40] Stig: It seems the second hum is louder, we should encourage an updated contribution from both authors and then to see whether we can then adopt these. [12:14:57] Dirk - Future work slideset [12:15:08] This is a contribution from several people [12:15:26] Slide 2 [12:17:15] Slide 3 [12:19:02] Slide 4 [12:20:11] Thomas: I see categories - the first block should be native mcast routing (e.g. AMT, VPN, etc); the second from my opinion would be to add mcast context to the transfer protocols (PMIP) and IGMP tuning is orthogonal [12:20:31] - OK, let's discuss - this is to stimulate thinking [12:21:02] Slide 6 [12:21:19] Slide 7 - Far Future [12:21:55] Slide 8 [12:22:09] Slide 9 [12:22:36] Slide 10 [12:23:08] Slide 11 [12:23:26] Rechartering discussion [12:23:49] Slides on Problem Descriptions [12:24:27] Slide 2: Collected set of slides contributed from the WG - one slide per problem [12:24:43] Protocol Extensions - Hotoshi [12:27:03] - Supports handover; hold/release - to prevent LMA peeling-off membership state during handover; [12:28:01] To Behcet [12:28:17] Now, I'm not there. I want to speak about direct routing solution shortly. [12:29:56] Chair: How many people this as something they wish to see considered for IGMP/MLD ext for handover? [12:30:28] Show of hands: 8 people [12:30:41] mic: +1 [12:30:54] OK :-) [12:31:48] Next topic: Reliability in wireless/mobile networks to counter high packet loss (ACKs etc) [12:33:05] Hitoshi: I think have some negative comments, this is more difficult to define the parameters - it would be a significant change to IGMP/MLD. [12:33:29] Thomas: I guess we do not mentions drafts, and focus on issues. [12:34:00] Stig: The drafts just illustrate prior interest/work and details will be up for discussion later. [12:34:14] Chair: How many people this are interested? [12:34:20] None in the room [12:34:27] In slide 5, this is my opinion for direct routing option [12:34:52] Do you want something echoed to the Mic? [12:34:57] Direct routing option can reduce "essentially" network load and tunnel/bandwidth problems without modification of PMIPv6. [12:35:06] It can be accepted as evolutionary option for current ISP [12:35:20] Thomas at Mic [12:35:40] A WiMAX or 3GPP can have native solution for multicasting. In some point, optional method can be coordinated with their solution. [12:35:54] Slide 6 [12:36:10] Behcet: Let's group these two together [12:36:22] Juan Carlos at Mic [12:37:46] Chair: How many people this as something they wish to see considered for these approaches to obtain multicast using dedicated LMA or direct routed infrastructure? [12:37:59] +1 [12:38:02] +1 [12:38:24] 8 people + 2 via jabber [12:38:42] Slide 7: Thomas at Mix [12:39:09] Extension for FMPI/PFMIP [12:39:47] Protocol Extensions for PMIP - Hitoshi at Mic [12:41:03] Fast Handover - Hui at Mic [12:42:44] Extensions ro accellerate Mag... ? at Mic? [12:44:34] Chair: How many people this as something they wish to see considered for Handover Optimisation? [12:44:49] 13 people [12:44:52] +1, specially on protocol extensions [12:45:04] +1 on jabber :- ) [12:45:27] Next topic: Multicast Mobile Source Solutions [12:45:52] Thomas, followed by ? [12:48:50] Behcet: what is the application where multicast is the content provider? [12:49:20] - [12:50:17] Chair: How many people see mobile sources as something they wish to see considered? [12:50:22] 14 people [12:50:31] mic: no proposal regarding multicast flows (multicast/multicast and multicast/unicast)? does the WG think there is no problem with this use-case? [12:52:11] Jari: Comments from AD: The idea in the current charter is that you complete the work - the PMIP stuff is on schedule, the MLD/IGMP stuff is not really on schedule. It could be premature to consider new work on this latter topic. [12:53:12] We should also explore whether there is a customer who needs the work - that is something we did not hear today, but the list could provide time to allow people to respond from companies who need this. [12:53:54] I did see rather a lot of topics, perhaps 3 big topics is too much. Complete something and then move forward. [12:55:00] Jari: We are fairly ready to make decisions in weeks rather than months. [12:55:25] Chairs will try to get a new charter as soon as they can [12:55:55] Meeting ended - did not get the comment to the mic, but will note it to the chairs. [12:56:19] thanks for the notes [12:56:28] thanks too [12:59:58] Seil Jeon leaves the room [13:00:14] pierrick seite leaves the room [13:01:58] gorryf leaves the room [13:02:07] behcet.sarikaya leaves the room [13:16:05] mab leaves the room [15:13:27] brian.bnsmith leaves the room