From amela at advanced.org Mon Jul 2 07:57:11 2001 From: amela at advanced.org (Amela Sadagic) Date: Thu Mar 25 12:00:11 2004 Subject: [e2e] Internet2 Fellowship on Application QoS Needs Message-ID: <5.1.0.14.0.20010702105523.00a20ec0@mailhost.advanced.org> Application QoS Needs Design Group is one of 5 design groups within QoS Internet2 Working Group and we would like to announce a fellowship that we envisaged as a part of our activities. Please would you be so kind to forward this announcement to any individual or relevant group that you might be associated with. More information about the Design Group can be obtained on our web pages: http://www.internet2.edu/qos/wg/apps/ best, Amela ----------------------------------------------------- Internet2 Fellowship on Application QoS Needs We announce Internet2 Fellowship which has been established to study and document applications QoS needs. Specifically, the recipient of this fellowship will be requested to produce a survey paper and create a framework for the ongoing analysis and documentation of the relationship between the needs of advanced Internet2 applications and new network services being deployed by Internet2. This is a Fall/short-term fellowship, and only one grant is available. Applicants can be masters or doctoral students or faculty members in computer science or a related field. The applicant must be available for six months in order to complete the expected document. The fellowship will pay $10,000. To apply for this fellowship, applicants should send email to: fellowship@internet2.edu Full text of the announcement can be found at: http://www.internet2.edu/qos/wg/apps/Documents/fellowship.html ------------------------------------------------------------ ~~~~~~~~~~ Amela Sadagic amela@advanced.org Advanced Network & Services ph/office : +1 914 765 8316 200 Business Park Drive fax: +1 914 765 8317 Armonk, NY 10504, USA http://www.advanced.org/teleimmersion.html http://www.thinkquest.org http://www.advanced.org/~amela From aaa at cs.stanford.edu Tue Jul 3 12:18:50 2001 From: aaa at cs.stanford.edu (Amr A. Awadallah) Date: Thu Mar 25 12:00:11 2004 Subject: [e2e] Pointers to dynamic content delivery research. Message-ID: <3B421A9A.E2508380@cs.stanford.edu> Hi, I am looking for pointers to previous research work in the area of dynamic interactive content delivery, i.e. how can services be moved closer to demand hot spots, e.g. maps.yahoo.com is a dynamic interactive service for which caching the map static image returned is useless since each user is looking at a different map, but the underlying server code and geo database could be cached since it is the same for all users. The hard part is providing mobility for such a service given all code dependencies it might have. There is a bunch of companies out there working on this problem (a brief list attached at end of this e-mail), but I am looking for published academic research in this field. Thanks and have a happy 4th, -- Amr On Demand Hosting: http://www.ejasent.com (Solaris OS Virtualization) http://www.latis.com (???) http://www.terraspring.com (???) http://www.ensim.com (Linux OS Virtualization) Dynamic Content Delivery: http://www.navisite.com/news/press2.cfm?release_id=191&pages=press http://www.platespin.com (Service Disk) http://www.openmarket.com (Satellite Server) http://www.appstream.com http://www.akamai.com/html/en/sv/edgesuite_over.html (Edge Suite) http://www.digitalisland.com (now C&W, ???) http://www.mirror-image.com http://www.inktomi.com http://www.cacheflow.com http://www.interwoven.com/products/cexpress/ http://www.vignette.com/CDA/Site/0,2097,1-1-1329-2067-1337-2186,00.html http://www.circadence.com/default.asp?T=2&M=1 http://www.spidercache.com/Home.asp?mainnodeid=196 http://www.xcache.com/home/ From mbeck at cs.utk.edu Tue Jul 3 12:58:59 2001 From: mbeck at cs.utk.edu (Micah Beck) Date: Thu Mar 25 12:00:11 2004 Subject: [e2e] Pointers to dynamic content delivery research. References: <3B421A9A.E2508380@cs.stanford.edu> Message-ID: <017401c103fa$9ae99070$0501a8c0@cs.utk.edu> Amr, I recommend you look at the paper entitled "Enabling Full Service Surrogates Using the Portable Channel Representation" by Beck, Moore, Abrahamsson, Achouiantz and Johansson that appeared in the 10th Intl. WWW Conference (http://www.www10.org/cdrom/papers/212/index.html). The Portable Channel Representation (PCR) is an outgrowth of the Internet Distributed Storage Initiative (I2-DSI), an academic project that I lead, and which involves researchers in Content Distribution at the Universities of Tennessee and North Carolina, and infrastructure and content partners at a number of other institutions (http://dsi.internet2.edu). We are currently seeking to provide support for Digital Library projects with active services among others. Note: the term "dynamic content" is used in the industry to mean cacheable Web content that simply changes very often, and may require server-driven invalidation. Services that are provided by scripts and programs and that are uncachable due to the need for processing present a different problem, so I refer to these as "active services" or "active content". This avoids confusion. I2-DSI predates many of the companies in the Content Distribution field, and differs from most other efforts in that it has focused on mirroring of active services rather than simple caching of static content. The Portable Channel Representation is a mechnaism for specifying a copy of a service, capturing not only source objects but also associated service metadata. PCR is intended as an open interface, and is under continued development at the University of Tennessee. If you have an interest in working on this problem, you might want to consider using PCR as a tool or seeking a collaboration with the I2-DSI project. We have plans to make an open source Java version of a simple content distribution framework based on PCR available to the public. Full disclosure: PCR is used as the basis for a commercial Content Distribution product, developed by Lokomo Systems, a company of which I am Chief Scientist (http://www.lokomo.com). Lokomo Systems is commited to preserving PCR as an open interface, and may collaborate in the open source project. Micah Beck Research Associate Professor Innovative Computing Laboratory University of Tennessee ----- Original Message ----- From: "Amr A. Awadallah" To: Sent: Tuesday, July 03, 2001 3:18 PM Subject: [e2e] Pointers to dynamic content delivery research. > > Hi, > > I am looking for pointers to previous research work in the area of dynamic > interactive content delivery, i.e. how can services be moved closer to demand > hot spots, e.g. maps.yahoo.com is a dynamic interactive service for which > caching the map static image returned is useless since each user is looking at > a different map, but the underlying server code and geo database could be > cached since it is the same for all users. The hard part is providing mobility > for such a service given all code dependencies it might have. > > There is a bunch of companies out there working on this problem (a brief > list attached at end of this e-mail), but I am looking for published academic > research in this field. > > Thanks and have a happy 4th, > > -- Amr > > On Demand Hosting: > http://www.ejasent.com (Solaris OS Virtualization) > http://www.latis.com (???) > http://www.terraspring.com (???) > http://www.ensim.com (Linux OS Virtualization) > > Dynamic Content Delivery: > http://www.navisite.com/news/press2.cfm?release_id=191&pages=press > http://www.platespin.com (Service Disk) > http://www.openmarket.com (Satellite Server) > http://www.appstream.com > http://www.akamai.com/html/en/sv/edgesuite_over.html (Edge Suite) > http://www.digitalisland.com (now C&W, ???) > http://www.mirror-image.com > http://www.inktomi.com > http://www.cacheflow.com > http://www.interwoven.com/products/cexpress/ > http://www.vignette.com/CDA/Site/0,2097,1-1-1329-2067-1337-2186,00.html > http://www.circadence.com/default.asp?T=2&M=1 > http://www.spidercache.com/Home.asp?mainnodeid=196 > http://www.xcache.com/home/ > From anoop at cosinecom.com Tue Jul 3 18:39:04 2001 From: anoop at cosinecom.com (Anoop Ghanwani) Date: Thu Mar 25 12:00:11 2004 Subject: [e2e] Windows NT implementation of TCP Message-ID: <6CECAF1A722ED842B24EC8EDA5B07604019F18@exchsrv4> First, apologies if it's not appropriate to be asking a question like this. I was trying to find out what flavor of TCP Windows NT 4.0 uses. Specifically, I'm trying to find out if it uses fast retransmit. Thanks, -Anoop -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20010703/ffc2aa61/attachment.html From mahesh at erg.abdn.ac.uk Wed Jul 4 03:53:33 2001 From: mahesh at erg.abdn.ac.uk (Mahesh Sooriyabandara) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Windows NT implementation of TCP References: <6CECAF1A722ED842B24EC8EDA5B07604019F18@exchsrv4> Message-ID: <3B42F5AC.944F0063@erg.abdn.ac.uk> I had a link to a white paper from Microsoft which describes the NT5.0 TCP implementation. Apparently page is no longer there. But answer to your question from that document is " By default, Windows NT 5.0 resends a segment if it receives three ACKs for the same sequence number, and that sequence number lags the current one. This is controllable with the TcpMaxDupAcks registry parameter" It has fast retransmit. Cheers, Mahesh. Anoop Ghanwani wrote: > > > First, apologies if it's not appropriate to be asking > a question like this. I was trying to find out what > flavor of TCP Windows NT 4.0 uses. Specifically, I'm > trying to find out if it uses fast retransmit. > > Thanks, -Anoop -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20010704/95d75c43/attachment.html From freedom at csie.nctu.edu.tw Wed Jul 4 11:57:03 2001 From: freedom at csie.nctu.edu.tw (Tan Koan-Sin) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Windows NT implementation of TCP In-Reply-To: <6CECAF1A722ED842B24EC8EDA5B07604019F18@exchsrv4>; from anoop@cosinecom.com on Tue, Jul 03, 2001 at 06:39:04PM -0700 References: <6CECAF1A722ED842B24EC8EDA5B07604019F18@exchsrv4> Message-ID: <20010705025703.A46201@magpie.csie.nctu.edu.tw> NT 4.0 doesn't support fast retransmit and fast recovery before Service Pack 2. But, why you still stick with NT 4.0. Windows 2000 comes with fast retransmit, fast recovery and SACK. On Tue, Jul 03, 2001 at 06:39:04PM -0700, Anoop Ghanwani wrote: > First, apologies if it's not appropriate to be asking > a question like this. I was trying to find out what > flavor of TCP Windows NT 4.0 uses. Specifically, I'm > trying to find out if it uses fast retransmit. From michael at tk.uni-linz.ac.at Thu Jul 5 03:33:56 2001 From: michael at tk.uni-linz.ac.at (Michael Welzl) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Congestion control decision frequency + scaling of related signaling Message-ID: Hi all, One major issue of Explicit Rate (and any other congestion control related) signaling is its scalability: whether it is designed for edge2edge or end2end usage, it must remain scalable. Some key factors are obvious: - treatment of ER signaling packets in routers must be very efficient - per flow state (or even flow counting) in routers should definitely be avoided Another important factor is the amount of packets. It is well known that adapting the sending rate faster than once per RTT can lead to oscillations whereas adapting slower can lead to "unresponsive behaviour". So the RTT (SRTT) could be seen as an optimal choice for any congestion control related signaling / decision frequency. There are two problems I have with that: 1.) Shouldn't the optimal decision frequency for congestion control generally be 2 RTT instead of 1 RTT? Here's a quote from "Congestion Avoidance in Computer Networks With a Connectionless Network Layer", Raj Jain / K. K. Ramakrishnan / Dah-Ming Chiu: "System control theory tells us that the optimal control frequency depends upon the feedback delay - the time between applying a control (change window) and getting feedback (bits) from the network corresponding to this control. In computer networks, it takes one round-trip delay to affect the control, that is, for the new window to take effect and another round-trip delay to get the resulting change fed back from the network to the users. This leads us to the recommendation that windows should be adjusted once every two round-trip delays (two window turns) (..)." 2.) A common method to make signaling scale is to make its traffic a certain percentage of a network node's generated traffic (or the related traffic). For a network wide given value (say 30% of the traffic), the overall signaling traffic in the network then does not exceed this percentage. This method is used in some experimental ABR schemes and in RTP / RTCP. But what is a reasonable value? Cheers, Michael From touch at ISI.EDU Thu Jul 5 09:50:51 2001 From: touch at ISI.EDU (Joe Touch) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Congestion control decision frequency + scaling of related signaling References: Message-ID: <3B449AEB.989A093B@isi.edu> Michael Welzl wrote: > > Hi all, > > One major issue of Explicit Rate (and any other congestion control > related) signaling is its scalability: whether it is designed for > edge2edge or end2end usage, it must remain scalable. > > Some key factors are obvious: > - treatment of ER signaling packets in routers must be very efficient > - per flow state (or even flow counting) in routers should definitely > be avoided > > Another important factor is the amount of packets. It is well known > that adapting the sending rate faster than once per RTT can lead to > oscillations whereas adapting slower can lead to "unresponsive behaviour". > So the RTT (SRTT) could be seen as an optimal choice for any congestion > control related signaling / decision frequency. > > There are two problems I have with that: > > 1.) Shouldn't the optimal decision frequency for congestion control > generally be 2 RTT instead of 1 RTT? > > Here's a quote from "Congestion Avoidance in Computer Networks With > a Connectionless Network Layer", Raj Jain / K. K. Ramakrishnan / > Dah-Ming Chiu: > "System control theory tells us that the optimal control frequency > depends upon the feedback delay - the time between applying a control > (change window) and getting feedback (bits) from the network > corresponding to this control. In computer networks, it takes one > round-trip delay to affect the control, that is, for the new window > to take effect and another round-trip delay to get the resulting > change fed back from the network to the users. This leads us to > the recommendation that windows should be adjusted once every two > round-trip delays (two window turns) (..)." Define decision frequency :-) at time T (zero) - you 'see' a picture of network state out to the endpoint, 1 RTT into the past you act on that picture (proactive) to effect a change at time T + 1 RTT - you 'see' 1 RTT into the past again, this time seeing everyone else's state _at the time you make your action decision_. you don't see the effect of your actions just yet, but you can update your actions if desired at time T + 2 RTTs - you see the effect of your actions (2 RTTs after you make them). I.e., you're always 1 RTT out of synch with network state, and 2 RTTs out of synch with seeing everyone else's actions on your actions. You still have to _ACT_ at time T+1RTT to see the effect of your actions at time T+2RTTs. There are decisions at time T+1 and at time T+2. At any given T, you see network state 1 RTT into the past you see the result of your behavior 2 RTTs into the past As a result, you should wait 1 RTT to act on network state alone (loss, router congestion that you think you did not create, route changes, etc), and 2 RTTs to correct your own behavior (if you think you caused the problem). The decision frequency thus should depend on what you're reacting to... Joe From jeevandra at swift.ee.umist.ac.uk Thu Jul 5 10:54:55 2001 From: jeevandra at swift.ee.umist.ac.uk (Jeevandra) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Packet transmission timer Message-ID: <001b01c1057b$9a264480$f7745882@ee.umist.ac.uk> Hi there, I am a research student trying to develop a rate-based protocol to stream video over the internet. I have encountered an implementation problem which I am hoping that someone from this mailing list could advise me on. In a rate based transport scheme, the inter packet gap is fixed according to the rate at which we want to deliver the packets. I do realise that for, say, MBits/s transmission of 1000 bytes packet size, this inter packet gap will be somewhere around milliseconds or less. But most OSs are not able to provide that of a high timer resolution. I am only able to obtain at most a 10ms granularity. This is certainly insufficient but I am sure people have worked around this constraint. I was just wondering if there is anyone on the list who could advise me on this. What is the most common implementation technique of the timer for these rate control method? How do I achieve MBits/s delivery rate on a Windows platform or a Linux platform? I thank you in advance. Regards, Jeevandra -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20010705/7b95cb41/attachment.html From michael at tk.uni-linz.ac.at Thu Jul 5 22:21:29 2001 From: michael at tk.uni-linz.ac.at (Michael Welzl) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Congestion control decision frequency + scaling of related signaling In-Reply-To: Message-ID: > > 1.) Shouldn't the optimal decision frequency for congestion control > > generally be 2 RTT instead of 1 RTT? (..) > Define decision frequency :-) > > at time T (zero) - > you 'see' a picture of network state > out to the endpoint, 1 RTT into the past > > you act on that picture (proactive) to > effect a change > > at time T + 1 RTT - > you 'see' 1 RTT into the past again, this time > seeing everyone else's state _at the time > you make your action decision_. > > you don't see the effect of your actions just yet, > but you can update your actions if desired > > at time T + 2 RTTs - > you see the effect of your actions (2 RTTs > after you make them). > > I.e., you're always 1 RTT out of synch with network state, and > 2 RTTs out of synch with seeing everyone else's actions on your > actions. > > You still have to _ACT_ at time T+1RTT to see the effect > of your actions at time T+2RTTs. There are decisions at > time T+1 and at time T+2. At any given T, > > you see network state 1 RTT into the past > > you see the result of your behavior 2 RTTs into the past > > As a result, you should wait 1 RTT to act on network > state alone (loss, router congestion that you think you > did not create, route changes, etc), and 2 RTTs to > correct your own behavior (if you think you caused the problem). > > The decision frequency thus should depend on what you're > reacting to... That definitely made it clear for me. Joe, thanks a lot for this explanation - things are sometimes simpler than they seem :) When I asked, I had the somewhat unreal homogeneous RTT case in mind - because, if everyone acted each RTT (and not every other RTT), each sender would react to the network state, not taking its own behaviour into account. So it seems as though acting every RTT would not scale. But that's probably different for the real-life heterogeneous RTT case, where you have a mixture of senders acting at various RTT's... hmmmm... now that I think of it .... is it really? Does acting every RTT scale? Wouldn't it be generally better if all TCP's would correct their rates every two RTT's? Cheers, Michael From luigi at info.iet.unipi.it Fri Jul 6 04:09:05 2001 From: luigi at info.iet.unipi.it (Luigi Rizzo) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Packet transmission timer In-Reply-To: <001b01c1057b$9a264480$f7745882@ee.umist.ac.uk> from Jeevandra at "Jul 5, 2001 06:54:55 pm" Message-ID: <200107061109.NAA75885@info.iet.unipi.it> > > In a rate based transport scheme, the inter packet gap is fixed > according to the rate at which we want to deliver the packets. I > do realise that for, say, MBits/s transmission of 1000 bytes packet > size, this inter packet gap will be somewhere around milliseconds > or less. But most OSs are not able to provide that of a high timer > resolution. I am only able to obtain at most a 10ms granularity. > This is certainly insufficient but I am sure people have worked > around this constraint. I was just wondering if there is anyone on > the list who could advise me on this. What is the most common > implementation technique of the timer for these rate control method? > How do I achieve MBits/s delivery rate on a Windows platform or a > Linux platform? I thank you in advance. as long as you make sure not to accumulate the scheduling errors, (basically, read the clock after sleeping and see how much you should really send), you will have some burstiness in the output. This is the best you can do given the timer limitations and unless you want to do busy waiting (or you can do something useful betwen the transmission of subsequent packets, which can be a meaningful options if e.g. you have also to encode the content you are going to transmit). I guess on most unixes you can tweak the timer granularity by recompiling a kernel with a different value for the HZ variable. cheers luigi From lazzaro at CS.Berkeley.EDU Fri Jul 6 11:53:23 2001 From: lazzaro at CS.Berkeley.EDU (John Lazzaro) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Packet transmission timer Message-ID: <200107061853.LAA21317@snap.CS.Berkeley.EDU> > Jeevandra writes > > or less. But most OSs are not able to provide that of a high timer > resolution. I am only able to obtain at most a 10ms granularity. There's a trick that works under Linux that comes out of the audio world, and so it only works if there is a soundcard in your machine and you have the OSS or ALSA drivers installed, that lets you do significantly better than 10ms. The way these audio API's work, at start time you have the option of creating a small pool of "fragment" buffers -- 4 buffers of 64 bytes each, for example. For 44100Hz mono 16 bit audio, a fragment holds 0.725ms of sound, and the 4 fragments together hold about 3ms of sound. Once you've created the fragment pool, you can write() to the sound card device, and either one of two things happen: -- There's a fragment free in the pool. If so, the data you write is copied to the fragment, which is then taken out of the pool and queued for playback to the soundcard, and the write() returns immediately. -- There's no fragments left in the pool -- because you've done a bunch of write() calls in succession, and so the playback queue is filled with all the fragments. In this case, the write() blocks, until the sound driver is finished playing out the lead fragment in the queue (which takes 0.725ms), and then unblocks. Given this behavior, you can write a simple "dummy" audio app, that sets up a fragment pool at the start of the fragment, and then does a set of quick write()'s to use up all the fragments (in our example 4). It then does a 5th write, which in effect will act as a 0.725ms timer. In this scenareo, everything else in your program is carefully designed to be non-blocking. Audio apps that do low-latency work under Linux (for example, music synthesis programs that are controlled by a MIDI keyboard) use this technique to get acceptably low latency. A few things to note: -- This is most reliable when you use real-time POSIX scheduling, and run the process in SCHED_FIFO. -- This is different than just calling a function like nanosleep(), because the process is really blocking during that 0.725ms -- you can run a program like this under X just fine, and maintain full cursor and window control, whereas running a SCHED_FIFO process with nanosleep() calls for timing and no other blocking would lock the mouse and keyboard until the process ended. -- You can query the soundcard using ioctl()'s to track the total number of fragments written during the lifetime of the program. You can use this a clock, and you can double check the number against the gettimeofday() clock to catch any catastrophes that led to an overrun, and compensate accordingly. The success of this technqiue ultimately lies in the ability of the kernel to deliver good SCHED_FIFO scheduling performance -- to quickly note when the soundcard driver unblocks, and hand control back to the SCHED_FIFO process. There's a relatively short list of "things not to do" if you want this to work reliably under Linux -- and if you're willing to install the special "low-latency kernel patches", the list gets even shorter. There's a community devoted to these sorts of techniques: http://www.linuxdj.com/audio/lad/resources.php3 for more details on how to make this actually work for you. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From dovrolis at mail.eecis.udel.edu Sat Jul 7 13:39:09 2001 From: dovrolis at mail.eecis.udel.edu (Constantinos Dovrolis) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Packet transmission timer In-Reply-To: <200107061853.LAA21317@snap.CS.Berkeley.EDU> Message-ID: John, We had done something similar in Solaris 2.6 a couple of years ago, trying to get fine-grained timeouts, not limited by the clock interrupt period. Actually, the main focus of that study was to examine the overhead involved in decreasing the clock interrupt period from 10msec to 1msec, and the corresponding improvement that results in the accuracy of synchronous execution. A report for anyone interested in this kind of stuff can be found at: http://www.cis.udel.edu/~dovrolis/Papers/timers.ps The trick with the audio card was also what we were doing to get accurate sub-millisecond timeouts. Of course, if you decrease the timeout period too much, the audio interrupt overhead becomes noticeable. Solaris comes with a 1msec clock interrupt these days, so our study is kind of obsolete I guess.. Constantinos Computer and Information Sciences - University of Delaware http://www.cis.udel.edu/~dovrolis/ On Fri, 6 Jul 2001, John Lazzaro wrote: > > > Jeevandra writes > > > > or less. But most OSs are not able to provide that of a high timer > > resolution. I am only able to obtain at most a 10ms granularity. > > There's a trick that works under Linux that comes out of the audio > world, and so it only works if there is a soundcard in your machine > and you have the OSS or ALSA drivers installed, that lets you do > significantly better than 10ms. > > The way these audio API's work, at start time you have the option > of creating a small pool of "fragment" buffers -- 4 buffers of 64 > bytes each, for example. For 44100Hz mono 16 bit audio, a fragment > holds 0.725ms of sound, and the 4 fragments together hold about 3ms > of sound. > > Once you've created the fragment pool, you can write() to the sound > card device, and either one of two things happen: > > -- There's a fragment free in the pool. If so, the data you write > is copied to the fragment, which is then taken out of the pool and > queued for playback to the soundcard, and the write() returns > immediately. > > -- There's no fragments left in the pool -- because you've done a > bunch of write() calls in succession, and so the playback queue > is filled with all the fragments. In this case, the write() blocks, > until the sound driver is finished playing out the lead fragment > in the queue (which takes 0.725ms), and then unblocks. > > Given this behavior, you can write a simple "dummy" audio app, > that sets up a fragment pool at the start of the fragment, and > then does a set of quick write()'s to use up all the fragments > (in our example 4). It then does a 5th write, which in effect > will act as a 0.725ms timer. In this scenareo, everything else > in your program is carefully designed to be non-blocking. Audio > apps that do low-latency work under Linux (for example, music > synthesis programs that are controlled by a MIDI keyboard) use > this technique to get acceptably low latency. A few things to > note: > > -- This is most reliable when you use real-time POSIX scheduling, > and run the process in SCHED_FIFO. > > -- This is different than just calling a function like nanosleep(), > because the process is really blocking during that 0.725ms -- > you can run a program like this under X just fine, and maintain > full cursor and window control, whereas running a SCHED_FIFO > process with nanosleep() calls for timing and no other blocking > would lock the mouse and keyboard until the process ended. > > -- You can query the soundcard using ioctl()'s to track the > total number of fragments written during the lifetime of the > program. You can use this a clock, and you can double check > the number against the gettimeofday() clock to catch any > catastrophes that led to an overrun, and compensate accordingly. > > > The success of this technqiue ultimately lies in the ability of > the kernel to deliver good SCHED_FIFO scheduling performance -- > to quickly note when the soundcard driver unblocks, and hand > control back to the SCHED_FIFO process. There's a relatively > short list of "things not to do" if you want this to work > reliably under Linux -- and if you're willing to install the > special "low-latency kernel patches", the list gets even shorter. > > There's a community devoted to these sorts of techniques: > > http://www.linuxdj.com/audio/lad/resources.php3 > > for more details on how to make this actually work for you. > > ------------------------------------------------------------------------- > John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley > lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro > ------------------------------------------------------------------------- > From julian_satran at il.ibm.com Sun Jul 8 23:54:09 2001 From: julian_satran at il.ibm.com (julian_satran@il.ibm.com) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] time for a presentation layer? Message-ID: There are at least to reason why an IP option (even in the disgust of a separate protocol header between IP and transport) looks better: available for any transport can be implemented with intercept code (bump in the stack) instead of changing code And several disadvantages: Negotiation in-band is difficult to sync (like IKE and IPSec) (not impossible though) Negotiation out-of-band requires (probably) a separate protocol Julo "Eric A. Hall" on 08-07-2001 19:50:51 Please respond to "Eric A. Hall" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: [e2e] time for a presentation layer? julian_satran@il.ibm.com wrote: > > Except for data typing - all could be glued in existing protocols. > I've attempted to start a "thread" on this with: > http://search.ietf.org/internet-drafts/draft-satran-transport-adaptation-framework-00.txt A couple of thoughts on this. First, there needs to be some sort of protocol specification for the representation, interpretation and handling of codes, both during the session-establishment phase and dynamically during an existing session. EG, if a socket is already established, how is it modified, what are the handling requirements for half- vs full-duplex option negotiation, etc. Secondarily (and larger), I think this approach would be most useful if it were an option in the transport headers rather than out-of-band messages. This is particularly true for in-process negotiation. But since UDP doesn't have any option space, I don't see how it would be possible to implement this in that way. Perhaps a separate TCP control channel? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From julian_satran at il.ibm.com Mon Jul 9 07:00:17 2001 From: julian_satran at il.ibm.com (julian_satran@il.ibm.com) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] time for a presentation layer? Message-ID: Eric, The trouble with transport options is that there so precious few of them and adding one involves taking care that nothing gets broken anywhere. Encapsulating the transport in another header just extends this space. As for how deep in the stack you have to make the information visible you may choose to do it in the transport just after the encapsulation if the table approach violates what you sense as "good layering". Some of the options are anyhow "constant driven" (like the integrity checks). In IPV6 it looks like the end-to-end options are a perfect match for this type of extension. Regards, Julo "Eric A. Hall" on 09-07-2001 16:07:16 Please respond to "Eric A. Hall" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: [e2e] time for a presentation layer? julian_satran@il.ibm.com wrote: > > There are at least to reason why an IP option (even in the disgust of a > separate protocol header between IP and transport) looks better: > > available for any transport Is it really needed for UDP? I mean *really* necessary? Do DNS and TFTP and NTP really need the extension capability? I can see how they would benefit from it. Certainly things like robust error-detection, compression and encryption would be nice to have, but for a one-off, unreliable datagram, is it really necessary? Moreover, should no-UDP-options penalize the other transports which do provide option negotiation? It would be nice for those apps to have access to such a set of services, but isn't the datagram model one in which the apps are responsible for all of this anyway? > And several disadvantages: > > Negotiation in-band is difficult to sync (like IKE and IPSec) (not > impossible though) > Negotiation out-of-band requires (probably) a separate protocol Also, the applications have to communicate with the network directly, which is too deep in the stack. They shouldn't be going any deeper than the transport. The only real way to solve this is to build a control service, which has its own problems. Maybe leaving UDP behind is the best approach in the long run. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From dpreed at reed.com Wed Jul 11 08:21:10 2001 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Forbes.com story highlights how NATs destroy end-to-end reliability Message-ID: <5.1.0.14.2.20010711105924.03528960@mail.reed.com> Thought that many on this list don't get Forbes, so I'd forward a link to a Stephen Manes column in the latest issue about 3Com's NAT software and how it changes data at whim and corrects the checksum to spoof the recipient. Fortunately, the mission critical backup application that discovered the problem was programmed according to the end-to-end principle: it didn't depend on the TCP checksum for reliability. While Manes calls it a "programming error", it appears more likely that it was a design feature - the NAT software scanned the entire TCP segment for addresses that matched the local address that must be translated. This kind of solution has been used in some NAT software I've seen on machines that try to be "automagical" thinking that the byte sequence 192.168.0.1 is pretty unlikely to appear in most data packets, so it should be corrected everywhere. 3Com probably bought the rights to a package like that one (anyone on this list know the truth?) This is a good argument for adversary-proof checksums (like one-way signed message digests) I suggested in a recent exchange - clearly there are devices that behave like adversaries out there in the real world today, designed by real programmers to change bits in a way that is not statistically independent of the data. It is also becoming clear that patching the symptoms of a bad design choice (NAT in this case) is going to be never-ending, and it's time to obviate the need to perpetuate such kludges. I realize that this (beginning with IPv6, end-to-end encryption, etc.) is a big job and the Cisco/3Com/Microsoft axis don't seem to have the guts to do it. But it is time. http://www.forbes.com/forbes/2001/0723/118.html The Four-Byte Shuffle Stephen Manes, Forbes Magazine, 07.23.01, 12:00 AM ET Digital bits are supposed to be sacrosanct. An error in just one among billions can create unknowable consequences, from innocuous to disastrous. I know this firsthand. Four little bytes of data corruption--just enough to spell a choice expletive--recently wasted many hours of my life. <...> - David -------------------------------------------- WWW Page: http://www.reed.com/dpr.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20010711/240226d3/attachment.html From deering at cisco.com Wed Jul 11 13:52:48 2001 From: deering at cisco.com (Steve Deering) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Forbes.com story highlights how NATs destroy end-to-end reliability In-Reply-To: <5.1.0.14.2.20010711105924.03528960@mail.reed.com> References: <5.1.0.14.2.20010711105924.03528960@mail.reed.com> Message-ID: At 11:21 AM -0400 7/11/01, David P. Reed wrote: >It is also becoming clear that patching the symptoms of a bad design >choice (NAT in this case)... David, It is overly charitable to call NAT a "design choice". >...is going to be never-ending, and it's time to obviate the need to >perpetuate such kludges. I realize that this (beginning with IPv6, >end-to-end encryption, etc.) is a big job and the Cisco/3Com/Microsoft >axis don't seem to have the guts to do it. Cisco, Microsoft, 3Com and many other vendors *are* doing it (i.e., providing IPv6 and IPsec capabilities in their products), but as you say, it's a big job, so it's taking a while. Your "don't have the guts" may have been a fair characterization two years ago, but certainly not now. Since you mentioned specific company names, perhaps I can be forgiven for posting a pointer to a relevant press release that just went out yesterday: http://newsroom.cisco.com/dlls/prod_071001b.html (Don't click on that link if you are offended by PR-speak.) Steve From aaa at cs.stanford.edu Thu Jul 12 15:50:25 2001 From: aaa at cs.stanford.edu (Amr A. Awadallah) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] Router ip stacks! References: Message-ID: <3B4E29B1.98DB1C94@cs.stanford.edu> Hi, I am researching router ip stacks and would appreciate pointers to implementations in this field either from open sources or private companies that license such stacks. Please drop me a line if you know of any. The list I collected so far is attached at end of this e-mail. Thanks in advance, -- Amr 1) IpInfusion ZebOS: http://www.ipinfusion.com 2) Zebra (GNU GPL version of ZebOS): http://www.zebra.org 3) NextHop (proprietary gated implementation): http://www.nexthop.com/ 4) Nortel's OpenIP (now dead) 5) Data Connection (DC): http://www.dataconnection.com/ 6) NetPlane OptiRoute: http://www.netplane.com 7) Spider Software SpiderTCP: http://www.spider.com 8) Inverness Systems (acquired by Virata): http://www.virata.com 9) Routerware (acquired by Wind River): http://www.wrs.com/routerware/ 10) BIRD: http://bird.network.cz 11) John Moy's OSPF Book: http://www.aw.com/product/0,2627,0201309661,00.html From rgm-ietf at htt-consult.com Tue Jul 17 06:21:17 2001 From: rgm-ietf at htt-consult.com (Robert Moskowitz) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: <5.1.0.14.2.20010711105924.03528960@mail.reed.com> Message-ID: <5.1.0.14.2.20010717091427.02495ea0@localhost> What if you always had ESP (RFC 2406 for you fellow old-timers taht are thinking back to our college days :). How would TCP change? First we would drop the CRC checksum. All of the ESP auth methods are much stronger. But what about sequence numbers? ESP has a seq # also. Can it be used in place of TCPs? What restrictions need be placed on ESP's seq #? Anything else? Why do I ask, you ask? Well I have been concentrating on good, end-2-end ESP with a new Key Management Protocol called HIP. And since I am already recommending changes to the TCB API (use a hash of the Host Identity in place of the IP address to decouple the internetwokring and transport layers), and since I want this to be very wireless friendly, I am looking at what I can do to 'compression' TCP's overhead. From craig at aland.bbn.com Tue Jul 17 09:19:28 2001 From: craig at aland.bbn.com (Craig Partridge) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: Your message of "Tue, 17 Jul 2001 09:21:17 EDT." <5.1.0.14.2.20010717091427.02495ea0@localhost> Message-ID: <200107171619.f6HGJTb73316@aland.bbn.com> In message <5.1.0.14.2.20010717091427.02495ea0@localhost>, Robert Moskowitz wri tes: >First we would drop the CRC checksum. All of the ESP auth methods are much >stronger. Surprisingly no, you can't claim that one method of error detection is better than another until and unless you define an error model to serve as the basis of comparison. ESP is no better than a checksum of the same length in the absence of an error model (per the checksum discussion on this list and Jonathan Stone's impending dissertation). >But what about sequence numbers? ESP has a seq # also. Can it be used in >place of TCPs? What restrictions need be placed on ESP's seq #? You need to be able to wrap the ESP sequence number (TCP places no constraints on the length of the data, ESP, with its requirement of ever increasing sequence numbers, does) or link one ESP session with another, seamlessly (which incidentally, we're already looking at in the context of very high speed ESP support as the ESP sequence space is too small). Craig From angelos at coredump.cis.upenn.edu Tue Jul 17 09:37:18 2001 From: angelos at coredump.cis.upenn.edu (Angelos D. Keromytis) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: Your message of "Tue, 17 Jul 2001 09:21:17 EDT." <5.1.0.14.2.20010717091427.02495ea0@localhost> Message-ID: <200107171637.f6HGbIA14498@nyarlathotep.keromytis.org> In message <5.1.0.14.2.20010717091427.02495ea0@localhost>, Robert Moskowitz wri tes: > >First we would drop the CRC checksum. All of the ESP auth methods are much >stronger. There is no real advantage to doing this AFAICT; if you're doing software-only ESP, the cost of the crypto (even if it's RC4/MD5) greatly overwhelms the cost of the CRC. On the other hand, the potential for bugs because of this layering violation is greater than zero. It's not clear what the cons and pros are. However, if you always had ESP, chances are you have some kind of hardware support. Today, you can buy either dedicated crypto boards (I know of at least 4 different PCI boards by different vendors that can do better than fast ethernet 3DES/SHA-1 ESP), or NICs with IPsec support (I know of one, with another one probably coming out soon). In both cases, it's easy to see how the boards can be induced to calculate the TCP CRC; in fact, the NIC that supports IPsec already can do IP and TCP checksumming for both directions of traffic. (Side note: for some obscure reason, said feature does not work in conjunction with IPsec, although there's no reason it couldn't; perhaps more amusing is the fact that the firmware on these cards is broken and causes the cards to hang in some cases where output TCP/UDP checksumming is done on the NIC). The best argument against TCP CRC checksumming in hardware lies with the placement of the TCP header: at the begining of the packet. This means the NIC has to buffer the packet (or at least receive all of it before it can start transmitting), since it needs to stick the checksum in the TCP header. IPsec processing, on the other hand, can easily be done in a "streaming" fashion, since the authenticator is at the end of the packet. >But what about sequence numbers? ESP has a seq # also. Can it be used in >place of TCPs? What restrictions need be placed on ESP's seq #? The main problem of course is that the ESP replay-protection counter counts packets, whereas the TCP sequence number counts bytes. As such, it would interact really badly with things like PMTU discovery or data aggregation -- anything that would cause the same data to be retransmitted despite the fact that it has already been received (the sender will not know it, of course). If you go down this path....good luck :-) >Anything else? VJ-style compression could eliminate the source/destination ports (since these can be uniquely identified by the SPI --- *after* the TCP handshake, or at least the first SYN). -Angelos From danmcd at east.sun.com Tue Jul 17 09:57:36 2001 From: danmcd at east.sun.com (Dan McDonald) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: <5.1.0.14.2.20010717091427.02495ea0@localhost> from Robert Moskowitz at "Jul 17, 2001 09:21:17 am" Message-ID: <200107171657.f6HGvan06250@kebe.east.sun.com> > First we would drop the CRC checksum. All of the ESP auth methods are much > stronger. You _may_ have a point here. David Reed has been talking about using cryptographically strong sums in lieu of TCP and/or IP checksums. I'm assuming TCP checksums (and IPv4's header checksum for that matter) were designed to protect against link-layer corruption, which doesn't look all that much different from an active attacker. > But what about sequence numbers? ESP has a seq # also. Can it be used in > place of TCPs? What restrictions need be placed on ESP's seq #? No. TCP's sequence numbers are byte counters, not ESP's packet counters. You'd need to rewhack TCP so much to use ESP's sequence numbers that you wouldn't have TCP anymore. > Why do I ask, you ask? Well I have been concentrating on good, end-2-end > ESP with a new Key Management Protocol called HIP. And since I am already > recommending changes to the TCB API (use a hash of the Host Identity in > place of the IP address to decouple the internetwokring and transport > layers) Such a change is far more than an API change. Doing that changes the TCP protocol, though perhaps not as drastically as your previous sequence number suggestion. > and since I want this to be very wireless friendly, I am looking > at what I can do to 'compression' TCP's overhead. Is this another argument for TCPng discussions? Dan From cristina.foderi at guest.cnuce.cnr.it Tue Jul 17 10:14:58 2001 From: cristina.foderi at guest.cnuce.cnr.it (Cristina Foderi) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How to unsubscribe? Message-ID: <3B547292.5AD016D7@guest.cnuce.cnr.it> Tell me please how can I delete my name from end2end-interest mailing list ? Thank you. From dotis at sanlight.net Tue Jul 17 10:32:23 2001 From: dotis at sanlight.net (Douglas Otis) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: <200107171657.f6HGvan06250@kebe.east.sun.com> Message-ID: Robert, If you wish this scheme to be useful for SCTP on a packet basis as well as TCP, you may wish to consider using the sequence number only to be restrictive within a sliding window and not use it to mandate sequential delivery. This suggestion changes existing schemes for TLS but would allow normal layering of security. As security digests are larger than current checksums or CRC fields, it would not be difficult to conclude improved error detection as a result. Doug > > First we would drop the CRC checksum. All of the ESP auth > methods are much > > stronger. > > You _may_ have a point here. David Reed has been talking about using > cryptographically strong sums in lieu of TCP and/or IP checksums. > > I'm assuming TCP checksums (and IPv4's header checksum for that > matter) were > designed to protect against link-layer corruption, which doesn't look all > that much different from an active attacker. > > > But what about sequence numbers? ESP has a seq # also. Can it > be used in > > place of TCPs? What restrictions need be placed on ESP's seq #? > > No. TCP's sequence numbers are byte counters, not ESP's packet counters. > You'd need to rewhack TCP so much to use ESP's sequence numbers that you > wouldn't have TCP anymore. > > > Why do I ask, you ask? Well I have been concentrating on good, > end-2-end > > ESP with a new Key Management Protocol called HIP. And since I > am already > > recommending changes to the TCB API (use a hash of the Host Identity in > > place of the IP address to decouple the internetwokring and transport > > layers) > > Such a change is far more than an API change. Doing that changes the TCP > protocol, though perhaps not as drastically as your previous > sequence number > suggestion. > > > and since I want this to be very wireless friendly, I am looking > > at what I can do to 'compression' TCP's overhead. > > Is this another argument for TCPng discussions? > > Dan > From craig at aland.bbn.com Tue Jul 17 10:50:36 2001 From: craig at aland.bbn.com (Craig Partridge) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: Your message of "Tue, 17 Jul 2001 09:21:17 EDT." <5.1.0.14.2.20010717091427.02495ea0@localhost> Message-ID: <200107171750.f6HHoab73789@aland.bbn.com> In message <5.1.0.14.2.20010717091427.02495ea0@localhost>, Robert Moskowitz wri tes: >First we would drop the CRC checksum. All of the ESP auth methods are much >stronger. Addendum to my last note (kudos to Hilarie here). Because all the ESP auth methods have far more bits in their sum, they're (but for certain presumably rare cases) stronger than the 16 bit TCP checksum. Craig From HORMAN at volera.com Tue Jul 17 10:50:37 2001 From: HORMAN at volera.com (Hilarie Orman) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP Message-ID: While what you say about checksums has some basis in theory, it is clearly wrong in practice. There's reason to believe that the computation necessary to produce even one undetectable corruption of a SHA-1 hash is beyond feasible computation today. Under the most aggressive communication growth models, and under any error model, an undetectable error under a SHA-1 hash would not occur in less than 80 years. SHA-1 is better than the 16-bit one's complement sum. Hilarie >>> Craig Partridge 07/17/01 10:19AM >>> In message <5.1.0.14.2.20010717091427.02495ea0@localhost>, Robert Moskowitz wri tes: >First we would drop the CRC checksum. All of the ESP auth methods are much >stronger. Surprisingly no, you can't claim that one method of error detection is better than another until and unless you define an error model to serve as the basis of comparison. ESP is no better than a checksum of the same length in the absence of an error model (per the checksum discussion on this list and Jonathan Stone's impending dissertation). >But what about sequence numbers? ESP has a seq # also. Can it be used in >place of TCPs? What restrictions need be placed on ESP's seq #? You need to be able to wrap the ESP sequence number (TCP places no constraints on the length of the data, ESP, with its requirement of ever increasing sequence numbers, does) or link one ESP session with another, seamlessly (which incidentally, we're already looking at in the context of very high speed ESP support as the ESP sequence space is too small). Craig From dotis at sanlight.net Tue Jul 17 11:53:00 2001 From: dotis at sanlight.net (Douglas Otis) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: <200107171750.f6HHoab73789@aland.bbn.com> Message-ID: Craig, For which cases would ESP digests appear weaker than a 16 bit TCP checksum? Doug > >First we would drop the CRC checksum. All of the ESP auth > methods are much > >stronger. > > Addendum to my last note (kudos to Hilarie here). Because all the ESP > auth methods have far more bits in their sum, they're (but for certain > presumably rare cases) stronger than the 16 bit TCP checksum. > > Craig > From craig at aland.bbn.com Tue Jul 17 11:58:01 2001 From: craig at aland.bbn.com (Craig Partridge) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: Your message of "Tue, 17 Jul 2001 11:53:00 PDT." Message-ID: <200107171858.f6HIw2b74586@aland.bbn.com> In message , "Douglas Otis" wr ites: >For which cases would ESP digests appear weaker than a 16 bit TCP checksum? If they had the same number of bits, then we'd have to evaluate the two over particular error models to determine which is stronger. Craig From HORMAN at volera.com Tue Jul 17 12:42:59 2001 From: HORMAN at volera.com (Hilarie Orman) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP Message-ID: There is no ESP digest with such a tiny blocksize! Hilarie >>> Craig Partridge 07/17/01 12:58PM >>> In message , "Douglas Otis" wr ites: >For which cases would ESP digests appear weaker than a 16 bit TCP checksum? If they had the same number of bits, then we'd have to evaluate the two over particular error models to determine which is stronger. Craig From dpreed at reed.com Wed Jul 18 00:50:38 2001 From: dpreed at reed.com (David P. Reed) Date: Thu Mar 25 12:00:12 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: <200107171858.f6HIw2b74586@aland.bbn.com> References: Message-ID: <5.1.0.14.2.20010718034251.043cfec0@mail.reed.com> At 02:58 PM 7/17/01 -0400, Craig Partridge wrote: >In message , "Douglas >Otis" wr >ites: > > >For which cases would ESP digests appear weaker than a 16 bit TCP checksum? > >If they had the same number of bits, then we'd have to evaluate the two >over particular error models to determine which is stronger. While this is true for one particular measure of effectiveness (average number of undetected erroneous packets from a distribution), I want to register the following observation: if the model of the "corrupting" process is not stochastic, this measure is both meaningless and irrelevant. 2 examples: 1. deterministic corruption ( non probabilistic process explicitly dependent on data or externalities like timing or congestion). In this case the measure is meaningless. 2. adversarial (conscious entities that may choose attack based on knowledge of the error detection method used). Measure irrelevant and meaningless. In other words there is no one measure for effectiveness of error detection that is appropriate over all situations. - David -------------------------------------------- WWW Page: http://www.reed.com/dpr.html From rgm-ietf at htt-consult.com Wed Jul 18 05:32:50 2001 From: rgm-ietf at htt-consult.com (Robert Moskowitz) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: <200107171637.f6HGbIA14498@nyarlathotep.keromytis.org> References: Message-ID: <5.1.0.14.2.20010718082657.024552c0@localhost> At 12:37 PM 7/17/2001 -0400, Angelos D. Keromytis wrote: >In message <5.1.0.14.2.20010717091427.02495ea0@localhost>, Robert >Moskowitz wri >tes: > > > >First we would drop the CRC checksum. All of the ESP auth methods are much > >stronger. > >There is no real advantage to doing this AFAICT; if you're doing software-only >ESP, the cost of the crypto (even if it's RC4/MD5) greatly overwhelms the >cost of the CRC. On the other hand, the potential for bugs because of this >layering violation is greater than zero. It's not clear what the cons and pros >are. The point is. You are doing ESP. Given that can you save on TCP? The answer gotten here is: Yeah, somewhat. ESP in software or hardware is not TOO much an issue. We already have devices altering TCP checksums, as they are playing with the IP headers that are included in the checksum calculation. So a hardware ESP implementation could strip off or re-add the checksum just as well as a software one. Plus if the kernel 'knew' that ESP was in use, end-2-end, then it COULD be tuned to the change. > >But what about sequence numbers? ESP has a seq # also. Can it be used in > >place of TCPs? What restrictions need be placed on ESP's seq #? > >The main problem of course is that the ESP replay-protection counter counts >packets, whereas the TCP sequence number counts bytes. As such, it would >interact really badly with things like PMTU discovery or data aggregation -- >anything that would cause the same data to be retransmitted despite the fact >that it has already been received (the sender will not know it, of course). >If you go down this path....good luck :-) oops. yeah. No can do, it seems. ESP and TCP sequence numbers have a considerably different set of symantics. Thanks. >VJ-style compression could eliminate the source/destination ports (since these >can be uniquely identified by the SPI --- *after* the TCP handshake, or at >least the first SYN). This assumes port level SAs. the basic HIP design is for 'kernel' level SAs. So I don't think I can add this. From rgm-ietf at htt-consult.com Wed Jul 18 05:36:07 2001 From: rgm-ietf at htt-consult.com (Robert Moskowitz) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: <200107171657.f6HGvan06250@kebe.east.sun.com> References: <5.1.0.14.2.20010717091427.02495ea0@localhost> Message-ID: <5.1.0.14.2.20010718083322.024677c8@localhost> At 12:57 PM 7/17/2001 -0400, Dan McDonald wrote: > > Why do I ask, you ask? Well I have been concentrating on good, end-2-end > > ESP with a new Key Management Protocol called HIP. And since I am already > > recommending changes to the TCB API (use a hash of the Host Identity in > > place of the IP address to decouple the internetwokring and transport > > layers) > >Such a change is far more than an API change. Doing that changes the TCP >protocol, though perhaps not as drastically as your previous sequence number >suggestion. Then how do NATs get away with altering TCP checksums? This is something that can well be handled in an end-2-end ESP implementation. Even a gateway-2-gateway one, come to think of it. > > and since I want this to be very wireless friendly, I am looking > > at what I can do to 'compression' TCP's overhead. > >Is this another argument for TCPng discussions? If you look at ESP as layer 3.5 and it is always there (or at least there enough to use it often), how WOULD layer 4 look? From rgm-ietf at htt-consult.com Wed Jul 18 05:38:19 2001 From: rgm-ietf at htt-consult.com (Robert Moskowitz) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: References: <200107171657.f6HGvan06250@kebe.east.sun.com> Message-ID: <5.1.0.14.2.20010718083624.02149008@localhost> At 10:32 AM 7/17/2001 -0700, Douglas Otis wrote: >If you wish this scheme to be useful for SCTP on a packet basis as well as >TCP, you may wish to consider using the sequence number only to be >restrictive within a sliding window and not use it to mandate sequential >delivery. This suggestion changes existing schemes for TLS but would allow >normal layering of security. As security digests are larger than current >checksums or CRC fields, it would not be difficult to conclude improved >error detection as a result. I am not conversant on SCTP, sigh. ESP does not call out for sequential delivery, even with IPsec compression. A sliding window of 32 packets is a MUST implement and 64 is RECOMMENDED. From rgm-ietf at htt-consult.com Wed Jul 18 05:40:31 2001 From: rgm-ietf at htt-consult.com (Robert Moskowitz) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: <200107171750.f6HHoab73789@aland.bbn.com> References: Message-ID: <5.1.0.14.2.20010718083827.02304d68@localhost> At 01:50 PM 7/17/2001 -0400, Craig Partridge wrote: >In message <5.1.0.14.2.20010717091427.02495ea0@localhost>, Robert >Moskowitz wri >tes: > > >First we would drop the CRC checksum. All of the ESP auth methods are much > >stronger. > >Addendum to my last note (kudos to Hilarie here). Because all the ESP >auth methods have far more bits in their sum, they're (but for certain >presumably rare cases) stronger than the 16 bit TCP checksum. Plus, Craig, you might remember way back on a list we are on a discussion of an ATM implementatino (in error of course) that managed to scramble a TCP packet is such a way that the TCP checksum did not catch the error. The nature of all current ESP auth modes would have failed to authenticate with such a packet content reordering. From rgm-ietf at htt-consult.com Wed Jul 18 05:43:21 2001 From: rgm-ietf at htt-consult.com (Robert Moskowitz) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] How TCP might look with always there ESP In-Reply-To: References: <200107171657.f6HGvan06250@kebe.east.sun.com> Message-ID: <5.1.0.14.2.20010718084052.01bd4728@localhost> At 08:00 PM 7/17/2001 +0100, Lloyd Wood wrote: >Even with robust widely-deployed ESP in a sensible security framework, >you'd still need a form of TCP for session management. By having ESP >take over TCP's session management, aren't you effectively >compromising the security model? Never considered doing a way with TCP session management, or rather re-inventing it. A number of us now view ESP as layer 3.5, and if done properly would allow for a layer 4 to readily traverse many layer 3 'realms'. For example, NATed to public to NATed. Or IPv6 to IPv4 to IPv6. From touch at ISI.EDU Wed Jul 18 18:18:57 2001 From: touch at ISI.EDU (Joe Touch) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] How to unsubscribe? References: <3B547292.5AD016D7@guest.cnuce.cnr.it> Message-ID: <3B563581.36418E76@isi.edu> Cristina Foderi wrote: > > Tell me please how can I delete my name from end2end-interest mailing > list ? > Thank you. FYI, and for anyone else so inclined: 1) you can visit the following website: http://www.postel.org/mailman/listinfo/end2end-interest 2) you can send mail to an automated mail agent; put the word 'help' in the body or subject line, and send to: end2end-interest-request@mailman.postel.org 3) if all else fails (yes, we'd prefer if you try automation first), send mail to: mailman-owner@postel.org Thanks! Joe From kandlur at us.ibm.com Fri Jul 20 10:25:34 2001 From: kandlur at us.ibm.com (Dilip D Kandlur) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] ACM Sigcomm 2001 Conference: Hotel registration deadline approaching Message-ID: The hotel registration deadline is next week, July 23rd. Call for Participation ACM SIGCOMM 2001 Conference August 27 - August 31, 2001 University of California, San Diego, CA USA http://www.acm.org/sigcomm/sigcomm2001 Deadlines: Proposals for student travel grant: June 15, 2001 Proposals for student poster session: June 17, 2001 Advance registration ends: August 3, 2001 Hotel registration deadline: July 23, 2001 ACM SIGCOMM 2001 is the annual conference of the Special Interest Group on Data Communication (SIGCOMM), a single-track, highly selective conference with a technical program of 23 papers, tutorials by noted instructors on the two days prior, and a panel discussion. Early registration for SIGCOMM 2001 will soon be available. Registration details, as well as information on student travel grants and requests for proposals for the work-in-progress poster session are available at the SIGCOMM website above. Social Events The reception will be at the Birch Aquarium at Scripps. The Aquarium is situated on a hilltop site that provides a spectacular view on the Scripps Institution of Oceanography campus, northern La Jolla, and the Pacific Ocean. Conference attendees will have full access to the aquarium exhibits during the reception. The reception is included in registration fee for attendees and their guests. No reservations necessary. The SIGCOMM 2001 Banquet will be held in the Main Ballroom of the Hotel Del Coronado, situated on picturesque Coronado Island. Over 112 years old, it is a National Historic Landmark renowned for its magnificent architecture and legendary guests. The banquet is included in the registration fee for attendees. There will be a $75 charge for each guest. SIGCOMM Award The SIGCOMM Award is given annually to a person whose career and technical achievements demonstrate a long-term commitment to the field of data communications. ACM SIGCOMM is pleased to announce that the 2001 SIGCOMM Award is being given to Van Jacobson of Packet Design, Inc. Van Jacobson will receive the award and give the conference keynote address in the opening session on Wednesday. Tutorials SIGCOMM 2001 begins with two days of full- and half-day tutorials covering single topics in detail at both the introductory and advanced level. Tutorials offered this year are: - Wireless Data Phil Karn, Qualcomm, Inc. - Traffic Measurement for IP Operations Matt Grossglauser and Jennifer Rexford, AT&T - Interdomain Routing and BGP Timothy G. Griffin, AT&T - Equilibrium and Dynamics of TCP Prof. Steven H. Low, California Inst. of Technology - Algorithms for Networks: Some Techniques for Design and Analysis Ashish Goel, University of Southern California Nick McKeown and Balaji Prabhakar, Stanford University Outrageous Opinions Session The Outrageous Opinions Session provides an opportunity for sharing entertaining, provocative, and otherwise enriching ideas and suggestions in their early stages. The session will be held Thursday evening. Poster Session - Work in Progress The Poster Session is aimed at showcasing the "work-in-progress" of students attending the conference. Poster proposals should be sent by email to Hari Balakrishnan (hari@lcs.mit.edu) by June 17 (no extensions). Please see the conference website for details regarding the submission format. Student Travel Awards The purpose of the student travel program is to encourage graduate student participation at the conference by partially or fully funding the travel costs of students who would otherwise be unable to attend. SIGCOMM 2001 thanks Cisco and SIGCOMM for funding the program this year. See the website for eligibility criteria and application procedures. General Co-Chairs Rene Cruz, UC San Diego, USA (cruz@ece.ucsd.edu) George Varghese, UC San Diego, USA (varghese@ece.ucsd.edu) Program Co-Chairs Roch Guerin, U. Pennsylvania, USA (guerin@ee.upenn.edu) Derek McAuley, Marconi Research Center, UK (derek.mcauley@marconi.com) Publicity Chair Dilip Kandlur, IBM TJ Watson Research Ctr, USA (kandlur@us.ibm.com) Tutorials Chair Chuck Kalmanek, AT&T Research, USA (crk@research.att.com) Local Arrangements Co-Chairs Geoff Voelker, UC San Diego, USA (voelker@cs.ucsd.edu) Finance Chair Joe Touch, UCS/ISI, USA (touch@isi.edu) Publication Chair Ramesh Govindan, USC/ISI, USA (govindan@isi.edu) Student Travel Award Chair Christos Papadopoulos, U. Southern California (christos@usc.edu) Student Poster Chair Hari Balakrishnan, MIT, USA (hari@lcs.mit.edu) Support from Cisco, IBM, Deloitte and Touche, PMC-Sierra, Marconi, Procket Networks, Agilent Technologies, Microsoft Research, and USC/ISI is gratefully acknowledged. From touch at ISI.EDU Fri Jul 20 14:34:51 2001 From: touch at ISI.EDU (Joe Touch) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] New mailing list - Internet History Message-ID: <3B58A3FB.23146AA4@isi.edu> Hi, all, At Bob Braden's request, I've created a new mailing list for discussions about Internet History. The hope is that this will be a forum for Q&A (as in 'who did this originally') as well as to collect FAQs and other links (which we'll do on the Postel Center web pages). To subscribe, see: http://www.postel.org/mailman/listinfo/internet-history Discussions about Internet History. An open forum for questions and clarifications about Internet History. There is also an email-based interface for users; you can get info about using it by sending a message with just the word `help' as subject or in the body, to: internet-history-request@postel.org Mail to the list should be directed to: internet-history@postel.org The internet-history list is currently maintained as a service of USC/ISI's Postel Center for Experimental Networking (PCEN). Joe Touch Director, PCEN From floyd at aciri.org Fri Jul 20 22:20:07 2001 From: floyd at aciri.org (Sally Floyd) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] Windows NT implementation of TCP Message-ID: <200107210520.f6L5K7k07277@elk.aciri.org> >> First, apologies if it's not appropriate to be asking >> a question like this. I was trying to find out what >> flavor of TCP Windows NT 4.0 uses. Specifically, I'm >> trying to find out if it uses fast retransmit. While it it true that Windows NT and Windows 2000 both implement Fast Retransmit, in many cases, due to a bug in the implementation, Fast Retransmit is never invoked, and the TCP sender has to wait for a Retransmit Timeout to retransmit a lost packet. This is discussed in more detail in the TBIT paper by Padhye and Floyd, available from "http://www.aciri.org/tbit/". - Sally http://www.aciri.org/floyd/ From huitema at windows.microsoft.com Mon Jul 23 11:12:36 2001 From: huitema at windows.microsoft.com (Christian Huitema) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] Windows NT implementation of TCP Message-ID: > >> First, apologies if it's not appropriate to be asking > >> a question like this. I was trying to find out what > >> flavor of TCP Windows NT 4.0 uses. Specifically, I'm > >> trying to find out if it uses fast retransmit. > > While it it true that Windows NT and Windows 2000 both implement > Fast Retransmit, in many cases, due to a bug in the implementation, > Fast Retransmit is never invoked, and the TCP sender has to wait > for a Retransmit Timeout to retransmit a lost packet. This is > discussed in more detail in the TBIT paper by Padhye and Floyd, > available from "http://www.aciri.org/tbit/". The bug occurred in Windows 2000, and has been fixed in the Service Pack 1 issued in July 2000. The bug does not affect NT4 or XP, or any version of W2K SP1 or greater. -- Christian Huitema From huitema at windows.microsoft.com Thu Jul 26 12:40:27 2001 From: huitema at windows.microsoft.com (Christian Huitema) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] Windows NT implementation of TCP Message-ID: Last Monday, I sent a message announcing that a specific bug was fixed in Windows 2000 since SP1, and I was wrong: > > While it it true that Windows NT and Windows 2000 both implement > > Fast Retransmit, in many cases, due to a bug in the implementation, > > Fast Retransmit is never invoked, and the TCP sender has to wait > > for a Retransmit Timeout to retransmit a lost packet. This is > > discussed in more detail in the TBIT paper by Padhye and Floyd, > > available from "http://www.aciri.org/tbit/". > > The bug occurred in Windows 2000, and has been fixed in the Service > Pack 1 issued in July 2000. The bug does not affect NT4 or XP, or any > version of W2K SP1 or greater. It turns out that I had a "communication failure" with the developers in charge of correcting the said bug, which is not fixed in either W2K SP1 or SP2. I am also told that it will be fixed shortly. To reproduce the bug (for those who care) you have to use a Microsoft specific socket command, "TransmitFile()" and you have to set the "TF_DISCONNECT" parameter to request an automatic disconnect at the end of the file transmission. -- Christian Huitema From braden at ISI.EDU Fri Jul 27 14:33:07 2001 From: braden at ISI.EDU (Bob Braden) Date: Thu Mar 25 12:00:13 2004 Subject: [e2e] Internet2 Application QoS Message-ID: <200107272133.VAA29014@gra.isi.edu> ----- Begin Included Message ----- >From amela@advanced.org Fri Jul 27 14:10:15 2001 X-Sender: amela@mailhost.advanced.org Date: Fri, 27 Jul 2001 17:10:06 -0400 To: braden@ISI.EDU From: Amela Sadagic Subject: Internet2 Application QoS Needs: monthly discussion topics Mime-Version: 1.0 Hi Bob, Please would you be so kind to forward this announcement to end2end-interest list or any other related group that you might be associated with. very best, Amela Sadagic ----------------------------------------------------- Internet2 Application QoS Needs Design Team would like to announce a set of discussion topics that we will be initiating and leading every month. Your input will be highly valuable and appreciated. Please feel free to contribute by posting your comments to mailing list. Discussion topic for August 2001: OBJECTIVE QUALITY MEASUREMENT OF AUDIO AND VIDEO OVER PACKET NETWORKS Moderator: Roch Guerin, Professor of Telecommunications Networks at the University of Pennsylvania, Philadelphia The successful transmission of audio and video applications over packet networks is unique in a number of ways. Both applications have a perceptual content that makes it difficult to readily map application level quality onto common, quantifiable quality measures readily available in packet networks, e.g., packet loss, delay, jitter, etc. In addition, audio and video both have "real-time" constraints and resource needs that introduce requirements, which are typically not present with traditional data applications. Hence, audio and video streaming have been identified as applications that stand to benefit from the availability of "QoS" in packet networks. Understanding the extent to which either application, as well as the two of them jointly as is often the case, benefits from different levels of QoS and resource guarantees is an open research topic. One promising direction is based on the adaptation to transmissions over packet networks of various objective quality measurement tools, which have been originally developed for evaluating the quality of different codecs as well as analog transmission channels. This approach has been explored to some extent for audio. In particular, the PSQM system described in ITU-T Recommendation P.861 and its PSQM+ extension described such an approach. Other related system include PAMS, PESQ, and PSQM/IP. In the context of video, efforts are at a somewhat earlier stage although a similar approach is being pursued, namely the adaptation of objective measurement tools to packet networks, e.g., based on the ANSI T1.801.03 specification, the ITU-T Recommendation P.910, as embodied in the VQM tool of the Institute for Telecommunication Sciences. Those initial efforts not withstanding, the incorporation of new network QoS capabilities remains a largely untouched topic. The purpose of this discussion forum is to review both the set of issues involved and the status of different activities aimed at developing solutions. WEB POINTERS: Post your discussion to: qos-appl-discuss@internet2.edu Review all discussions on our arhive site: http://mail.internet2.edu:8080/guest/archives/qos-appl-discuss/ Announcement of discussion topics: http://www.internet2.edu/qos/wg/apps/Documents/discussions.html Internet2 Application QoS Needs Design Team: http://www.internet2.edu/qos/wg/apps/ ----------------------------------------------- ~~~~~~~~~~ Amela Sadagic amela@advanced.org Advanced Network & Services ph/office : +1 914 765 8316 200 Business Park Drive fax: +1 914 765 8317 Armonk, NY 10504, USA http://www.advanced.org/teleimmersion.html http://www.thinkquest.org http://www.advanced.org/~amela ----- End Included Message -----