From exim@www1.ietf.org Mon Dec 1 14:07:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22908 for ; Mon, 1 Dec 2003 14:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtO1-0002Ar-G6 for ieprep-archive@odin.ietf.org; Mon, 01 Dec 2003 14:07:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1J79Gn008351 for ieprep-archive@odin.ietf.org; Mon, 1 Dec 2003 14:07:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtO0-0002Ac-Ng for ieprep-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 14:07:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22886 for ; Mon, 1 Dec 2003 14:06:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtNy-0006w1-00 for ieprep-web-archive@ietf.org; Mon, 01 Dec 2003 14:07:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQtNx-0006vx-00 for ieprep-web-archive@ietf.org; Mon, 01 Dec 2003 14:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtNt-00028s-8Z; Mon, 01 Dec 2003 14:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtNV-00028D-GI for ieprep@optimus.ietf.org; Mon, 01 Dec 2003 14:06:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22861 for ; Mon, 1 Dec 2003 14:06:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtNT-0006vR-00 for ieprep@ietf.org; Mon, 01 Dec 2003 14:06:35 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQtNS-0006vE-00 for ieprep@ietf.org; Mon, 01 Dec 2003 14:06:34 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06514; Mon, 1 Dec 2003 14:06:01 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26550; Mon, 1 Dec 2003 14:06:02 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 14:06:01 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B613B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rex Buddenberg'" , Mpierce1@aol.com Cc: jmpolk@cisco.com, steves@shentel.net, jgunn@ix.netcom.com, carlberg@g11.org.uk, ieprep@ietf.org Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls Date: Mon, 1 Dec 2003 14:06:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This discussion relates to another thread happening on dccp. The basis of that thread is a discussion of whether it is possible to design a protocol that can be used for real time data that is "fair" with respect to TCP. One of the opinions on this thread (mine among others) is that fairness can only be achieved if TCP also changes to be aware of "constant bit rate"-like streams. If there was a mechanism introduced into TCP that worked to allow real time media and TCP to better co-exist, as well as protocols that allowed media streams to better co-exist with TCP, then perhaps there would be opportunities to address some of the concerns Rex raises. Please also let me comment on: > - cut back a VTC to voice only. The psychologists tell > us that a > talking-head VTC has visual cues that we use for about 5-10 minutes; > after that we might as well turn the video off and just leave the > audio. I'd like to see the citation on this research. Our research shows that people in the same room with one another look intently on the faces of those talking, typically 90% of the time if engaged. On a well designed "VTC", you can observe the same effect, even an hour or more into a call. On a poorer quality system, participants tend to look around the room a lot. I wonder if the research you refer to is out of date. And yes Scott, a router can't be expected to tell the difference between a well designed and a poorly designed video system. Brian > -----Original Message----- > From: Rex Buddenberg [mailto:budden@nps.navy.mil] > Sent: Wednesday, November 26, 2003 4:47 PM > To: Mpierce1@aol.com > Cc: jmpolk@cisco.com; steves@shentel.net; jgunn@ix.netcom.com; > carlberg@g11.org.uk; ieprep@ietf.org > Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls > > > On Wed, 2003-11-26 at 12:17, Mpierce1@aol.com wrote: > ... > > > > The current GSCR was written for circuit mode. Unless we get it > > changed, it will apply to packet mode (even when it doesn't always > > make sense). This is one of the areas we are trying to change, so it > > correctly takes into account the advantages of using packet. > ... > > > This whole conversation appears to be predicated on some > tacit and false > assumptions. > > The principal assumption seems to be that the entire capacity of a hop > is taken up with VOICE conversations so that the solution to > oversubscription is to shed some of those VOICE conversations. > > If you come to the conversation with a bellhead mentality, then we can > probably read up on Erlangs and reach much the same > conclusion that the > circuit switch world reached years ago. > > > If you have a priority voice conversation and experience > congestion, it > would seem to me that we would want to bump something other than other > voice conversations: > - anything file transfer (incl e-mail enclosures) with > .ppt in the file > label. The content:bit-bloat ratio there is terrible to the > extent that > I'm calling powerpoint a virus these days. > - cut back a VTC to voice only. The psychologists tell > us that a > talking-head VTC has visual cues that we use for about 5-10 minutes; > after that we might as well turn the video off and just leave the > audio. The problem here is that we can't know by looking at port > numbers whether someone has turned the camera around and is > sharing view > of a crime scene > - filter out any ftp-based operating system installs > (they can wait). > Only picking on this example because I did it this morning. > What we have to be careful not to do is filter out > things that are > higher priority than the priority voice conversation. LSAs > (router link > state announcements, necessary to keep the network converged and > functioning) is one example. > > > -- > b > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Dec 1 14:46:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24293 for ; Mon, 1 Dec 2003 14:46:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtzh-0004e2-2Y for ieprep-archive@odin.ietf.org; Mon, 01 Dec 2003 14:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Jk5CJ017848 for ieprep-archive@odin.ietf.org; Mon, 1 Dec 2003 14:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtzg-0004dn-TV for ieprep-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 14:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24286 for ; Mon, 1 Dec 2003 14:45:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtze-0007J8-00 for ieprep-web-archive@ietf.org; Mon, 01 Dec 2003 14:46:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQtzd-0007J5-00 for ieprep-web-archive@ietf.org; Mon, 01 Dec 2003 14:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtzd-0004d6-9Y; Mon, 01 Dec 2003 14:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtz9-0004ZM-V7 for ieprep@optimus.ietf.org; Mon, 01 Dec 2003 14:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24280 for ; Mon, 1 Dec 2003 14:45:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtz7-0007Iu-00 for ieprep@ietf.org; Mon, 01 Dec 2003 14:45:29 -0500 Received: from ellis.ad.nps.navy.mil ([131.120.18.61] helo=[140.32.132.66]) by ietf-mx with esmtp (Exim 4.12) id 1AQtz6-0007Ir-00 for ieprep@ietf.org; Mon, 01 Dec 2003 14:45:28 -0500 Received: from no.name.available by [140.32.132.66] via smtpd (for [132.151.6.1]) with ESMTP; Mon, 1 Dec 2003 11:41:45 -0800 Received: from ro178-234.ro.nps.navy.mil ([131.120.178.234]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Dec 2003 11:45:16 -0800 Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls From: Rex Buddenberg To: "Rosen, Brian" Cc: Mpierce1@aol.com, jmpolk@cisco.com, steves@shentel.net, jgunn@ix.netcom.com, carlberg@g11.org.uk, ieprep@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF070B613B@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF070B613B@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain Message-Id: <1070307914.3760.115.camel@ro178-234.ro.nps.navy.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Dec 2003 11:45:15 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2003 19:45:16.0616 (UTC) FILETIME=[A4F22C80:01C3B843] Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, There have been a lot of wannabe TCP replacements over the years. The CS landscape is littered with them. Why didn't any catch on? Well, a few did. The transport layer functionality ended up inside the application. NFS is a good example of this. But leaving that aside, why has TCP endured so well? I suppose part of the reason is that Vint Cerf et al did so well. But I think that one of the reasons that none of the wannabes never caught on is that they only have tackled one of the problems and I think there are four: - reliable multicast. More on this below. - built-in security. Authentication of SYNs, for example. - QoS sensitivity (more than just congestion) - early open. Reliable multicast is a conceptually sticky problem and there is more than one correct answer. I can articulate at least two: - in a reliable file transfer type of operation, you handle a late joiner by scrolling back to the beginning of the operation because that late joiner needs the entire file. This resembles TCP's reliability definition, but in a multicast environment. - in a common operational picture type of operation, the session may have been in existence for an indefinitely long period of time. A late joiner may need a little history, but certainly not all of it. But once he's joined, he needs transport layer reliability of some sort. The problem is complicated by the fact that the only scalable reliable transport systems are subscriber-oriented; originator-origin systems all fail on ACK-implosion. Early open means including real data with the opening SYN and ACK packets in the three-way handshake. In TCP, these are overhead-only packets. If you have a low-interactivity hop somewhere in your network (e.g. a satellite throw), then the propagation time for this interactivity adds up quickly ... right at the front of a session. XTP is one transport protocol that allows early-open piggy backing; I'd assume there are more. If you see somebody flogging a Performance Enhancement Proxy gadget, this is usually what's under the hood. QoS sensitivity. The problem is sticky because there are several variables and attitudes ... you can't take the bellhead approach of simply counting Erlangs any more. - a lost packet, esp in a radio network, may not be a sign of congestion. So the TCP reactions to a lost packet are now wide of the target. - 'fairness' needs definition. TCP window, backoff, and slowstart behavior are all socialistic -- all pigs are equal. One of the points here is that we need to be able to make some pigs more equal than others. CBR is a poor descriptor, IMHO, because it has to do with determinism, not congestion -- poor fit in nethead thinking. If you want determinism, say so. Bounded delay delivery is a synonym. But determinism is _not_ what we need to make voice work and it's bought quite expensively in terms of bandwidth abuse. - there's no free lunch and there seem to be several ways to spawn lose-lose situations. Bandwidth efficiency, latency, jitter, interactivity and determinism are all in tension -- if you optimize latency/interactivity, you will pay for it in losses in bandwidth efficiency. The default behavior at the network layer is to optimize bandwidth efficiency and take whatever hits are required in the other categories. One of the current research projects at MIT is called XCP and is designed to smarten up the qos impairment problem. It requires modifying the network layer protocols so that more information than simply a lost packet is passed to the transport layer. There are some clever insights here, but I'm guessing XCP will be doomed to be a toy unless it accounts for the other three bullets on the next-gen list. On Mon, 2003-12-01 at 11:06, Rosen, Brian wrote: > This discussion relates to another thread happening on dccp. > The basis of that thread is a discussion of whether it is possible > to design a protocol that can be used for real time data that is > "fair" with respect to TCP. One of the opinions on this thread > (mine among others) is that fairness can only be achieved if TCP > also changes to be aware of "constant bit rate"-like streams. > If there was a mechanism introduced into TCP that worked to allow > real time media and TCP to better co-exist, as well as protocols > that allowed media streams to better co-exist with TCP, then perhaps > there would be opportunities to address some of the concerns Rex raises. > > Please also let me comment on: > > - cut back a VTC to voice only. The psychologists tell > > us that a > > talking-head VTC has visual cues that we use for about 5-10 minutes; > > after that we might as well turn the video off and just leave the > > audio. > I'd like to see the citation on this research. Our research shows that > people in the same room with one another look intently on the faces of > those talking, typically 90% of the time if engaged. On a well designed > "VTC", you can observe the same effect, even an hour or more into a call. > On a poorer quality system, participants tend to look around the room a > lot. I wonder if the research you refer to is out of date. > > And yes Scott, a router can't be expected to tell the difference between > a well designed and a poorly designed video system. > > Brian > > > -----Original Message----- > > From: Rex Buddenberg [mailto:budden@nps.navy.mil] > > Sent: Wednesday, November 26, 2003 4:47 PM > > To: Mpierce1@aol.com > > Cc: jmpolk@cisco.com; steves@shentel.net; jgunn@ix.netcom.com; > > carlberg@g11.org.uk; ieprep@ietf.org > > Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls > > > > > > On Wed, 2003-11-26 at 12:17, Mpierce1@aol.com wrote: > > ... > > > > > > The current GSCR was written for circuit mode. Unless we get it > > > changed, it will apply to packet mode (even when it doesn't always > > > make sense). This is one of the areas we are trying to change, so it > > > correctly takes into account the advantages of using packet. > > ... > > > > > > This whole conversation appears to be predicated on some > > tacit and false > > assumptions. > > > > The principal assumption seems to be that the entire capacity of a hop > > is taken up with VOICE conversations so that the solution to > > oversubscription is to shed some of those VOICE conversations. > > > > If you come to the conversation with a bellhead mentality, then we can > > probably read up on Erlangs and reach much the same > > conclusion that the > > circuit switch world reached years ago. > > > > > > If you have a priority voice conversation and experience > > congestion, it > > would seem to me that we would want to bump something other than other > > voice conversations: > > - anything file transfer (incl e-mail enclosures) with > > .ppt in the file > > label. The content:bit-bloat ratio there is terrible to the > > extent that > > I'm calling powerpoint a virus these days. > > - cut back a VTC to voice only. The psychologists tell > > us that a > > talking-head VTC has visual cues that we use for about 5-10 minutes; > > after that we might as well turn the video off and just leave the > > audio. The problem here is that we can't know by looking at port > > numbers whether someone has turned the camera around and is > > sharing view > > of a crime scene > > - filter out any ftp-based operating system installs > > (they can wait). > > Only picking on this example because I did it this morning. > > What we have to be careful not to do is filter out > > things that are > > higher priority than the priority voice conversation. LSAs > > (router link > > state announcements, necessary to keep the network converged and > > functioning) is one example. > > > > > > -- > > b > > > > > > _______________________________________________ > > Ieprep mailing list > > Ieprep@ietf.org > > https://www1.ietf.org/mailman/listinfo/ieprep > > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep -- b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Dec 1 15:18:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26442 for ; Mon, 1 Dec 2003 15:18:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuUe-0006CA-0l for ieprep-archive@odin.ietf.org; Mon, 01 Dec 2003 15:18:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1KI36t023808 for ieprep-archive@odin.ietf.org; Mon, 1 Dec 2003 15:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuUd-0006Bv-Ry for ieprep-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 15:18:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26395 for ; Mon, 1 Dec 2003 15:17:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuUc-0007ac-00 for ieprep-web-archive@ietf.org; Mon, 01 Dec 2003 15:18:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQuUc-0007aZ-00 for ieprep-web-archive@ietf.org; Mon, 01 Dec 2003 15:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuUb-0006BP-Ek; Mon, 01 Dec 2003 15:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuUD-0006B7-Ah for ieprep@optimus.ietf.org; Mon, 01 Dec 2003 15:17:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26355 for ; Mon, 1 Dec 2003 15:17:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuUC-0007aW-00 for ieprep@ietf.org; Mon, 01 Dec 2003 15:17:36 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQuUB-0007Zs-00 for ieprep@ietf.org; Mon, 01 Dec 2003 15:17:35 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09101; Mon, 1 Dec 2003 15:17:02 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA07868; Mon, 1 Dec 2003 15:17:02 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Dec 2003 15:17:01 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B613D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rex Buddenberg'" Cc: Mpierce1@aol.com, jmpolk@cisco.com, steves@shentel.net, jgunn@ix.netcom.com, carlberg@g11.org.uk, ieprep@ietf.org Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls Date: Mon, 1 Dec 2003 15:16:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , Rex I agree with all you have written, and yet I wonder if the problem we are having getting VoIP and TCP to co-exist nicely is going to be solved if we try to also solve the other problems you raise. It would be nice, I think, to do so, but is it practical? It does seem that we could tinker with TCP to allow it to be less greedy than it is now, just as we can tinker with UDP to add enough congestion control to prevent congestion collapse and to appropriately trigger better TCP behavior. Some of the proposals on the DCCP list are, uh, interesting. Like the one that suggests that we use up to twice the bandwidth we need so that TCP will back off enough to maintain what we need. That would actually work, but it may not be the best way to solve the problem. On this list, the issue is do we actually have some requirements in IEPREP that impinge on TCP that are similar to, but not exactly the same as, the VoIP (or other real-time media) problem? Should we codify such requirements so that IEPREP could be added to the (small) chorus of voices that are talking about heresy -- making TCP not so greedy when no one else is pigging out. I treat TCP replacements as "run away, run away fast" for much of the reasons you have elucidated. However, we have tinkered with TCP in several ways of late. Not all have (yet) been widely implemented, but there is some hope. The problem at the moment is that the UDP toting media stream folks don't have any incentive to add congestion control when the big bad TCP gobbles up all their bandwidth if they do or they don't, and the TCP crowd thinks if everyone else was just TCP friendly (they even have an acronym!) life would be great, for TCP. Brian > -----Original Message----- > From: Rex Buddenberg [mailto:budden@nps.navy.mil] > Sent: Monday, December 01, 2003 2:45 PM > To: Rosen, Brian > Cc: Mpierce1@aol.com; jmpolk@cisco.com; steves@shentel.net; > jgunn@ix.netcom.com; carlberg@g11.org.uk; ieprep@ietf.org > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls > > > Brian, > > There have been a lot of wannabe TCP replacements over the years. The > CS landscape is littered with them. Why didn't any catch on? > > Well, a few did. The transport layer functionality ended up > inside the > application. NFS is a good example of this. But leaving that aside, > why has TCP endured so well? > > I suppose part of the reason is that Vint Cerf et al did so well. > > But I think that one of the reasons that none of the wannabes never > caught on is that they only have tackled one of the problems > and I think > there are four: > - reliable multicast. More on this below. > - built-in security. Authentication of SYNs, for example. > - QoS sensitivity (more than just congestion) > - early open. > > Reliable multicast is a conceptually sticky problem and there is more > than one correct answer. I can articulate at least two: > - in a reliable file transfer type of operation, you > handle a late > joiner by scrolling back to the beginning of the operation > because that > late joiner needs the entire file. This resembles TCP's reliability > definition, but in a multicast environment. > - in a common operational picture type of operation, > the session may > have been in existence for an indefinitely long period of > time. A late > joiner may need a little history, but certainly not all of > it. But once > he's joined, he needs transport layer reliability of some sort. > The problem is complicated by the fact that the only > scalable reliable > transport systems are subscriber-oriented; originator-origin > systems all > fail on ACK-implosion. > > Early open means including real data with the opening SYN and ACK > packets in the three-way handshake. In TCP, these are overhead-only > packets. If you have a low-interactivity hop somewhere in > your network > (e.g. a satellite throw), then the propagation time for this > interactivity adds up quickly ... right at the front of a session. > XTP is one transport protocol that allows early-open > piggy backing; I'd > assume there are more. If you see somebody flogging a Performance > Enhancement Proxy gadget, this is usually what's under the hood. > > QoS sensitivity. The problem is sticky because there are several > variables and attitudes ... you can't take the bellhead approach of > simply counting Erlangs any more. > - a lost packet, esp in a radio network, may not be a sign of > congestion. So the TCP reactions to a lost packet are now wide of the > target. > - 'fairness' needs definition. TCP window, backoff, > and slowstart > behavior are all socialistic -- all pigs are equal. One of the points > here is that we need to be able to make some pigs more equal than > others. CBR is a poor descriptor, IMHO, because it has to do with > determinism, not congestion -- poor fit in nethead thinking. If you > want determinism, say so. Bounded delay delivery is a synonym. But > determinism is _not_ what we need to make voice work and it's bought > quite expensively in terms of bandwidth abuse. > - there's no free lunch and there seem to be several > ways to spawn > lose-lose situations. Bandwidth efficiency, latency, jitter, > interactivity and determinism are all in tension -- if you optimize > latency/interactivity, you will pay for it in losses in bandwidth > efficiency. The default behavior at the network layer is to optimize > bandwidth efficiency and take whatever hits are required in the other > categories. > One of the current research projects at MIT is called XCP and is > designed to smarten up the qos impairment problem. It requires > modifying the network layer protocols so that more information than > simply a lost packet is passed to the transport layer. There are some > clever insights here, but I'm guessing XCP will be doomed to be a toy > unless it accounts for the other three bullets on the next-gen list. > > > > On Mon, 2003-12-01 at 11:06, Rosen, Brian wrote: > > This discussion relates to another thread happening on dccp. > > The basis of that thread is a discussion of whether it is possible > > to design a protocol that can be used for real time data that is > > "fair" with respect to TCP. One of the opinions on this thread > > (mine among others) is that fairness can only be achieved if TCP > > also changes to be aware of "constant bit rate"-like streams. > > If there was a mechanism introduced into TCP that worked to allow > > real time media and TCP to better co-exist, as well as protocols > > that allowed media streams to better co-exist with TCP, > then perhaps > > there would be opportunities to address some of the > concerns Rex raises. > > > > Please also let me comment on: > > > - cut back a VTC to voice only. The psychologists tell > > > us that a > > > talking-head VTC has visual cues that we use for about > 5-10 minutes; > > > after that we might as well turn the video off and just leave the > > > audio. > > I'd like to see the citation on this research. Our > research shows that > > people in the same room with one another look intently on > the faces of > > those talking, typically 90% of the time if engaged. On a > well designed > > "VTC", you can observe the same effect, even an hour or > more into a call. > > On a poorer quality system, participants tend to look > around the room a > > lot. I wonder if the research you refer to is out of date. > > > > And yes Scott, a router can't be expected to tell the > difference between > > a well designed and a poorly designed video system. > > > > Brian > > > > > -----Original Message----- > > > From: Rex Buddenberg [mailto:budden@nps.navy.mil] > > > Sent: Wednesday, November 26, 2003 4:47 PM > > > To: Mpierce1@aol.com > > > Cc: jmpolk@cisco.com; steves@shentel.net; jgunn@ix.netcom.com; > > > carlberg@g11.org.uk; ieprep@ietf.org > > > Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low > priority calls > > > > > > > > > On Wed, 2003-11-26 at 12:17, Mpierce1@aol.com wrote: > > > ... > > > > > > > > The current GSCR was written for circuit mode. Unless we get it > > > > changed, it will apply to packet mode (even when it > doesn't always > > > > make sense). This is one of the areas we are trying to > change, so it > > > > correctly takes into account the advantages of using packet. > > > ... > > > > > > > > > This whole conversation appears to be predicated on some > > > tacit and false > > > assumptions. > > > > > > The principal assumption seems to be that the entire > capacity of a hop > > > is taken up with VOICE conversations so that the solution to > > > oversubscription is to shed some of those VOICE conversations. > > > > > > If you come to the conversation with a bellhead > mentality, then we can > > > probably read up on Erlangs and reach much the same > > > conclusion that the > > > circuit switch world reached years ago. > > > > > > > > > If you have a priority voice conversation and experience > > > congestion, it > > > would seem to me that we would want to bump something > other than other > > > voice conversations: > > > - anything file transfer (incl e-mail enclosures) with > > > .ppt in the file > > > label. The content:bit-bloat ratio there is terrible to the > > > extent that > > > I'm calling powerpoint a virus these days. > > > - cut back a VTC to voice only. The psychologists tell > > > us that a > > > talking-head VTC has visual cues that we use for about > 5-10 minutes; > > > after that we might as well turn the video off and just leave the > > > audio. The problem here is that we can't know by looking at port > > > numbers whether someone has turned the camera around and is > > > sharing view > > > of a crime scene > > > - filter out any ftp-based operating system installs > > > (they can wait). > > > Only picking on this example because I did it this morning. > > > What we have to be careful not to do is filter out > > > things that are > > > higher priority than the priority voice conversation. LSAs > > > (router link > > > state announcements, necessary to keep the network converged and > > > functioning) is one example. > > > > > > > > > -- > > > b > > > > > > > > > _______________________________________________ > > > Ieprep mailing list > > > Ieprep@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ieprep > > > > > > > _______________________________________________ > > Ieprep mailing list > > Ieprep@ietf.org > > https://www1.ietf.org/mailman/listinfo/ieprep > -- > b > > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Dec 2 15:37:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09064 for ; Tue, 2 Dec 2003 15:37:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHGg-00077G-5O for ieprep-archive@odin.ietf.org; Tue, 02 Dec 2003 15:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Kb9Ht027340 for ieprep-archive@odin.ietf.org; Tue, 2 Dec 2003 15:37:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHGf-00076l-9A for ieprep-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:37:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08972 for ; Tue, 2 Dec 2003 15:36:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHGd-0000CF-00 for ieprep-web-archive@ietf.org; Tue, 02 Dec 2003 15:37:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARHGc-0000CA-00 for ieprep-web-archive@ietf.org; Tue, 02 Dec 2003 15:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHGX-00070h-Lb; Tue, 02 Dec 2003 15:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHFw-0006s9-NP for ieprep@optimus.ietf.org; Tue, 02 Dec 2003 15:36:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08875; Tue, 2 Dec 2003 15:36:11 -0500 (EST) Message-Id: <200312022036.PAA08875@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 02 Dec 2003 15:36:11 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-telephony-07.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : IP Telephony Requirements for Emergency Telecommunication Service Author(s) : K. Carlberg, R. Atkinson Filename : draft-ietf-ieprep-ets-telephony-07.txt Pages : 6 Date : 2003-12-2 This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in [3]. Solutions to these requirements are not presented in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-ets-telephony-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ieprep-ets-telephony-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-ets-telephony-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-2154550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-ets-telephony-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-ets-telephony-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-2154550.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Dec 3 10:12:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18751 for ; Wed, 3 Dec 2003 10:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYfn-00024i-9E for ieprep-archive@odin.ietf.org; Wed, 03 Dec 2003 10:12:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3FCDl1007885 for ieprep-archive@odin.ietf.org; Wed, 3 Dec 2003 10:12:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYff-00022F-6B for ieprep-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 10:12:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18671 for ; Wed, 3 Dec 2003 10:11:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYfc-0002iT-00 for ieprep-web-archive@ietf.org; Wed, 03 Dec 2003 10:12:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYfc-0002iQ-00 for ieprep-web-archive@ietf.org; Wed, 03 Dec 2003 10:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYfZ-00021L-Df; Wed, 03 Dec 2003 10:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYfQ-000219-87 for ieprep@optimus.ietf.org; Wed, 03 Dec 2003 10:11:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18647 for ; Wed, 3 Dec 2003 10:11:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYfO-0002iF-00 for ieprep@ietf.org; Wed, 03 Dec 2003 10:11:50 -0500 Received: from mailgw1a.lmco.com ([192.31.106.7]) by ietf-mx with esmtp (Exim 4.12) id 1ARYfN-0002iB-00 for ieprep@ietf.org; Wed, 03 Dec 2003 10:11:49 -0500 Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54]) by mailgw1a.lmco.com (8.12.10/8.12.10) with ESMTP id hB3FBmNK002045 for ; Wed, 3 Dec 2003 08:11:48 -0700 (MST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HPB00E01RJ9B2@lmco.com> for ieprep@ietf.org; Wed, 03 Dec 2003 08:11:47 -0700 (MST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HPB00ISORJ6V6@lmco.com> for ieprep@ietf.org; Wed, 03 Dec 2003 08:11:33 -0700 (MST) Date: Wed, 03 Dec 2003 10:11:24 -0500 From: "Eagan, Christopher" To: ieprep@ietf.org Message-id: <3F2F205501D3D411878C0008C7E6459410CFECCC@emss09m06.ems.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: multipart/mixed; boundary="Boundary_(ID_xTVFXgTG3O6Tn0liH6VAVA)" Thread-Topic: I-D ACTION:draft-baker-tsvwg-mlpp-that-works-00.txt Thread-Index: AcO5H4kfsgbN7+tFTi2ZWbZPqPxxTAAkD9yQ content-class: urn:content-classes:message X-MS-Has-Attach: yes Subject: [Ieprep] FW: I-D ACTION:draft-baker-tsvwg-mlpp-that-works-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_xTVFXgTG3O6Tn0liH6VAVA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT FYI -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, December 02, 2003 3:35 PM Subject: I-D ACTION:draft-baker-tsvwg-mlpp-that-works-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Implementing MLPP in the Internet Protocol Suite Author(s) : F. Baker Filename : draft-baker-tsvwg-mlpp-that-works-00.txt Pages : 23 Date : 2003-12-2 The Defense Information Systems Agency of the United States Department of Defense, with is contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: 'Architecture for Assured Service Capabilities in Voice over IP' and 'Requirements for Assured Service Capabilities in Voice over IP'. Responding to these are three documents: 'Reason Header Field for the Session Initiation Protocol', 'Extending the Session Initiation Protocol Reason Header to account for Preemption Events', 'Communications Resource Priority for the Session Initiation Protocol'. What remains to this specification is to provide a Call Admission Control procedure and a Per Hop Behavior for the data which meet the needs of this architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-baker-tsvwg-mlpp-that-works-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-baker-tsvwg-mlpp-that-works-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_xTVFXgTG3O6Tn0liH6VAVA) Content-type: application/octet-stream; name=ATT532229.TXT Content-disposition: attachment; filename=ATT532229.TXT Content-description: ATT532229.TXT Content-Transfer-Encoding: BASE64 Q29udGVudC10eXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7CWFjY2Vzcy10eXBl PSJtYWlsLXNlcnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0K Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOgk8MjAwMy0xMi0y MTU0MTQ0LkktREBpZXRmLm9yZz4NCg0KRU5DT0RJTkcgbWltZQ0KRklMRSAvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWJha2VyLXRzdndnLW1scHAtdGhhdC13b3Jrcy0w MC50eHQNCg== --Boundary_(ID_xTVFXgTG3O6Tn0liH6VAVA) Content-type: application/octet-stream; name=draft-baker-tsvwg-mlpp-that-works-00.URL Content-disposition: attachment; filename=draft-baker-tsvwg-mlpp-that-works-00.URL Content-description: draft-baker-tsvwg-mlpp-that-works-00.URL Content-Transfer-Encoding: BASE64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1iYWtlci10c3Z3Zy1tbHBwLXRoYXQtd29ya3MtMDAu dHh0DQo= --Boundary_(ID_xTVFXgTG3O6Tn0liH6VAVA)-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Dec 3 10:25:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19435 for ; Wed, 3 Dec 2003 10:25:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYsL-0002SG-04 for ieprep-archive@odin.ietf.org; Wed, 03 Dec 2003 10:25:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3FPCK3009436 for ieprep-archive@odin.ietf.org; Wed, 3 Dec 2003 10:25:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYsJ-0002S5-6M for ieprep-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 10:25:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19414 for ; Wed, 3 Dec 2003 10:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYsG-0002pM-00 for ieprep-web-archive@ietf.org; Wed, 03 Dec 2003 10:25:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYsG-0002pJ-00 for ieprep-web-archive@ietf.org; Wed, 03 Dec 2003 10:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYsB-0002RN-9K; Wed, 03 Dec 2003 10:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYry-0002Qk-VN for ieprep@optimus.ietf.org; Wed, 03 Dec 2003 10:24:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19407 for ; Wed, 3 Dec 2003 10:24:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYrw-0002p8-00 for ieprep@ietf.org; Wed, 03 Dec 2003 10:24:48 -0500 Received: from mailgw1a.lmco.com ([192.31.106.7]) by ietf-mx with esmtp (Exim 4.12) id 1ARYrv-0002p5-00 for ieprep@ietf.org; Wed, 03 Dec 2003 10:24:47 -0500 Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54]) by mailgw1a.lmco.com (8.12.10/8.12.10) with ESMTP id hB3FOkNM012893 for ; Wed, 3 Dec 2003 08:24:46 -0700 (MST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HPB00301S4YS6@lmco.com> for ieprep@ietf.org; Wed, 03 Dec 2003 08:24:46 -0700 (MST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HPB00ME8S4QY2@lmco.com> for ieprep@ietf.org; Wed, 03 Dec 2003 08:24:34 -0700 (MST) Date: Wed, 03 Dec 2003 10:24:20 -0500 From: "Eagan, Christopher" To: ieprep@ietf.org Message-id: <3F2F205501D3D411878C0008C7E6459410CFECCD@emss09m06.ems.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: multipart/mixed; boundary="Boundary_(ID_EQ0pGBai/z9oOVZAXuM0Yw)" Thread-Topic: I-D ACTION:draft-baker-tsvwg-mlef-concerns-00.txt Thread-Index: AcO5IZMxm8r8bscARkSfL1GKbWBB/wAkBEog content-class: urn:content-classes:message X-MS-Has-Attach: yes Subject: [Ieprep] FW: I-D ACTION:draft-baker-tsvwg-mlef-concerns-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_EQ0pGBai/z9oOVZAXuM0Yw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, December 02, 2003 3:35 PM Subject: I-D ACTION:draft-baker-tsvwg-mlef-concerns-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MLEF Considered Harmful Author(s) : F. Baker Filename : draft-baker-tsvwg-mlef-concerns-00.txt Pages : 19 Date : 2003-12-2 The Defense Information Systems Agency of the United States Department of Defense, with is contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. This is called the Assured Service, and is defined in two documents: 'Architecture for Assured Service Capabilities in Voice over IP' and 'Requirements for Assured Service Capabilities in Voice over IP'. Responding to these are four documents: 'Reason Header Field for the Session Initiation Protocol', 'Extending the Session Initiation Protocol Reason Header to account for Preemption Events', 'Communications Resource Priority for the Session Initiation Protocol', and the 'Multi-Level Expedited Forwarding Per Hop Behavior' (MLEF PHB). MLEF, as currently defined, has serious problems, which this draft seeks to discuss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlef-concerns-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-baker-tsvwg-mlef-concerns-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-baker-tsvwg-mlef-concerns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_EQ0pGBai/z9oOVZAXuM0Yw) Content-type: application/octet-stream; name=ATT533372.TXT Content-disposition: attachment; filename=ATT533372.TXT Content-description: ATT533372.TXT Content-Transfer-Encoding: BASE64 Q29udGVudC10eXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7CWFjY2Vzcy10eXBl PSJtYWlsLXNlcnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0K Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOgk8MjAwMy0xMi0y MTU0MzQ4LkktREBpZXRmLm9yZz4NCg0KRU5DT0RJTkcgbWltZQ0KRklMRSAvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWJha2VyLXRzdndnLW1sZWYtY29uY2VybnMtMDAu dHh0DQo= --Boundary_(ID_EQ0pGBai/z9oOVZAXuM0Yw) Content-type: application/octet-stream; name=draft-baker-tsvwg-mlef-concerns-00.URL Content-disposition: attachment; filename=draft-baker-tsvwg-mlef-concerns-00.URL Content-description: draft-baker-tsvwg-mlef-concerns-00.URL Content-Transfer-Encoding: BASE64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1iYWtlci10c3Z3Zy1tbGVmLWNvbmNlcm5zLTAwLnR4 dA0K --Boundary_(ID_EQ0pGBai/z9oOVZAXuM0Yw)-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Dec 3 15:30:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04286 for ; Wed, 3 Dec 2003 15:30:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARddb-0002Dr-Ez for ieprep-archive@odin.ietf.org; Wed, 03 Dec 2003 15:30:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3KUJZ9008542 for ieprep-archive@odin.ietf.org; Wed, 3 Dec 2003 15:30:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARddb-0002Dh-Bh for ieprep-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 15:30:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04171 for ; Wed, 3 Dec 2003 15:30:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARddZ-0007g6-00 for ieprep-web-archive@ietf.org; Wed, 03 Dec 2003 15:30:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARddZ-0007g3-00 for ieprep-web-archive@ietf.org; Wed, 03 Dec 2003 15:30:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARddL-000279-2B; Wed, 03 Dec 2003 15:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARdcM-0001xK-Nz for ieprep@optimus.ietf.org; Wed, 03 Dec 2003 15:29:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03946; Wed, 3 Dec 2003 15:28:46 -0500 (EST) Message-Id: <200312032028.PAA03946@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 03 Dec 2003 15:28:46 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-07.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : Framework for Supporting IEPS in IP Telephony Author(s) : K. Carlberg, I. Brown, C. Beard Filename : draft-ietf-ieprep-framework-07.txt Pages : 26 Date : 2003-12-3 This document presents a framework for supporting authorized emergency related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These, models, coupled with an example of an existing service in the PSTN, contribute to a constrained solution space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-framework-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ieprep-framework-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-framework-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-3152840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-framework-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-framework-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-3152840.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Dec 11 20:44:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06860 for ; Thu, 11 Dec 2003 20:44:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUcLe-0005E7-Hu for ieprep-archive@odin.ietf.org; Thu, 11 Dec 2003 20:44:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC1i6Fm020085 for ieprep-archive@odin.ietf.org; Thu, 11 Dec 2003 20:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUcLe-0005Ds-DR for ieprep-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 20:44:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06848 for ; Thu, 11 Dec 2003 20:44:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUcLc-00008v-00 for ieprep-web-archive@ietf.org; Thu, 11 Dec 2003 20:44:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUcLb-00008p-00 for ieprep-web-archive@ietf.org; Thu, 11 Dec 2003 20:44:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUcLZ-0005Co-6k; Thu, 11 Dec 2003 20:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUcL4-0005CM-46 for ieprep@optimus.ietf.org; Thu, 11 Dec 2003 20:43:30 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06836 for ; Thu, 11 Dec 2003 20:43:27 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AUcJg-000108-Nd; Thu, 11 Dec 2003 20:42:04 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Thu, 11 Dec 2003 20:42:04 -0500 Subject: [Ieprep] Document Action: 'IP Telephony Requirements for Emergency Telecommunication Service' to Informational RFC Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , The IESG has approved the following document: - 'IP Telephony Requirements for Emergency Telecommunication Service ' as an Informational RFC This document is the product of the Internet Emergency Preparedness Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements previously developed in the IEPREP WG. Solutions to these requirements are not presented in this document. Working Group Summary The IEPREP Working Group supports the document. Protocol Quality This document was reviewed for the IESG by Jon Peterson. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Dec 22 11:11:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23476 for ; Mon, 22 Dec 2003 11:11:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSeK-00072G-Vy for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 11:11:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMGBGoP027040 for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 11:11:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSeK-000723-SB for ieprep-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 11:11:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23470 for ; Mon, 22 Dec 2003 11:11:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYSeI-0000dX-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 11:11:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYSeG-0000dJ-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 11:11:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYSeG-0000ck-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 11:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSe6-00070R-Aj; Mon, 22 Dec 2003 11:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSdr-0006yf-1c for ieprep@optimus.ietf.org; Mon, 22 Dec 2003 11:10:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23404 for ; Mon, 22 Dec 2003 11:10:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYSdn-0000YU-00 for ieprep@ietf.org; Mon, 22 Dec 2003 11:10:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYSdi-0000YC-00 for ieprep@ietf.org; Mon, 22 Dec 2003 11:10:40 -0500 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx with esmtp (Exim 4.12) id 1AYSdi-0000Y9-00 for ieprep@ietf.org; Mon, 22 Dec 2003 11:10:38 -0500 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Mon, 22 Dec 2003 11:10:24 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003122211102426812 for ; Mon, 22 Dec 2003 11:10:24 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Dec 2003 11:10:24 -0500 Message-Id: From: "King, Kimberly S." To: "Ieprep (E-mail)" Date: Mon, 22 Dec 2003 11:10:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ieprep] TCP PEPs and Priority-based Mechanisms Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This Information RFC may be of interest. For example, PEPs can be useful for moving TCP traffic over satellite links. http://www.ietf.org/rfc/rfc3135.txt 3.5 Priority-based Multiplexing Implementing priority-based multiplexing of data over a slow and expensive link may significantly improve the performance and usability of the link for selected applications or connections. A user behind a slow link would experience the link more feasible to use in case of simultaneous data transfers, if urgent data transfers (e.g., interactive connections) could have shorter response time (better performance) than less urgent background transfers. If the interactive connections transmit enough data to keep the slow link fully utilized, it might be necessary to fully suspend the background transfers for awhile to ensure timely delivery for the interactive connections. In flight TCP segments of an end-to-end TCP connection (with low priority) cannot be delayed for a long time. Otherwise, the TCP timer at the sending end would expire, resulting in suboptimal performance. However, this kind of operation can be controlled in conjunction with a split connection TCP PEP by assigning different priorities for different connections (or applications). A split connection PEP implementation allows the PEP in an intermediate node to delay the data delivery of a lower-priority TCP flow for an unlimited period of time by simply rescheduling the order in which it forwards data of different flows to the destination host behind the slow link. This does not have a negative impact on the delayed TCP flow as normal TCP flow control takes care of suspending the flow between the TCP sender and the PEP, when the PEP is not forwarding data for the flow, and resumes it once the PEP decides to continue forwarding data for the flow. This can further be assisted, if the protocol stacks on both sides of the slow link implement priority based scheduling of connections. With such a PEP implementation, along with user-controlled priorities, the user can assign higher priority for selected interactive connection(s) and have much shorter response time for the selected connection(s), even if there are simultaneous low priority bulk data transfers which in regular end-to-end operation would otherwise eat the available bandwidth of the slow link almost completely. These low priority bulk data transfers would then proceed nicely during the idle periods of interactive connections, allowing the user to keep the slow and expensive link (e.g., wireless WAN) fully utilized. Other priority-based mechanisms may be applied on shared wireless links with more than two terminals. With shared wireless mediums becoming a weak link in Internet QoS architectures, many may turn to PEPs to provide extra priority levels across a shared wireless medium [SHEL00]. These PEPs are distributed on all nodes of the shared wireless medium. For example, in an 802.11 WLAN this PEP is implemented in the access point (base station) and each mobile host. One PEP then uses distributed queuing techniques to coordinate traffic classes of all nodes. This is also sometimes called subnet bandwidth management. See [BBKT97] for an example of queuing techniques which can be used to achieve this. This technique can be implemented either above or below the IP layer. Priority treatment can typically be specified either by the user or by marking the (IPv4) ToS or (IPv6) Traffic Class IP header field. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Dec 22 13:53:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29974 for ; Mon, 22 Dec 2003 13:53:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYVAk-0004l2-5W for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 13:52:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMIqsRw018284 for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 13:52:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYVAk-0004kp-2D for ieprep-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 13:52:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29966 for ; Mon, 22 Dec 2003 13:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYVAc-0006M3-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 13:52:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYVAB-0006Li-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 13:52:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYVAB-0006LE-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 13:52:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYV9s-0004i9-MW; Mon, 22 Dec 2003 13:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYV9i-0004hy-9i for ieprep@optimus.ietf.org; Mon, 22 Dec 2003 13:51:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29941 for ; Mon, 22 Dec 2003 13:51:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYV9W-0006Kk-00 for ieprep@ietf.org; Mon, 22 Dec 2003 13:51:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYV95-0006KV-00 for ieprep@ietf.org; Mon, 22 Dec 2003 13:51:12 -0500 Received: from ellis.ad.nps.navy.mil ([131.120.18.61] helo=[140.32.132.66]) by ietf-mx with esmtp (Exim 4.12) id 1AYV95-0006JT-00 for ieprep@ietf.org; Mon, 22 Dec 2003 13:51:11 -0500 Received: from no.name.available by [140.32.132.66] via smtpd (for [132.151.6.1]) with ESMTP; Mon, 22 Dec 2003 10:46:17 -0800 Received: from [131.120.178.39] ([131.120.178.39]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Dec 2003 10:50:42 -0800 Subject: Re: [Ieprep] TCP PEPs and Priority-based Mechanisms From: Rex Buddenberg To: "King, Kimberly S." Cc: "Ieprep (E-mail)" In-Reply-To: References: Content-Type: text/plain Message-Id: <1072119042.3760.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 22 Dec 2003 10:50:42 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Dec 2003 18:50:42.0465 (UTC) FILETIME=[80132110:01C3C8BC] Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Make sure you read section 6 on page 33. The use of Performance Enhancing Proxies introduces several issues which impact security. First, (as described in detail in Section 4.1.1,) using PEPs and using IPsec is generally mutually exclusive. On Mon, 2003-12-22 at 08:10, King, Kimberly S. wrote: > This Information RFC may be of interest. For example, PEPs can be useful > for moving TCP traffic over satellite links. > > http://www.ietf.org/rfc/rfc3135.txt > > 3.5 Priority-based Multiplexing > > Implementing priority-based multiplexing of data over a slow and > expensive link may significantly improve the performance and > usability of the link for selected applications or connections. > > A user behind a slow link would experience the link more feasible to > use in case of simultaneous data transfers, if urgent data transfers > (e.g., interactive connections) could have shorter response time > (better performance) than less urgent background transfers. If the > interactive connections transmit enough data to keep the slow link > fully utilized, it might be necessary to fully suspend the background > transfers for awhile to ensure timely delivery for the interactive > connections. > > In flight TCP segments of an end-to-end TCP connection (with low > priority) cannot be delayed for a long time. Otherwise, the TCP > timer at the sending end would expire, resulting in suboptimal > performance. However, this kind of operation can be controlled in > conjunction with a split connection TCP PEP by assigning different > priorities for different connections (or applications). A split > connection PEP implementation allows the PEP in an intermediate node > to delay the data delivery of a lower-priority TCP flow for an > unlimited period of time by simply rescheduling the order in which it > forwards data of different flows to the destination host behind the > slow link. This does not have a negative impact on the delayed TCP > flow as normal TCP flow control takes care of suspending the flow > between the TCP sender and the PEP, when the PEP is not forwarding > data for the flow, and resumes it once the PEP decides to continue > forwarding data for the flow. This can further be assisted, if the > protocol stacks on both sides of the slow link implement priority > based scheduling of connections. > > With such a PEP implementation, along with user-controlled > priorities, the user can assign higher priority for selected > interactive connection(s) and have much shorter response time for the > selected connection(s), even if there are simultaneous low priority > bulk data transfers which in regular end-to-end operation would > otherwise eat the available bandwidth of the slow link almost > completely. These low priority bulk data transfers would then > proceed nicely during the idle periods of interactive connections, > allowing the user to keep the slow and expensive link (e.g., wireless > WAN) fully utilized. > > Other priority-based mechanisms may be applied on shared wireless > links with more than two terminals. With shared wireless mediums > becoming a weak link in Internet QoS architectures, many may turn to > PEPs to provide extra priority levels across a shared wireless medium > [SHEL00]. These PEPs are distributed on all nodes of the shared > wireless medium. For example, in an 802.11 WLAN this PEP is > implemented in the access point (base station) and each mobile host. > One PEP then uses distributed queuing techniques to coordinate > traffic classes of all nodes. This is also sometimes called subnet > bandwidth management. See [BBKT97] for an example of queuing > techniques which can be used to achieve this. This technique can be > implemented either above or below the IP layer. Priority treatment > can typically be specified either by the user or by marking the > (IPv4) ToS or (IPv6) Traffic Class IP header field. > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep -- b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Dec 22 14:18:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01370 for ; Mon, 22 Dec 2003 14:18:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYVZG-0005ZY-C6 for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 14:18:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMJIEhd021414 for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 14:18:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYVZG-0005ZI-5v for ieprep-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 14:18:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01354 for ; Mon, 22 Dec 2003 14:18:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYVZD-0007Tb-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 14:18:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYVZC-0007TU-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 14:18:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYVZC-0007TR-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 14:18:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYVZ3-0005YX-2H; Mon, 22 Dec 2003 14:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYVYE-0005Xn-CM for ieprep@optimus.ietf.org; Mon, 22 Dec 2003 14:17:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01305 for ; Mon, 22 Dec 2003 14:17:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYVYB-0007Sg-00 for ieprep@ietf.org; Mon, 22 Dec 2003 14:17:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYVYB-0007SZ-00 for ieprep@ietf.org; Mon, 22 Dec 2003 14:17:07 -0500 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx with esmtp (Exim 4.12) id 1AYVYA-0007SW-00 for ieprep@ietf.org; Mon, 22 Dec 2003 14:17:06 -0500 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com; Mon, 22 Dec 2003 14:16:53 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003122214165223572 ; Mon, 22 Dec 2003 14:16:52 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Dec 2003 14:16:53 -0500 Message-Id: From: "King, Kimberly S." To: "'Rex Buddenberg'" , "King, Kimberly S." Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] TCP PEPs and Priority-based Mechanisms Date: Mon, 22 Dec 2003 14:16:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > The use of Performance Enhancing Proxies introduces several issues > which impact security.=20 Yes, you are right to point that out but unfortunately that's just the = way it is. Even if we forget about PEPs for the moment. =20 Use IPsec but mark the packets using DSCPs kept in the clear. Consider traffic analysis...sit back and watch the codepoints (lots of high = priority MLEF?) " * Security UP =3D>=AD Bandwidth Utilization DOWN * Security UP =3D>=AD Performance DOWN * Tunnels Tunnels Tunnels and more Tunnels * Performance DOWN =3D> Security DOWN =3D> User turns OFF Security to make system usable! * Thus, we need more bandwidth to ensure security. " http://spacecom.grc.nasa.gov/icnsconf/docs/2002/10/Session_E1-5_Ivancic.= pdf I think one makes the choices that best fit because there is no free = lunch. :-( _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Dec 22 14:53:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02725 for ; Mon, 22 Dec 2003 14:53:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW6s-0006fe-Bo for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 14:52:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMJqwg5025636 for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 14:52:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW6s-0006fP-8k for ieprep-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 14:52:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02669 for ; Mon, 22 Dec 2003 14:52:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYW6f-0000aM-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 14:52:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYW6E-0000Zs-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 14:52:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYW6E-0000Z4-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 14:52:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW5x-0006cB-2K; Mon, 22 Dec 2003 14:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW5P-0006bY-Qe for ieprep@optimus.ietf.org; Mon, 22 Dec 2003 14:51:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02586 for ; Mon, 22 Dec 2003 14:51:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYW5H-0000WX-00 for ieprep@ietf.org; Mon, 22 Dec 2003 14:51:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYW4r-0000W9-00 for ieprep@ietf.org; Mon, 22 Dec 2003 14:50:54 -0500 Received: from ellis.ad.nps.navy.mil ([131.120.18.61] helo=[140.32.132.66]) by ietf-mx with esmtp (Exim 4.12) id 1AYW4r-0000Vd-00 for ieprep@ietf.org; Mon, 22 Dec 2003 14:50:53 -0500 Received: from no.name.available by [140.32.132.66] via smtpd (for [132.151.6.1]) with ESMTP; Mon, 22 Dec 2003 11:45:58 -0800 Received: from [131.120.178.39] ([131.120.178.39]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Dec 2003 11:50:41 -0800 Subject: RE: [Ieprep] TCP PEPs and Priority-based Mechanisms From: Rex Buddenberg To: "King, Kimberly S." Cc: "Ieprep (E-mail)" In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Message-Id: <1072122641.3760.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 22 Dec 2003 11:50:41 -0800 X-OriginalArrivalTime: 22 Dec 2003 19:50:41.0307 (UTC) FILETIME=[E126D6B0:01C3C8C4] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA02587 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Kimberly, Actually you hit the one compelling reason, IMHO, for shifting to IPv6.=20 Note that I'm here at the network layer, not transport. IPv6 supports header extensions -- the extension+payload get encrypted but the base header (which includes DSCP) does not. So any network level QoS you choose to use is unaffected by IPSec. Back at the transport layer, I'm just not terribly turned on by PEPs.=20 The RFC is useful because it surveys a fairly wide set of bandaids that fall under the general PEP category. But these remain bandaids until we grapple with the nextgen transport protocol issue. On Mon, 2003-12-22 at 11:16, King, Kimberly S. wrote: > > The use of Performance Enhancing Proxies introduces several issues > > which impact security.=20 >=20 > Yes, you are right to point that out but unfortunately that's just the = way > it is. Even if we forget about PEPs for the moment. =20 >=20 > Use IPsec but mark the packets using DSCPs kept in the clear. Consider > traffic analysis...sit back and watch the codepoints (lots of high prio= rity > MLEF?) >=20 > " > * Security UP =3D>=C2=AD Bandwidth Utilization DOWN > * Security UP =3D>=C2=AD Performance DOWN > * Tunnels Tunnels Tunnels and more Tunnels > * Performance DOWN =3D> Security DOWN > =3D> User turns OFF Security to make system usable! > * Thus, we need more bandwidth to ensure security. > " > http://spacecom.grc.nasa.gov/icnsconf/docs/2002/10/Session_E1-5_Ivancic= .pdf >=20 > I think one makes the choices that best fit because there is no free lu= nch. > :-( --=20 b _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Dec 22 17:16:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09647 for ; Mon, 22 Dec 2003 17:16:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYYLo-00030i-AK for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 17:16:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMMGWYT011572 for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 17:16:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYYLo-00030Z-3m for ieprep-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 17:16:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09594 for ; Mon, 22 Dec 2003 17:16:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYYLl-0006aV-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 17:16:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYYIm-0006Ah-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 17:16:25 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AYXOg-0004BZ-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 16:15:26 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AYXOM-0001rJ-DP for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 16:15:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYXOJ-0001Qv-16; Mon, 22 Dec 2003 16:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYXO1-0001On-2K for ieprep@optimus.ietf.org; Mon, 22 Dec 2003 16:14:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08116 for ; Mon, 22 Dec 2003 16:14:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYXNw-0004FK-00 for ieprep@ietf.org; Mon, 22 Dec 2003 16:14:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYXIX-00045h-00 for ieprep@ietf.org; Mon, 22 Dec 2003 16:12:29 -0500 Received: from kc-msxproto3.kc.umkc.edu ([134.193.143.160]) by ietf-mx with esmtp (Exim 4.12) id 1AYXIM-00045R-00 for ieprep@ietf.org; Mon, 22 Dec 2003 16:08:55 -0500 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 22 Dec 2003 14:55:51 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ieprep] TCP PEPs and Priority-based Mechanisms Date: Mon, 22 Dec 2003 14:55:50 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011081F0@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] TCP PEPs and Priority-based Mechanisms Thread-Index: AcPIxRQLgO1Kdof8TtqG1sNvNNuyLAABY/Ji From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Rex Buddenberg" , "King, Kimberly S." Cc: "Ieprep \(E-mail\)" X-OriginalArrivalTime: 22 Dec 2003 20:55:51.0635 (UTC) FILETIME=[FBE38A30:01C3C8CD] Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > Actually you hit the one compelling reason, IMHO, for shifting to = IPv6. > Note that I'm here at the network layer, not transport. IPv6 supports > header extensions -- the extension+payload get encrypted but the base > header (which includes DSCP) does not. So any network level QoS you > choose to use is unaffected by IPSec. =20 This will lead to denial of QoS attacks. One can easily change the=20 subscription by modifying the headers. But, lets first see some=20 flow-label enabled packets across the Internet to talk about the=20 operational security implications. btw, one can still encrypt=20 flow-labels using tunnel mode. please read the recently approved proposed standard ( IPv6 flow label spec) > Back at the transport layer, I'm just not terribly turned on by PEPs. > The RFC is useful because it surveys a fairly wide set of bandaids = that > fall under the general PEP category. But these remain bandaids until > we grapple with the nextgen transport protocol issue. =20 nextgen transport protocol? DCCP is not a next generation protocol; it=20 just provides option for various cc profiles, mibility and multihoming support and security features. As for tranport, incremental approach by=20 TCP extenstions works better (e.g., widespread SACK deployment.) The one = you mention, XCP does major changes; its a interesting research work but = support for high speed networks is not a pressing problem. In short, we=20 will never see any nextgen transport protocol. =20 btw, protocol boosters like PEP are not paper model; they have seen a = lot=20 of deployment. So, we should know to live with them. We have came a long way from the pilc work.=20 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Dec 22 18:07:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15334 for ; Mon, 22 Dec 2003 18:07:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZ8X-0005K3-2k for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 18:06:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMN6rok020453 for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 18:06:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZ8W-0005Jo-Up for ieprep-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 18:06:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15142 for ; Mon, 22 Dec 2003 18:06:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYZ8T-0004kJ-01 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 18:06:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYZ6k-0004iP-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 18:05:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYZ6k-0004iM-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 18:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZ6l-00055V-CN; Mon, 22 Dec 2003 18:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZ5p-00052w-TJ for ieprep@optimus.ietf.org; Mon, 22 Dec 2003 18:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14688 for ; Mon, 22 Dec 2003 18:04:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYZ5m-0004Zp-00 for ieprep@ietf.org; Mon, 22 Dec 2003 18:04:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYZ1t-0003jS-00 for ieprep@ietf.org; Mon, 22 Dec 2003 18:00:02 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AYZ1t-0003cp-00 for ieprep@ietf.org; Mon, 22 Dec 2003 18:00:01 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Dec 2003 15:03:44 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBMMxTJ6008802 for ; Mon, 22 Dec 2003 14:59:29 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA11484 for ; Mon, 22 Dec 2003 14:59:29 -0800 (PST) Message-Id: <4.3.2.7.2.20031222165900.026d7278@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Dec 2003 16:59:30 -0600 To: ieprep@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] test, please ignore Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 testing 1 2 3 cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Dec 22 18:15:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16543 for ; Mon, 22 Dec 2003 18:15:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZGR-0005tM-MB for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 18:15:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMNF33i022642 for ieprep-archive@odin.ietf.org; Mon, 22 Dec 2003 18:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZGR-0005t7-Hh for ieprep-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 18:15:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16458 for ; Mon, 22 Dec 2003 18:14:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYZGO-0005Gr-01 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 18:15:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYZDT-0005Bn-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 18:12:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYZDT-0005Bk-00 for ieprep-web-archive@ietf.org; Mon, 22 Dec 2003 18:11:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZDV-0005nS-3D; Mon, 22 Dec 2003 18:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYZCb-0005mU-18 for ieprep@optimus.ietf.org; Mon, 22 Dec 2003 18:11:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15917 for ; Mon, 22 Dec 2003 18:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYZCY-00057x-00 for ieprep@ietf.org; Mon, 22 Dec 2003 18:11:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYZAB-0004wK-00 for ieprep@ietf.org; Mon, 22 Dec 2003 18:08:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AYZAB-0004uX-00 for ieprep@ietf.org; Mon, 22 Dec 2003 18:08:35 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 22 Dec 2003 23:09:27 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBMN82Qu012697; Mon, 22 Dec 2003 15:08:03 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA25427; Mon, 22 Dec 2003 15:08:01 -0800 (PST) Message-Id: <4.3.2.7.2.20031222170740.02152380@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Dec 2003 17:08:02 -0600 To: Rex Buddenberg From: "James M. Polk" Subject: RE: [Ieprep] TCP PEPs and Priority-based Mechanisms Cc: "Ieprep (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable At 11:50 AM 12/22/2003 -0800, Rex Buddenberg wrote: >Kimberly, > >Actually you hit the one compelling reason, IMHO, for shifting to IPv6. >Note that I'm here at the network layer, not transport. IPv6 supports >header extensions -- the extension+payload get encrypted but the base >header (which includes DSCP) does not. So any network level QoS you >choose to use is unaffected by IPSec. How does IPv6 behave differently than v4 with respect to IPsec? What do you do to limit or prevent remarking DSCPs to mean something other= =20 than what the sender (or domain at the edge) legitimately mean? In other words, where is the integrity protection for DSCP marking? Where=20 is the authorization mechanism for DSCP marking? How do you prevent an eavesdropper from looking for the pattern of packets= =20 (perhaps with the same length) occurring every 20ms or so to see if a=20 particular stream is a call or not (perhaps to do something to that stream= =20 - or just the IPv4 or v6 header to muck with it (like change the DSCP= value))? >Back at the transport layer, I'm just not terribly turned on by PEPs. >The RFC is useful because it surveys a fairly wide set of bandaids that >fall under the general PEP category. But these remain bandaids until >we grapple with the nextgen transport protocol issue. > > >On Mon, 2003-12-22 at 11:16, King, Kimberly S. wrote: > > > The use of Performance Enhancing Proxies introduces several issues > > > which impact security. > > > > Yes, you are right to point that out but unfortunately that's just the= way > > it is. Even if we forget about PEPs for the moment. > > > > Use IPsec but mark the packets using DSCPs kept in the clear. Consider > > traffic analysis...sit back and watch the codepoints (lots of high= priority > > MLEF?) > > > > " > > * Security UP =3D>=C2=AD Bandwidth Utilization DOWN > > * Security UP =3D>=C2=AD Performance DOWN > > * Tunnels Tunnels Tunnels and more Tunnels > > * Performance DOWN =3D> Security DOWN > > =3D> User turns OFF Security to make system usable! > > * Thus, we need more bandwidth to ensure security. > > " > >= http://spacecom.grc.nasa.gov/icnsconf/docs/2002/10/Session_E1-5_Ivancic.pdf > > > > I think one makes the choices that best fit because there is no free= lunch. > > :-( >-- >b > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Dec 23 09:59:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22302 for ; Tue, 23 Dec 2003 09:59:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYo05-0002Uk-Nu for ieprep-archive@odin.ietf.org; Tue, 23 Dec 2003 09:59:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNEx9vH009584 for ieprep-archive@odin.ietf.org; Tue, 23 Dec 2003 09:59:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYo05-0002UV-JA for ieprep-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 09:59:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22239 for ; Tue, 23 Dec 2003 09:59:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYo03-0000xZ-00 for ieprep-web-archive@ietf.org; Tue, 23 Dec 2003 09:59:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYnx6-0000sa-00 for ieprep-web-archive@ietf.org; Tue, 23 Dec 2003 09:56:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYnx6-0000sX-00 for ieprep-web-archive@ietf.org; Tue, 23 Dec 2003 09:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYnx6-00027V-MU; Tue, 23 Dec 2003 09:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYnwR-00024u-F7 for ieprep@optimus.ietf.org; Tue, 23 Dec 2003 09:55:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22027 for ; Tue, 23 Dec 2003 09:55:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYnwP-0000It-00 for ieprep@ietf.org; Tue, 23 Dec 2003 09:55:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYniR-0000Fj-00 for ieprep@ietf.org; Tue, 23 Dec 2003 09:40:56 -0500 Received: from mailgw1a.lmco.com ([192.31.106.7]) by ietf-mx with esmtp (Exim 4.12) id 1AYniQ-0000El-00 for ieprep@ietf.org; Tue, 23 Dec 2003 09:40:55 -0500 Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54]) by mailgw1a.lmco.com (8.12.10/8.12.10) with ESMTP id hBNEeGTZ015115; Tue, 23 Dec 2003 07:40:16 -0700 (MST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HQC00201RF4XD@lmco.com>; Tue, 23 Dec 2003 07:40:16 -0700 (MST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HQC006O0RF2J0@lmco.com>; Tue, 23 Dec 2003 07:40:15 -0700 (MST) Received: from EMSS09M02.us.lmco.com ([158.183.26.5]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 23 Dec 2003 09:40:15 -0500 Date: Tue, 23 Dec 2003 09:40:14 -0500 From: "Eagan, Christopher" Subject: RE: [Ieprep] TCP PEPs and Priority-based Mechanisms To: "James M. Polk" , Rex Buddenberg Cc: "Ieprep (E-mail)" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-Topic: [Ieprep] TCP PEPs and Priority-based Mechanisms Thread-Index: AcPI4VBh1oZATeJOQ7WTCxXezJx+CAAfLxeg content-class: urn:content-classes:message X-OriginalArrivalTime: 23 Dec 2003 14:40:15.0297 (UTC) FILETIME=[AD990310:01C3C962] Content-Transfer-Encoding: 7BIT Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > What do you do to limit or prevent remarking DSCPs to mean > something other > than what the sender (or domain at the edge) legitimately mean? 1. In some scenarios can you assume all nodes are trusted to behave well (possibly by virtue of them being able to encrypt/decrypt at a lower network layer - "they can speak on this encrypted link layer therefore I trust them at the higher layers")? Obviously this does not satisfy the problems for security purely in the internet layer but may be practical. 2. Has anyone considered dynamic and pseudo-random codepoints? Ingress nodes sharing time-based pseudo-randomly sequenced dscp->traffic class mappings - starting values updated periodically generated from a real random sequence? This will promote the precedence of some packets that should not be promoted but all in all could work? Anybody looked at this? Too organizationally infeasible for IANA perhaps? > In other words, where is the integrity protection for DSCP > marking? Where > is the authorization mechanism for DSCP marking? > How do you prevent an eavesdropper from looking for the > pattern of packets > (perhaps with the same length) occurring every 20ms or so to see if a The issues of unencrypted headers being altered and traffic analysis are not unique to dscp's. Again these can both be solved by requiring lower layer bulk encryption and requiring lower layers to send random junk when there is no legitimate traffic (so the observer sees a random stream of bits at all times independent of the actual traffic). Not satisfying the security requirements in the internet layer but may be most practical solution. Chris _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep