TSVAREA IETF 85 Atlanta, GA State Migration --------------- Yingjie Gu presented on the state migration issues, approaches, and relation to existing protocols. http://tools.ietf.org/html/draft-gu-statemigration-framework-03 Matt Mattis: It is an interesting problem but maybe too constrained problem, which means that the problem is not yet well specified. Kevin Fall: custom ICMP messages for evil middlebox Melinda Shore: this document does not fully conform it but can easily be made to be conformant. Someone: The most successful middlebox protocols are the ones that dont directly talk to the middlebox but work with them like ICE, STUN, TURN Melinda Shore: It is important infrastructure which we should be able to manage LMAP ---- Henning Schulzrinne presented on the FCC's plans for broadband network measurement and LMAP: http://tools.ietf.org/html/draft-schulzrinne-lmap-requirements-00 Lars Eggert: if you measure only actively and not when users are not using the system then you only measure during off-peak hours Henning: We dont need everyone's measurements and surprisingly there are some users which are not using their systems and they can correlate Lars: but what if I use the web radio all day then you may not get measurements J. Lennox: what if the ISPs start to prioritize measurement traffic? Henning: some measurement servers are outside the ISP control and then there is a code-of-coduct in place. However, since the FCC also involved there is less risk of that happen Sam: answering to Lars: drop off in peak times is about 8-10% in the sample size. Sam questions why data integrity is out-of-scope Henning (as indiviual): since data storage is not an IETF or protocol problems. Statistics will fall into the IRTF as opposed to the IETF. Marcelo: you were trying to measure performance provided by the access provider Henning: the measurement servers are very close to the ISP i.e., they have a very low latency to the ISPs. The distance doesn't seem to make that much difference. We use MLAB servers for measurement storage. Someone: CDNs may cache the 10 webpages that you measure therefore there may be another measurement bias here. Henning: measuring just latency for handful is not scientific but it is possible that if an ISP has a high score then it is likely they will have a high score across other popular websites. Matt Mathis: is the measurement data accessible? James: 2011 data is available on the website along with the report. you will find raw tests in a tar ball in csv format. Al morton: Performance of throughput predictability may be peak rate and not sustained speed. Henning: The customer wont know the difference and it is better for the consumer. So they should use the right metric, the consumer visible speed and not the peak speed Al Morton: Verify both, peak and average speed. Scott: just to continue from Al morton, term throughput may be the wrong term because it means something different in the IETF than used here. Henning: If you download a large file, the consumer should be able to generally get that advertised speed. However, I do agree that there may be some ISP specific behaviours such as power boosters etc. James: The statistics you see here are based on the measurement data. So the metrics and apparatus of measurements should be discussed in the Bar-BOF which is on Wednesday after the plenary. We worked with the ISPs and found out what was the provisioned rate for the user. So Someone: I support the work, it is not the metrics but the protocols to enable measurements. Henning: Right, metrics are an evolving science, and we make them better over time. Someone: +1, the slides may be Biggest concerns I have with the privacy of the end-user. So the end-user may not want the government or a researcher into a home Michael Tuexen: What about bit testing features instead of metrics. Like IPv6. non-TCP and non-UDP. Henning: We could do DNS-SEC or some other low hanging fruits like IPv6 etc. I'd gladly say we should be able to do everything and we should be building a generic infrastructure. So that other people can join in. Lars: Instead of using a hardware do something a purely software based Henning: there are 3 steps: 1. We are largely box based. 2. we can add it easily to the DSL box, your linksys box 3. add software based. But the 3rd one is more a research project and has more security issues like trust of the software. Lars: wouldn't be easy to do software and then go to the hardware, instead of the other way round which you are proposing. Henning: we have the box providers interested and we can easily integrate these tests into them. Jana Iyenger: instead of metrics, I would like to replace features with reachability. Bob Briscoe: you are only talking about active measurements, are you religiously opposed to passive measurements. Henning: we should make sure passive measurements work. However, it may depend on the end-user if they want to share those test results. Passive measurements may open a can of worms that I didn't want to fall into. Bob: Passive measurement should be possible Henning: a mobile device had a passive measurement turned on and then the data got leaked though nothing bad happened, but it would be something we wanted to avoid. however the architecture doesn't make a distinction between active and passive measurements. >From Jabber: is this architecture applicable to both mobile measurements? Hennning: It should be possible, but is the problem statement scoping question.