IETF
irtf
irtf@jabber.ietf.org
Tuesday, 15 November 2011< ^ >
Room Configuration

GMT+0
[01:46:50] john.levine joins the room
[01:47:06] john.levine leaves the room
[04:59:46] shima joins the room
[04:59:55] shima leaves the room
[05:02:52] pselkirk joins the room
[05:03:08] pselkirk leaves the room
[05:03:56] naptee joins the room
[05:04:00] naptee leaves the room
[05:04:36] wesley.m.eddy joins the room
[05:04:53] naptee joins the room
[05:10:43] nco joins the room
[05:11:07] Scott Brim joins the room
[05:13:34] <Scott Brim> Greetings
[05:14:10] dhruvdhody joins the room
[05:14:20] <Scott Brim> will anyone be scribing?
[05:14:40] <wesley.m.eddy> I can; we're talking about IPR
[05:14:45] <Scott Brim> oof
[05:14:53] <Scott Brim> (and thanks)
[05:14:59] <wesley.m.eddy> the slide only says "IPR and the IRTF"
[05:15:22] <wesley.m.eddy> the IETF note-well applies
[05:15:27] <wesley.m.eddy> ken calvert at mic
[05:15:42] <wesley.m.eddy> asking if networking complexity group is proceeding
[05:15:57] <wesley.m.eddy> lars shows prior slide that says they were chartered (but not meeting this week)
[05:15:59] <Scott Brim> Thanks Wes I'm grateful
[05:16:04] <wesley.m.eddy> they are preparing meeting for paris
[05:16:59] sftcd joins the room
[05:17:00] <wesley.m.eddy> IPR text for the IRTF will be discussed in Paris
[05:17:21] <wesley.m.eddy> must disclose existence of IPR; not necessarily discuss licensing terms
[05:17:39] <wesley.m.eddy> IRTF doesn't do standards, so disclosure only
[05:17:39] <sftcd> @wes: s/not necessarily/not/ I think
[05:18:13] <wesley.m.eddy> moving onto applied network research prize
[05:18:47] Scott Brim claps
[05:21:04] <wesley.m.eddy> showing michio's certificate
[05:21:17] dhruvdhody leaves the room
[05:21:39] <Scott Brim> fyi I tried to get the audio stream but if it's working then my hotel net is overwhelmed
[05:21:42] <wesley.m.eddy> mat ford giving miciho the plaque
[05:22:14] <wesley.m.eddy> now showing michio's slide deck "is it still possible to extend tcp?"
[05:22:39] <wesley.m.eddy> motivation
[05:23:28] <wesley.m.eddy> slde: the original internet
[05:23:46] <wesley.m.eddy> slide: the real internet
[05:23:53] <Scott Brim> :)
[05:24:16] <wesley.m.eddy> (mobile phone messing with mic)
[05:24:48] <wesley.m.eddy> slide: extending tcp: the reality
[05:25:20] <wesley.m.eddy> slide: contributions
[05:25:57] <wesley.m.eddy> slide: measurement methodology
[05:27:22] <wesley.m.eddy> slide: experimental setup
[05:27:57] <wesley.m.eddy> slide: our tests
[05:28:22] <wesley.m.eddy> slide: middleox behaviors depend on the port number
[05:29:35] <wesley.m.eddy> slide: tcp option test results
[05:30:34] <wesley.m.eddy> slide: how tcp options are removed
[05:31:33] <wesley.m.eddy> slide: sequence number hole test
[05:33:36] <wesley.m.eddy> slide: segment splitting/coalescing test
[05:34:45] <wesley.m.eddy> slide: intelligent nics
[05:36:02] <wesley.m.eddy> slide: design implications multipath tcp
[05:39:29] <wesley.m.eddy> slide: design implications tcpcrypt
[05:40:13] <Scott Brim> I have no issues with the first two presentations. I will probably have some questions about CSO
[05:40:29] <wesley.m.eddy> slide: design implications: tcp extended option space
[05:40:39] <wesley.m.eddy> I think *everyone* has questions about CSO ...
[05:40:43] <Scott Brim> :)
[05:40:55] <wesley.m.eddy> slide: design guidelines for tcp extensions
[05:42:21] <wesley.m.eddy> slide: conclusion
[05:43:07] <Scott Brim> conclusion: TCP minion mode will rule
[05:43:09] <wesley.m.eddy> (clapping)
[05:43:42] <wesley.m.eddy> mat ford: longitudinal analysis of results would be interesting; have numbers evolved over time; is this ongoing work?
[05:44:54] <wesley.m.eddy> michio: doesn't expect to change so quickly, but can measure the same path over time
[05:45:12] <wesley.m.eddy> unknown from pakistan: mptcp question about head-of-line blocking
[05:45:35] <wesley.m.eddy> michio: mptcp is more robust
[05:46:00] <wesley.m.eddy> lars points to mptcp later in the week, then takes back (it won't meet this week)
[05:46:21] <wesley.m.eddy> matt mathis (google): missed the paper, but AWESOME piece of work here
[05:46:31] <wesley.m.eddy> what is the lower system interface?
[05:46:45] <wesley.m.eddy> michio: linux, freebsd, mac os x, with libpcap and raw ip socket
[05:47:35] <wesley.m.eddy> hannes t: likes the work, and hopes for more for different layers, results may be different with more countries
[05:48:32] <wesley.m.eddy> hannes only cares about measurements, not about tcpcrypt
[05:48:35] <Scott Brim> What does that mean, more for different layers? Doing the same for HTTP? Huh?
[05:48:38] <wesley.m.eddy> looking for behavior of IP options
[05:48:41] <Scott Brim> ok
[05:49:01] <wesley.m.eddy> wants more "systematic" and timely/regular testing
[05:49:26] <wesley.m.eddy> matt and spencer d lining up at mic
[05:49:34] <wesley.m.eddy> michio: systematic is very hard
[05:49:50] <wesley.m.eddy> lars: agree with hannes and say "yes we need to measure more"
[05:49:58] <wesley.m.eddy> hannes: wants more data
[05:50:26] <wesley.m.eddy> lars: this was published at IMC (internet measurement conference); we used to have internet measurement research group
[05:50:42] <wesley.m.eddy> michio got this award because the findings help us design protocols in light of reality
[05:50:50] <wesley.m.eddy> reviewers stressed this as "really good"
[05:51:05] <wesley.m.eddy> mathis: question of what you need to install on system - requires root
[05:51:42] <wesley.m.eddy> google is running ongoing ipv6 experiment in javascript; everytime you use youtube, they may get a datapoint on if v6 works for you
[05:51:59] <wesley.m.eddy> runs in any browser, any platform, anywhere
[05:52:08] <wesley.m.eddy> because this requires root, you can't run in browser
[05:52:19] <wesley.m.eddy> lars: and you need sender and receiver to measure these things
[05:52:28] <wesley.m.eddy> matt: youtube experiment on v6 is public
[05:52:38] <wesley.m.eddy> lars: you ship handsets; you have root!
[05:52:42] <wesley.m.eddy> matt: I do not have root!
[05:52:48] <Scott Brim> :)
[05:53:26] <wesley.m.eddy> spencer: really pleased, remember tcp-impl working group that used to document stuff like this
[05:53:37] <wesley.m.eddy> revisit need for that in ietf/irtf?
[05:54:10] <wesley.m.eddy> dirk k: nice work, come back to hannes point
[05:54:37] <wesley.m.eddy> look more into different architectures, home, 3g, etc might be interesting
[05:54:49] <wesley.m.eddy> michio: some described in paper
[05:55:02] <wesley.m.eddy> stewart c and jerry chu at mic
[05:55:13] anonymous4706 joins the room
[05:56:08] <wesley.m.eddy> stewart (apple): quick comments - matt talked about browser tests - great for what you can do there, for what dirk said - that is very valuable, on different networks (with apple products) apple tv uses link-local, you can use sctp on home net, but need to know what works on public internet
[05:56:33] anonymous4706 leaves the room
[05:56:37] tplunke\40jabber.org joins the room
[05:56:52] <wesley.m.eddy> chu (google): comment on TSO - ietf should produce informational rfc on TSO - we spend a lot of time on this - what is the right thing to do?
[05:57:15] <wesley.m.eddy> vendors don't provide information; makes it hard to do the right thing
[05:57:42] <wesley.m.eddy> matt: not a public spec, can't tell someone they've done it wrong
[05:58:19] <wesley.m.eddy> piers o'hanlon: tools that fingerprint OSes, can you figure out what boxes are to blame?
[05:58:52] <wesley.m.eddy> michio: we don't do that
[05:58:59] <wesley.m.eddy> mathis at mic
[05:59:11] <wesley.m.eddy> likely that lots and lots of datapoints fall into finite number of bins
[05:59:28] <wesley.m.eddy> could ask particular ISP whose product is deployed
[05:59:39] <wesley.m.eddy> michio: did ask people, can't write it :)
[06:00:10] <wesley.m.eddy> hannes again
[06:00:23] <wesley.m.eddy> tor project has tool for doing that (figuring out middleboxes)
[06:01:37] <wesley.m.eddy> thank you, clapping
[06:02:21] <wesley.m.eddy> changing to naif: misbehaviors in tcp sack generation
[06:02:23] <wesley.m.eddy> clapping
[06:02:37] <wesley.m.eddy> nasif gets a plaque
[06:03:19] <wesley.m.eddy> outline slide
[06:03:25] <wesley.m.eddy> tcp acknowledgements
[06:03:40] <wesley.m.eddy> (slides look like they were done in latex! -- haven't seen that in a while)
[06:04:39] <wesley.m.eddy> slide: deployment of sack
[06:05:16] <wesley.m.eddy> slide: data reneging
[06:06:55] <wesley.m.eddy> slide: renegdetect
[06:08:07] sftcd leaves the room
[06:08:34] <wesley.m.eddy> slide: research goal
[06:08:44] <wesley.m.eddy> slide: experimental design
[06:10:01] <wesley.m.eddy> slide: misbehavior a
[06:12:55] naptee leaves the room
[06:13:57] <wesley.m.eddy> slide: misbehavior c
[06:14:05] <wesley.m.eddy> slide: misbehavior d
[06:16:16] <wesley.m.eddy> slide: misbehavior e
[06:16:56] <wesley.m.eddy> slide: misbehavior f
[06:18:37] <wesley.m.eddy> slide: misbehavior g
[06:19:25] sftcd joins the room
[06:19:55] <wesley.m.eddy> slide: results
[06:20:20] <wesley.m.eddy> cheshire: what about os 10
[06:20:30] <wesley.m.eddy> (it's in next slide, passed all tests)
[06:20:55] <wesley.m.eddy> slide: summary
[06:21:07] sftcd leaves the room
[06:21:45] <wesley.m.eddy> questions (clapping)
[06:22:01] <Scott Brim> does that mean OS 10 was the only one of any of them that passed all the tests?
[06:22:07] <wesley.m.eddy> lars: hard to implement something simple, how would we do with something hard?
[06:22:35] <wesley.m.eddy> scott - yes, there are 2 results slide, one with 26 OSes that failed one or more tests, and another with those that passed all test
[06:22:44] <Scott Brim> Oh now I see, thanks
[06:22:53] <wesley.m.eddy> long mic line
[06:23:23] <wesley.m.eddy> yoav (checkpoint): tcp does work, what is impact to performance of these misbehaviors
[06:23:37] <wesley.m.eddy> nasif: you have to spend much more time to measure performance, can be done
[06:23:44] <wesley.m.eddy> lars: one case where it's halved
[06:24:15] <wesley.m.eddy> brian ?: question on size of drops - they were 1460 (entire segment)
[06:25:16] <wesley.m.eddy> spencer: very valuable work; difference between unexpected and mis-behaviors ... spectacular misbehaviors have happened, be careful in distinguishing between them
[06:25:35] <wesley.m.eddy> nasif: spec is mostly SHOULD statements
[06:27:19] <wesley.m.eddy> mathis: every single SHOULD is there because we knew a reason not to do it
[06:27:48] <wesley.m.eddy> nasif: the more you send, the more robust to ack loss
[06:28:09] <wesley.m.eddy> mathis: case where that happens is astonishingly complicated (dozen packets, 3-4 losses in each direction)
[06:28:29] <wesley.m.eddy> some are bugs in document - no applications sent bidirectional data at the time
[06:28:42] <wesley.m.eddy> when 2018 was written
[06:28:46] <wesley.m.eddy> first was BGP
[06:28:57] <wesley.m.eddy> before ssh, telnet only sent short segments
[06:29:36] <wesley.m.eddy> reneg is not about memory, about bugs, forced whoever did the sender to test reneg code so that consequence is timeout rather than more serious
[06:29:55] <wesley.m.eddy> nobody deliberately renegs
[06:30:25] <wesley.m.eddy> oran: quick question about state leakage between subsequent connections
[06:30:39] <wesley.m.eddy> ISN randomization might prevent bug g
[06:31:12] <wesley.m.eddy> nasif: slide gives mistaken impression
[06:31:21] <wesley.m.eddy> clapping
[06:31:33] <wesley.m.eddy> lars: rest of session available for CSO
[06:32:02] <wesley.m.eddy> will be more ANRPs next year - thinking of going less frequently (yearly)
[06:32:24] naptee joins the room
[06:32:27] <wesley.m.eddy> help us find papers
[06:32:40] <wesley.m.eddy> slides: cross stratum optimization research proposal
[06:32:59] <wesley.m.eddy> ning so presenting
[06:33:03] <wesley.m.eddy> slide: current approaches
[06:34:10] <wesley.m.eddy> slide: cso approach
[06:35:16] <wesley.m.eddy> slide: cso goals
[06:37:01] <wesley.m.eddy> slide: key research problems
[06:37:41] <Scott Brim> I have a concern about "responsiveness to quickly changing" etc. You need to be careful about positive feedback loops.
[06:37:52] <Scott Brim> (on "goals" slide)
[06:39:08] <Scott Brim> As for "best location", do not assume that the best location for resources is near the sinks. If cost is taken into consideration, and the network is good, sometimes the best place for the most used resources is where power is cheapest.
[06:41:32] <wesley.m.eddy> slide: cso research progress
[06:42:33] <wesley.m.eddy> slide: UTdallas research results
[06:44:22] naptee leaves the room
[06:44:45] <wesley.m.eddy> hannes at mic; questions will be afterwards
[06:45:05] <Scott Brim> does hannes have a role in cso?
[06:45:47] <wesley.m.eddy> he's at the mic line
[06:46:01] <wesley.m.eddy> cso does not exist yet, as far as I understand
[06:46:09] <wesley.m.eddy> it's proposed to exist
[06:48:36] <wesley.m.eddy> hannes: question regarding work - mentioned couple of examples, but wondering whether you plan to look into specific needs of apps, or if those are just examples
[06:48:59] <wesley.m.eddy> from purely academic perspective, we don't want to attach to specific apps - generalize or categorize
[06:49:18] <wesley.m.eddy> hannes: exactly what I was worred about
[06:49:39] <wesley.m.eddy> video has different needs than gaming or voip - hannes likes computer games
[06:49:48] <wesley.m.eddy> select server with small ping time
[06:50:01] <wesley.m.eddy> voip you care who you call, totally different constraints
[06:50:53] <Scott Brim> It seems to me they are both right: obviously you want to solve the specific problems of particular apps, but you want to do it in ways that are generally useful. That means characterizing app desires in using a library
[06:50:57] <wesley.m.eddy> answer: present at the end what is the charter - limit to very large flow not individual of micro-flow, next presentation in optical networks dealing with larger flows between data centers
[06:51:42] <wesley.m.eddy> couple of specific applications - remote surgery
[06:53:36] <wesley.m.eddy> sue harres: would you be able to discuss with people coming from specific interests and talking in general?
[06:53:43] <wesley.m.eddy> yes
[06:54:03] <wesley.m.eddy> slide: BUPT research results
[06:55:47] <wesley.m.eddy> slide: GLB strategies and algorithms
[06:56:43] <wesley.m.eddy> slide: performance results
[06:56:57] <wesley.m.eddy> slide: charter
[06:57:03] <wesley.m.eddy> lars: 3 minutes left
[06:57:21] <wesley.m.eddy> lars: proposed charter
[06:57:35] <wesley.m.eddy> slide: relationship to other groups
[06:58:09] <Scott Brim> I do not understand what it says about SDN. Is the bullet under that about CSO or about SDN?
[06:58:15] <wesley.m.eddy> nil comments
[06:58:21] <wesley.m.eddy> slide was taken down
[06:58:25] <wesley.m.eddy> people are leaving
[06:58:29] <Scott Brim> ok
[06:58:30] <Scott Brim> thanks much
[06:58:35] <Scott Brim> It's 22:58 in Seattle
[06:58:38] <Scott Brim> Have a good day
[06:58:45] <wesley.m.eddy> you too!
[06:58:47] naptee joins the room
[06:58:49] Scott Brim leaves the room
[06:58:53] wesley.m.eddy leaves the room
[06:59:08] nco leaves the room
[07:01:38] tplunke\40jabber.org leaves the room
[07:08:01] naptee leaves the room
[07:27:12] tplunke\40jabber.org joins the room
[07:28:10] tplunke\40jabber.org leaves the room
[07:28:40] nco joins the room
[08:08:20] nco leaves the room