09:05 TSV/NOMCOM (15 minutes) ----- lars: people don't want to put names in because they think there would be better choices; nomcom needs people to pick from; please put your name in; you can still give positive feedback for someone else ----- 09:20 MPTCP Update (30 minutes) ----- bob: clarification what does not publicly available mean? phil: code and anon is not pub. available but interop is tested lars: will you work on all this items first before you move this to standards track? ask ADs what needs to be done martin: editorial stuff needs to be fixed first phil: people think add_addr should be solved, others might be discussion lars: don't see value in waiting a long time to move it over because there are enough implementations marcelo: fixing the editorial is very easy martin/phil: having this discussion on mptcp list mptcp implementation report comments: no. ----- 09:50 Minions (30 minutes + 15 minutes Q&A) ----- scott: run by vendor or at home? Jana: run at home stuart: in last slide was only exp setup to see how http would perform with minion without rewriting safari. that's why we used a proxy. when a web browser opens multiple connections you are not under control when data will arrive thus having one single connection is better jana: new applications give you control and you wouldn't need proxy jim: power of beginning truly backwards compatible is large. then deployment by upgrading millions of system went quickly because advantage to application designers is large m. tüxen: important to provide this to apps. how this is done in tcp is different. but getting app designers aware to use this. thought this would be on app layer stuart: my contribution was that pairing of request and reply was needed. can be done at the app or transport layer. try to keep it simple to implemented it. but request/response is so common that we can take the responsibility to support in network api to have it comfortable to use jim: have pain level low for app designers for them to use it because they can't multiple their testing feature jana: one feature of minions is also reuse. few more modifications only needed m. tüxen: where is matching of request/response used and is this only a question of the api? stuart: additional message in transport and then api makes it easy to resend code and run a reply m. tüxen: is this only an api benefit at the sender or is it used anywhere else? does it has to be on the wire? stuart: different api and it also makes different bits on the wire. draft -00 not written in stone yoav nir: nat might not except anything just because its tcp jana: nat that looks at payload might not understand but it can also be encrypted. firewall vendors would need to decode yoav: 10 years ago we had firewall everywhere and then 8 years ago it stopped working because ssl changed jana: firewalls can look at the minions description randell: home femtocell sends sctp; 4 mio deployed; and my homebox lets them through now stuart: we dont think nat cant be changed but we don't know how many of them and how fast. how many of your costumers are you willing to sacrifice marc nottingham: request/response in transport; http2 we have a model were we have streams stuart: might be wrong impression; request/response is optional marc: should be more generic stuart: its involving right now; input welcome jim: http 1.1 can do what you want marc: is source code available because it's apple? stuart: think about releasing this but apple needs a while ?(1): http perspective with dpi boxes jana: tool is working on transition and negotiates to switch modes; minion offers end of minion message to turn it of stuart: general transport protocol to make it easier for apple developers to make new applications; if it fits with http that would be wonderful and switch modes would be easy but potentially not without additional rtts but we are happing to work on this. see what works well enough to get deployed jana: new api allows app developers to design app around this api ?(1): dpi might not be possible anymore on port 80 because of additional headers even when backwards compatible on the wire with tcp stuart: we wanted to be compatible with tcp. ip over http would go too far m. scharf: shim layer on top of tcp. same discussion on mp but decided to go for tcp option. couldn't you achieve the same thing with options instead of out-of-order delivery jana: no negotiation needed and don't have to change the other endpoint. main idea change api and be widely compatible; deployment advantage to provide this early stuart: its a shim that ...??; out-of-order is only implemented at receiving end to support this better; large number in flight makes big number of packet sitting in the kernel; does happen when there is no loss; unjam kernels so apps can go on jim: have to have incentive for app developers because they need to change there code and u cant make the testing harder that encourages upgrade of things elsewhere; mayor reason on ipv6 deployment because app code goes more complex and untestable; get the incentives right and you can get rapid upgrades to minion usage stuart: extra incentive for new applications to have faster time to market; focus is not rewrite jana: main reason to have this in tsvwg to have more general usage fre?: TLS and Minion? jana: would loose advantage of kernel implementation ?(2): flow control of streams is addressed? release buffer quickly but put this task to app developers jana: section in draft and minion doesn't do flow control stuart: discussion offline and in draft why we think that is not necessary 10:35 Online Games Tutorial (45 minutes) ----- stuart: not a fan of qos; might mis-classify and also in my experience it might get better but others get worse. flow separation would help fairness mirco: ?? jim: fairness relates also to RTT; bufferbloat found through WoW playing m. tüxen: requirements that apps want to see from service layer, rtcweb are doing this; udp unaffected by high packet loss, what congestion control will they do? mirco: fec, probably no cc jason livingood: interesting presentation; many gaming companies are only single homed and have own data center