[04:42:57] Carsten Bormann joins the room [04:54:15] Carsten Bormann leaves the room: Replaced by new connection [04:54:17] Carsten Bormann joins the room [05:55:01] Carsten Bormann leaves the room [06:24:31] Aleksi Suhonen joins the room [06:33:30] jlcjohn joins the room [06:43:40] ayourtch joins the room [06:49:35] anyrhine joins the room [06:53:03] jariarkko joins the room [06:59:49] jonas joins the room [07:00:48] starting [07:01:12] slide 2 - "Note Well" [07:01:21] iljitsch joins the room [07:01:33] Good morning, I'm one of the two jabber scribes [07:01:48] strategically located right next to the microphone so I can relay any questions [07:01:56] Scott showed the note well [07:02:03] so we're starting [07:02:04] I am the other one [07:02:29] arifumi joins the room [07:02:32] mark will be up first [07:02:43] agenda slide up now [07:03:11] magnus joins the room [07:03:41] during presentations only clarification questions, then 30 mn of tech discussion and then 30 min of charter discussion [07:03:47] mark presenting now [07:04:44] PJS200 joins the room [07:05:57] shep joins the room [07:06:22] Scott.Brim joins the room [07:06:56] Materials at https://datatracker.ietf.org/meeting/75/materials.html [07:07:47] MING joins the room [07:07:48] arifumi leaves the room: Replaced by new connection [07:08:13] psavola joins the room [07:08:42] anyone here who wants to know what mark is saying but can't listen to the audio? [07:09:15] teco joins the room [07:09:31] If his point can be summarized in one sentence, yes ;-) [07:09:39] :) [07:10:59] He's saying, "Redundancy is good." [07:11:02] make one tcp connection but make it run over multiple paths where each path has more or less its own congestion control so it adjusts to the path properties but still some coupling of the congestion control. can't do that with normal multihoming. [07:11:39] tmonca joins the room [07:13:03] if one path gets congested because a legacy user uses up capacity, the multipath traffic moves away from that path, can't do that with other solutions, call it "resource pooling" = have multiple resources work like a single big one [07:15:03] multipath also lets you support a larger set of traffic matrices in your network [07:15:16] see the slide with approximately that as the title [07:15:23] (no slide #s I'm afraid) [07:16:31] slide "scenario: mobile client" shown now. [07:17:39] mp transport protocols seem to be key to making the internet more robust and more responsive to congestion, reacting on timescales that routing can't support [07:17:53] (I'm assuming interdomain routing, internal routing can be pretty fast) [07:18:02] PasiS joins the room [07:18:18] Any idea where these slides are online? I missed the first 10 mins trying to persuade my jabber client to work... [07:18:30] ayourtch has set the subject to: Materials at https://datatracker.ietf.org/meeting/75/materials.html [07:18:49] Scott.Brim thanks ayourtch [07:19:16] mp tcp: tcp is ubiquitous [07:19:28] why not on top of tcp? [07:19:40] thanks. Just found them. Was confused because they weren't listed on the pretty HTML agenda on the tools page... [07:19:52] helps bootstrapping and gives you congestion control coupling [07:20:02] I didn't manage to get all the tools knitted together [07:20:34] ( + from me: otherwise you have to reimplement segmentation and even reliablity again on top of tcp) [07:20:58] mptcp proposed before [07:21:09] multipath capable protocols not mentioned on the slide: HIP and Mobile IP [07:21:13] Carsten Bormann joins the room [07:22:03] Aleksi: the point here is to use multiple paths for a single flow, simultaneously. MIP flow binding doesn't do that, nor does HIP. They are below transport. [07:22:05] ams: do these allow you to use multiple paths in parallel in their current form? [07:22:33] joe touch runs to the mike: [07:22:47] he's curious and concerned about 3 completely separate things [07:22:52] i've seen some demos from Ericsson where they were watching a movie and it migrated over several interfaces (wired and wireless) mid flow [07:22:56] using HIP [07:22:59] 1 is tcp dealing with multiple paths, useful [07:23:08] 2nd supporting striping, also useful [07:23:47] 3rd multiple endpoints, want to stress more and more endpoints on one device, but I see more and more virtualization, don't want to end up in a situation where this breaks [07:23:54] fujiwara joins the room [07:24:36] Joe is correct, BTW, to say that multiple IPs don't imply multiple paths. [07:24:36] I would like to encourage an acid test: great if it works over multiple interfaces, but then show me that it behaves like current stuff over a single interface [07:24:37] that was a year or two ago [07:24:41] alan is up [07:25:28] mark replied to Joe "if you notice later we havent' tried to answer these questions, bring it back up" [07:25:28] john: we are aware of that, one goal is to be fair to normal flows when the multipath flow thinks it runs over multiple paths but it's actually the same path [07:25:55] slide 3 [07:26:17] slide 4 [07:26:28] magnus leaves the room [07:26:29] gigix73 joins the room [07:26:49] alan: when one path breaks, packets in transit over that path are retransmitted over the still functioning path [07:27:02] slide 5 [07:27:28] different scenarios with different properties, most obvious is bulk file transfer [07:27:41] I just uploaded Jana and Bryan's "Rethinking the Transport Layer" to the materials. It should appear in a minute or two. [07:28:39] slide 6 [07:28:56] Lars joins the room [07:29:21] slide 7 [07:29:28] gorryf joins the room [07:30:09] standard tcp, with the potential for multiple paths, no need for api changes [07:30:17] (deployability, speed >= tcp, compatibility) are the requirements [07:30:20] slide 8 [07:30:58] Aleksi: getting back to your statement, "i've seen some demos from Ericsson where they were watching a movie and it migrated over several interfaces (wired and wireless) mid flow" ... but the flow still only uses one paths at a time, whereas the point of multipath is to use multiple paths and balance across them, modulo goodput, policy, etc. [07:31:32] slide 9 [07:32:25] how to do signaling - in the payload (chunking): app level, not transport; tcp options - currently preferred, but limited space [07:32:28] slide 10 [07:33:08] MING leaves the room [07:33:28] slide 11 [07:33:43] danwing joins the room [07:33:50] slide 12 [07:34:03] one-ended mptcp [07:34:40] Mingdong joins the room [07:34:47] only the sender is modified, works with existing receivers [07:34:49] does this 1e-mp-tcp break SAVI on all but one of the paths? [07:35:10] savi is basically BCP38, right? [07:35:19] danwing leaves the room: Replaced by new connection [07:35:50] the one-ended mptcp requires that (as usual) a single source address, single destination address [07:35:58] slide 13 - two ended mptcp [07:36:08] so it would work for people who are multihomed using provider independent address space [07:36:48] k [07:36:54] two-ended could allow v4 + v6 subflows [07:36:57] the current two-ended proposal expresses different paths using different addresses [07:36:58] slide 14 [07:37:50] slide 15 [07:38:20] goal: no worse security compared to tcp, if possible then try to do better security [07:38:26] two-ended security issues are similar to mobility/shim6 security issues [07:38:34] lifenghua@gmail.com joins the room [07:38:36] slide 16 [07:39:07] joe has clarifying questions [07:39:17] clatze joins the room [07:39:18] endpoints start off with socket pair association [07:39:22] then add more socket pairs [07:39:30] what if first shuts down because ICMP? [07:39:50] arifumi joins the room [07:40:05] I have to say the wiki looks a little bare at the moment. Would be nice to have a few background links (not just to the resource pooling paper...) [07:40:13] first socket stays for the entire life of the mptcp session as its identifier [07:40:15] Matt Zekauskas joins the room [07:40:53] haa joins the room [07:41:13] Iljitsch: when does socket go away due to ICMP? [07:41:27] tmonca: the drafts on the materials page have links to whitepapers [07:41:29] magnus joins the room [07:41:35] (the point being that it doesn't, although I think windows may reset sessions upon an unreachable) [07:41:41] there are also lots on the mailing list [07:41:55] his point is: what happens on additional subflows when the initial/main one goes away [07:42:08] (which I think is way too much detail at this point) [07:42:17] michael tüxen: [07:42:31] Andrew McGregor joins the room [07:42:37] one or more address pairs, one or more port numbers? [07:42:47] alan: each subflow has its own port [07:42:57] (I guess they're talking about the two-ended solution...) [07:43:10] michael: so multiple congestion control instances? [07:43:12] alan: yes [07:43:14] I know there's lots of material out there. Really just a comment that since two presenters have now pointed at the wiki it would be good if everytghin was available there. However I realise that requires someone to actually do quite a lot of work [07:43:15] direct link to mailing list archive: http://www.ietf.org/mail-archive/web/multipathtcp/current/maillist.html [07:43:20] Answer to Joe: to any middlebox, mptcp looks like separate TCP connections, but to the application, it looks like just one. [07:43:42] michael: in sctp path per remote address, so no explosion with 10 source, 10 dest addresses [07:44:19] the pairs of (addr port) are used as a pool, not "full mesh" [07:45:30] john: careful to make the distinction between one- and two-ended, in one-ended the subflows are basically half (or third etc) tcp sessions [07:45:49] the web server (your tcp peer) might still have multiple interfaces [07:46:10] pmtu will need to become mpmtu [07:46:25] question about the extra complexity that this can intro with pmtu, "no need to answer" - question acked. [07:46:43] ams: it's already called _path_ MTU discovery so we're good there. :-) [07:47:11] gabriel montenegro speaking [07:47:32] Lars leaves the room [07:47:38] what happens with mptcp over mptcp [07:48:17] i'm sure SCTP already handles mpmtud [07:48:55] costin is up [07:48:57] first demo [07:49:04] then talk about congestion control [07:49:10] he has sender, receiver, router [07:49:14] 10 mbit interfaces [07:49:22] "shaped" [07:49:24] starts the receiver on the right [07:49:28] Lars joins the room [07:49:36] you see slightly more than 2 mbit [07:49:40] kill interface on router [07:49:45] speed goes down to ~ 1 [07:49:49] brings it back up again [07:49:55] and it's back to 2 mbit [07:50:03] brings them both down [07:50:07] everything stops [07:50:11] takes some time [07:50:15] 1 mbps [07:50:19] second one up [07:50:23] 2 mbps [07:50:37] sorry , megabytes per second [07:50:46] question: rtt ? a: 10ms, small. [07:51:11] about linking congestion controllers [07:51:29] how much traffic do we put on each path? [07:51:34] goals: [07:51:45] danwing joins the room [07:51:53] 1. improve throughput compared to single path on best path with normal tcp [07:51:59] danwing leaves the room [07:52:03] 2. on any path, don't be more aggressive than single path tcp [07:52:06] Dan Wing joins the room [07:52:19] 3. balance congestion = move it to less congested links [07:52:56] (actually need to be fair on shared bottlenecks, too = when 2 or more sublfows flow over the same bottleneck) [07:53:14] which is what he's saying (more or less) now [07:54:06] what if we do independent cc on each path? [07:54:26] 2 paths = 2 x performance of single path tcp, no bottleneck fairness, no resource pooling [07:54:47] (actually you still have weak resource pooling because the second path makes you finish faster on the first path) [07:55:05] solution: couple congestion controllers [07:55:40] this will easily drop w_r below zero? [07:56:02] ams: that was a problem with early versions of this, yes [07:56:03] now on the "fully coupled" slide [07:56:06] don't know if they fixed this [07:56:17] i guess i need to wait till next slide [07:56:24] Iljitsch, could you ask that at the mic if not dealt with? [07:56:26] gigix73 leaves the room [07:56:34] scott: sure [07:56:47] ams: what's your name? [07:56:48] rababy joins the room [07:56:51] Aleksi Suhonen [07:57:33] beautiful wave functions [07:58:04] :^) [08:00:33] what costin just said isn't entirely correct: the window stays the same but you get to send fewer windows per second because fewer rtts per second [08:01:23] I hope we can avoid spending too much time today on peer-review of academic papers... [08:02:18] BTW, I'm not sure what slide is up. [08:02:24] "it works" [08:02:29] This is the foundation for the work. One of the questions is "Is a solution feasible enough to progress in the IETF?". Without the research we couldn't answer that. [08:02:29] the results of the experiment [08:02:31] slides don't seem to be numbered [08:03:06] slide 33 [08:03:30] Scott: may I remind you that peer-review expands to fill the space alloted? [08:03:43] slightly more than fill [08:03:58] :-) his slot is over in 10 minutes [08:04:12] i'm not sure flappiness is that big of an issue: the basic tcp congestion control is flappy too [08:04:25] Have I missed something ... is this looking at varying rtts or just a set of simulated fixed rtts? [08:04:48] gorryf: simulations look at simulations [08:04:55] tsavo_work@jabber.org/Meebo joins the room [08:04:58] :-\ [08:05:38] fully coupled one (the original step) had the problem, but not the final version [08:05:47] right [08:06:21] the expanded question: when you have 2 subfflows, one with 25 window other with 15, would the second have to go to -5 on loss? answer: no [08:06:37] the new algorithm doesn't have that issue, the original coupled algo did, though [08:07:33] gabriel: there should be a goal to behave no worse than current, under perturbations -since the paths are controlled by operators [08:07:43] question at the mike: [08:07:48] is a path like mpls? [08:08:04] costin: no, a path is identified by source/dest addresses in 2-ended mptcp [08:08:06] Home joins the room [08:08:24] he's asking what if you have single-homed endpoints but multipath availability deeper in the network [08:08:29] HannesTschofenig joins the room [08:08:34] what if you have paths that fork in the middle? [08:08:35] I think the answer to this question is that this is only layer 3 path separation not necessarily layer 2. [08:08:47] costin: don't address it, iljitsch is very interested in that [08:08:48] :-) [08:09:21] resnick joins the room [08:09:35] I have not followed this work: How different is multipath TCP from the functionality offered by SCTP? [08:09:45] not very much [08:10:01] So, more or less reinventing it for TCP? [08:10:03] main difference is that mptcp tries to pass through legacy nat boxes and path normalizers [08:10:04] it does about the same as SCTP *with the CMT extension* [08:10:12] but it actually is deployable [08:10:31] A good answer to his question is to see Xiaowei Yang's NIRA paper in the FDNA workshop several years ago. [08:10:37] and for CMT< they never worked out how to couple the congestion control [08:10:45] iljitch discusses about path selector idea. but this involves modifying the router so on the list was decided we do not go this far for now [08:10:57] (how to expose multiple paths in the network to the end systems) [08:10:59] deployable because it uses TCP instead SCTP. [08:11:06] OK. Some congestion control refinements. [08:11:45] gorry fairhurst: question about RTT. rtt on access links can vary very significantly, is this something that is addressed ? [08:11:46] gorry fairhurst is worried about rtts because it's subject to constant change [08:12:26] costin: it's adaptive to whatever the network properties are [08:12:50] costin shows the graphs with the throughput, showing that it's as aggressive as tcp but not more [08:12:57] brian ford?? [08:13:02] bryan [08:13:02] yes [08:13:32] what if you weight the subflows with 1/n [08:13:37] bryan ford: one example was fully coupled and the other uncoupled. suppose you use absolutely standard TCP, but using weighting [08:13:43] costin: bottleneck fairness but not good performance (I think) [08:13:53] costin: you get the bottleneck fairness you no resource pooling [08:14:01] bryan: get over time resource pooling [08:14:28] mark: 2 levels of resource pooling: instantaneous rate and over multiple sessions over time [08:14:29] mark: two different resource poolings - immediate and over time [08:14:41] bryan: promising and I like it but... [08:14:53] we always have a backup position [08:14:54] Dan Wing leaves the room: Replaced by new connection [08:15:08] Dan Wing joins the room [08:15:17] remi: [08:15:21] despres [08:16:04] remi: want to congratulate 3 speakers, most promising and exciting proposal heard in some time [08:16:47] question about finding the right path, the presentation I gave in int area is complemantary, would solve this [08:17:11] if you run this with IPv6 mtu 1280 it would work immediately without mtu problems [08:17:30] costin: need to rework stack to handle path mtuds [08:17:33] costin: you need to do pmtud on each of the path [08:17:52] jana is up [08:18:59] audio okay? [08:19:03] a bit low [08:19:31] how is this related to mptcp? [08:19:34] see bryan's presentation in tsv area for transport layer refactoring [08:19:36] room mics are very quiet. Apeakers and chairs are fine [08:19:42] we saw that already [08:20:08] Lars: I think you'll see. Potential opportunities in refactoring transport influence _how_ one might do multipath [08:20:26] So maybe this was answered before I arrived, or maybe it will be soon, but will this thing realize if I get a new interface and add a new path dynamically while the connection is up? [08:20:58] resnick: the two-ended multipath tcp could certainly be made to do that [08:21:00] Yes [08:21:07] not sure if they're going to bother at this stage, though [08:21:14] send mail to Costin [08:21:31] (how often do you add interfaces in the middle of a session, anyway?) [08:21:34] i don't see the point of doing it wrong [08:22:02] with wireless devices, constantly [08:22:05] @iljitsch: This happens all of the time in mobile environments. [08:22:14] @iljitch: also on servers, would be a useful property [08:22:35] I would assume then you mean an interface comes up and is configured, not that it's physically added to the system [08:22:42] but that stuff is mobility, not multipath [08:22:46] Dave Thaler joins the room [08:22:53] every time you migrate to a new ipv4 network, you get a new ipv6 interface (via 6to4 or teredo) with a bit of latency [08:23:06] as an example [08:23:07] Actually, in wireless you don't _add_ interfaces: they go up and down, and are assigned different IP addresses [08:23:24] If MPTCP does this, the apps folks will stop whining so loudly about ID/Locator split. [08:23:41] jana talking about acks [08:23:53] and evil acking middleboxes [08:23:55] don't the app writers already have dns for id/locator splitting :-( [08:24:02] you must use end-to-end acks [08:24:51] note that what jana is talking about only applies to the single ended solution [08:24:59] @ams: Bah! With only DNS, you get to implement "MPTCP" at the apps layer, or just do random source/destination selection. [08:25:21] Alexander Zimmermann joins the room [08:25:25] And you get to re-implement it for each app. [08:25:59] there's going to be an interesting draft regarding this from christian vogt [08:26:06] he's already written a whitepaper about it [08:26:16] ams: about what? [08:26:40] changing socket api to work with names instead of addresses [08:26:44] basically what jana is proposing is tunnel tcp over multiple tcps [08:27:04] ams: that has been proposed many times, undertaken fewer times [08:27:12] yeah [08:27:17] joe touch: [08:27:22] Yes, I know what Christian proposes. It is terrible compared to this. This is much better for apps. [08:27:25] (not sure what he's saying) [08:27:42] i'm wondering what the routing table will look like. that has to be changed to handle multiple default routes ? [08:27:47] tls doesn't protect tcp at all, need ipsec or tcp-ao for that [08:27:57] TLS protects payload, not header [08:28:10] and he said if MPTCP uses TLS might end up with TLS over TLS. [08:28:12] resnick: with christian's proposal, you can hide a lot more useful features inside the stack, and all the apps will automatically benefit [08:28:12] (but in jana's case the upper tcp would be protected by the tls between the upper tcp and lower tcps) [08:28:19] [08:28:59] tim shepard: can of worms here- browsers do cert checking with the users, what do you propose there with multiple TLS ? query for each ? no need to answer now, just take it into account. not clear now what you are planning to do. [08:29:38] @ams: You end up needing new APIs, and you don't want to hide certain things. Again, MPTCP is much better from the apps perspective. Dynamic binding to the paths, which the app shouldn't have to care about. [08:30:00] bryan ford: don't want the possibility precluded [08:30:28] andrew y: there's also a possibility to have a single TLS layer over multiple paths [08:30:38] so the tls does the multiplexing [08:30:44] jana: yes, absolutely [08:31:07] but if you lose one path you lose the entire association, here (pointing) you don't have that problem [08:31:50] (disagree with him, if the tls messages are sent over a single path and can be retransmitted over another (= changes to tls) then you can survive losing a path) [08:31:57] Alexander Zimmermann leaves the room [08:32:51] @iljitch: yes this would require some tweaks to tls, but i do not see why it would not be possible in principle [08:33:12] Iljitsch: makes sense. security is in the topmost of their transport sublayers, so it could be path-independent. [08:33:31] Dan Wing leaves the room: Replaced by new connection [08:33:45] danwing joins the room [08:33:51] jana: would like to see an architectural document be part of this proposed wg's efforts [08:34:12] "architecture" can mean so many things. He wants to show how functions can be isolated from each other, made modular. [08:34:52] I like that idea. [08:35:12] why do architects always want that? my laptop cut out of a single slab of aluminium is much nicer than one assembled from badly fitting parts [08:35:27] marc blanchet: [08:35:42] are we on the general tch discussion? [08:35:46] mark: yes [08:35:53] williw joins the room [08:35:54] (please not all at the same time!) [08:36:04] marc: [08:36:11] can't you multipath chat [08:36:13] gigix73 joins the room [08:36:20] you're at the socket level, same address family, correct? [08:36:20] Yes you can :-) [08:36:22] mark: yes [08:36:40] can use v4 and v6 streams at the same time? [08:36:45] the interesting thing about text-based media is that everyone can talk at once and be heard. So the overall bandwidth can be significant if a group knows how to use it [08:36:50] mark: yes, but don't think our implementation can [08:37:12] scott: and you can tell the difference between marc and mark [08:37:18] imho it would take a new socket API but I think it would be a great idea. [08:37:18] marc: and do we want to do this? [08:37:45] (I think that's really good because v4/v6 automatically gives you paths that are likely to be different somewhere along the way) [08:37:51] @scott: and use the name as a parameter there as opposed to address [08:37:57] see also my shim6to4 draft [08:38:08] @iljitsch: v4mapped sockets are dual-family sockets [08:38:29] Is Marc asking whether we need to change the Application Interface if MPTCP uses both v4 and v6? [08:39:01] I think he was [08:39:03] didn't catch name: using more ports, how feasible is this? [08:39:14] gabriel montenegro: v4v6 issues, something to be aware of, the ports are not just ports, but are part of the v4 address space. when we have the discussion here why dont we just use the ports, we need to be aware of the effect of that on other proposals [08:39:50] costin: the only reason it has ports in it is for legacy reasons, no reason to use more ports [08:39:56] Ouch, that sounds like a security nightmare... identifiers are tricky to get right... [08:40:32] costin: identifiers is something that gets negotiated, to get the demuxing; you use the ports for legacy reasons [08:40:44] there's been some debate about shared bottleneck detection on the mailing list, but I haven't noticed anyone mentioning this: if the peer receives any icmp messages regarding two different subflows from the same router, it can mark them as possibly sharing a bottleneck and use that info in the algorithm, if it needs it [08:42:17] dino: mptcp can not choose path [08:42:29] it only chooses exit interface [08:42:42] exit router [08:42:50] there may be more than one on the same link [08:43:19] dino: ingress filtering issues, if you send packet with source A to ISP B the ISP drops the packet [08:43:31] williw leaves the room [08:43:39] mark: yes, issues that need to be addresses [08:43:43] addressed [08:43:46] dino: keeping interface and path selection loosely coupled means things would break in a lot of cases [08:44:08] Dino: folks who pay for two ISPs always make some arrangement to be able to send on both [08:44:32] This is rubbish. This is not just for load splitting. [08:44:38] i'm doing some work on address selection algorithms, probably ending up in 6man, but one thing I'm going to be keeping in mind is interaction with MIF and with multipath protocols [08:44:39] john: not in the case of consumer cable link + consumer adsl link [08:45:15] resnick: this is different things for different people [08:45:29] Iljitsch: yes, you can send on both, you just need to use different source IPs [08:45:29] dino is right for 1-ended solution, but not for 2-ended solution for which dest addr also gives different paths, not just first hops [08:45:37] @ams: Correct. But Dino is assuming only one scenario. [08:45:52] but the uRPF applies in all cases, which scott is saying now too [08:46:18] tim sheperd: [08:46:29] bundle of comments, want to use up 2 hrs [08:46:29] shepard [08:46:51] (people should spell their name at the mike) [08:46:59] :) [08:47:06] there's so many ways to spell sheep herd :) [08:47:10] agree :) [08:47:31] Bar-code reader at the mic to scan the badges. [08:47:46] need a QR on badges then [08:47:54] yeah RFID [08:48:07] oh boy that would be fun to hack [08:48:07] rfid's would obsolete blue sheets [08:48:10] There's already a zebra stripe on the badges. [08:48:12] or use the built-in mike on your own laptop, especially in 150-across stadium seating [08:48:22] joao.taveira joins the room [08:48:34] iljitsch: that would be awesome [08:48:37] not sure what the question is that Tim is trying to work up to, though [08:48:50] the smaller and cheaper your mic, the more fans you'd instantly get! [08:49:29] There's his point: security of sets of paths... [08:49:31] ams: check out my homegate bar bof home recording: http://www.muada.com/Homegate-2009-07-27-Stockholm.mp3 [http://www.muada.com/Homegate-2009-07-27-Stockholm.mp3] [08:49:33] Tim says hip/shim6 needs something like this [08:49:37] gigix73 leaves the room [08:51:01] I'm with Scott on this. [08:51:57] Oh I'm so surprised! [08:52:10] ;) [08:53:38] we already have multicast and ipsec and mobile ip that work in ipv6 and not in ipv4 [08:53:49] [08:53:52] remi wants to make mptcp the killer app for ipv6 [08:55:12] what I said at the mike: what I imagined was build one-ended mptcp first and then put it on top of shim6 to gain multi-address support, which is nice and modular, but the two-ended approach has the advantage that it runs over IPv4 [08:56:32] not sure what Bryan's point about flow layers and IP versions is [08:56:38] except that IPv6 is cleaner [08:56:41] would the working group have to gravitate towards one-ended or two-ended? [08:56:49] um there's V6 firewalls too [08:56:50] that's the next topic [08:56:53] And you can always use the backwards-sequence-numbers trick that Skype uses if you want to play with the minds of v4 middleboxen [08:56:59] joao: it's up for grabs, so pose an opinion [08:57:04] the one-ended approach doesn't seem to extend naturally to the two-ended one [08:57:13] at least when comparing your approach and Mark's [08:57:34] joao: could be make to if desired, though [08:57:56] gorry: not want to see all of this go on at the same time in the same group [08:57:59] gorry would not like to see everything at the same time (v4/v6) [08:58:04] sctp is able to migrate connections between ipv4 and ipv6 btw [08:58:16] sorry, sometimes name: means name is speaking, sometimes it's me replying to them [08:58:22] I'll do the latter with @ from now on [08:58:48] HIP can migrate v4 to v6 with arbitrary transports... congestion control is sometimes a problem though [08:58:53] joe touch: this doesn't help the port consumption issues [08:59:23] mark: there will definitely v6 nats but not translate port numbers [08:59:28] joe: no they will [08:59:46] michael tüxen?? [08:59:53] yes [08:59:55] tuexen also [09:00:02] no no, tüxen [09:00:15] more subflows means more state in nats [09:00:30] depends on whether you have an umlaut available on your keyboard layout! [09:00:41] alt-u u [09:00:45] (on the mac) [09:01:04] ümlaüt [09:01:12] I think the discussion is spiraling out of control... or at least away from the topic [09:01:20] yes but we're done now [09:01:21] ł is harder, though [09:01:29] more than IPv6 NATs? [09:01:50] wg chartering discussion [09:01:59] scott wants to NAT the mailing list... [09:02:07] comment: In my opinion, multipath TCP work should be done so that we can maximize its deployability. This means working through existing middleboxes and support for both IPv4 and IPv6. Perhaps it will also have a role in promoting IPv6 deployment, but I see that more through enabling the use of IPv4 and IPv6 at the same time, rather than artificially restricting it to IPv6 only. [09:02:15] point is to decide whether to charter a wg [09:02:22] @jari: ask at mike? [09:02:34] jari is in finland [09:02:44] @jariarkko: yeah that was what Aleksi mentioned and I already voiced that at the mic [09:03:24] joe touch: set of problems is fairly well-defined [09:03:32] HUI joins the room [09:03:40] hesitate to colaboratively design a horse [09:03:45] But camels work really well... they might be ugly and smelly, but they work. [09:03:55] if lisp is a wg then this ought to be one for sure [09:04:06] needs to go to experimental [09:04:15] @iljitsh: +1 [09:04:27] (channeling joe right now) [09:04:38] All the platforms out there that are likely to ever get an implementation of this already have an SCTP implementation. --> the reason to form this wg has to be something sctp (or hip or mobile ip or any of the other existing protocols) can't do [09:04:49] mark: we have two detailed proposals [09:05:09] not here with a blank slate [09:05:09]