Subject: Re: [irtf-discuss] preliminary IRTF Open meeting minutes from IETF-82

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 16 Dec 2011 06:50:41 +0000

I haven't received any comments, so I will be uploading these now.

Lars

On Nov 18, 2011, at 5:02, Lars Eggert wrote:

> Thanks to Stuart Cheshire for taking minutes! Please reply with corrections and additions to me.
> 
> Lars
> 
> 
> IRTF Open Meeting
> Taipei, Taiwan
> TUESDAY, November 15, 2011
> 1300-1500  Afternoon Session I
> Room 201 ABC
> 
> State of the IRTF (RG Chairs & Lars Eggert)
> 
> 	Lars and various RG chairs presented status updates
> 
> IPR and the IRTF
> 
> 	Lars presented clarification that IETF "Note Well" does apply
> 	to IRTF participation. Explicit document explaining this is being
> 	prepared.
> 
> 	Ken Carlberg: How is NCRG proceeding?
> 
> 	Lars Eggert: Meeting is planned for Paris. Work has been done already.
> 	There is a wiki.
> 
> 
> 
> Applied Networking Prize (ANRP) Award
> 
> 	Lars presented background on ANRP Award.
> 
> 	Nomination form is at <http://irtf.org/anrp>
> 
> 	Nominees need to have published or accepted academic paper.
> 
> 	Both self-nomination and third-party nomination is encouraged.
> 
> *** Michio Honda *** for his research into determining the future 
> extensibility of TCP:
> 
> Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam Greenhalgh, Mark
> Handley and Hideyuki Tokuda. Is it Still Possible to Extend TCP?
> Proc. ACM Internet Measurement Conference (IMC), November 2011, Berlin,
> Germany.
> 
> 	Mat Ford: Do you intend to continue taking measurements to see how these
> 	results change over time?
> 
> 	Michio Honda: 
> 
> 	Peer Azmat Shah: Is head-of-line-blocking a problem?
> 
> 	Michio Honda: No
> 
> 	Matthew Mathis: What software did you use to send raw packets from
> 	Python?
> 
> 	Michio Honda: Raw IP Sockets on Linux, libpcap on BSD and OS X
> 
> 	Hannes Tschofenig: It may be difficult to do the same tests repeatably
> 	over time. Also, you meshed two things together in one document: 1. New
> 	TCP Encryption option, 2. Measurements. Would like data on how IP
> 	options fare in today's Internet. Can't we have a more systematic way of 
> 	taking these measurements?
> 
> 	Michio Honda: The Internet evolves unexpectedly
> 
> 	Lars Eggert: This is not the only work measurement work going on.
> 	This was presented at IMC -- Internet Measurement Conference
> 
> 	Matthew Mathis: These tools require root permission
> 
> 	Google is doing an IPv6 experiment in JavaScript via YouTube views,
> 	which does not require root permission.
> 
> 	Stuart Cheshire: JavaScript experiments in the browser are useful,
> 	but some experiments can't be done that way
> 
> 	Spencer Dawkins: I'm really pleased with the award being given for this
> 	work. There used to be a Working Group working on stuff like this.
> 	Maybe we could resurrect that.
> 
> 	Dirk Kutscher: Look into different architectures like home networks and
> 	3G.
> 
> 	Stuart Cheshire: Different things are possible on different networks -- 
> 	things like IPv6 link-local can be used on a home network but not the
> 	public Internet. Knowing what's viable on the public Internet is still
> 	very valuable.
> 
> 	HK Chu: Should have an RFC or other document on what is the right thing
> 	to do for new vendors. E.g. for TSO or Large Segmentation Offload.
> 
> 	Matthew Mathis: The IETF needs a doc stating what is allowed and what is 
> 	not. Otherwise we have no way to tell vendors they are wrong.
> 
> 	Piers O'Hanlon: Can you use something like nmap to identify what 
> 	middlebox did the damage?
> 
> 	Michio Honda: No
> 
> 	Hannes Tschofenig: Some work has been done on identifying middleboxes.
> 	Will you release the data you collected?
> 
> 	Michio Honda: Yes, the URL for the raw data is in the paper, with
> 	anonymized IP addresses
> 
> 
> *** Nasif Ekiz *** for his analysis of misbehaving TCP receivers:
> 
> Nasif Ekiz, Abuthahir Habeeb Rahman and Paul D. Amer. Misbehaviors
> in TCP SACK Generation. ACM SIGCOMM Computer Communication Review,
> Volume 41, Issue 2, April 2011.
> 
> 	Mat Ford: Are there any conclusions you draw about how we might specify
> 	future IETF standards to reduce such mistakes?
> 
> 	Nasif Ekiz: Implementers should test better
> 
> 	Yoav Nir: But TCP does actually work on Windows. How much performance
> 	degradation did all these problems cause?
> 
> 	Nasif Ekiz: In some cases, half 
> 
> 	Brian Trammell: Were you testing just single byte drops?
> 
> 	Nasif Ekiz: No. It's just written that way for clarity in the paper.
> 
> 	Spencer Dawkins: Thank you for doing this work. You talked about the
> 	difference between unexpected behaviors and misbehaviors.
> 	At the IETF we've seen spectacular misbehaviors.
> 	I hope you are presenting this work elsewhere too.
> 
> 	Nasif Ekiz: Most of these things were "SHOULD" statements in the specs,
> 	but they still look like bugs. In some cases we could look at source
> 	code to see the bugs.
> 
> 	Matthew Mathis: Every single SHOULD is there because there's also a
> 	reason not to do it. Reneging language was there specifically to
> 	accommodate receiver bugs.
> 
> 	Dave Oran: Where there was state leakage between TCP connections the
> 	example had the same ISN for both connections - which should never/
> 	rarely happen if you implement ISN randomization correctly.
> 
> 
> Ning So, Cross Stratum Optimization
> 
> 	Hannes Tschofenig: Are you planning to look into the specific needs of
> 	particular applications?
> 
> 	Ning So: We don't want to attach the study to any specific application.
> 
> 	Hannes Tschofenig: Different applications have very different needs.
> 
> 	Susan Hares: Would you like to get cooperation from people like game
> 	developers?
> 
> 	Ning So: Yes, we would love to have collaboration.
> 

-- 
Mobile number during December:    +358 46 5215582
Mobile number starting January:  +49 151 12055791