From ratul at microsoft.com Sun Mar 4 10:51:26 2007 From: ratul at microsoft.com (Ratul Mahajan) Date: Sun, 4 Mar 2007 10:51:26 -0800 Subject: [e2e] CFP: NetEcon+IBC 2007 Message-ID: <5CC2EE1CA894334FB0514CB4C63940673997CD160D@NA-EXMSG-C103.redmond.corp.microsoft.com> on behalf of the organizing committee, i am pleased to announce the NetEcon+IBC 2007 workshop which focuses on the increasingly important area of the role of incentives in networked systems. this workshop combines the workshop on the Economics of Networked Systems (NetEcon) and the workshop on Incentive-Based Computing (IBC), two successful venues from previous years. it will be a discussion-oriented workshop that will bring together a diverse set of interested researchers. i would like to encourage you to submit your work and participate in the workshop. the cfp is appended below. --------------------------- NetEcon+IBC 2007 Joint Workshop on The Economics of Networked Systems and Incentive-Based Computing URL: http://netecon-ibc.si.umich.edu The emergence of the Internet as a global platform for computation and communication has sparked the development and deployment of many large-scale distributed systems. Often, these systems involve multiple stakeholders with divergent or even competing interests. Unmitigated selfish behavior in these systems can lead to high inefficiency or even complete collapse. There has been an increasing interest in applying economic and game-theoretic principles to help analyze and design such systems. The NetEcon+IBC Workshop aims to promote a cross-disciplinary discussion on the role of incentives in computational and communication systems. It will bring together researchers from a diverse set of areas including systems, theory, distributed computing, artificial intelligence, and economics. NetEcon+IBC 2007 will be held in conjunction with the 2007 ACM Conference on Electronic Commerce (EC'07) which is part of the 2007 Federated Computer Research Conference (FCRC'07). In the spirit of FCRC, the workshop combines two successful workshops from previous years: the workshop on the Economics of Networked Systems (NetEcon) and the Workshop on Incentive-Based Computing (IBC). We invite submissions of technical or position papers on topics related to the goals of the workshop. Submissions should be at most 6 pages in length with 10pt fonts or larger. Additional information (such as proofs) may be included in a clearly marked appendix, which will be read at the discretion of the the referees. Papers will be selected based on both technical merit and their potential to spark discussion at the workshop. Accepted papers will be published on the workshop website. Topics of interest include, but are not limited to: - Potential roles of economics in networks: analysis, design, or just a distraction? - Application of incentive mechanisms for peer-to-peer systems, grids, SPAM, security, Internet routing and peering, wireless networks, etc. - Methods for engineering incentives and disincentives (e.g., reputation, trust, control, accountability, and anonymity, etc.) - Empirical studies of strategic or non-strategic behavior in existing systems - Incentive mechanisms for scheduling, resource allocation, and computation - Models and solution concepts (e.g., evolutionary games, repeated games, cooperative games, etc.) - Algorithmic mechanism design and distributed protocols based on markets or auctions - Experimental methodologies for testing incentive schemes - Privacy-preserving incentive mechanisms - What systems researchers think theoreticians should do, and vice versa? Important Dates Deadline for paper submission March 26, 2007 Notification of acceptance April 30, 2007 Deadline for camera-ready papers May 21, 2007 Workshop date Jun 11, 2007 Program Commitee Vincent Conitzer, Duke University John Douceur, Microsoft Research Michal Feldman, Hebrew University Daniel Grosu, Wayne State University (co-chair) Ramesh Johari, Stanford University Ratul Mahajan, Microsoft Research (co-chair) Herve Moulin, Rice University Tim Roughgarden, Stanford University Rahul Sami, University of Michigan (co-chair) Alex Snoeren, University of California at San Diego Paul Spirakis, Computer Technology Institute Xiaowei Yang, University of California at Irvine From stl0774 at yahoo.com Thu Mar 8 07:56:13 2007 From: stl0774 at yahoo.com (Abi Babu) Date: Thu, 8 Mar 2007 07:56:13 -0800 (PST) Subject: [e2e] Limit on simultaneous Persistent connections to a HTTP server Message-ID: <865372.48427.qm@web39811.mail.mud.yahoo.com> Is there a limit on the number of persistent (HTTP/1.0)connections that an HTTP client simultaneously opens with a web server? The HTTP/1.1 RFC constrains a client to atmost two simultaneous persistent connections Thanks --------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070308/b8306f0e/attachment.html From touch at ISI.EDU Fri Mar 9 08:10:17 2007 From: touch at ISI.EDU (Joe Touch) Date: Fri, 09 Mar 2007 08:10:17 -0800 Subject: [e2e] Limit on simultaneous Persistent connections to a HTTP server In-Reply-To: <865372.48427.qm@web39811.mail.mud.yahoo.com> References: <865372.48427.qm@web39811.mail.mud.yahoo.com> Message-ID: <45F186E9.4010409@isi.edu> Abi Babu wrote: > Is there a limit on the number of persistent (HTTP/1.0)connections > that an HTTP client simultaneously opens with a web server? > > The HTTP/1.1 RFC constrains a client to at most > two simultaneous persistent connections RFC2616, Sec 8.1.4, says: Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. SHOULD isn't a constraint; it's a strong recommendation not to do otherwise unless there is a particular overriding consideration. It's not the same as "MUST", so no, there is no strict limit for 1.1. 1.0 didn't specify persistent connections AFAICT; that was a later addition as I recall. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070309/b54f6886/signature.bin From detlef.bosau at web.de Sat Mar 10 13:36:01 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 10 Mar 2007 22:36:01 +0100 Subject: [e2e] Opportunistic Scheduling: Good? Or Evil? In-Reply-To: <45DC4CDD.7040500@reed.com> References: <45DC27E4.4010901@web.de> <45DC4CDD.7040500@reed.com> Message-ID: <45F324C1.9030601@web.de> David P. Reed wrote: > The delays come from buffering and retrying for long times, on the > basic theory that the underlying network is trying to be "smart" and > guarantee delivery in the face of congestion or errors. Because I still do not understand the opportunistic scheduling stuff in mobile networks, I?m actually trying to simulate this stuff myself. I?m finished with an extremely simple, yet perphas not that bad, RLP simulator which does not really simulate RLP data transfer but the transport delays caused by RLP. And I added a component for MAC scheduling. (This is all trivial stuff, in summeay less than perhaps 300 lines.) Media access in mobile networks immediatley leads to the question: Why do we use dynamic time slot allocation at all? Why don?t we use a simple collision scheme or CSMA/CA or something like that? To my understanding, a reason can be that ALOHA flavours (and the aforementioned techniques are such flavours) do not well exploit a channel?s capacity. So, when small bandwidth is a concern, dynamic time slot allocation can lead to a better channel utiliziation than ALOHA flavours. Do you agree here? Or am I wrong? Now, there must be a coordination function which actually does the dynamic TSA. Fine. So, the next question is: Why don?t we simply use "first come first serve"? It?s simple, it?s pretty stupid - and pretty attractive ;-) In fact, my own scheduler actually does "first come first serve", because I have not yet implemented the scheduling priority functions which are necessary for proportinal fair scheduling and the like. However: At least with greedy sources, a simple FCFS scheme leads to a perfectly fair distribution of (time slot) ressources between the actaually sending (or receiving ) mobiles of a cell and I don?t see, where this should lead to a problem with TCP. O.k., I know the rationale that proportinoal fair scheduling increases the overall throughput. But I do not yet know at which expenses this is accomplished. I know of serval papers which consider fairness and throughput issues with a mix of applications. What I do _not_ yet know are papers which study opportunistic scheduling under varying error scenarios. And I?m particurlaly not interested in the whole "soft" models which model fading channels with an attenuation proportional to the square of the BS-mobile distance and the like. What will happen, when there are "noise spikes" or a channel suffers from sudden and drasting quality changes due to multipath fading or whatever? When we use a simple FCFS scheme, changes to channel will only affect this one channel. When we use opportunistic channel, there will be side effects to other channels. Of course: on the link layer, we will optimize the channel utilization. But how does this affect TCP? Does your statement, the underlying network was "too smart" , still hold here? I would appreciate any hint on this one. And perhaps, my simulations will give a clue here. Thanks. Detlef From dpreed at reed.com Sat Mar 10 15:22:51 2007 From: dpreed at reed.com (David P. Reed) Date: Sat, 10 Mar 2007 18:22:51 -0500 Subject: [e2e] Opportunistic Scheduling: Good? Or Evil? In-Reply-To: <45F324C1.9030601@web.de> References: <45DC27E4.4010901@web.de> <45DC4CDD.7040500@reed.com> <45F324C1.9030601@web.de> Message-ID: <45F33DCB.3010901@reed.com> Detlef - If still focused on why GPRS has long delays, I think you are looking at the wrong layer. The end-to-end delay in a GPRS network has nothing to do with the MAC layer. You can tell because of the order of magnitude of the actual delays observed (seconds) compared with the time constants of the MAC layers involved (one or two digit milliseconds). That's why I said to look at buffering in queues above the PHY and Medium Access layers - the network transport layers. Regarding Aloha et al., it's clear that the point of Aloha is to be memoryless. Every new packet comes along and pretends that no memory of the past is relevant, no knowledge of the demand by other users and terminals is relevant, and no knowledge of the propagation environment is relevant. This is true only if devices are built without sensing, without memory, etc. OR if the environment is so unpredictable as to benefit not at all from memory and state. Aloha makes only a trivial assumption (short-term channel state coherence) and only requires trivial algorithmic state (the backoff time). Nothing especially good about that, other than being somewhat universal and awfully cheap to implement. That said, protocols that build low level circuits by TDM or whatever are making an implicit assumption of coherence of channel state, stability of demand (constant rate), and totally anticipated future. Nothing especially good about that. Everything else is detail. Most of the detail added to either approach is usually got wrong. KISS (Keep it simple, stupid) is a good engineering maxim here. Complexity is what engineers do when they don't have a clue what they are designing for, and want to impress their friends. Detlef Bosau wrote: > David P. Reed wrote: >> The delays come from buffering and retrying for long times, on the >> basic theory that the underlying network is trying to be "smart" and >> guarantee delivery in the face of congestion or errors. > Because I still do not understand the opportunistic scheduling stuff > in mobile networks, I?m actually trying to simulate this stuff myself. > I?m finished with an extremely simple, yet perphas not that bad, RLP > simulator which does not really simulate RLP data transfer but the > transport delays caused by RLP. And I added a component for MAC > scheduling. (This is all trivial stuff, in summeay less than perhaps > 300 lines.) > > Media access in mobile networks immediatley leads to the question: Why > do we use dynamic time slot allocation at all? Why don?t we use a > simple collision scheme or CSMA/CA or something like that? > > To my understanding, a reason can be that ALOHA flavours (and the > aforementioned techniques are such flavours) do not well exploit a > channel?s capacity. So, when small bandwidth is a concern, dynamic > time slot allocation can lead to a better channel utiliziation than > ALOHA flavours. Do you agree here? Or am I wrong? > > Now, there must be a coordination function which actually does the > dynamic TSA. Fine. > > So, the next question is: Why don?t we simply use "first come first > serve"? It?s simple, it?s pretty stupid - and pretty attractive ;-) > In fact, my own scheduler actually does "first come first serve", > because I have not yet implemented the scheduling priority functions > which are necessary for proportinal fair scheduling and the like. > > However: At least with greedy sources, a simple FCFS scheme leads to a > perfectly fair distribution of (time slot) ressources between the > actaually sending (or receiving ) mobiles of a cell and I don?t see, > where this should lead to a problem with TCP. > > O.k., I know the rationale that proportinoal fair scheduling increases > the overall throughput. But I do not yet know at which expenses this > is accomplished. I know of serval papers which consider fairness and > throughput issues with a mix of applications. > > What I do _not_ yet know are papers which study opportunistic > scheduling under varying error scenarios. And I?m particurlaly not > interested in the whole "soft" models which model fading channels with > an attenuation proportional to the square of the BS-mobile distance > and the like. > > What will happen, when there are "noise spikes" or a channel suffers > from sudden and drasting quality changes due to multipath fading or > whatever? > > When we use a simple FCFS scheme, changes to channel will only affect > this one channel. When we use opportunistic channel, there will be > side effects to other channels. > > Of course: on the link layer, we will optimize the channel > utilization. But how does this affect TCP? Does your statement, the > underlying network was "too smart" , still hold here? > > I would appreciate any hint on this one. And perhaps, my simulations > will give a clue here. > > Thanks. > > Detlef > > From detlef.bosau at web.de Sun Mar 11 05:22:20 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 11 Mar 2007 13:22:20 +0100 Subject: [e2e] Opportunistic Scheduling: Good? Or Evil? In-Reply-To: <45F33DCB.3010901@reed.com> References: <45DC27E4.4010901@web.de> <45DC4CDD.7040500@reed.com> <45F324C1.9030601@web.de> <45F33DCB.3010901@reed.com> Message-ID: <45F3F47C.9090302@web.de> David P. Reed wrote: > Detlef - If still focused on why GPRS has long delays, I think you are > looking at the wrong layer. And if I would still focus only on GPRS, I would focus on the wrong network ;-) GPRS is intended to be a "migration technolgy". A migration technology has three aspects: - the scientific one: GPRS is irrelevant in the long run, howevever we can gain experiences from it. - the intention: GPRS is stillborn. It was buried before it was born and the NOs expected high revenues from the burial ;-) - reality: As we all know, "migration" is a state. Not a project. ;-) > The end-to-end delay in a GPRS network has nothing to do with the MAC > layer. Hm. I?m always told, what are _not_ the reasons for long delays. I?m about to run out of reasons here =8-) At the moment, I?m looking for an unbiased understanding of delays here. At the moment, I see the following delay sources: 1. Physical bandwidth of the wireless network, length of a timesolot, payload of a time slot. This highly depends on the technology in use. Some days ago, I found it extremely helpful in a paper, that all delays were given in timeslot units there. 2. Recovery. How often are corrupted RLP frames retransmitted? I have well in mind that you wrote that at most one retransmission would make sense, anything else should be left to the upper layers. 3. MAC. 4. Processing. I?m often told that GPRS has a lot of inefficiencies in its protocol stack. 5. Queueing. I think, for a scientific considertaion, only points 2 and 3 are important. WRT point 2, I tend to disagree with you: If an IP packet consists of e.g. 20 RLP frames and each RLP frame suffers from a corruption rate of e.g. 0.3 or 0.4, the whole packet suffers from an error rate close to 1. So, in such a case error recovery for RLP frame makes sense. And if RLP frames suffer from a corruption rate 0.3 or 0.4, it would make sense to allow more than one retransmission in order to keep the whole packet corruption rate acceptable small. However, and perhaps you have this in mind, the important question is: What are the effective packet delay and the packet corruption rate, thus basically the "throughput", perceived by the user? Does it make sense to run TCP and applications built upon this in a "noisy environment"? You may well argue that running network applications in the presence of a BLER of 0.3 or 0.4 is simply inappropriate, not to say simply stupid. Some years ago, I had to deal with "adaptation". The task was to built "adaptive multimedia applications" for mobile networks. Simply spoken, this is like Mrs. Jones, who is out of coffee. So, Mrs. Jones has two possibilities. First: Go to the store and buy some. Second: Drink tea instead. (I?m not Mrs. Jones. When I?m out of tea, I have two possibilites. First: Go to the store and buy some. Second: Be in an extremely bad mood.) However, in our project, we hat another possibility: Simply adapt Mrs. Jones :-) > You can tell because of the order of magnitude of the actual delays > observed (seconds) compared with the time constants of the MAC layers > involved (one or two digit milliseconds). That's why I said to look > at buffering in queues above the PHY and Medium Access layers - the > network transport layers. Absolutely. However, queues don?t pile up by themselves. That?s why I currently build a simulator component. So I can simulate, and hopefully understand, what?s happening here. > > Regarding Aloha et al., it's clear that the point of Aloha is to be > memoryless. Every new packet comes along and pretends that no memory > of the past is relevant, no knowledge of the demand by other users and > terminals is relevant, and no knowledge of the propagation environment > is relevant. This is true only if devices are built without sensing, > without memory, etc. OR if the environment is so unpredictable as to > benefit not at all from memory and state. > Does this mean that it basically doesn?t matter in a memoryless environment whether I use a PCF or a DCF (spoken in WLAN terms)? At least as long as I dont have any QoS requirements (which I totally ignore for the moment). > Aloha makes only a trivial assumption (short-term channel state > coherence) and only requires trivial algorithmic state (the backoff > time). Nothing especially good about that, other than being somewhat > universal and awfully cheap to implement. > Just wrt ALOHA: I often found references to the Abramson paper which introduced ALOHA. Unfortunately, I never got it anywhere. I would appreciate if it would be possible to send me copy of this work, if this is possible. It?s just one of the network classics :-) > That said, protocols that build low level circuits by TDM or whatever > are making an implicit assumption of coherence of channel state, > stability of demand (constant rate), and totally anticipated future. > Nothing especially good about that. > > Everything else is detail. Most of the detail added to either > approach is usually got wrong. KISS (Keep it simple, stupid) is a > good engineering maxim here. May I qoute this one: > Complexity is what engineers do when they don't have a clue what > they are designing for, and want to impress their friends. > > iu my signature? :-) From sambits at us.ibm.com Tue Mar 13 20:20:45 2007 From: sambits at us.ibm.com (Sambit Sahu) Date: Tue, 13 Mar 2007 23:20:45 -0400 Subject: [e2e] CFP for IEEE ICNP 2007 Message-ID: Dear colleague: Our sincere apologies if you receive multiple copies of this announcement. -- ICNP 2007 organizers ICNP 2007 CALL FOR PAPER 15th IEEE International Conference on Network Protocols Beijing, CHINA, October 16-19, 2007 ICNP 2007, the fifteenth IEEE International Conference on Network Protocols, is a conference covering all aspects of network protocols, including design, analysis, specification, verification, implementation, and performance. ICNP 2007 will be held in Beijing, CHINA, October 16-19, 2007. Papers with significant research contributions to the field of network protocols are solicited for submission. Papers cannot be previously published nor under review by another conference or journal. Topics of interest include, but are not limited to: 1. Protocol testing, analysis, design and implementation 2. Measurement and monitoring of protocols 3. Protocols designed for specific functions, such as: routing, flow and congestion control, QoS, signaling, security, network management, or resiliency 4. Protocols designed for specific networks, such as: wireless and mobile networks, ad hoc and sensor networks, virtual networks, and ubiquitous networks Quality papers dealing specifically with protocols will be preferred over quality papers of a more general networking nature. ICNP will select an accepted full paper for the best paper award. IMPORTANT DATES Paper registration: April 8, 2007 Paper submission: April 15, 2007 Notification of acceptance: June 29, 2007 Camera ready version: July 20, 2007 For paper submission, please visit http://icnp2007.edu.cn/ ORGANIZING COMMITTEES EXECUTIVE COMMITTEE: David Lee, Ohio State University, USA (chair) Mostafa Ammar, Georgia Tech, USA Ken Calvert, University of Kentucky, USA Teruo Higashino, Osaka University, Japan Raymond Miller, University of Maryland, USA GENERAL CHAIR: Jianping Wu, Tsinghua University, CHINA John Lui, Chinese University of Hong Kong, CHINA VICE GENERAL CHAIR: Xia Yin,Tsinghua University, CHINA PROGRAM CHAIR: Kenneth L. Calvert, University of Kentucky, USA David Yau, Purdue University, USA WORKSHOP CHAIR: Cristina Nita-Rotaru, Purdue University, USA Prof. Xing Li, Tsinghua University, China LOCAL ARRANGEMENT CHAIR: Youjian Zhao,Tsinghua University, CHINA PUBLICATION CHAIR: Ke Xu,Tsinghua University, CHINA PUBLICITY CHAIR: Mingwei Xu,Tsinghua University, CHINA Sambit Sahu, IBM T.J. Watson, USA STEERING COMMITTEE: Simon Lam, University of Texas, USA (co-chair) David Lee, Ohio State University, USA (co-chair) Mostafa Ammar, Georgia Tech, USA Ken Calvert, University of Kentucky, USA Mohamed Gouda, University of Texas, USA Teruo Higashino, Osaka University, Japan Mike T. Liu, Ohio State University, USA Raymond Miller, University of Maryland, USA Krishan Sabnani, Bell Labs, USA PROGRAM COMMITTEE: See http://icnp2007.edu.cn/ FURTHER INFORMATION: Web site: http://icnp2007.edu.cn/ http://www.ieee-icnp.org/ E-mail: icnp2007 at tsinghua.edu.cn TEL: +86 10 62788109 FAX: +86 10 62771527 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070313/1957104b/attachment.html From arjuna at erg.abdn.ac.uk Fri Mar 23 02:07:51 2007 From: arjuna at erg.abdn.ac.uk (Arjuna Sathiaseelan) Date: Fri, 23 Mar 2007 09:07:51 -0000 Subject: [e2e] Small packets - Definition needed.. Message-ID: <200703230908.l2N97w5g011866@erg.abdn.ac.uk> Dear All, I have been trying to find out the definition of small and large packets. There are protocols such as TFRC-SP which are used for small packets. I am wondering how do we define small packets? What is the size limit? My thoughts on this is : any packet size less than 576 bytes, could be considered as small packets. And more than 576 bytes, could be termed large packets. Any thoughts. Regards Arjuna ------------------------------- Dr.Arjuna Sathiaseelan Electronics Research Group University of Aberdeen Aberdeen AB24 3UE Email: arjuna at erg.abdn.ac.uk Web: www.erg.abdn.ac.uk/users/arjuna Phone : +44-1224-272780 Fax : +44-1224-272497 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070323/0ff6a883/attachment.html From csp at csperkins.org Fri Mar 23 03:34:33 2007 From: csp at csperkins.org (Colin Perkins) Date: Fri, 23 Mar 2007 11:34:33 +0100 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: <200703230908.l2N97w5g011866@erg.abdn.ac.uk> References: <200703230908.l2N97w5g011866@erg.abdn.ac.uk> Message-ID: On 23 Mar 2007, at 10:07, Arjuna Sathiaseelan wrote: > I have been trying to find out the definition of small and large > packets. There are protocols such as TFRC-SP which are used for small > packets. I am wondering how do we define small packets? What is the > size limit? > > My thoughts on this is : any packet size less than 576 bytes, could be > considered as small packets. And more than 576 bytes, could be termed > large packets. Surely it depends on the application and environment? In the context of TFRC-SP, the aim was to support VoIP traffic, so small would be a low-rate voice codec (tens of octets of payload data per packet), but I don't think that generalises. -- Colin Perkins http://csperkins.org/ From craig at aland.bbn.com Fri Mar 23 04:44:15 2007 From: craig at aland.bbn.com (Craig Partridge) Date: Fri, 23 Mar 2007 07:44:15 -0400 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: Your message of "Fri, 23 Mar 2007 09:07:51 -0000." <200703230908.l2N97w5g011866@erg.abdn.ac.uk> Message-ID: <20070323114415.64D6D123842@aland.bbn.com> I don't know of a general definition. As I recall, for router tests in the early 1990s, the idea of a small packet was 64 bytes and big was an Ethernet MTU. Personally, I'd react that somewhere around 64 bytes is where packets get small -- as the addition of a header becomes a notable overhead. I'm not sure where I'd say "large" starts these days. Craig From dpreed at reed.com Fri Mar 23 07:20:20 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 23 Mar 2007 10:20:20 -0400 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: <200703230908.l2N97w5g011866@erg.abdn.ac.uk> References: <200703230908.l2N97w5g011866@erg.abdn.ac.uk> Message-ID: <4603E224.5000000@reed.com> 576 is a lovely number of octets. I first encountered its loveliness when I realized that it is 9 times 64. Which means that all the popular word sizes of computers divide it evenly. Thus, you can transmit packets that are composed of 72-bit, 36-bit, 64-bit, 32-bit, 24-bit, 18-bit, 16-bit, 12-bit, 8-bit, and 4-bit data arrays. And RSA-576 is the second largest number factored in the RSA Factoring Challenge (640, another number to be conjured with, was chosen by IBM and Microsoft as the limiting size of the IBM PC architecture's memory, and RSA-640 is the largest factored number in that challenge). And it has many other numerological properties. It is the sum of 2^6 and 2^9 octets. 69 is a wonderful reference (at least in English speaking countries). If you add the number 90 to it, it generates the biblical number we must not refer to here. If you subtract 80 from it, you get one of the "perfect" numbers. So it stands in the middle between perfectability and evil. Arjuna Sathiaseelan wrote: > > Dear All, > I have been trying to find out the definition of small and large > packets. There are protocols such as TFRC-SP which are used for small > packets. I am wondering how do we define small packets? What is the > size limit? > > My thoughts on this is : any packet size less than 576 bytes, could be > considered as small packets. And more than 576 bytes, could be termed > large packets. > > Any thoughts. > > Regards > Arjuna > > > > ------------------------------- > > Dr.Arjuna Sathiaseelan > > Electronics Research Group > > University of Aberdeen > > Aberdeen AB24 3UE > > Email: arjuna at erg.abdn.ac.uk > > Web: www.erg.abdn.ac.uk/users/arjuna > > > Phone : +44-1224-272780 > Fax : +44-1224-272497 > > > From dpreed at reed.com Fri Mar 23 08:50:46 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 23 Mar 2007 11:50:46 -0400 Subject: [e2e] Proposing the Sathiaseelan-Partridge Law of Mice and Elephants In-Reply-To: <4603E224.5000000@reed.com> References: <200703230908.l2N97w5g011866@erg.abdn.ac.uk> <4603E224.5000000@reed.com> Message-ID: <4603F756.1010801@reed.com> Another reaction is that "fixed size fields" always get us into trouble,so we should never define a fixed size without indexing it temporally. I always regret the IP protocol chose 32-bit addresses of type A, B, and C got us NAT boxes that are now viewed as "good things" even as they balkanize the Internet, destroying the Internet's universal goal of interoperability and interconnectivity. So we should be careful about picking any number. One possibility is to pick a "law" to generate the number. If Craig is right that the correct number was 64 bytes in 1991, and Arjun's right that 576 is the right number in 2007, let's assume it's an exponential, and the result we get is: N = 2 ^ [6 + (1/8 * log 3) * (Y - 1991)] I propose we call this "Sathiaseelan-Partridge Law of Mice and Elephants". All protocol engineers can thus tune their work and measurements can be indexed to this growth law. The Internet economic process can use it to design its roadmap of protocol field size evolution. Etc. It may be extremely helpful to know that the doubling time of packet distinctions is predictable. Moore's Law is 18 months. Sathiaseelan-Partridge predicts mouse-scale packet doubling every 61 months or so. From touch at ISI.EDU Mon Mar 26 07:40:10 2007 From: touch at ISI.EDU (Joe Touch) Date: Mon, 26 Mar 2007 07:40:10 -0700 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: <20070323114415.64D6D123842@aland.bbn.com> References: <20070323114415.64D6D123842@aland.bbn.com> Message-ID: <4607DB4A.6080609@isi.edu> Craig Partridge wrote: > I don't know of a general definition. > > As I recall, for router tests in the early 1990s, the idea of a small packet > was 64 bytes and big was an Ethernet MTU. 64 bytes was the smallest effective link size, since Ethernet padded everything smaller out to 64 bytes. As a result, it often doesn't make sense to think of packets being smaller on ethernet links. > Personally, I'd react that somewhere around 64 bytes is where packets get > small -- as the addition of a header becomes a notable overhead. I'm not > sure where I'd say "large" starts these days. When the header becomes notable depends on the header: UDP/IPv4/PPP = 30 TCP/IPv6/IPsec/IPv6/ether+VLAN/GFP = 162 There's quite a bit of range there, but the relative size of headers to payload is a good place to start. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070326/1fc16881/signature.bin From rhee at eos.ncsu.edu Mon Mar 26 14:16:19 2007 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Mon, 26 Mar 2007 17:16:19 -0400 Subject: [e2e] Linux TCP Stack test results Message-ID: <00d201c76fec$003ea920$4a580e98@ncsu2cc0c3fa00> Hi, We put together our recent test results of Linux TCP stacks of the latest LINUX versions. We are continually adding results as they come up. This page will be used for validating our claim in the Internet draft of CUBIC. If you have a new set of test scenarios and result statistics that you want us to add, please feel free to let us know. http://netsrv.csc.ncsu.edu/wiki/index.php/TCP_Testing Thanks Injong From rhee at eos.ncsu.edu Mon Mar 26 14:20:33 2007 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Mon, 26 Mar 2007 17:20:33 -0400 Subject: [e2e] Linux TCP Stack test results Message-ID: <00d801c76fec$97129190$4a580e98@ncsu2cc0c3fa00> Further to add, if you have any new protocol stacks that you would like us to test in the same scenarios, please feel free to let us know. We can arrange something. Ultimately, our plan is to automate these tests so that a third party can schedule a new test using the existing scenarios or by submitting a new scenarios with a TCP stack. Well that has to wait until we get some more funding :-). But that is in the plan. ----- Original Message ----- From: "Injong Rhee" To: Cc: Sent: Monday, March 26, 2007 5:16 PM Subject: Linux TCP Stack test results > Hi, > We put together our recent test results of Linux TCP stacks of the latest > LINUX versions. We are continually adding results as they come up. This > page will be used for validating our claim in the Internet draft of CUBIC. > If you have a new set of test scenarios and result statistics that you > want us to add, please feel free to let us know. > > http://netsrv.csc.ncsu.edu/wiki/index.php/TCP_Testing > > Thanks > Injong > From arjuna at erg.abdn.ac.uk Mon Mar 26 15:37:11 2007 From: arjuna at erg.abdn.ac.uk (Arjuna Sathiaseelan) Date: Mon, 26 Mar 2007 23:37:11 +0100 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: <4603E224.5000000@reed.com> Message-ID: <200703262237.l2QMbGMZ012636@erg.abdn.ac.uk> Dear All, (CCing to the DCCP mailing list) Thanks a lot for your replies. >From the replies, I could see that its hard to generalize the definition of small and large packets. My only worry is that that a proper consensus has to be reached on deciding the definition of small packets as currently there seems to be an ambiguity (from my point of view) in some of the drafts when it comes to defining small packets. For example consider the TFRC-SP and Faster Restart for TFRC drafts. Draft 1) TFRC-SP says the following in the Introduction ("draft-ietf-dccp-tfrc-voip-07.txt", currently in the RFC Editor's queue): "TFRC-SP is intended for flows that need to send frequent small packets, with less than 1500 bytes per packet, limited by a minimum interval between packets of 10 ms." "Applications that are not willing to be limited by a minimum interval of 10 ms. between packets, or that want to send packets larger than 1500 bytes, should not use TFRC-SP. However, for applications with a minimum interval of at least 10 ms. between packets and with data packets of at most 1500 bytes, the performance of TFRC-SP should be at least as good as that from TFRC." Draft 2) Faster Restart for TFRC (http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-02. txt) after idle periods: the allowed sending rate is never reduced below four packets per RTT, or eight packets per RTT for small packets, as the result of an idle or slow period. FR uses a variable called X_active_min_rate: X_active_min_rate The minimum restart rate allowed by Faster Restart in the presence of idle and/or data-limited periods. Note that Faster Restart flows can drop below this rate as the result of actual loss feedback. X_active_min_rate is defined as follows: X_active_min_rate := min(8*s, max(4*s, 8760 bytes)). So here the small packet is defined as anything less than 1095 bytes. As Joe Touch put forward, the relative size of header to payload could be the key to the answer. Regards Arjuna -----Original Message----- Craig Partridge wrote: > I don't know of a general definition. > > As I recall, for router tests in the early 1990s, the idea of a small > packet was 64 bytes and big was an Ethernet MTU. 64 bytes was the smallest effective link size, since Ethernet padded everything smaller out to 64 bytes. As a result, it often doesn't make sense to think of packets being smaller on ethernet links. > Personally, I'd react that somewhere around 64 bytes is where packets > get small -- as the addition of a header becomes a notable overhead. > I'm not sure where I'd say "large" starts these days. When the header becomes notable depends on the header: UDP/IPv4/PPP = 30 TCP/IPv6/IPsec/IPv6/ether+VLAN/GFP = 162 There's quite a bit of range there, but the relative size of headers to payload is a good place to start. Joe ------------------------------- From: David P. Reed [mailto:dpreed at reed.com] Sent: 23 March 2007 14:20 To: Arjuna Sathiaseelan Cc: end2end-interest at postel.org Subject: Re: [e2e] Small packets - Definition needed.. 576 is a lovely number of octets. I first encountered its loveliness when I realized that it is 9 times 64. Which means that all the popular word sizes of computers divide it evenly. Thus, you can transmit packets that are composed of 72-bit, 36-bit, 64-bit, 32-bit, 24-bit, 18-bit, 16-bit, 12-bit, 8-bit, and 4-bit data arrays. And RSA-576 is the second largest number factored in the RSA Factoring Challenge (640, another number to be conjured with, was chosen by IBM and Microsoft as the limiting size of the IBM PC architecture's memory, and RSA-640 is the largest factored number in that challenge). And it has many other numerological properties. It is the sum of 2^6 and 2^9 octets. 69 is a wonderful reference (at least in English speaking countries). If you add the number 90 to it, it generates the biblical number we must not refer to here. If you subtract 80 from it, you get one of the "perfect" numbers. So it stands in the middle between perfectability and evil. ------------------------------- Surely it depends on the application and environment? In the context of TFRC-SP, the aim was to support VoIP traffic, so small would be a low-rate voice codec (tens of octets of payload data per packet), but I don't think that generalises. -- Colin Perkins http://csperkins.org/ Arjuna Sathiaseelan wrote: > > Dear All, > I have been trying to find out the definition of small and large > packets. There are protocols such as TFRC-SP which are used for small > packets. I am wondering how do we define small packets? What is the > size limit? > > My thoughts on this is : any packet size less than 576 bytes, could be > considered as small packets. And more than 576 bytes, could be termed > large packets. > > Any thoughts. > > Regards > Arjuna > > > > ------------------------------- > > Dr.Arjuna Sathiaseelan > > Electronics Research Group > > University of Aberdeen > > Aberdeen AB24 3UE > > Email: arjuna at erg.abdn.ac.uk > > Web: www.erg.abdn.ac.uk/users/arjuna > > > Phone : +44-1224-272780 > Fax : +44-1224-272497 > > > From Jon.Crowcroft at cl.cam.ac.uk Tue Mar 27 02:22:49 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 27 Mar 2007 10:22:49 +0100 Subject: [e2e] [dccp] RE: Small packets - Definition needed.. In-Reply-To: Message from "Ingemar Johansson S \(LU/EAB\)" of "Tue, 27 Mar 2007 11:16:08 +0200." <026F8EEDAD2C4342A993203088C1FC0504A9EA1B@esealmw109.eemea.ericsson.se> Message-ID: 576 is equally rediculous as 53 bytes in that it doesnt represent a good tradfe off between header wire overead versus payload, header processing time and payload, serialisation delays in modern codecs, or any recognizable unit of page/disk block, or any sensible zero copy stack programming models. time to move on. I think colin perkins has the right idea - we should use 666 bits with 6 bit hyper-expontial mu-law samples for audio and 333 bit samples for dct run length huffman coded blocks for HD video, and 111 bits for most wireless game consle controllers, and all 666 bits for direct neural implants. j From dmchiu at ie.cuhk.edu.hk Tue Mar 27 02:34:38 2007 From: dmchiu at ie.cuhk.edu.hk (Dah Ming Chiu) Date: Tue, 27 Mar 2007 17:34:38 +0800 Subject: [e2e] Small packets - Definition needed.. References: <200703262237.l2QMbGMZ012636@erg.abdn.ac.uk> Message-ID: <00bc01c77053$2b126210$db60bd89@IESTP19> A natural reason for discussing "small" vs "large" packets is concerned with the packet header overhead, as several people suggested. For example, when the header size is smaller than certain percentage of the total packet size, you can ignore the overhead in your engineering considerations. Arjuna's problems, as stated in his latest email, are different. In the case of "Draft 1", you can avoid the problem by simply rephrasing the sentence to: "TFRC-SP is intended for flows that send packets no larger than 1500 bytes with inter-packet intervals no smaller than 10 ms". The "small" here is something quite arbitrary due to the specific design of TFRC-SP that when satisfied makes TFRC-SP work better than TFRC. In the case of "Draft 2", you can avoid the problem by simply replacing the word "small packets" by "packets no smaller than 1095 bytes". In other words, you don't need to define "small". If you are trying to justify "1095 bytes", it will not be easy, and you will not get people to agree. You could have picked 1500 or 800, I doubt there is a big difference. It is just an engineering constant. Why do we need such an engineering constant? It is like the problem of how loud are we allowed to talk in a public place with other people around. In most civilized places, it is rude to talk too loud. Since network protocols codify the level of "rudeness" into programs, you get to pick these numbers. Of course you will not get concensus on what level of rudeness is appropriate. Whether this (IETF policying it) works or not, and how you may want to accommodate different people under different circumstances, is a different debate, which has been played out on this list many times in the past. Dah Ming Chiu CUHK ----- Original Message ----- From: "Arjuna Sathiaseelan" To: Cc: ; Sent: Tuesday, March 27, 2007 6:37 AM Subject: Re: [e2e] Small packets - Definition needed.. > Dear All, (CCing to the DCCP mailing list) > > Thanks a lot for your replies. > >>From the replies, I could see that its hard to generalize the definition >>of > small and large packets. My only worry is that that a proper consensus has > to be reached on deciding the definition of small packets as currently > there > seems to be an ambiguity (from my point of view) in some of the drafts > when > it comes to defining small packets. For example consider the TFRC-SP and > Faster Restart for TFRC drafts. > > > Draft 1) TFRC-SP says the following in the Introduction > ("draft-ietf-dccp-tfrc-voip-07.txt", currently in the RFC Editor's > queue): > > "TFRC-SP is intended for flows that need to send frequent small > packets, with less than 1500 bytes per packet, limited by a minimum > interval between packets of 10 ms." > > "Applications that are not willing to be limited by a minimum > interval of 10 ms. between packets, or that want to send packets > larger than 1500 bytes, should not use TFRC-SP. However, for > applications with a minimum interval of at least 10 ms. between > packets and with data packets of at most 1500 bytes, the performance > of TFRC-SP should be at least as good as that from TFRC." > > Draft 2) Faster Restart for TFRC > (http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-02. > txt) after idle periods: the allowed sending rate is never reduced below > four packets per RTT, or eight packets per RTT for small packets, as the > result of an idle or slow period. > > FR uses a variable called X_active_min_rate: > X_active_min_rate > The minimum restart rate allowed by Faster Restart in the presence > of idle and/or data-limited periods. Note that Faster Restart > flows can drop below this rate as the result of actual loss > feedback. X_active_min_rate is defined as follows: > > X_active_min_rate := min(8*s, max(4*s, 8760 bytes)). > > So here the small packet is defined as anything less than 1095 bytes. > > As Joe Touch put forward, the relative size of header to payload could be > the key to the answer. > > Regards > Arjuna > > -----Original Message----- > Craig Partridge wrote: >> I don't know of a general definition. >> >> As I recall, for router tests in the early 1990s, the idea of a small >> packet was 64 bytes and big was an Ethernet MTU. > > 64 bytes was the smallest effective link size, since Ethernet padded > everything smaller out to 64 bytes. As a result, it often doesn't make > sense > to think of packets being smaller on ethernet links. > >> Personally, I'd react that somewhere around 64 bytes is where packets >> get small -- as the addition of a header becomes a notable overhead. >> I'm not sure where I'd say "large" starts these days. > > When the header becomes notable depends on the header: > > UDP/IPv4/PPP = 30 > TCP/IPv6/IPsec/IPv6/ether+VLAN/GFP = 162 > > There's quite a bit of range there, but the relative size of headers to > payload is a good place to start. > > Joe > > ------------------------------- > From: David P. Reed [mailto:dpreed at reed.com] > Sent: 23 March 2007 14:20 > To: Arjuna Sathiaseelan > Cc: end2end-interest at postel.org > Subject: Re: [e2e] Small packets - Definition needed.. > > 576 is a lovely number of octets. I first encountered its loveliness > when I realized that it is 9 times 64. Which means that all the > popular word sizes of computers divide it evenly. Thus, you can > transmit packets that are composed of 72-bit, 36-bit, 64-bit, 32-bit, > 24-bit, 18-bit, 16-bit, 12-bit, 8-bit, and 4-bit data arrays. > > And RSA-576 is the second largest number factored in the RSA Factoring > Challenge (640, another number to be conjured with, was chosen by IBM > and Microsoft as the limiting size of the IBM PC architecture's memory, > and RSA-640 is the largest factored number in that challenge). > > And it has many other numerological properties. It is the sum of 2^6 > and 2^9 octets. 69 is a wonderful reference (at least in English > speaking countries). > > If you add the number 90 to it, it generates the biblical number we must > not refer to here. If you subtract 80 from it, you get one of the > "perfect" numbers. So it stands in the middle between perfectability > and evil. > > ------------------------------- > > Surely it depends on the application and environment? In the context of > TFRC-SP, the aim was to support VoIP traffic, so small would be a low-rate > voice codec (tens of octets of payload data per packet), but I don't think > that generalises. > > -- > Colin Perkins > http://csperkins.org/ > > > Arjuna Sathiaseelan wrote: >> >> Dear All, >> I have been trying to find out the definition of small and large >> packets. There are protocols such as TFRC-SP which are used for small >> packets. I am wondering how do we define small packets? What is the >> size limit? >> >> My thoughts on this is : any packet size less than 576 bytes, could be >> considered as small packets. And more than 576 bytes, could be termed >> large packets. >> >> Any thoughts. >> >> Regards >> Arjuna >> >> >> >> ------------------------------- >> >> Dr.Arjuna Sathiaseelan >> >> Electronics Research Group >> >> University of Aberdeen >> >> Aberdeen AB24 3UE >> >> Email: arjuna at erg.abdn.ac.uk >> >> Web: www.erg.abdn.ac.uk/users/arjuna >> >> >> Phone : +44-1224-272780 >> Fax : +44-1224-272497 >> >> >> > From detlef.bosau at web.de Tue Mar 27 07:05:56 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 27 Mar 2007 16:05:56 +0200 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: <00bc01c77053$2b126210$db60bd89@IESTP19> References: <200703262237.l2QMbGMZ012636@erg.abdn.ac.uk> <00bc01c77053$2b126210$db60bd89@IESTP19> Message-ID: <460924C4.6080705@web.de> Dah Ming Chiu wrote: > A natural reason for discussing "small" vs "large" packets is concerned > with the packet header overhead, as several people suggested. For Yes. There is a tradeoff between packet lenght and header size. That?s well known. However, to me this whole discussion seems to be an engineering discussion, related to certain technologies. I never gave much thought absolute packet sizes, IIRC 536 was motivated by some SLIP pecularities, 1500 is somewhat Ethernet related. So, tomorrow someone will invent a new technology - and packets may be much larger. Of course, traffic shall be not too bursty, so one should consider a packet?s temporal length on a certain netwok. In Ethernet, a packet may last 1.2 ms. So, that?s obviously acceptable. So, why shouldn?t wie use packets which last 1.2 ms on a Terbit network? Then a maximum packet size would be 150 MByte. Then we have a look at applications. How large is an e-mail? (O.k., let?s leave out those written by me ;-)) 10 kByte? 1 kByte? Or when the newest DVD immage is attached: 2 Gbyte? And how large should IP packets be then? Personally, 1500 bytes is somewhat a "magic number" to me, perhpas not only for me, for historical reasons and Ethernet influence. However, "small", "large" are relative attributes. I can say a packet is "small" compared to an average packet length. But I don?t see a sense in defining "small" to, say, less then 500 bytes. Perhaps, tomorrow 90 % of packets are larger than 100.000 bytes and then 90.000 bytes would be "small". So, in my opinion we can give some orientation what is "small" or "large" in some "best current practice" RFC which reflects the actual situation, i.e. "spring 2007". But I don?t see a sense in a generic definition. Detlef From huitema at windows.microsoft.com Tue Mar 27 16:27:22 2007 From: huitema at windows.microsoft.com (Christian Huitema) Date: Tue, 27 Mar 2007 16:27:22 -0700 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: <460924C4.6080705@web.de> References: <200703262237.l2QMbGMZ012636@erg.abdn.ac.uk><00bc01c77053$2b126210$db60bd89@IESTP19> <460924C4.6080705@web.de> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064040E1D8D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> > Dah Ming Chiu wrote: > > A natural reason for discussing "small" vs "large" packets is > concerned > > with the packet header overhead, as several people suggested. For > > Yes. There is a tradeoff between packet lenght and header size. That?s > well known. There is another dimension, besides overhead. It has to do with queue management and you of course now that the Internet is made of a big collection of tubes through which the information flows. The packet size affects how your packets are going to flow in "the tubes". Small packets flow like sand, big ones like rocks. -- Christian Huitema From detlef.bosau at web.de Wed Mar 28 05:08:01 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 28 Mar 2007 14:08:01 +0200 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064040E1D8D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <200703262237.l2QMbGMZ012636@erg.abdn.ac.uk><00bc01c77053$2b126210$db60bd89@IESTP19> <460924C4.6080705@web.de> <70C6EFCDFC8AAD418EF7063CD132D064040E1D8D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <460A5AA1.4030202@web.de> Christian Huitema wrote: >> Dah Ming Chiu wrote: >> >>> A natural reason for discussing "small" vs "large" packets is >>> >> concerned >> >>> with the packet header overhead, as several people suggested. For >>> >> Yes. There is a tradeoff between packet lenght and header size. That?s >> well known. >> > > There is another dimension, besides overhead. It has to do with queue management and you of course now that the Internet is made of a big collection of tubes through which the information flows. The packet size affects how your packets are going to flow in "the tubes". Small packets flow like sand, big ones like rocks. > > And that again depends on the technology in use. On a slow modem line a 5000 byte packet, if allowed at all, is similar to Ayers Rock. In a 10 Tbps network, its finest sand not to say nearly water ;-) I think, the temporal length is important here to see what jitter can be caused by packets of a certain size. Detlef From matthew.roughan at adelaide.edu.au Wed Mar 28 17:28:47 2007 From: matthew.roughan at adelaide.edu.au (Matthew Roughan) Date: Thu, 29 Mar 2007 09:58:47 +0930 Subject: [e2e] CFP Internet Measurement Conference (IMC) 2007 Message-ID: <460B083F.5000705@adelaide.edu.au> http://www.imconf.net/imc-2007/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: imc07-cfp.txt Url: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070329/59a26649/imc07-cfp.txt From dpreed at reed.com Fri Mar 30 15:48:58 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 30 Mar 2007 18:48:58 -0400 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: <460924C4.6080705@web.de> References: <200703262237.l2QMbGMZ012636@erg.abdn.ac.uk> <00bc01c77053$2b126210$db60bd89@IESTP19> <460924C4.6080705@web.de> Message-ID: <460D93DA.6090204@reed.com> I understood Arjuna to be asking about a boundary line between small and large. That has nothing, of course, to do with any "optimum" overhead, etc. One would expect large to be larger than the boundary line, and small to be smaller. In fact, the idea that a size is a really bad choice makes it a good breakpoint - one won't find much argument if the cumulative distribution function is flat in the region one picks. Once upon a time, 576 would have been viewed as large (and common) packets. Now we see them only in certain topologies, as the typical FTP and HTTP packets soar to the artificial limit of 1500 or so (reminds me of the "640K PC memory limit" or the "32-bit IP address" - bad choices that stopped progress for no particularly good reason). From dpreed at reed.com Fri Mar 30 18:01:47 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 30 Mar 2007 21:01:47 -0400 Subject: [e2e] Small packets - Definition needed.. In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064040E1D8D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <200703262237.l2QMbGMZ012636@erg.abdn.ac.uk><00bc01c77053$2b126210$db60bd89@IESTP19> <460924C4.6080705@web.de> <70C6EFCDFC8AAD418EF7063CD132D064040E1D8D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <460DB2FB.4010205@reed.com> I've been for a while now suggesting that we should design networks as if they are in a phase analogous to the liquid phase. Let's eliminate the rocks - a crusher or two would do the job. Then the sand could be turned into a slurry by applying some high frequency acoustic energy at the SIP control points. Christian Huitema wrote: >> Dah Ming Chiu wrote: >> >>> A natural reason for discussing "small" vs "large" packets is >>> >> concerned >> >>> with the packet header overhead, as several people suggested. For >>> >> Yes. There is a tradeoff between packet lenght and header size. That?s >> well known. >> > > There is another dimension, besides overhead. It has to do with queue management and you of course now that the Internet is made of a big collection of tubes through which the information flows. The packet size affects how your packets are going to flow in "the tubes". Small packets flow like sand, big ones like rocks. > > -- Christian Huitema > > > > > > From rhee at eos.ncsu.edu Sat Mar 31 15:44:17 2007 From: rhee at eos.ncsu.edu (Injong Rhee) Date: Sat, 31 Mar 2007 17:44:17 -0500 Subject: [e2e] Linux TCP Stack test results In-Reply-To: References: <00d801c76fec$97129190$4a580e98@ncsu2cc0c3fa00> Message-ID: Unfortunately, we are not yet ready to give an account to control the test. However, if you can give us the protocol stack to be tested, we can test it for you. On Mar 31, 2007, at 5:19 AM, Daniel Schaffrath wrote: > Thanks, Injong. > > Are there any ways to acquire an account? > > Daniel > > > On 2007/03/26 , at 23:20, Injong Rhee wrote: > >> Further to add, if you have any new protocol stacks that you would >> like us to test in the same scenarios, please feel free to let us >> know. We can arrange something. Ultimately, our plan is to automate >> these tests so that a third party can schedule a new test using the >> existing scenarios or by submitting a new scenarios with a TCP stack. >> Well that has to wait until we get some more funding :-). But that is >> in the plan. >> >> ----- Original Message ----- From: "Injong Rhee" >> To: >> Cc: >> Sent: Monday, March 26, 2007 5:16 PM >> Subject: Linux TCP Stack test results >> >> >>> Hi, >>> We put together our recent test results of Linux TCP stacks of the >>> latest LINUX versions. We are continually adding results as they >>> come up. This page will be used for validating our claim in the >>> Internet draft of CUBIC. If you have a new set of test scenarios and >>> result statistics that you want us to add, please feel free to let >>> us know. >>> >>> http://netsrv.csc.ncsu.edu/wiki/index.php/TCP_Testing >>> >>> Thanks >>> Injong >> >> >