[08:53:17] --- Melinda has joined
[08:55:33] --- iljitsch has joined
[08:58:57] --- lars has joined
[09:02:04] --- jordipalet has joined
[09:04:53] <lars> are all of you oon the audio?
[09:05:03] <lars> (i can relay question, but cannot scribe)
[09:06:13] <Melinda> I'm having audio problems; hoping to get them sorted out momentarily
[09:06:52] <iljitsch> I'm in the meeting room.
[09:07:25] --- sarolaht has joined
[09:08:17] --- Fred Baker has joined
[09:08:37] <Fred Baker> yes
[09:11:16] <lars> Kwok - Aggregation of DiffServ Service Classes 9:15-9:25 draft-ietf-tsvwg-diffserv-class-aggr-00 (10 min)
[09:14:44] --- cabo has joined
[09:15:23] <lars> Randy and Michael - SCTPbis and SCTP Padding Chunks 9:25-9:40 draft-ietf-tsvwg-2960bis-02 (15 min) draft-ietf-tsvwg-sctp-padding-00
[09:21:57] <lars> Marushin - SCTP ASCONF Chunk Transmission Ext. 9:40-9:45 draft-marushin-sctp-asconfext-01 (5 min)
[09:27:12] --- mattz has joined
[09:36:40] --- yjs has joined
[09:38:04] --- yjs has left
[09:38:49] <lars> Randy and Michael - SCTP Threats and Socket 9:45-9:55 draft-ietf-tsvwg-sctpthreat-00 (10 min) draft-ietf-tsvwg-sctpsocket-13
[09:44:24] <lars> Francois - RSVP Extensions for Emergency Services 9:55-10:05 draft-lefaucheur-emergency-rsvp-02 (10 min)
[09:47:07] --- shivanajay has joined
[09:52:39] --- ltn22@jabber.org has joined
[09:52:59] <lars> Bob - Policing and Accountability for Causing Congestion on Borders draft-briscoe-tsvwg-re-ecn-tcp-02 10:05-10:25 draft-briscoe-tsvwg-re-ecn-border-cheat-01 (20 min) draft-briscoe-tsvwg-re-ecn-apps-00
[09:53:07] <lars> sorry
[09:53:14] <lars> Bob and Phil - Controlled Load 10:25-10:45 draft-briscoe-tsvwg-cl-phb-02 (20 min) draft-briscoe-tsvwg-cl-architecture-03
[10:00:10] --- iljitsch has left
[10:01:39] --- iljitsch has joined
[10:08:29] <lars> Bob - Policing and Accountability for Causing Congestion on Borders draft-briscoe-tsvwg-re-ecn-tcp-02 10:05-10:25 draft-briscoe-tsvwg-re-ecn-border-cheat-01 (20 min) draft-briscoe-tsvwg-re-ecn-apps-00
[10:18:50] --- shivanajay has left
[10:19:40] --- shivanajay has joined
[10:28:35] --- Melinda has left: Lost connection
[10:28:35] --- sarolaht has left: Lost connection
[10:28:35] --- ltn22@jabber.org has left: Lost connection
[10:28:35] --- cabo has left: Lost connection
[10:31:02] --- Melinda has joined
[10:44:59] --- shikob has joined
[10:53:34] --- yjs has joined
[10:59:31] <iljitsch> What I'm wondering about... is there much congestion to speak of in the core of today's internet? This seems like a huge project, it had better have some payoff.
[11:00:23] <lars> Francois - RSVP Ext for Admission Control over DS using PCN 10:45-10:55 draft-lefauchuer-rsvp-ecn-01 (10 min)
[11:01:19] <Fred Baker> The question is generally not the core. Yes, operators tell me that congestion exists. But the real issues tend to be in the access links that people use to get to the core.
[11:01:48] <Fred Baker> They also occur in non-core networks in large enterprises.
[11:02:14] <iljitsch> right. and, not having read the 90 pages, I assume that this isn't really applicable to IETF wifi access points or home user ADSL lines.
[11:02:34] <Fred Baker> I would quibble there.
[11:03:17] <Fred Baker> For example,my home cable modem interface has a configuration on it for voice and for video. I added that basically because my laptop is able to disrupt phone calls and video sessions I run over it.
[11:04:02] <Fred Baker> On the WiFi (and WiMax), there are "just a few" additional issues. This could be useful assuming that the AP is IP layer aware.
[11:04:13] <iljitsch> yes, but is it going to collude with your ISP's policy boxes?
[11:04:31] <Fred Baker> It might have a policy of its own.
[11:05:12] <Fred Baker> No, I doubt that we are going to see multi-administration policy control here very soon. I think we may see successive admiinistrations (including the WiFi) making their own decisions independently.
[11:07:01] <iljitsch> it might be useful to see if we can make transports that can work with high packet drop rates so we don't have to work so hard on avoiding congestion, but rather just send a bit too fast so we know we utilize as much bandwidth as possible.
[11:09:56] <Fred Baker> that's not really a transport problem. We have ways to overcome packet loss - TCP slows down, some codecs basically encode their data twice for FEC purposes, and there is draft-ietf-avt-rtp-retransmission-12.txt. What there isn't is a way to make an application that really and truly wants all the bits to be delivered within a stated interval (think HDTV) and has a large number of bits it cares about to work when there are just plain too many bits on the wire
[11:18:40] --- LouBerger has joined
[11:22:31] <iljitsch> it's not a question of wanting all the bits, it's a question of how long you want to wat for them. If you want them too fast you're resending before you know for sure which ones made it to the other side and which ones didn't, so you're resending packets that weren't dropped and wasting bandwidth. With large file transfers you can wait long enough to be sure about the need to resend.
[11:24:45] <Fred Baker> you missed it. This isn't about file transfers. This is about real time video and other telemetry.
[11:25:19] --- yjs has left
[11:25:38] --- yjs has joined
[11:25:55] --- yjs has left
[11:26:20] <iljitsch> if you can make the bittorrent traffic not care about packet loss then you can easily give real time traffic higher precedence and both will have the best performance that can be had given available bandwidth.
[11:29:07] --- Fred Baker has left: Logged out
[11:32:26] --- jordipalet has left
[11:34:37] --- lars has left
[11:34:40] --- mattz has left
[11:34:57] --- shikob has left
[11:35:36] --- shivanajay has left
[11:54:01] --- LouBerger has left
[12:06:45] --- Melinda has left
[12:40:51] --- iljitsch has left
[13:02:04] --- shivanajay has joined
[13:10:10] --- shivanajay has left
[19:00:30] --- LOGGING STARTED