[17:19:53] --- lisa has joined
[17:28:24] --- mrose has joined
[17:28:43] --- mrose has left
[17:43:07] --- jis has joined
[17:43:25] <lisa> yes, this is the IEPREP jabber room :)
[17:43:44] <lisa> Are you Jeff and are you in the physical room too?
[17:49:34] <jis> no, I am in MARID
[17:49:47] <lisa> Were you hoping for a jabber scribe here?
[17:49:57] <jis> I was hoping to hear what was going on... yes I was hoping for a Jabber scribe
[17:50:04] <jis> But I don't want to impose on you to do it
[17:50:12] <jis> (given that it is only the two of us in the Jabber room)
[17:50:16] <lisa> I can try to do that but I don't understand all the stuff here much
[17:50:23] <lisa> but it will focus me on listening which I need help to do :)
[17:50:29] <jis> don't worry about it. I am sure I can get someone to give me a report
[17:50:36] <jis> ok then
[17:51:05] <lisa> Fred Baker is presenting
[17:51:31] <lisa> They're talking about AAA, and how sometimes you need geopriv to know where the user is, and sometimes you *don't* want to know where they are physically
[17:51:51] --- naotaka has joined
[17:52:07] <lisa> basically how authentication might affect the level of service you're given, if I understand it
[17:52:45] <lisa> Scott says that diffserv specifically designed so that you can override the DSRP (?)
[17:53:27] <lisa> Janet asks if requests come in through a network that strips off the DSCP, then you dont' get what you want
[17:53:37] <lisa> Baker says yes, effectively you're not asking for the service.
[17:53:54] <lisa> Janet: I have to know that my network access point allows this
[17:54:17] <lisa> Voice at the back: best case the whole network supports this
[17:54:25] <lisa> Scott: Best case, but unlikely case.
[17:54:58] <lisa> Baker: If we let the user request the service, we could RSVP for a TCP session on a given port, with DSCP -- but we don't necessarily know the port.
[17:55:04] <lisa> Baker: There be dragons here.
[17:55:40] <lisa> Baker: "Traditionally", what a bandwidth broker does is different on every broker.
[17:57:11] <lisa> Baker: File transfer is particularly part of this because file transfers need predictability
[17:58:01] <lisa> Baker: This is an interesting research problem and somebody could generate IPR around this.
[17:58:27] <lisa> Baker: Interesting work done recently by a guy named Case ??
[17:58:47] <lisa> Baker: Case has a computer on a network, 622 megabit network, he's the only one on it.
[17:59:03] <lisa> Baker: He thinks he should be able to actually get 622 megabut, but he doesn't, he only gets 70 megabits.
[17:59:23] <lisa> Baker Case is happier, but not happy, after Cisco upgrade, when he gets 400 megabits.
[17:59:31] <lisa> Baker: Problem is TCP.
[17:59:43] <lisa> Baker: Australian defense is looking at same problem.
[17:59:59] <lisa> Baker: They've got high-error-rate radio, ship to ship.
[18:00:16] <lisa> Baker: THey have a file, blow it up into datagrams, enumerate them, throw them across the link.
[18:00:30] <lisa> Baker: Some datagrams get ACKed, some ACKs get received.
[18:00:44] <lisa> baker: Unless the error rater approaches 1, we're eventually going to get the file across.
[18:01:59] <lisa> This results in a throughput roughly equal to ....
[18:02:10] <lisa> but not very good if you're not hte only user on the link.
[18:02:40] <lisa> Throughput rate = effective-window / round-trip-time
[18:03:38] <lisa> RFC2581 and a CalTech FAST TCP project have different measurements
[18:03:55] <lisa> Is there a way I could measure capacity and choose an appropriate window to maximize throughput rate?
[18:04:50] <lisa> Srinivasan was figuring out how to send two packets across a link to have a micro-measurement of the rate of the link.
[18:05:05] <lisa> That's one data point. Can we generate a filtered mean rate?
[18:06:04] <lisa> That allows us to send at a more optimal rate to get high throughput.
[18:06:21] <lisa> Next-generation SACK procedures can increase the effective window
[18:06:36] <lisa> I can keep transmitting at the calculated rate and pick up the retransmissions later.
[18:06:46] <lisa> Now I can deliver a whole file at a predictable time.
[18:07:47] <lisa> Electronic mail could be a privileged service, attempting to deliver each email in a finite known time.
[18:09:48] <lisa> But how can this work, when I asserted an identity only known to the first domain in the email delivery?
[18:10:47] <lisa> Today, when I connect to my email server and start downloading mail, I have to download them all before seeing one of them is super important.
[18:11:55] <lisa> We're going to have to apply priorities every step of the way: from me to my SMTP server, from that SMTP serer to the ISP, and so on to the end machine.
[18:12:51] <lisa> Another thing we need is quick failure. If something's going to take an hour rather than 7 minutes, don't just leave it in the queue, let me know.
[18:13:29] <lisa> Janet: how do we prevent the spammers from putting priority on their messages?
[18:13:39] <lisa> Baker: I don't know that answer, it's going to hve to be addressed.
[18:14:35] <lisa> Kimberly says the military is looking at assigning slots
[18:14:59] <lisa> Kim: Are they looking for end-to-end solutions?
[18:15:07] <lisa> Baker: US Navy is in fact looking for E2E solutions
[18:15:14] <lisa> Baker: including undersea cable hops
[18:15:15] --- ray_atarashi has joined
[18:15:30] <lisa> Baker They drew a picture of a ship on the way to Bahrain from Norfolk
[18:15:57] <lisa> Baker: The msg had to go undersea cable to italy, in air to ship, with a hop to bahrain in there. But to authenticate it, it had to go to Norfolk.
[18:16:05] <lisa> Baker: it ended up with a 2 sec roundtrip delay.
[18:16:40] <lisa> Steve: I'm stuck onthe differences between the military sol'n, where there's a hierarchy of overrides, with the civilian emergency case.
[18:17:04] <lisa> Steve: Compare the CEO and the cleaner, trying to use the emergency services, where the cleaner is actually the important person communicating with emerg svcs.
[18:17:27] <lisa> Baker: We can't just take all the routine traffic and put it in the dumpster.
[18:17:42] <lisa> Priority, as a scheduling algorithm, is a way to reduce jitter.
[18:18:19] <lisa> So yes, you actually want to reserve traffic for *each* traffic class, not bump the lowest priorities right off.
[18:18:27] <lisa> You could use round-robin to allocate for each fo the classes.
[18:18:51] <lisa> If some class isn't using its bandwidth, it's proportionally allocated to the other classes. So normally that means that routine traffic gets 100% of bandwidth.
[18:19:07] <lisa> Aaron asked for URL to slides.
[18:19:24] <lisa> ftp://ftpeng.cisco.com/fred/ieprep
[18:19:43] <lisa> Aaron: The likelihood of big fils on long-delay links is a corner case
[18:19:58] <lisa> Aaron: I'm not sure there's a problem that needs to be solved here.
[18:20:09] <lisa> Baker: Just try going to MCS in Washington and tell them this.
[18:20:26] <lisa> ??: Maybe no standardization is required here even if MCS is working on it.
[18:21:40] <lisa> ftp://ftpeng.cisco.com/fred/ieprep/ieprep-08-04-2004-elastic-services-Baker.ppt
[18:21:48] <lisa> Scott: We're in the weeds;
[18:21:58] <lisa> Scott This isn't presented as a proposal, it's an environment.
[18:22:14] <lisa> Me, aside: It felt a lot like a tutorial but it's been intersting.
[18:22:30] <lisa> Baker: This isn't the Internet2 bandwidth broker; it's not mosaic
[18:22:35] --- yjs has joined
[18:23:06] <lisa> Ken: In your last slide you had two items, the SMTP auth and priority.
[18:23:29] <lisa> Ken: Three years ago a fellow submitted a draft on prioiritized SMTP. It's expired but maybe good background reading, including the list discussion at that time.
[18:24:01] <lisa> Guy: Do you expect somebody from the agency to authenticate themselves to their NAS (?) server, then use that to access a server in some enterprise?
[18:24:16] <lisa> Baker: You'd have to talk to the gov't, but I wouldn't have them going to a single-point-of-failure server to do that.
[18:24:30] <lisa> Baker: I'd want an instance of that server in each of UUNet's datacenters, for example.
[18:25:04] <lisa> Baker: In the military probably one auth throughout. When you talk to GETS (?) it's different
[18:25:41] <lisa> Janet: This is a response to Steve: to the extent this corresponds to what's done in WPNSGETS (?), this needs to be avialable to everybody, and you don't know who's going to be important ahead of time.
[18:25:56] <lisa> Janet: That's different from the emergecny preparedness where we know who needs the special service.
[18:26:37] <lisa> Question about EF which Baker said he wouldn't recommend using EF for elastic traffic....
[18:27:46] <lisa> Scott: On the agenda: where do we go with ieprep.
[18:28:06] <lisa> We have one more item on our charter, a recommendations I-D, recommending to service providers, ISPs, how to do something using available tech.
[18:28:17] <lisa> we were hoping to use stoff Fred did before to meet that milestone
[18:28:52] <lisa> He covered the gamut of things assumed to be required in emergency cases
[18:29:05] <lisa> I think some of these things are potentially important, some we can do something with, but not all of them.
[18:29:33] <lisa> How we can constrain the problem if ieprep to something we can deal with.
[18:29:42] --- Fred Baker has joined
[18:30:13] <lisa> Hi Fred, I probably misquoted you all over the place ;)
[18:30:32] <Fred Baker> ftp://ftpeng.cisco.com/fred/ieprep/ieprep-08-04-2004-elastic-services-Baker.ppt
[18:30:36] <lisa> Scott: some of the work has limited applicability to a single domain with unified authentication
[18:30:46] <Fred Baker> I probably misquoted myself :-)
[18:30:59] <lisa> Aaron: it might make sense to sort through the list and see the delta, the need statement.
[18:31:25] <lisa> Scott: this group did a requirements ocument for SIP priority header, then shifted that work to SIP WG to actually do the work.
[18:31:36] <lisa> Scott: We give the requirements, not how to do it.
[18:31:50] --- jishac has joined
[18:32:11] <lisa> Scott: I would propose to interact with the IESG to extend the charter to work on the things baker describes here
[18:32:18] <lisa> Scott but as requirements, not as solutions.
[18:32:32] <lisa> Steve Norreys: The requirements need to be very clear that this isnot ETS we're talking about here.
[18:32:49] <lisa> Steve: To me, ATS as been defined in ITU and so forth is the 999, 911 services.
[18:32:59] <lisa> General response to steve: No, it's the opposite.
[18:33:11] <lisa> Baker: This WG is not addressing 911.
[18:33:25] <lisa> Baker: This WG is specifically from authorized user to authorized user,.
[18:33:29] <lisa> Steve: We're in violent agreement.
[18:33:41] <lisa> Kim: You have a definition of ETS it's not our definition.
[18:33:58] <lisa> Scott We agree we're not working on 911.
[18:34:12] <lisa> Jon Peterson: There's work in teh SIP wg on this, a recent proposal for a broader work effort.
[18:34:24] <lisa> Scott: there's only two big issues: Where are you, and where do you wnat to talk to
[18:34:34] <lisa> Jon: Some high level architecture would be useful for the industry.
[18:34:43] --- Fred Baker has left: Replaced by new connection
[18:34:43] --- Fred Baker has joined
[18:34:43] --- Fred Baker has left
[18:34:46] <lisa> Scott: Important work, just not in the charter of this WG.
[18:35:10] <lisa> Aaron: I found that many people making design decisions are not people you'd typically find at an IETF meeting though many are in this room.
[18:35:33] <lisa> Aaron: I chaired TCP over Satellite WG,.. people don't necessarily know the right combination of RFCs to use to put the network togetehr.
[18:35:56] <lisa> Aaron: It may be useful not only to make requirements to other WGs, but also to explain what services providiers should use to put together ETS services.
[18:36:02] --- jishac has left: Replaced by new connection
[18:36:03] --- jishac has joined
[18:36:14] <lisa> Aaron: ETS == Emergency Telecommunication Systems.
[18:36:24] <lisa> 3889 provides some examples.
[18:36:32] <lisa> (that was Ken)
[18:36:41] <lisa> Scott: This is non-911 emergency communications.
[18:37:19] <lisa> Scott But if you're saying that clue exists outside the IETF, I definitely want to encourage input, etc.
[18:37:41] <lisa> Baker: If you read the ITU specifications, this is ETS.
[18:37:50] --- xmlscott has joined
[18:38:13] <lisa> Scott: We do not want to go and change every application.
[18:38:46] <lisa> Question: is this more for the Internet or for military or private networks
[18:39:00] --- xmlscott has left
[18:39:03] <lisa> Scott: It's a general question: when considerations of private networks arise should they affect our design
[18:39:18] <lisa> Scott This WG is to look at the public internet, but those techs are not turned off on private networks.
[18:40:39] <lisa> Scott made a bad pun which I refuse to propagate here :)
[18:41:01] <lisa> Scott: Does anybody think it's a bad idea to pursue charter change with the IESG and IAB?
[18:41:22] <lisa> Andrew Teeson: I work with a gov't sponsored program named SafeCon, we work with fire, police and EMS.
[18:41:35] <lisa> Andrew: when you look at first-responder, it's owned by the states and locals themselves.
[18:41:48] <lisa> Andrew: This work is certainly of interest to SafeConn and first responders.
[18:42:07] <lisa> Andrew: We want to liaise with IETF to see how we can best use the good work done here.
[18:42:58] <lisa> Andrew: I've done this before, an "easy reading guide" for this
[18:43:05] <lisa> Scott: It would be great if you could do this as a I-D
[18:43:13] <lisa> Baker: Or even just put the URL to the list.
[18:43:35] <lisa> Question: about SiP headers
[18:43:48] <lisa> Scott: Once we handed the priority headers to SIPPING, that's their bailywick.
[18:44:03] <lisa> Scott: it's not our responsibility any more. You can join that list and discuss it.
[18:44:06] --- naotaka has left
[18:53:39] --- ray_atarashi has left: Replaced by new connection
[18:53:39] --- ray_atarashi has joined
[18:53:39] --- ray_atarashi has left
[18:54:29] --- lisa has left
[18:55:15] --- jishac has left
[18:59:13] --- jis has left
[19:06:03] --- yjs has left