- Thursday, 29 March 2012

conex@jabber.ietf.org

Thursday, 29 March 2012< ^ >

Room Configuration

GMT+0
[12:40:26] nanditad joins the room
[13:04:31] nanditad leaves the room
[15:38:16] nanditad joins the room
[15:44:13] fh joins the room
[15:44:27] malc joins the room
[15:46:17] wesley.m.eddy joins the room
[15:46:32] rscheff joins the room
[15:47:01] <wesley.m.eddy> is anyone remote? the microphones are not working here, so you will not be able to hear until it is fixed
[15:47:23] dragana.damjano joins the room
[15:47:40] Andrew McGregor joins the room
[15:48:02] <Andrew McGregor> I'll jabber scribe
[15:48:30] <Andrew McGregor> Oh, Gorry volunteered
[15:48:39] gorryf joins the room
[15:49:16] <gorryf> Hi I'm in the meeting and will try to ask questions at the Mic and help with interaction with the room (Gorry Fairhurst)
[15:49:45] <gorryf> The mics have just been fixed - can remote participants now hear Nandita?
[15:49:57] <rscheff> Status of WG items
[15:51:50] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-conex-0.pdf
[15:52:50] <gorryf> Matt - first presenter
[15:54:04] <gorryf> Slide: WGLC
[15:55:01] <gorryf> Are there any remote participants?
[15:55:26] <dragana.damjano> i am here
[15:55:39] <gorryf> OK
[15:55:48] <gorryf> Slide: One new technical issue
[15:55:52] bob.briscoe joins the room
[15:56:20] <gorryf> Slide A Framework for modeling audit
[15:58:17] <gorryf> Slide: The Story
[15:58:56] <rscheff> remote audio isn't all that good..
[15:59:30] <gorryf> ...Matt is abut ti finish
[15:59:44] <rscheff> pkts vs bytes -
[15:59:44] <gorryf> Philip: What about packets v Bytes?
[16:00:08] <gorryf> Matt: says should be in Bytes - doc needs to be updated
[16:00:19] <gorryf> .. TCP behaviour needs to say this.
[16:00:41] <gorryf> Nandita: What are the pros/cons that this syas.
[16:01:02] <gorryf> Matt: The framework lays out the questions to do a real experiment
[16:01:18] <gorryf> Nandit: Final draft has abstract mechanimss
[16:01:22] <gorryf> Matt: yes
[16:01:38] <rscheff> Bob on mike
[16:01:41] <gorryf> Authors will try to finish the doc
[16:02:03] <rscheff> Requirements on concrete mechanism also added to doc
[16:02:11] <rscheff> apart from abstract mechanism
[16:02:19] <gorryf> Plan to finish in 1 months?
[16:02:23] <gorryf> Matt: Yes, less
[16:02:42] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-conex-1.pdf
[16:02:45] <gorryf> Mirja
[16:04:26] <gorryf> Slide: Change on Conex Destination Option (CDO)
[16:05:37] <gorryf> Comments
[16:05:53] <gorryf> Is the document pretty much done
[16:05:56] <gorryf> - Yes
[16:06:24] <gorryf> Plan is to issue a WGLC and TCP extensions together
[16:06:46] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-conex-2.pdf
[16:06:50] <gorryf> Also Mirja
[16:07:52] <gorryf> Slide: Timeliness of the ConEx Signals
[16:09:42] <gorryf> Slide: Other Changes
[16:11:40] <gorryf> Slide: Open Issues
[16:12:53] <gorryf> Comments?
[16:13:11] <gorryf> Jana:
[16:13:40] <gorryf> You changed a MUST to SHOULD?
[16:13:57] <gorryf> Explained in draft - for equal sized packets
[16:14:22] <gorryf> The audit works in bytes
[16:14:30] <gorryf> Matt:
[16:14:49] fh leaves the room
[16:14:52] <gorryf> I noticed a new problem - colliding with google work that looks at TCP
[16:15:13] fh joins the room
[16:15:28] <gorryf> there are corner cases that are hard to deal with - some logic is to defend on deliberate DSACK to lie about congestion
[16:16:07] <gorryf> There is code in te filed (apparently) to hide congestion. We need to think about the implications of spurious retx are not congestion
[16:16:22] <gorryf> Conex may require this marking
[16:16:36] <gorryf> Mirja: It all happens in one RTT?
[16:16:54] <gorryf> Matt: yes you normally know in 1 RTT if this was spurious?
[16:17:26] <gorryf> Matt: payload = IP or TCP?
[16:17:32] <gorryf> - TCP
[16:17:48] <rscheff> Gorry:
[16:18:28] <rscheff> RTT path changes need to investigated
[16:18:37] <rscheff> Mirja: being conservative is good
[16:19:06] <gorryf> Gorry said something like: Spurious retx can occur when you have very sudden/weird changes in RTT - was that an issue
[16:19:21] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-conex-3.pdf
[16:19:55] <gorryf> Bob next:
[16:20:07] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-conex-4.pdf
[16:20:25] <gorryf> - individual draft
[16:21:26] <gorryf> slide: three example network arrangements
[16:22:55] <gorryf> Slide: #3 Multi-tenant data centreFeatures of ConEx Solution
[16:26:26] <gorryf> SLide: ConEx recap basic signals and functional units
[16:27:14] <gorryf> Next slide
[16:28:10] <gorryf> Slide: Arrangement of ConEx functions
[16:30:02] <gorryf> Jana
[16:30:09] bob.briscoe leaves the room
[16:30:24] <gorryf> The auditer lies in the hypervisor and is in a specific system
[16:30:36] <gorryf> Bob- audit on each hypervisor
[16:30:45] <gorryf> Jana: Does it move
[16:31:09] <gorryf> Bob: explained later
[16:31:40] <gorryf> There is an allowance per user tenant
[16:32:35] <gorryf> Slide: one logical token bucket per tenant
[16:36:09] <gorryf> Slide: Deplyment
[16:39:10] <gorryf> Slide: status & plans
[16:40:17] <gorryf> Question?
[16:40:55] <gorryf> Ken Carlberg:
[16:41:23] <gorryf> seems like one more scenario within a domain - what about other domains?
[16:41:42] <gorryf> Bob: Once ina DC, think about between DCs
[16:42:10] <gorryf> Is this one polcy?
[16:42:14] <gorryf> Chosen that way
[16:42:46] <gorryf> Nandita: You can have use-case in Dc without virtual machines? why thsi way?
[16:42:58] <gorryf> Bob: This is how most hosted DCs work
[16:43:20] <gorryf> ... It could be a private DC with different services
[16:43:46] <gorryf> .. e.g. backup competing with other datas
[16:44:00] <gorryf> Comment: XSAN already touces all packets
[16:44:21] <gorryf> Chairs: What do people feel - of intrest?
[16:44:40] <gorryf> Ken: Don't we need to see the 2nd half of the presentations?
[16:44:50] <rscheff> my comment was around VXLAN :)
[16:45:07] <gorryf> :-)
[16:45:10] <rscheff> sorry for the poor pronounciation
[16:46:30] <gorryf> .Mirja: I think we should move forward it has value
[16:47:11] <gorryf> Jana: I like this scenario
[16:48:49] <gorryf> WE are doing seewall as you mention at MS
[16:49:58] <gorryf> Yushun speaking
[16:51:16] <gorryf> Tunneling scenario at bot ends of hypervisor - separate flow.
[16:51:36] wesley.m.eddy leaves the room
[16:52:08] wesley.m.eddy joins the room
[16:52:19] <gorryf> Tunnel aspect being talked about in MDO BOF for VM traffic
[16:52:57] <gorryf> Jana: Initial deployment isn't really an agreed term
[16:53:08] <gorryf> Chairs - Ask for adoption?
[16:54:03] <gorryf> Matt: Document has 3 use cases
[16:54:21] <gorryf> Bob: Intro could be in each document
[16:54:46] <gorryf> ]Mirja - Was the titel conusing or was teh split-up confusing?
[16:55:07] <gorryf> Chairs; DC use case seems interesting
[16:55:50] <gorryf> ... seems very good idea to make a separate DC document that we can send.
[16:56:00] <gorryf> ... to other communites
[16:56:22] <gorryf> Chairs: WE'll do teh DC thing and then decide on the next step
[16:56:31] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-conex-3.pdf
[16:56:59] <gorryf> Nandita please explain the 3GPP terms
[16:57:04] <gorryf> Dirk: OK
[16:59:08] <gorryf> Slide: Cong Man in 3GPP
[17:00:16] <gorryf> Slide: Use cases
[17:01:36] <gorryf> Slide: Conex
[17:02:34] <gorryf> Slide: draft
[17:02:49] <gorryf> EPS = evolved packet system :-)
[17:03:42] <gorryf> Sldie: Summary of Recent Changes
[17:06:00] <gorryf> Sldie: CONEX Support on Servers and Caches
[17:07:17] <gorryf> ken Claver - the coed loop is to the web cache with feedback of ECN
[17:07:22] <gorryf> Dirk: yes
[17:07:32] <gorryf> Ken: is AQM part of teh design?
[17:08:08] <gorryf> Dirk: The BS do a lot of Q man talready
[17:08:40] <gorryf> Slide: CONEX and 3GPP PCC - Policy Charging Control
[17:10:00] <gorryf> Slide: Next Steps
[17:11:34] <gorryf> Comments?
[17:13:13] <gorryf> Sebastien: It would be useful to have such a document. With initial/partial deployments. Missing may be the part dealing with the wireless segment
[17:15:23] <gorryf> Dirk: BS marking was something we thought about - maybe without describing mechanisms
[17:15:36] gorryf leaves the room
[17:15:41] gorryf joins the room
[17:15:47] <gorryf> Michael: +1
[17:16:52] <gorryf> Mirja: I thought he brought up the idea of taking the channel into account, and I think you don't want to do this.
[17:17:38] <gorryf> If there is more marking on a poor link then CONEX auto gives the incentives
[17:18:24] <gorryf> Nandita: There are things to be discussed,
[17:18:54] <gorryf> Bob: You get more symbols bits in bad radio conditions.
[17:19:47] <gorryf> Chairs: Feedback seems to suggest this use case is worthwhile - so does the WG thiink this is a good basis to start this work?
[17:20:07] <gorryf> Who think we should adopt? (bunch of people)
[17:20:15] <gorryf> People who think not? (none)
[17:20:28] <gorryf> decision - will consider adoption on the mailing list.
[17:20:33] <gorryf> http://tools.ietf.org/agenda/83/slides/slides-83-conex-5.pdf
[17:20:58] <gorryf> M Menth
[17:23:49] <gorryf> Slides .. Definitions
[17:25:22] <gorryf> Impact of Allowance Rate
[17:27:37] <gorryf> Impact of Policer Type
[17:28:32] <gorryf> Slide: Impact of TCP Pressure
[17:29:59] <gorryf> Slide Performance Analysis
[17:33:19] <gorryf> RTT slide
[17:34:43] <gorryf> one case dashed line blue (predicetd) red (actual) - for 90% bottleneck
[17:35:02] <gorryf> Summary & Conclusions
[17:37:01] <gorryf> Comments?
[17:37:09] <gorryf> Matt
[17:37:37] wesley.m.eddy leaves the room
[17:37:42] <gorryf> How much did you tinker with pressure metric - this may be sensitive to the exp setup.
[17:38:19] <gorryf> You could try to estimate the increase from the flows... I think the RTT is a part of the best metric - increase in window per second may be better
[17:38:37] <gorryf> The problem is that RTT is also a func of the network
[17:39:00] <gorryf> When you didnt fill the pipe - what cases low tput
[17:39:07] <gorryf> Micahel: It was RTT
[17:39:32] <gorryf> ...but conex based policing was the reason that this was lower
[17:39:42] <gorryf> Matt; pick a trace and check it for sanity
[17:40:08] <gorryf> michael: we have our own implementation with our own TCP?
[17:40:22] <gorryf> Matt: was the max window size fixed?
[17:40:29] <gorryf> M: yes, 64K
[17:40:36] <gorryf> Msatt: Not big enough
[17:40:55] <gorryf> Mirja : Fairness needs to be used carefully
[17:41:34] <gorryf> R: May be useful to publish the loss rate / sec this is a good metric for some cases.
[17:41:53] <gorryf> Michael: the loss rates are porr when teh allowance is low.
[17:42:09] wesley.m.eddy joins the room
[17:42:14] <gorryf> ...can trade losses at policer v losses at bottleneck
[17:42:30] <gorryf> Nandita: could you post a summary and conclusion to the mailing list.
[17:42:31] <gorryf> OK
[17:42:54] nanditad leaves the room
[17:42:58] <gorryf> Bob: Was the policer losses greater just in a heavy flow or overall.
[17:43:20] <gorryf> Michael : we got losses for both users at the polcier. More for the heavy suer
[17:43:48] <gorryf> ... If allowance rate <5, we saw loss, for >5 no losses for light usres.
[17:43:57] rscheff leaves the room: Computer went to sleep
[17:43:59] <gorryf> Chairs : the meeting has ended
[17:45:33] Andrew McGregor leaves the room
[17:45:38] wesley.m.eddy leaves the room
[17:46:55] gorryf leaves the room
[17:58:12] fh leaves the room
[18:16:05] dragana.damjano leaves the room
[18:24:09] wesley.m.eddy joins the room
[19:06:21] wesley.m.eddy leaves the room
[22:21:41] Andrew McGregor joins the room
[23:36:52] Andrew McGregor leaves the room: Replaced by new connection
[23:36:55] Andrew McGregor joins the room
[23:45:49] Andrew McGregor leaves the room: Replaced by new connection
[23:45:50] Andrew McGregor joins the room
[23:51:12] Andrew McGregor leaves the room: Replaced by new connection
[23:51:15] Andrew McGregor joins the room
[23:57:34] Andrew McGregor leaves the room: Replaced by new connection
[23:57:34] Andrew McGregor joins the room