Thursday, November 13, 2014< ^ >
mls.ietf has set the subject to: TSVWG mtg at IETF 89
Room Configuration
Room Occupants

[18:52:50] joins the room
[18:55:58] spencerdawkins joins the room
[18:57:15] Michael Tuexen joins the room
[18:58:15] Gorry  Fairhurst joins the room
[19:00:22] John Leslie joins the room
[19:00:50] tuexen joins the room
[19:01:49] rscheff joins the room
[19:02:08] Brian Carpenter joins the room
[19:03:02] jlcJohn joins the room
[19:03:12] Lars joins the room
[19:03:15] Lars leaves the room: Disconnected: connection closed
[19:03:16] <spencerdawkins> So both of your ADs are acting as jabber scribes :-)
[19:03:29] <jlcJohn> :^)
[19:03:30] <tuexen> Great, thanks a lot!
[19:04:11] Martin Stiemerling joins the room
[19:04:16] <spencerdawkins> audio/meetecho OK?
[19:04:25] <tuexen> Almost...
[19:04:40] Gorry Fairhurst joins the room
[19:04:46] <jlcJohn> audio good, video as usual...
[19:04:53] <rscheff> chair slides - pg 3
[19:05:32] <rscheff> agenda bash - agenda listing (not slide)
[19:07:01] <rscheff> chair slides, pg 4
[19:08:39] PasiS joins the room
[19:09:24] <rscheff> pg 6
[19:10:27] <rscheff> pg 7
[19:10:35] <rscheff> pg 8
[19:10:56] hta joins the room
[19:11:01] <rscheff> pg 9
[19:12:45] aaron joins the room
[19:12:50] <rscheff> pg 10
[19:13:07] <aaron> FWIW, I'm putting meeting notes here:
[19:13:27] <rscheff> pg 11
[19:13:53] <Gorry  Fairhurst> Thanks aaron - that is helpful
[19:14:32] <rscheff> transport port uses
[19:14:37] <rscheff> pg 1
[19:15:04] <rscheff> pg 2
[19:15:11] Meetecho joins the room
[19:15:26] <rscheff> pg 3
[19:15:45] Lars joins the room
[19:16:02] <rscheff> pg 4
[19:17:17] <rscheff> stream schedulers sctcp
[19:17:19] <rscheff> pg 1
[19:17:29] <rscheff> pg 2
[19:19:09] <rscheff> pg 3
[19:20:09] <Gorry  Fairhurst> Gorry->Mic: It was suggested that this draft be called "Immediate Data" I think, is the group able to suggest a better name?
[19:20:26] <Gorry  Fairhurst> <thanks David>
[19:20:55] <rscheff> MuxData :)
[19:20:55] <Michael Tuexen> Michael-{MIC,Gorry}: Maybe Interleaving...
[19:21:23] <Gorry  Fairhurst> Mic : Can we suggest Interleaved data  as a name???
[19:21:51] <rscheff> interleaved should be good enough, no need to bike-sched, or?
[19:22:06] <Michael Tuexen> And then all it I-DATA chunk. Of course we would not change the name if the ID...
[19:22:33] <Gorry  Fairhurst> Change the TITLE not the filename please:-)
[19:23:24] <Michael Tuexen> Yepp, that was the plan. Will talk to Randy... We also need to change names in the code, but that is not released yet...
[19:23:52] <Gorry  Fairhurst> Ok - talk and propose on the list and I'm sure it will be fine
[19:25:42] <Michael Tuexen> While slide is Karen pesenting right now?
[19:25:56] <aaron> #3
[19:25:56] <Michael Tuexen> s/While/Which
[19:26:10] <Michael Tuexen> Thanks!
[19:26:51] <Gorry  Fairhurst> Karen is at slide 4
[19:26:54] <rscheff> alex zimmermann
[19:26:56] <rscheff> on mic
[19:30:45] <Gorry  Fairhurst> Who waas at the Mic?
[19:30:55] <aaron> Yoshifumi
[19:31:02] <Gorry  Fairhurst> OK
[19:31:03] <aaron> I didn't get the question
[19:31:48] <rscheff> yoshifumi wanted to point out, that the mod in 6675 to sack is not very aggressive with the rescuerxt i believe
[19:32:15] <aaron> thx
[19:32:16] <rscheff> (sending the last packet once more, if no new data is available, but cwnd allows new data to be sent still)
[19:33:39] <rscheff> an karen mentioned that  6675 (and 3517 probably) is already more agressive than what sctp sack is doing today by initiating FR earlier, not only after 3 sacks returned
[19:40:40] <Gorry  Fairhurst> *MIC* I like this work, and think we should get updates as this work progresses - in the end we need to consider make a conscious decision if this looks to be proposing something different to what happens in TCP (future check)
[19:44:36] Gorry  Fairhurst leaves the room
[19:44:57] G Fairhurst joins the room
[19:45:22] spencerdawkins leaves the room
[19:45:25] spencerdawkins joins the room
[19:45:39] <Michael Tuexen> "MIC": I like this work, too. I is not only useful in signalling networks, but also for RTCWeb.
[19:48:13] leaves the room
[19:48:23] <G Fairhurst> ***** Can someone relay the Mic ******
[19:49:04] <G Fairhurst> THX
[19:49:09] <Martin Stiemerling> Gorry, didn't see your comment, just spotted Michaels
[19:49:13] <Martin Stiemerling> will do better from now on!
[19:50:23] Michael Tuexen leaves the room
[19:50:37] G Fairhurst leaves the room
[19:50:59] G Fairhurst joins the room
[19:54:33] <G Fairhurst> Gorry: I have no objection to David's request as a co-chair, I think this should be done.
[19:58:56] <rscheff> gorry, did you heared the question?
[19:59:18] <G Fairhurst> The CB should act over longer timescales than TCP - that is on many many second of response
[19:59:36] <Martin Stiemerling> in line
[19:59:37] Dan Wing joins the room
[19:59:41] <Martin Stiemerling> waiting
[20:02:45] <G Fairhurst> I think it is a checklist and set of things to do as a protocol designers
[20:03:05] <G Fairhurst> <yes like RFC 5405> -- if we think this needs to be done.
[20:10:57] <G Fairhurst> RFC 6830 - need to checek this
[20:14:11] <Martin Stiemerling> somebody has to take the jabber-to-mic translator for the next five minutes. stepping shortly out
[20:16:44] <Lars> i can
[20:17:27] <Martin Stiemerling> back again
[20:27:08] tuexen leaves the room
[20:43:55] <G Fairhurst> MIC: If we are looking at a CB then  are you  looking at long-term *persistent* marking? (not a few marks or occassional marks)
[20:46:03] <G Fairhurst> Gorry: Read
[20:47:04] <jlcJohn> Dig here: +
[20:47:34] <G Fairhurst> Dig, but do not know this will work yet
[20:49:48] <jlcJohn> Briscoe could write a good starting-point draft on "ECN-means..."
[20:50:05] <G Fairhurst> I think this should not be adopted as it stands (no chair hat)
[20:50:42] <G Fairhurst> ... becasue we have not really explained yet how this works on paths that do not work on arbitary paths
[20:51:01] <jlcJohn> ADs need to say ECN is in-scope in which WG.
[20:51:32] <G Fairhurst> With some work this is likely to be sueful though:-)
[20:51:41] <jlcJohn> I think Martin is saying it's in-scope here.
[20:52:18] <G Fairhurst> I think it is too. It's not deisgn of AQM algorithms.
[20:52:28] <Martin Stiemerling> ecn is in scope of tsvwg, but I am not sure that this draft as it stands right is fully in scope of tsvwg, but it doesn't belong to AQM
[20:52:41] <G Fairhurst> I agree
[20:56:03] hta leaves the room
[21:05:52] <G Fairhurst> MIc: I see support to dig in this topic - the srop by design for ECN - is not the issue, the robustness of the mechanism needs to be looked at, and we get good feedback next meeting
[21:06:32] <Martin Stiemerling> at the mic, waiting
[21:07:34] <G Fairhurst> I think this is a traffic control fucntion, and hence I would suggest may fall in tsvwg
[21:07:57] Meetecho leaves the room
[21:07:57] Meetecho joins the room
[21:08:27] <G Fairhurst> THX - terrible typing but good relay
[21:08:37] <Martin Stiemerling> you are welcome
[21:09:41] G Fairhurst leaves the room
[21:09:57] aaron leaves the room
[21:09:57] Martin Stiemerling leaves the room
[21:10:48] Lars leaves the room: Disconnected: session closed
[21:10:53] spencerdawkins leaves the room
[21:12:25] rscheff leaves the room: Disconnected: closed
[21:12:55] Gorry Fairhurst leaves the room
[21:12:56] Brian Carpenter leaves the room: offline
[21:12:56] John Leslie leaves the room
[21:16:03] hta joins the room
[21:27:19] Dan Wing leaves the room
[21:35:50] PasiS leaves the room
[21:36:09] Meetecho leaves the room
[21:49:22] hta leaves the room
[22:04:42] jlcJohn leaves the room
[22:09:42] Dan Wing joins the room
[22:09:44] Dan Wing leaves the room
[22:33:54] rscheff joins the room
[22:35:50] hta joins the room
[22:58:10] Meetecho joins the room
[23:00:09] aaron joins the room
[23:00:40] <aaron> ping?
[23:01:02] joins the room
[23:01:42] <aaron> hey gorry, are you watching the video?  I noticed the camera was pointed at the chairs before.  if you (or anyone) requests, we can move it around.  
[23:01:57] <> Does anyone else have an error when they try to join meetecho for the tsvwg-II session?
[23:01:58] jlcJohn joins the room
[23:02:31] <jlcJohn> What's the story on Meetecho?
[23:02:57] <> Thanks aaron - but it seems we don't have support - is there a camera in the room?
[23:03:05] <> Is it just a tech fault?
[23:03:44] Martin Stiemerling joins the room
[23:03:48] <> Maybe someone local can ask for meetecho support please?
[23:03:48] <Meetecho> all sessions are supported
[23:03:54] <Meetecho> what's not working?
[23:03:59] <Meetecho> audio or video?
[23:03:59] <aaron> whoops, forgot we moved rooms.
[23:04:05] Lars joins the room
[23:04:18] <Meetecho> where are you now? are you not in coral-2?
[23:04:27] spencerdawkins joins the room
[23:04:31] <Martin Stiemerling> tsvwg is in coral I
[23:04:32] <jlcJohn> "Unhandled IETF Meeting session"
[23:04:39] <> +1
[23:04:52] <aaron> we are in Coral 1
[23:05:00] <Meetecho> yep sorry my typo
[23:05:00] Lars leaves the room
[23:06:16] Dan Wing joins the room
[23:06:29] <> In case people haven't fiigured - the audio stream is working at:
[23:06:31] <>
[23:06:43] <Meetecho> working on that right now
[23:07:50] Lars joins the room
[23:07:53] Brian Carpenter joins the room
[23:07:58] <jlcJohn> BTW, I have no clue which draft is being asked to hum on
[23:08:07] <Lars> 5405bis
[23:08:11] <Martin Stiemerling> the udp guidelines
[23:08:14] <aaron> draft-eggert-tsvwg-rfc5405bis <>
[23:08:27] <jlcJohn> thanks... I tend to favor, BTW
[23:09:30] <> Meetscho: Still same error as far as I can see
[23:10:06] <Meetecho> yep fixing this, just a minute
[23:10:16] <Meetecho> in the meanwhile try the webinar mode:
[23:11:23] <jlcJohn> Is there a way to mute webinar audio?
[23:11:59] <Martin Stiemerling> for me there is a volume ruler at the left bottom
[23:12:01] <jlcJohn> Found it (top right) blank box
[23:12:41] <jlcJohn> Yeah, there's one there too -- doesn't seem to do much now...
[23:13:05] c joins the room
[23:17:26] Lorenzo Miniero joins the room
[23:17:33] Lorenzo Miniero leaves the room
[23:17:53] <Meetecho> this link works:
[23:19:42] Gorry Fairhurst joins the room
[23:20:23] <> Video et al, now works for me ;-)
[23:21:56] John Leslie joins the room
[23:22:01] mls.ietf joins the room
[23:23:22] Craig Taylor joins the room
[23:24:57] <> *Mic*: One thing that has been assumed for MPLS/UDP is that we do not need to traverse middleboxes of any type, assuming this WITHIN a managed network — however it is important we establish whether this an assumption for GRE/UDP?
[23:25:36] <Martin Stiemerling> Gorry: Aaron is at mic
[23:26:37] aaron stumps the room
[23:33:29] <> Ahhh - The middlebox issue is related - it impacts the use of IPv6 zero checksum - that's one reason MPLS/UDP can be engineered as a safe solution - but it likely needs more protocol machinery
[23:34:47] <> if some packets traverse a link that may/may not support this.
[23:35:23] Matt Mathis joins the room
[23:39:06] <> *MIc* : The implications of allowing a zero checksum may actually require new protocol mechanisms to work on a general network path… I suspect many end hosts and routers may already be able to do this checksum. This is not likely to be a simple problem just to "write text around".
[23:40:14] <Martin Stiemerling> at the mic...
[23:41:07] Dan Wing leaves the room
[23:44:16] <Gorry Fairhurst> Sure, we could use a UDP-Lite-style pseudoheader and that may work
[23:44:36] Dan Wing joins the room
[23:53:52] <Gorry Fairhurst> MIc: I think it is a transport problem...
[23:57:59] <Matt Mathis> Given that transport "owns the hourglass", we should take the lead on all DSCP  issues.
[23:59:50] <hta> ... unless comcast ...
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!