From marcel at end2end.l.wanda.ch Mon Nov 1 00:15:59 2004 From: marcel at end2end.l.wanda.ch (Marcel Waldvogel) Date: Mon Nov 1 00:16:26 2004 Subject: [e2e] Internet path dynamics In-Reply-To: <16770.56656.573619.976199@roam.psg.com> References: <200409220011.i8M0BTp3043151@jaguar.icir.org> <4182CCB6.9020207@end2end.l.wanda.ch> <16770.56656.573619.976199@roam.psg.com> Message-ID: <4185F0BF.1080508@end2end.l.wanda.ch> Randy, Thank you for the pointer. Unfortunately, RouteViews still only seems to keep track of BGP-level connectivity and changes. The data I would be interested in would hop-by-hop (i.e., router-by-router) changes of paths. But it seems that no such data is currently available. -Marcel Randy Bush wrote: >http://route-views.org/ > > From jeroen at unfix.org Mon Nov 1 00:26:56 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Mon Nov 1 00:27:25 2004 Subject: [e2e] Internet path dynamics In-Reply-To: <4185F0BF.1080508@end2end.l.wanda.ch> References: <200409220011.i8M0BTp3043151@jaguar.icir.org> <4182CCB6.9020207@end2end.l.wanda.ch> <16770.56656.573619.976199@roam.psg.com> <4185F0BF.1080508@end2end.l.wanda.ch> Message-ID: <1099297616.13314.4.camel@firenze.zurich.ibm.com> On Mon, 2004-11-01 at 09:15 +0100, Marcel Waldvogel wrote: > Randy, > > Thank you for the pointer. Unfortunately, RouteViews still only seems to > keep track of BGP-level connectivity and changes. The data I would be > interested in would hop-by-hop (i.e., router-by-router) changes of > paths. But it seems that no such data is currently available. What about http://ris.ripe.net then? :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041101/278820de/attachment.bin From randy at psg.com Mon Nov 1 09:03:43 2004 From: randy at psg.com (Randy Bush) Date: Mon Nov 1 09:04:25 2004 Subject: [e2e] Internet path dynamics References: <200409220011.i8M0BTp3043151@jaguar.icir.org> <4182CCB6.9020207@end2end.l.wanda.ch> <16770.56656.573619.976199@roam.psg.com> <4185F0BF.1080508@end2end.l.wanda.ch> Message-ID: <16774.27759.760080.486991@ran.psg.com> > Thank you for the pointer. Unfortunately, RouteViews still only seems to > keep track of BGP-level connectivity and changes. The data I would be > interested in would hop-by-hop (i.e., router-by-router) changes of > paths. But it seems that no such data is currently available. marcel, you are correct. very isps even gather or keep those data internally. randy From randy at psg.com Mon Nov 1 10:01:10 2004 From: randy at psg.com (Randy Bush) Date: Mon Nov 1 10:01:25 2004 Subject: [e2e] Internet path dynamics References: <200409220011.i8M0BTp3043151@jaguar.icir.org> <4182CCB6.9020207@end2end.l.wanda.ch> <16770.56656.573619.976199@roam.psg.com> <4185F0BF.1080508@end2end.l.wanda.ch> <16774.27759.760080.486991@ran.psg.com> Message-ID: <16774.31206.100011.468277@ran.psg.com> > you are correct. very isps even gather or keep those data ^ few > internally. From nischal at lamar.colostate.edu Mon Nov 1 10:13:05 2004 From: nischal at lamar.colostate.edu (Nischal Piratla) Date: Mon Nov 1 10:12:29 2004 Subject: [e2e] Internet path dynamics Message-ID: <4188132D@webmail.colostate.edu> Marcel, You may already know about this forum, if not, you can try asking them for such data: http://www.nanog.org/mailinglist.html - Nischal >===== Original Message From Randy Bush ===== >> Thank you for the pointer. Unfortunately, RouteViews still only seems to >> keep track of BGP-level connectivity and changes. The data I would be >> interested in would hop-by-hop (i.e., router-by-router) changes of >> paths. But it seems that no such data is currently available. > >marcel, > >you are correct. very isps even gather or keep those data >internally. > >randy /****************************************** Research Assistant Computer Networking Research Laboratory Department of Electrical and Computer Eng. 1373, Colorado State University, Fort Collins, CO 80523 USA http://www.cnrl.colostate.edu http://lamar.colostate.edu/~nischal ******************************************* From dima at krioukov.net Mon Nov 1 12:51:55 2004 From: dima at krioukov.net (Dmitri Krioukov) Date: Mon Nov 1 12:53:41 2004 Subject: [e2e] Internet path dynamics In-Reply-To: <4182CCB6.9020207@end2end.l.wanda.ch> Message-ID: marcel, could you please point me to the igp-monitoring studies? thanks, -- dima. http://www.caida.org/~dima/ > -----Original Message----- > From: end2end-interest-bounces@postel.org > [mailto:end2end-interest-bounces@postel.org]On Behalf Of Marcel > Waldvogel > Sent: Friday, October 29, 2004 4:05 PM > To: end2end-interest@postel.org > Subject: Re: [e2e] Internet path dynamics > > > I am looking for data on how frequently the actual routing path changes. > I am aware of studies that infer BGP AS route changes and those that > monitor OSPF messages, but for our work, we would be interested in the > rate of change to the set of routers on an end-to-end path. > > As I do not want to flood arbitrary sites with constant traceroutes (see > the "probing and laws" thread) nor limit myself to skewed subsets (such > as PlanetLab), I would appreciate pointers to existing data sets. > > -Marcel > > >You may find: > > > > On the Constancy of Internet Path Properties > > Y. Zhang, N. Duffield, V. Paxson, and S. Shenker > > Proc. ACM SIGCOMM Internet Measurement Workshop, November 2001. > > > > http://www.icir.org/vern/papers/constancy-IMW01.ps.gz > > > >of interest in this regard. > > > > Vern > > > > From jshen_cad at yahoo.com.cn Tue Nov 2 03:29:24 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Tue Nov 2 03:30:30 2004 Subject: [e2e] Internet path dynamics In-Reply-To: <4182CCB6.9020207@end2end.l.wanda.ch> Message-ID: <20041102112924.40096.qmail@web15401.mail.cnb.yahoo.com> If OSPF-ECMP or similar technique is used, you could find route swan between routers between packets. I met such thing when trying to traceroute to a Japanese server. Sometimes route table analysis may not be adquate because even packet flow through the same router the address it shows may be different ( PBR or load balancing configurations). regards jing shen > I am looking for data on how frequently the actual > routing path changes. > I am aware of studies that infer BGP AS route > changes and those that > monitor OSPF messages, but for our work, we would be > interested in the > rate of change to the set of routers on an > end-to-end path. > > As I do not want to flood arbitrary sites with > constant traceroutes (see > the "probing and laws" thread) nor limit myself to > skewed subsets (such > as PlanetLab), I would appreciate pointers to > existing data sets. > > -Marcel > > >You may find: > > > > On the Constancy of Internet Path Properties > > Y. Zhang, N. Duffield, V. Paxson, and S. Shenker > > Proc. ACM SIGCOMM Internet Measurement Workshop, > November 2001. > > > > > http://www.icir.org/vern/papers/constancy-IMW01.ps.gz > > > >of interest in this regard. > > > > Vern > > > > > > ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From Jon.Crowcroft at cl.cam.ac.uk Thu Nov 4 01:13:03 2004 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu Nov 4 01:13:48 2004 Subject: [e2e] NAT traversal for src+dst routing Message-ID: File this under Truly Horrible Idea/Concept/Kludge (T.H.I.C.K.) reading some stuff recently about how MPLS can be used to do various traffic engineering hacks that "cannot" be done with normal IP forwarding as it would need source+destination, which we "know" doesnt scale (if there's an algorithm for labels, i dont quite see why an algorithm for fast longest prefix packet classification doesnt just double in time/space for src+dst given both are in the FIB anyhow, but hey...) so i was also reading about various cute NAT traversal hacks (many aimed at allowing incoming SIP signaling for end-customer VOIP calls etc.... so one can combine these - if a provider has a set of destination prefixes that are used to share out load over various paths, then one can achieve src+dst routing by looking at the _source_ of the call at the application layer hack that triggers the nat traversal, and put in a NAT globally reachable address on the public side from the appropriate _destination_ prefix in - then the src is irrelevant - but different sources or potentially the same source with different calls are going to different "destinations" i.e. a NAT is a label switch - it operates in a nice part of the architecture where we (the end users, not the router and swithc vendors) can still play... the statefulness of the NAT is no different (in terms of being yucky) from the statefulness of forwarding equivalence classes - there are several _different_ ways one might implement the state instantiation (but all are just slight enhancements to NAT traversal stuff) the really neat thing is that this works _inter-domain_ (albeit potentially making the multi-homing pressure on BGP and use of all the BGP wunderkind hacks of path prepending and MEDs and whatever even more stressful...:-) In fact, if implemented AT the border, we might call this Border Address Translation even better than getting fingerprinted j. From fu at cs.uni-goettingen.de Thu Nov 4 01:43:33 2004 From: fu at cs.uni-goettingen.de (Xiaoming Fu) Date: Thu Nov 4 01:44:52 2004 Subject: [e2e] NAT traversal for src+dst routing In-Reply-To: References: Message-ID: <4189F9C5.2020803@cs.uni-goettingen.de> Jon, Binding/Address-mapping state instantiation (as well as maintenance and deletion) for NAT devices is being discussed in IETF NSIS WG (previously also in MIDCOM); http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-04.txt describes a soft-state based approach. Is this a way you'd expect? Cheers, Xiaoming Jon Crowcroft wrote: > File this under > Truly Horrible Idea/Concept/Kludge (T.H.I.C.K.) > > reading some stuff recently about how MPLS can be used to do various > traffic engineering hacks that "cannot" be done with normal IP > forwarding as it would need source+destination, which we "know" doesnt > scale (if there's an algorithm for labels, i dont quite see why an > algorithm for fast longest prefix packet classification doesnt just > double in time/space for src+dst given both are in the FIB anyhow, but > hey...) > > so i was also reading about various cute NAT traversal hacks (many > aimed at allowing incoming SIP signaling for end-customer VOIP calls > etc.... > > so one can combine these - if a provider has a set of destination > prefixes that are used to share out load over various paths, then one > can achieve src+dst routing by looking at the _source_ of the call at the > application layer hack that triggers the nat traversal, and put in a > NAT globally reachable address on the public side from the > appropriate _destination_ prefix in - then the src is irrelevant - but > different sources or potentially the same source with different calls > are going to different "destinations" > > i.e. a NAT is a label switch - it operates in a nice part of the > architecture where we (the end users, not the router and swithc > vendors) can still play... > > the statefulness of the NAT is no different (in terms of being yucky) > from the statefulness of forwarding equivalence classes - there are > several _different_ ways one might implement the state instantiation > (but all are just slight enhancements to NAT traversal stuff) > > the really neat thing is that this works _inter-domain_ (albeit > potentially making the multi-homing pressure on BGP and use of all the > BGP wunderkind hacks of path prepending and MEDs and whatever even > more stressful...:-) > > In fact, if implemented AT the border, we might call this > Border Address Translation > > even better than getting fingerprinted > > j. From marcel at end2end.l.wanda.ch Thu Nov 4 07:46:02 2004 From: marcel at end2end.l.wanda.ch (Marcel Waldvogel) Date: Thu Nov 4 07:46:56 2004 Subject: [e2e] Internet path dynamics In-Reply-To: References: Message-ID: <418A4EBA.3090307@end2end.l.wanda.ch> Dmitri, the ones I know are due to personal communications and seem to be based on informal sources or close personal contacts with ISPs. As such, there is really nothing public I can point you to, sorry. -Marcel Dmitri Krioukov wrote: >marcel, > >could you please point me to the igp-monitoring studies? > >thanks, >-- >dima. >http://www.caida.org/~dima/ > > > >>-----Original Message----- >>From: end2end-interest-bounces@postel.org >>[mailto:end2end-interest-bounces@postel.org]On Behalf Of Marcel >>Waldvogel >>Sent: Friday, October 29, 2004 4:05 PM >>To: end2end-interest@postel.org >>Subject: Re: [e2e] Internet path dynamics >> >> >>I am looking for data on how frequently the actual routing path changes. >>I am aware of studies that infer BGP AS route changes and those that >>monitor OSPF messages, but for our work, we would be interested in the >>rate of change to the set of routers on an end-to-end path. >> >>As I do not want to flood arbitrary sites with constant traceroutes (see >>the "probing and laws" thread) nor limit myself to skewed subsets (such >>as PlanetLab), I would appreciate pointers to existing data sets. >> >>-Marcel >> >> >> >>>You may find: >>> >>> On the Constancy of Internet Path Properties >>> Y. Zhang, N. Duffield, V. Paxson, and S. Shenker >>> Proc. ACM SIGCOMM Internet Measurement Workshop, November 2001. >>> >>> http://www.icir.org/vern/papers/constancy-IMW01.ps.gz >>> >>>of interest in this regard. >>> >>> Vern >>> >>> From touch at ISI.EDU Thu Nov 4 08:37:58 2004 From: touch at ISI.EDU (Joe Touch) Date: Thu Nov 4 08:39:39 2004 Subject: [e2e] NAT traversal for src+dst routing In-Reply-To: References: Message-ID: <418A5AE6.2050504@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Crowcroft wrote: | File this under | Truly Horrible Idea/Concept/Kludge (T.H.I.C.K.) | | reading some stuff recently about how MPLS can be used to do various | traffic engineering hacks that "cannot" be done with normal IP | forwarding as it would need source+destination, which we "know" doesnt | scale (if there's an algorithm for labels, i dont quite see why an | algorithm for fast longest prefix packet classification doesnt just | double in time/space for src+dst given both are in the FIB anyhow, but | hey...) | | so i was also reading about various cute NAT traversal hacks (many | aimed at allowing incoming SIP signaling for end-customer VOIP calls | etc.... Many of these assume that the NAT conforms to a standard, notably one that exposes a) the fact that there _is_ a NAT b) the fact that there are multiple machines behind a NAT Both of these are things that some NAT users and many NAT designers want to deliberately obfuscate. I.e., cute traversal hacks work fine when the NAT _wants_ to be found, but they fail exactly where - and why - most NATs are actually deployed, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBilrmE5f5cImnZrsRAkDbAKDCSEjYOwco1dfC+LeCuKO1Z+kAUwCfTRmf tZsiVfWxRQ+7LijGV+iOVws= =UhgZ -----END PGP SIGNATURE----- From mshore at cisco.com Thu Nov 4 08:58:34 2004 From: mshore at cisco.com (Melinda Shore) Date: Thu Nov 4 08:59:50 2004 Subject: [e2e] NAT traversal for src+dst routing In-Reply-To: <418A5AE6.2050504@isi.edu> Message-ID: On Thursday, November 4, 2004, at 11:37 AM, Joe Touch wrote: > I.e., cute traversal hacks work fine when the NAT _wants_ to be found, > but they fail exactly where - and why - most NATs are actually > deployed, > IMO. Unfortunately that's probably become reasonable for several related reasons, and that's that NATs are now very widely being used as outside->inside access control devices for networks. The default policy is stupid ("any flows initiated from inside are good, any flows initiated from outside are bad") and the natural evolution is towards a mechanism for providing finer-grained policy enforcement at the edges. Yes, that's a firewall, but that's what NATs have become. Melinda From lars.eggert at netlab.nec.de Thu Nov 4 13:21:03 2004 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Thu Nov 4 14:14:32 2004 Subject: [e2e] topological locality of Internet communication? Message-ID: <418A9D3F.9020302@netlab.nec.de> Hi, since we were just talking about Internet statistics: I'm looking to get a feel of how much topological locality Internet communication exhibits, to calibrate some simulations we plan to run. Is anyone aware of measurements of how many "AS hops" typical connections cross in the Internet? Ideal would be a CDF of "AS hops crossed" for connection percentages. (I thought about looking at the TTLs of incoming TCP packets at servers, infering the OS based on TCP characteristics like nmap and using this to guess the default outbound TTL for that OS. But that yields IP hops, not AS hops.) Thanks, Lars -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3360 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041104/e254237a/smime.bin From pingpan at cs.columbia.edu Thu Nov 4 14:54:30 2004 From: pingpan at cs.columbia.edu (Ping Pan) Date: Thu Nov 4 14:55:04 2004 Subject: [e2e] topological locality of Internet communication? In-Reply-To: <418A9D3F.9020302@netlab.nec.de> Message-ID: <2DAC9E7A4640234B85975565E5D83AE17A7C37@srvcaexg01.headquarters.hammerheadsystems.com> A few years ago, from Oregon Universoty (NLANR) and Belnet (Europe), the AS-hop mean value is about 4. The max can be 7-8. I suspect that number is larger now, as we have more national IP backbones around the globe. Given the carriers will use AS aggregation for stability reasons, the actual recorded AS hops in BGP route announcement may be smaller than the actual path. - Ping > -----Original Message----- > From: end2end-interest-bounces@postel.org > [mailto:end2end-interest-bounces@postel.org] On Behalf Of Lars Eggert > Sent: Thursday, November 04, 2004 1:21 PM > To: end2end-interest@postel.org > Subject: [e2e] topological locality of Internet communication? > > > Hi, > > since we were just talking about Internet statistics: > > I'm looking to get a feel of how much topological locality Internet > communication exhibits, to calibrate some simulations we plan to run. > > Is anyone aware of measurements of how many "AS hops" typical > connections cross in the Internet? Ideal would be a CDF of "AS hops > crossed" for connection percentages. > > (I thought about looking at the TTLs of incoming TCP packets > at servers, > infering the OS based on TCP characteristics like nmap and > using this to > guess the default outbound TTL for that OS. But that yields > IP hops, not > AS hops.) > > Thanks, > Lars > -- > Lars Eggert NEC Network > Laboratories > From pingpan at cs.columbia.edu Thu Nov 4 15:07:03 2004 From: pingpan at cs.columbia.edu (Ping Pan) Date: Thu Nov 4 15:08:53 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: Message-ID: <2DAC9E7A4640234B85975565E5D83AE17A7C38@srvcaexg01.headquarters.hammerheadsystems.com> First, in the (MPLS) backbone networks, most of the links are over-provisioned, so not sure CAC and many QoS enforcement would make much use there. At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP, that can be used to carry DiffServ class. The LSP's that carry such information is called EXP-inferred LSP (E-LSP). The MPLS router can run the standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the packets within the LSP. This function becomes more important during flow aggregation. There are a bunch of drafts from Cisco on this topic over the years. - Ping > -----Original Message----- > From: end2end-interest-bounces@postel.org > [mailto:end2end-interest-bounces@postel.org] On Behalf Of Fahad Dogar > Sent: Wednesday, October 20, 2004 12:12 AM > To: end2end-interest@postel.org > Subject: [e2e] Admission Control and Policing in MPLS > > > Hi, > > I would like to know the mechanism employed in MPLS networks > for admission control and the process of subsequently > policing the flow in order to ensure that it does not violate the SLA. > > Any help or pointers to any standardized requirements would > be greatly appreciated. > > Thanks in advance, > Fahad > From pingpan at cs.columbia.edu Thu Nov 4 15:28:40 2004 From: pingpan at cs.columbia.edu (Ping Pan) Date: Thu Nov 4 15:29:22 2004 Subject: [e2e]where can i find an ip or host address list? In-Reply-To: <297846276.18963@hnu.cn> Message-ID: <2DAC9E7A4640234B85975565E5D83AE17A7C39@srvcaexg01.headquarters.hammerheadsystems.com> A few years ago, Vern Paxson had a setup to collect packet traces from different parts of the Internet. From which, he had derived a number of pathological behaviors about the network (check Sigcomm from 6-7 years ago). It would be very useful to see the some results from traces collected from more sample points in today's network. (Or maybe I should check Sigcomm Measurement Workshop papers before I speak ;-)) However, what you proposed below seems to be ethic-challenged. ;-) - Ping -----Original Message----- From: end2end-interest-bounces@postel.org [mailto:end2end-interest-bounces@postel.org] On Behalf Of liww Sent: Friday, October 15, 2004 7:08 AM To: end2end-interest@postel.org Subject: [e2e]where can i find an ip or host address list? hi, Now I'm doing an experiment which needs to probe 100000 more or less hosts in the Internet via ICMP and TCP with slight loads. The goal of this experiment is to find the difference between ICMP and TCP when they are used to probe host connectivity.May be I can randomly generate the amount of IP address I needed. But considering there are a great deal of unused IP addresses in the IPv4 address space,the random approach may be less efficient.One better way is to find a list with addresses or hosts name real in use. Does any one have such an IP address or hosts list? or can direct me where can i get such a list? Thanks! liww -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20041104/91d4bf8b/attachment.html From swapnil at nec-labs.com Thu Nov 4 15:30:28 2004 From: swapnil at nec-labs.com (Swapnil Patil) Date: Thu Nov 4 15:30:54 2004 Subject: [e2e] topological locality of Internet communication? In-Reply-To: <418A9D3F.9020302@netlab.nec.de> Message-ID: <000b01c4c2c6$44811580$a56b0f8a@neclabs.com> You could get some accurate data from the evaluations in the Sigcomm 2003 paper on AS-level Traceroute measurement by Jennifer Rexford et. al. (http://www.research.att.com/~jrex/papers/sigcomm03.pdf ) Regards -swapnil NEC Labs-America Princeton, NJ -----Original Message----- From: end2end-interest-bounces@postel.org [mailto:end2end-interest-bounces@postel.org] On Behalf Of Lars Eggert Sent: Thursday, November 04, 2004 4:21 PM To: end2end-interest@postel.org Subject: [e2e] topological locality of Internet communication? Hi, since we were just talking about Internet statistics: I'm looking to get a feel of how much topological locality Internet communication exhibits, to calibrate some simulations we plan to run. Is anyone aware of measurements of how many "AS hops" typical connections cross in the Internet? Ideal would be a CDF of "AS hops crossed" for connection percentages. (I thought about looking at the TTLs of incoming TCP packets at servers, infering the OS based on TCP characteristics like nmap and using this to guess the default outbound TTL for that OS. But that yields IP hops, not AS hops.) Thanks, Lars -- Lars Eggert NEC Network Laboratories From jshen_cad at yahoo.com.cn Fri Nov 5 02:45:27 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Fri Nov 5 02:45:59 2004 Subject: [e2e] QBONE abandon QoS research ? Message-ID: <20041105104527.7272.qmail@web15403.mail.cnb.yahoo.com> Hi, Maybe this is a OLD question but maybe it's valuable to find out more on DiffServ+MPLS QoS. To my knowledge, some new ISP establish QoS enabled service around but some old ISP still overprovision their backbone. QBONE could be the first testbed for QoS across WAN. But, words on their homepage (http://qbone.internet2.edu) seem to indicate they give up QoS at all while they try to find something like "less than best effort". My questions: 1. Is there any summary report/paper on their experience with DiffServ+MPLS based QoS? Have they summarized the result of implementing WRED (or similar technique) in QBONE? 2. How could QBONE be kept no congestion ? inside China, the bandwidth needed increase so quick that backbone BW or BW between ISPS need to be negotiated one or more times a year. It's really valuable to differentiate service between users, but technique like WRED seems not considering fair-treating between users, and there is also question like e2e service verification. Is there any work on this area? 3. Any paper on Congestion control inside a QoS tunnel exist? thanks Jing ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From p.trimintzios at eim.surrey.ac.uk Fri Nov 5 03:43:18 2004 From: p.trimintzios at eim.surrey.ac.uk (Panos TRIMINTZIOS) Date: Fri Nov 5 03:44:25 2004 Subject: [e2e] topological locality of Internet communication? In-Reply-To: <418A9D3F.9020302@netlab.nec.de> References: <418A9D3F.9020302@netlab.nec.de> Message-ID: Information about AS Paths from routes advertised with BGP on the average/maximum AS path length (maybe also taking into account AS Path prepending statistics) is an indication of the "AS hops" a typical connection may cross in the Internet. Currently I the average AS Path size is around 3.5 AS hops, while the maximum 11-12. An analysis of the various BGP reports given in: http://bgp.potaroo.net/index-bgp.html can give you a reasonable indication for the "AS hops" statistics you need for your simulations. -Panos Trimintzios On Thu, 4 Nov 2004, Lars Eggert typed: // Hi, // // since we were just talking about Internet statistics: // // I'm looking to get a feel of how much topological locality Internet // communication exhibits, to calibrate some simulations we plan to run. // // Is anyone aware of measurements of how many "AS hops" typical // connections cross in the Internet? Ideal would be a CDF of "AS hops // crossed" for connection percentages. // // (I thought about looking at the TTLs of incoming TCP packets at servers, // infering the OS based on TCP characteristics like nmap and using this to // guess the default outbound TTL for that OS. But that yields IP hops, not // AS hops.) // // Thanks, // Lars // -- // Lars Eggert NEC Network Laboratories // ======================================================= Panos Trimintzios Research Fellow, Networks Research Group Centre for Communication Systems Research (CCSR) Univ. of Surrey, Guildford, Surrey GU2 7XH, U.K. Tel: +44 (0)1483 686005 Fax: +44 (0)1483 686011 Email: ======================================================= From lars.eggert at netlab.nec.de Fri Nov 5 04:39:31 2004 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Fri Nov 5 04:40:04 2004 Subject: [e2e] topological locality of Internet communication? In-Reply-To: References: <418A9D3F.9020302@netlab.nec.de> Message-ID: <418B7483.60802@netlab.nec.de> Panos TRIMINTZIOS wrote: > Information about AS Paths from routes advertised with BGP on the > average/maximum AS path length (maybe also taking into account AS Path > prepending statistics) is an indication of the "AS hops" a typical > connection may cross in the Internet. Currently I the average AS Path > size is around 3.5 AS hops, while the maximum 11-12. Thanks to Panos and others for providing these BGP-based numbers! However, they're not exactly what I was looking for. Knowing that the average BGP path is around 3.5 hops is useful *if* the "average" host starts connections to random other hosts in the Internet. I'm pretty sure that the latter doesn't hold, i.e., that the communication pattern of hosts isn't random. Jennifer's work on an AS-level traceroute is also interesting and relevant; thanks for pointing me at it. However, I'm not completely sure whether her tool can be run against an existing dump or requires live traces. If the latter, I fear that those measurements could take up the student's entire thesis time to be reasonably accurate. Thanks again to all who responded! Lars -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3360 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041105/500df207/smime-0001.bin From sudeepg at cse.iitb.ac.in Fri Nov 5 04:59:46 2004 From: sudeepg at cse.iitb.ac.in (Sudeep Goyal) Date: Fri Nov 5 05:01:32 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: <2DAC9E7A4640234B85975565E5D83AE17A7C38@srvcaexg01.headquarters.hammerheadsystems.com> References: <2DAC9E7A4640234B85975565E5D83AE17A7C38@srvcaexg01.headquarters.hammerheadsystems.com> Message-ID: Hi Ping Pan, Thanks for the information. But, you say that CAC would make sense at the edge. Would you please tell what are the mechanisms used in real ISP networks to find out the explicit paths that meet certain QoS flow requirement. Or are the paths are statically (manually) set without any dynamic traffic engineering ? I am presently working on algorithms on admission control on MPLS (and MPLS over DiffServ network) and have worked out few algorithms in theory. But, I donot yet know how and what actually ISPs are doing in reality for admission control ? Does it make sense commercially to come up with good TE techniques or algorithms that would help us find explicit paths in MPLS network at the edge that would meet certain QoS requirements. Or may be, given a LSP path, it makes more sense going for a DiffServ admission control rather than finding explicit path. Thanks for anticipated help. warm regards, Sudeep On Thu, 4 Nov 2004, Ping Pan wrote: > First, in the (MPLS) backbone networks, most of the links are > over-provisioned, so not sure CAC and many QoS enforcement would make much > use there. > > At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP, > that can be used to carry DiffServ class. The LSP's that carry such > information is called EXP-inferred LSP (E-LSP). The MPLS router can run the > standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the > packets within the LSP. This function becomes more important during flow > aggregation. > > There are a bunch of drafts from Cisco on this topic over the years. > > - Ping > >> -----Original Message----- >> From: end2end-interest-bounces@postel.org >> [mailto:end2end-interest-bounces@postel.org] On Behalf Of Fahad Dogar >> Sent: Wednesday, October 20, 2004 12:12 AM >> To: end2end-interest@postel.org >> Subject: [e2e] Admission Control and Policing in MPLS >> >> >> Hi, >> >> I would like to know the mechanism employed in MPLS networks >> for admission control and the process of subsequently >> policing the flow in order to ensure that it does not violate the SLA. >> >> Any help or pointers to any standardized requirements would >> be greatly appreciated. >> >> Thanks in advance, >> Fahad >> > > -- From rja at extremenetworks.com Fri Nov 5 05:46:30 2004 From: rja at extremenetworks.com (RJ Atkinson) Date: Fri Nov 5 05:46:59 2004 Subject: [e2e] QBONE abandon QoS research ? In-Reply-To: <20041105104527.7272.qmail@web15403.mail.cnb.yahoo.com> References: <20041105104527.7272.qmail@web15403.mail.cnb.yahoo.com> Message-ID: <1934DDA0-2F31-11D9-BABE-000D93B505E6@extremenetworks.com> On Nov 5, 2004, at 05:45, Jing Shen wrote: > 2. How could QBONE be kept no congestion ? inside > China, the bandwidth needed increase so quick that > backbone BW or BW between ISPS need to be negotiated > one or more times a year. In North America between 1995 and 2000, it was not unusual for the larger ISPs to upgrade bandwidth capacity 2 or more times per year to keep up with the increase in offered load. Sometimes a little traffic engineering was needed here and there to buy time, but the main strategy was just to upgrade bandwidth capacity very frequently. This is one of the reasons that several firms spent big money building out additional US long-distance fibre networks during the 1990s, and then leasing or selling (IRU) portions of those fibre networks to various ISPs or telephone companies. Given where China is today in its Internet growth curve, I would guess that ISPs in China will need to continue to upgrade 2-3 times per year for the next few years. Ran rja@extremenetworks.com From shalunov at internet2.edu Fri Nov 5 14:21:18 2004 From: shalunov at internet2.edu (stanislav shalunov) Date: Fri Nov 5 14:22:01 2004 Subject: [e2e] Re: QBONE abandon QoS research ? In-Reply-To: <20041105104527.7272.qmail@web15403.mail.cnb.yahoo.com> References: <20041105104527.7272.qmail@web15403.mail.cnb.yahoo.com> Message-ID: <86fz3o3pk1.fsf@abel.internet2.edu> Jing Shen writes: > 1. Is there any summary report/paper on their experience with > DiffServ+MPLS based QoS? Have they summarized the result of > implementing WRED (or similar technique) in QBONE? The closest we've come to writing is: http://qbone.internet2.edu/papers/non-architectural-problems.txt See also: http://portal.acm.org/citation.cfm?id=944600 http://portal.acm.org/citation.cfm?id=944603 > 2. How could QBONE be kept no congestion ? The networks were upgraded faster than the users' appetites for capacity use grew. Doubling every year (on average) is a reasonable rule of thumb. How fast does your traffic grow? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Democracy is a form of government that substitutes election by the incompetent many for appointment by the corrupt few. -- G. B. Shaw From pingpan at cs.columbia.edu Sat Nov 6 06:37:37 2004 From: pingpan at cs.columbia.edu (Ping Pan) Date: Sat Nov 6 06:38:13 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: References: <2DAC9E7A4640234B85975565E5D83AE17A7C38@srvcaexg01.headquarters.hammerheadsystems.com> Message-ID: <418CE1B1.6040908@cs.columbia.edu> Hi, Traffic provisioning at network edge seems to be largely depending on carriers. Some of the existing networks maintain traditional (ATM/frame) connections with almost static configuration. However, this is likely to change as they all move toward higher bandwidth (GigE) and offer more services. But if the bandwidth is high enough at access/edge, it becomes a simple over-provisioning model, thus no QoS/CAC needed.... Another observation, most deployed MPLS networks in metro area use LDP to setup LSP's. LDP does not have QoS awareness by design. - Ping Sudeep Goyal wrote: > Hi Ping Pan, > > Thanks for the information. But, you say that CAC would make sense at > the edge. Would you please tell what are the mechanisms used in real > ISP networks to find out the explicit paths that meet certain QoS flow > requirement. Or are the paths are statically (manually) set without any > dynamic traffic engineering ? > I am presently working on algorithms on admission control on MPLS (and > MPLS over DiffServ network) and have worked out few algorithms in > theory. But, I donot yet know how and what actually ISPs are doing in > reality for admission control ? Does it make sense commercially to come > up with good TE techniques or algorithms that would help us find > explicit paths in MPLS network at the edge that would meet certain QoS > requirements. Or may be, given a LSP path, it makes more sense going for > a DiffServ admission control rather than finding explicit path. > > Thanks for anticipated help. > > warm regards, > Sudeep > > > On Thu, 4 Nov 2004, Ping Pan wrote: > >> First, in the (MPLS) backbone networks, most of the links are >> over-provisioned, so not sure CAC and many QoS enforcement would make >> much >> use there. >> >> At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP, >> that can be used to carry DiffServ class. The LSP's that carry such >> information is called EXP-inferred LSP (E-LSP). The MPLS router can >> run the >> standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the >> packets within the LSP. This function becomes more important during flow >> aggregation. >> >> There are a bunch of drafts from Cisco on this topic over the years. >> >> - Ping >> >>> -----Original Message----- >>> From: end2end-interest-bounces@postel.org >>> [mailto:end2end-interest-bounces@postel.org] On Behalf Of Fahad Dogar >>> Sent: Wednesday, October 20, 2004 12:12 AM >>> To: end2end-interest@postel.org >>> Subject: [e2e] Admission Control and Policing in MPLS >>> >>> >>> Hi, >>> >>> I would like to know the mechanism employed in MPLS networks >>> for admission control and the process of subsequently >>> policing the flow in order to ensure that it does not violate the SLA. >>> >>> Any help or pointers to any standardized requirements would >>> be greatly appreciated. >>> >>> Thanks in advance, >>> Fahad >>> >> >> > From Jon.Crowcroft at cl.cam.ac.uk Sat Nov 6 07:52:01 2004 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat Nov 6 07:53:12 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: Message from Ping Pan of "Sat, 06 Nov 2004 06:37:37 PST." <418CE1B1.6040908@cs.columbia.edu> Message-ID: on a more general point... personally , i could never see the fundamental different between packet drop mechanis and congestion control and call admission control with call blocking in both cases, you have to look at the provisioning of buffers - based on some model of the traffic source, and make decisions about which packet/flow to drop/block based on the specific source model and the multiplexing and aggregate behaviours...its just a timescale/granualrity difference in the end we dont just have to call block, we could do pre-emption, or re-routng of calls, and we dont just have to drop-tail in a fifo queue, we could do RED, or fair dropping or whatever... anyhow, as you say, as the edge/core system evolves right, no qos/cac is needed it seems...although one could imagine a world where the net moves back to a regime where it might be.. In missive <418CE1B1.6040908@cs.columbia.edu>, Ping Pan typed: >>Hi, >> >>Traffic provisioning at network edge seems to be largely depending on >>carriers. Some of the existing networks maintain traditional (ATM/frame) >>connections with almost static configuration. However, this is likely to >>change as they all move toward higher bandwidth (GigE) and offer more >>services. >> >>But if the bandwidth is high enough at access/edge, it becomes a simple >>over-provisioning model, thus no QoS/CAC needed.... >> >>Another observation, most deployed MPLS networks in metro area use LDP >>to setup LSP's. LDP does not have QoS awareness by design. >> >>- Ping >> >> >>Sudeep Goyal wrote: >>> Hi Ping Pan, >>> >>> Thanks for the information. But, you say that CAC would make sense at >>> the edge. Would you please tell what are the mechanisms used in real >>> ISP networks to find out the explicit paths that meet certain QoS flow >>> requirement. Or are the paths are statically (manually) set without any >>> dynamic traffic engineering ? >>> I am presently working on algorithms on admission control on MPLS (and >>> MPLS over DiffServ network) and have worked out few algorithms in >>> theory. But, I donot yet know how and what actually ISPs are doing in >>> reality for admission control ? Does it make sense commercially to come >>> up with good TE techniques or algorithms that would help us find >>> explicit paths in MPLS network at the edge that would meet certain QoS >>> requirements. Or may be, given a LSP path, it makes more sense going for >>> a DiffServ admission control rather than finding explicit path. >>> >>> Thanks for anticipated help. >>> >>> warm regards, >>> Sudeep >>> >>> >>> On Thu, 4 Nov 2004, Ping Pan wrote: >>> >>>> First, in the (MPLS) backbone networks, most of the links are >>>> over-provisioned, so not sure CAC and many QoS enforcement would make >>>> much >>>> use there. >>>> >>>> At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP, >>>> that can be used to carry DiffServ class. The LSP's that carry such >>>> information is called EXP-inferred LSP (E-LSP). The MPLS router can >>>> run the >>>> standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the >>>> packets within the LSP. This function becomes more important during flow >>>> aggregation. >>>> >>>> There are a bunch of drafts from Cisco on this topic over the years. >>>> >>>> - Ping >>>> >>>>> -----Original Message----- >>>>> From: end2end-interest-bounces@postel.org >>>>> [mailto:end2end-interest-bounces@postel.org] On Behalf Of Fahad Dogar >>>>> Sent: Wednesday, October 20, 2004 12:12 AM >>>>> To: end2end-interest@postel.org >>>>> Subject: [e2e] Admission Control and Policing in MPLS >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I would like to know the mechanism employed in MPLS networks >>>>> for admission control and the process of subsequently >>>>> policing the flow in order to ensure that it does not violate the SLA. >>>>> >>>>> Any help or pointers to any standardized requirements would >>>>> be greatly appreciated. >>>>> >>>>> Thanks in advance, >>>>> Fahad >>>>> >>>> >>>> >>> cheers jon From sudeepg at cse.iitb.ac.in Sat Nov 6 08:55:50 2004 From: sudeepg at cse.iitb.ac.in (Sudeep Goyal) Date: Sat Nov 6 08:50:09 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: References: Message-ID: On Sat, 6 Nov 2004, Jon Crowcroft wrote: > on a more general point... > > personally , i could never see the fundamental different between > packet drop mechanis and congestion control > and > call admission control with call blocking > > in both cases, you have to look at the provisioning of buffers - > based on some model of the traffic source, and make decisions about > which packet/flow to drop/block based on the specific source model and > the multiplexing and aggregate behaviours...its just a > timescale/granualrity difference in the end Jon. In my humble opinion, there is a big difference depending on the kind of traffic that is being injected into the network. Say, for example you have a CBR (constant bit rate) traffic for VoIP, video-conferencing and you need to provide stringent qos requirements. You donot bring congestion in the network and here, CAC plays important role. Because any implementation of congestion control mechanism at the core nodes would produce delay etc which we donot want for CBR kind of traffic. The schedulling in this case at each node would also be highest. In above traffic, delay and jitter are important qos parameters. But, for elastic traffic (like FTP) which is also greedy and built over TCP we need to be careful about the throughput because here throughput is more important than delay and hence, we need to deploy proper RED mechanism and maintain high throughput and admit more flows. Dropping of packets and little delay is accpetable. But, throughput should be high. Therefore, CAC algorithm should consider this and accept such elastic traffic accordingly, fulling knowing that RED and congestion control (TCP) is used for such traffic. For CBR traffic, CBR algorithm cannot take the chance for congestion and most importantly, delay and loss of packets, therefore, never overprovision any flow (flows are also more UDP-oriented). Then there can be other kinds of flows like VBR, elastic short-lived flows and best-effort. Thanks Ping Pan for the information again :) But, plz help me clarify following: > >> > >>Another observation, most deployed MPLS networks in metro area use LDP > >>to setup LSP's. LDP does not have QoS awareness by design. This is informative. But, could you plz tell if coming up with good MPLS over DiffServ CAC algorithms that would help the incoming traffic meet its requested QoS be useful (commercially). From what you have said, it feels that ISPs are not doing it and may not need it at present, but future could be a possiblity. Am i right? If people have already done some work, can you plz refer some links to me (from where I can know the state-of-art of MPLS over DiffServ admission control algorithms)? Thanks a lot Again. Warm Regards, Sudeep > >>- Ping > >> > >> > >>Sudeep Goyal wrote: > >>> Hi Ping Pan, > >>> > >>> Thanks for the information. But, you say that CAC would make sense at > >>> the edge. Would you please tell what are the mechanisms used in real > >>> ISP networks to find out the explicit paths that meet certain QoS flow > >>> requirement. Or are the paths are statically (manually) set without any > >>> dynamic traffic engineering ? > >>> I am presently working on algorithms on admission control on MPLS (and > >>> MPLS over DiffServ network) and have worked out few algorithms in > >>> theory. But, I donot yet know how and what actually ISPs are doing in > >>> reality for admission control ? Does it make sense commercially to come > >>> up with good TE techniques or algorithms that would help us find > >>> explicit paths in MPLS network at the edge that would meet certain QoS > >>> requirements. Or may be, given a LSP path, it makes more sense going for > >>> a DiffServ admission control rather than finding explicit path. > >>> > >>> Thanks for anticipated help. > >>> > >>> warm regards, > >>> Sudeep > >>> > >>> > >>> On Thu, 4 Nov 2004, Ping Pan wrote: > >>> > >>>> First, in the (MPLS) backbone networks, most of the links are > >>>> over-provisioned, so not sure CAC and many QoS enforcement would make > >>>> much > >>>> use there. > >>>> > >>>> At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP, > >>>> that can be used to carry DiffServ class. The LSP's that carry such > >>>> information is called EXP-inferred LSP (E-LSP). The MPLS router can > >>>> run the > >>>> standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the > >>>> packets within the LSP. This function becomes more important during flow > >>>> aggregation. > >>>> > >>>> There are a bunch of drafts from Cisco on this topic over the years. > >>>> > >>>> - Ping > >>>> > >>>>> -----Original Message----- > >>>>> From: end2end-interest-bounces@postel.org > >>>>> [mailto:end2end-interest-bounces@postel.org] On Behalf Of Fahad Dogar > >>>>> Sent: Wednesday, October 20, 2004 12:12 AM > >>>>> To: end2end-interest@postel.org > >>>>> Subject: [e2e] Admission Control and Policing in MPLS > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> I would like to know the mechanism employed in MPLS networks > >>>>> for admission control and the process of subsequently > >>>>> policing the flow in order to ensure that it does not violate the SLA. > >>>>> > >>>>> Any help or pointers to any standardized requirements would > >>>>> be greatly appreciated. > >>>>> > >>>>> Thanks in advance, > >>>>> Fahad > >>>>> > >>>> > >>>> > >>> > > cheers > > jon > > -- From Jon.Crowcroft at cl.cam.ac.uk Sat Nov 6 08:59:14 2004 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat Nov 6 09:00:10 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: Message from Sudeep Goyal of "Sat, 06 Nov 2004 22:25:50 +0530." Message-ID: I dont think you are getting my point at all what i mean is that the _algorithms and framework_ to do congestion control and to do CAC are related and similar - the timescales are different - one is per packet or rtt, the other is per session or flow or call or forwarding equiv. class or diff serve class or whatever aggregate you want but as the system gets very big, the differences get very small indeed actually. i wasnt suggesting that all video/voice/game traffic should be converted to be elastic adaptive behaviour (although its not so hard for many of them) - conversely one can argue that limiting the number of TCP flows through CAC might give a good (near guaranteed ) response time to web users too - sure - two sides of same coin.... In missive , Sudeep Goya l typed: >>On Sat, 6 Nov 2004, Jon Crowcroft wrote: >> >>> on a more general point... >>> >>> personally , i could never see the fundamental different between >>> packet drop mechanis and congestion control >>> and >>> call admission control with call blocking >>> >>> in both cases, you have to look at the provisioning of buffers - >>> based on some model of the traffic source, and make decisions about >>> which packet/flow to drop/block based on the specific source model and >>> the multiplexing and aggregate behaviours...its just a >>> timescale/granualrity difference in the end >> >>Jon. In my humble opinion, there is a big difference depending on the >>kind of traffic that is being injected into the network. >> >>Say, for example you have a CBR (constant bit rate) traffic for VoIP, >>video-conferencing and you need to provide stringent qos requirements. >>You donot bring congestion in the network and here, CAC plays important >>role. Because any implementation of congestion control mechanism at the >>core nodes would produce delay etc which we donot want for CBR kind of >>traffic. The schedulling in this case at each node would also be highest. >>In above traffic, delay and jitter are important qos parameters. >> >>But, for elastic traffic (like FTP) which is also greedy and built over >>TCP we need to be careful about the throughput because here throughput is >>more important than delay and hence, we need to deploy proper RED >>mechanism and maintain high throughput and admit more flows. Dropping of >>packets and little delay is accpetable. But, throughput should be high. >>Therefore, CAC algorithm should consider this and accept such elastic >>traffic accordingly, fulling knowing that RED and congestion control >>(TCP) is used for such traffic. >> >>For CBR traffic, CBR algorithm cannot take the chance for congestion and >>most importantly, delay and loss of packets, therefore, never >>overprovision any flow (flows are also more UDP-oriented). Then there can >>be other kinds of flows like VBR, elastic short-lived flows and best-effort. >> >> Thanks Ping Pan for the information again :) But, plz help me clarify >>following: >> >>> >> >>> >>Another observation, most deployed MPLS networks in metro area use LDP >>> >>to setup LSP's. LDP does not have QoS awareness by design. >> >>This is informative. But, could you plz tell if coming up with good MPLS >>over DiffServ CAC algorithms that would help the incoming traffic meet its >>requested QoS be useful (commercially). From what you have said, it feels >>that ISPs are not doing it and may not need it at present, but future could be a >>possiblity. Am i right? >> If people have already done some work, can you plz refer some links to me >>(from where I can know the state-of-art of MPLS over DiffServ admission >>control algorithms)? >> >>Thanks a lot Again. >> >>Warm Regards, >>Sudeep >> >> >> >> >> >>> >>- Ping >>> >> >>> >> >>> >>Sudeep Goyal wrote: >>> >>> Hi Ping Pan, >>> >>> >>> >>> Thanks for the information. But, you say that CAC would make sense at >>> >>> the edge. Would you please tell what are the mechanisms used in real >>> >>> ISP networks to find out the explicit paths that meet certain QoS flow >>> >>> requirement. Or are the paths are statically (manually) set without any >>> >>> dynamic traffic engineering ? >>> >>> I am presently working on algorithms on admission control on MPLS (and >>> >>> MPLS over DiffServ network) and have worked out few algorithms in >>> >>> theory. But, I donot yet know how and what actually ISPs are doing in >>> >>> reality for admission control ? Does it make sense commercially to come >>> >>> up with good TE techniques or algorithms that would help us find >>> >>> explicit paths in MPLS network at the edge that would meet certain QoS >>> >>> requirements. Or may be, given a LSP path, it makes more sense going for >>> >>> a DiffServ admission control rather than finding explicit path. >>> >>> >>> >>> Thanks for anticipated help. >>> >>> >>> >>> warm regards, >>> >>> Sudeep >>> >>> >>> >>> >>> >>> On Thu, 4 Nov 2004, Ping Pan wrote: >>> >>> >>> >>>> First, in the (MPLS) backbone networks, most of the links are >>> >>>> over-provisioned, so not sure CAC and many QoS enforcement would make >>> >>>> much >>> >>>> use there. >>> >>>> >>> >>>> At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP, >>> >>>> that can be used to carry DiffServ class. The LSP's that carry such >>> >>>> information is called EXP-inferred LSP (E-LSP). The MPLS router can >>> >>>> run the >>> >>>> standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the >>> >>>> packets within the LSP. This function becomes more important during flow >>> >>>> aggregation. >>> >>>> >>> >>>> There are a bunch of drafts from Cisco on this topic over the years. >>> >>>> >>> >>>> - Ping >>> >>>> >>> >>>>> -----Original Message----- >>> >>>>> From: end2end-interest-bounces@postel.org >>> >>>>> [mailto:end2end-interest-bounces@postel.org] On Behalf Of Fahad Dogar >>> >>>>> Sent: Wednesday, October 20, 2004 12:12 AM >>> >>>>> To: end2end-interest@postel.org >>> >>>>> Subject: [e2e] Admission Control and Policing in MPLS >>> >>>>> >>> >>>>> >>> >>>>> Hi, >>> >>>>> >>> >>>>> I would like to know the mechanism employed in MPLS networks >>> >>>>> for admission control and the process of subsequently >>> >>>>> policing the flow in order to ensure that it does not violate the SLA. >>> >>>>> >>> >>>>> Any help or pointers to any standardized requirements would >>> >>>>> be greatly appreciated. >>> >>>>> >>> >>>>> Thanks in advance, >>> >>>>> Fahad >>> >>>>> >>> >>>> >>> >>>> >>> >>> >>> >>> cheers >>> >>> jon >>> >>> >> >>-- cheers jon From pingpan at cs.columbia.edu Sat Nov 6 15:17:44 2004 From: pingpan at cs.columbia.edu (Ping Pan) Date: Sat Nov 6 15:18:18 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: References: Message-ID: <418D5B98.9050103@cs.columbia.edu> > what i mean is that the _algorithms and framework_ to do congestion > control and to do CAC are related and similar - the timescales are > different - one is per packet or rtt, the other is per session or flow > or call or forwarding equiv. class or diff serve class or whatever > aggregate you want but as the system gets very big, the differences > get very small indeed actually. > Agree 100%. With the advance in silicon, per-flow policing/shaping, queuing and scheduling for various traffic types, dropping... can be done at very high speed. Not sure there much magic in this area. The issue becomes where to apply all this. > i wasnt suggesting that all video/voice/game traffic should be > converted to be elastic adaptive behaviour (although its not so hard > for many of them) - conversely one can argue that limiting the number > of TCP flows through CAC might give a good (near guaranteed ) response > time to web users too - sure - two sides of same coin.... > In missive , Sudeep Goya > l typed: > Maybe. There are a couple of exceptions here. Since the beginning of commercial data networking, carrier's business model has been selling guaranteed bandwidth to individual users. Much of the telecom operation has been built around this model (accounting, planning, restoration, OAM...). And this is not likely to change in the near future, even when you have GigE all over the place. Thus, per-flow, per-customer, per-call, per-whatever policing will still be in place at edge. However, this does not impact how e2e applications suppose to work - long live TCP. ;-) Another issue is the method of migrating traffic from the existing networks to new ones, while still making money for the carriers. This is likely taking place at the edge. During the migration, the entire suite of QoS must be in place for many business users. This is where some DiffServ type of conditioning would be useful. This is the reason why you see a number of proposals on ATM-MPLS interworking in recent months. Again, you may find them from IETF MPLS/PWE3/L2VPN WG drafts.... As for the traffic types. VoIP traffic is not CBR, and never will be. ;-) In fact, the entire VoIP looks like an enterprise/end-user application to me. The switches/routers have no way of knowing what it is from the packet itself. One deployment scenario I have seen is to map VoIP traffic onto a VLAN, and provisioning BW on that VLAN from network edge. In this case, a simple priority queue or a half decent WFQ would do the job. - Ping > >>On Sat, 6 Nov 2004, Jon Crowcroft wrote: > >> > >>> on a more general point... > >>> > >>> personally , i could never see the fundamental different between > >>> packet drop mechanis and congestion control > >>> and > >>> call admission control with call blocking > >>> > >>> in both cases, you have to look at the provisioning of buffers - > >>> based on some model of the traffic source, and make decisions about > >>> which packet/flow to drop/block based on the specific source model and > >>> the multiplexing and aggregate behaviours...its just a > >>> timescale/granualrity difference in the end > >> > >>Jon. In my humble opinion, there is a big difference depending on the > >>kind of traffic that is being injected into the network. > >> > >>Say, for example you have a CBR (constant bit rate) traffic for VoIP, > >>video-conferencing and you need to provide stringent qos requirements. > >>You donot bring congestion in the network and here, CAC plays important > >>role. Because any implementation of congestion control mechanism at the > >>core nodes would produce delay etc which we donot want for CBR kind of > >>traffic. The schedulling in this case at each node would also be highest. > >>In above traffic, delay and jitter are important qos parameters. > >> > >>But, for elastic traffic (like FTP) which is also greedy and built over > >>TCP we need to be careful about the throughput because here throughput is > >>more important than delay and hence, we need to deploy proper RED > >>mechanism and maintain high throughput and admit more flows. Dropping of > >>packets and little delay is accpetable. But, throughput should be high. > >>Therefore, CAC algorithm should consider this and accept such elastic > >>traffic accordingly, fulling knowing that RED and congestion control > >>(TCP) is used for such traffic. > >> > >>For CBR traffic, CBR algorithm cannot take the chance for congestion and > >>most importantly, delay and loss of packets, therefore, never > >>overprovision any flow (flows are also more UDP-oriented). Then there can > >>be other kinds of flows like VBR, elastic short-lived flows and best-effort. > >> > >> Thanks Ping Pan for the information again :) But, plz help me clarify > >>following: > >> > >>> >> > >>> >>Another observation, most deployed MPLS networks in metro area use LDP > >>> >>to setup LSP's. LDP does not have QoS awareness by design. > >> > >>This is informative. But, could you plz tell if coming up with good MPLS > >>over DiffServ CAC algorithms that would help the incoming traffic meet its > >>requested QoS be useful (commercially). From what you have said, it feels > >>that ISPs are not doing it and may not need it at present, but future could be a > >>possiblity. Am i right? > >> If people have already done some work, can you plz refer some links to me > >>(from where I can know the state-of-art of MPLS over DiffServ admission > >>control algorithms)? > >> > >>Thanks a lot Again. > >> > >>Warm Regards, > >>Sudeep > >> > >> > >> > >> > >> > >>> >>- Ping > >>> >> > >>> >> > >>> >>Sudeep Goyal wrote: > >>> >>> Hi Ping Pan, > >>> >>> > >>> >>> Thanks for the information. But, you say that CAC would make sense at > >>> >>> the edge. Would you please tell what are the mechanisms used in real > >>> >>> ISP networks to find out the explicit paths that meet certain QoS flow > >>> >>> requirement. Or are the paths are statically (manually) set without any > >>> >>> dynamic traffic engineering ? > >>> >>> I am presently working on algorithms on admission control on MPLS (and > >>> >>> MPLS over DiffServ network) and have worked out few algorithms in > >>> >>> theory. But, I donot yet know how and what actually ISPs are doing in > >>> >>> reality for admission control ? Does it make sense commercially to come > >>> >>> up with good TE techniques or algorithms that would help us find > >>> >>> explicit paths in MPLS network at the edge that would meet certain QoS > >>> >>> requirements. Or may be, given a LSP path, it makes more sense going for > >>> >>> a DiffServ admission control rather than finding explicit path. > >>> >>> > >>> >>> Thanks for anticipated help. > >>> >>> > >>> >>> warm regards, > >>> >>> Sudeep > >>> >>> > >>> >>> > >>> >>> On Thu, 4 Nov 2004, Ping Pan wrote: > >>> >>> > >>> >>>> First, in the (MPLS) backbone networks, most of the links are > >>> >>>> over-provisioned, so not sure CAC and many QoS enforcement would make > >>> >>>> much > >>> >>>> use there. > >>> >>>> > >>> >>>> At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP, > >>> >>>> that can be used to carry DiffServ class. The LSP's that carry such > >>> >>>> information is called EXP-inferred LSP (E-LSP). The MPLS router can > >>> >>>> run the > >>> >>>> standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the > >>> >>>> packets within the LSP. This function becomes more important during flow > >>> >>>> aggregation. > >>> >>>> > >>> >>>> There are a bunch of drafts from Cisco on this topic over the years. > >>> >>>> > >>> >>>> - Ping > >>> >>>> > >>> >>>>> -----Original Message----- > >>> >>>>> From: end2end-interest-bounces@postel.org > >>> >>>>> [mailto:end2end-interest-bounces@postel.org] On Behalf Of Fahad Dogar > >>> >>>>> Sent: Wednesday, October 20, 2004 12:12 AM > >>> >>>>> To: end2end-interest@postel.org > >>> >>>>> Subject: [e2e] Admission Control and Policing in MPLS > >>> >>>>> > >>> >>>>> > >>> >>>>> Hi, > >>> >>>>> > >>> >>>>> I would like to know the mechanism employed in MPLS networks > >>> >>>>> for admission control and the process of subsequently > >>> >>>>> policing the flow in order to ensure that it does not violate the SLA. > >>> >>>>> > >>> >>>>> Any help or pointers to any standardized requirements would > >>> >>>>> be greatly appreciated. > >>> >>>>> > >>> >>>>> Thanks in advance, > >>> >>>>> Fahad > >>> >>>>> > >>> >>>> > >>> >>>> > >>> >>> > >>> > >>> cheers > >>> > >>> jon > >>> > >>> > >> > >>-- > > cheers > > jon From Jon.Crowcroft at cl.cam.ac.uk Sun Nov 7 04:04:59 2004 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun Nov 7 04:05:19 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: Message from Ping Pan of "Sat, 06 Nov 2004 15:17:44 PST." <418D5B98.9050103@cs.columbia.edu> Message-ID: I can't stress how much I agree about the evolution of carrier business - this is an area that is extremely interesting, both commercially to vendors and service providers, but also to researchers as we need to consider how to provision for aggregates of traditional traffic, but flowing over VPNs and current work on provisioning has tended to assume the traffic matrix is transparent, whereas its partially opaque in a vpn.... plus the "arrival process" for a network provider is of entire legacy enterprise nets (previously provisioned using frame relay or atm ) moving over to the IP core...it would be interesting to get estimates from the large teleco/isps (at&t obviously, but on a smaller scale a lot of european outfits - certinly BT, FT and DT and telecom italia) of the amount of legacy net that we might expect to migrate... also agree about voip.. In missive <418D5B98.9050103@cs.columbia.edu>, Ping Pan typed: >>> what i mean is that the _algorithms and framework_ to do congestion >>> control and to do CAC are related and similar - the timescales are >>> different - one is per packet or rtt, the other is per session or flow >>> or call or forwarding equiv. class or diff serve class or whatever >>> aggregate you want but as the system gets very big, the differences >>> get very small indeed actually. >>> >> >>Agree 100%. With the advance in silicon, per-flow policing/shaping, >>queuing and scheduling for various traffic types, dropping... can be >>done at very high speed. Not sure there much magic in this area. The >>issue becomes where to apply all this. >> >>> i wasnt suggesting that all video/voice/game traffic should be >>> converted to be elastic adaptive behaviour (although its not so hard >>> for many of them) - conversely one can argue that limiting the number >>> of TCP flows through CAC might give a good (near guaranteed ) response >>> time to web users too - sure - two sides of same coin.... >>> In missive , Sudeep Goya >>> l typed: >>> >> >>Maybe. There are a couple of exceptions here. >> >>Since the beginning of commercial data networking, carrier's business >>model has been selling guaranteed bandwidth to individual users. Much of >>the telecom operation has been built around this model (accounting, >>planning, restoration, OAM...). And this is not likely to change in the >>near future, even when you have GigE all over the place. Thus, per-flow, >>per-customer, per-call, per-whatever policing will still be in place at >>edge. However, this does not impact how e2e applications suppose to work >>- long live TCP. ;-) >> >>Another issue is the method of migrating traffic from the existing >>networks to new ones, while still making money for the carriers. This is >>likely taking place at the edge. During the migration, the entire suite >>of QoS must be in place for many business users. This is where some >>DiffServ type of conditioning would be useful. This is the reason why >>you see a number of proposals on ATM-MPLS interworking in recent months. >>Again, you may find them from IETF MPLS/PWE3/L2VPN WG drafts.... >> >>As for the traffic types. VoIP traffic is not CBR, and never will be. >>;-) In fact, the entire VoIP looks like an enterprise/end-user >>application to me. The switches/routers have no way of knowing what it >>is from the packet itself. One deployment scenario I have seen is to map >>VoIP traffic onto a VLAN, and provisioning BW on that VLAN from network >>edge. In this case, a simple priority queue or a half decent WFQ would >>do the job. >> >>- Ping >> >>> >>On Sat, 6 Nov 2004, Jon Crowcroft wrote: >>> >> >>> >>> on a more general point... >>> >>> >>> >>> personally , i could never see the fundamental different between >>> >>> packet drop mechanis and congestion control >>> >>> and >>> >>> call admission control with call blocking >>> >>> >>> >>> in both cases, you have to look at the provisioning of buffers - >>> >>> based on some model of the traffic source, and make decisions about >>> >>> which packet/flow to drop/block based on the specific source model and >>> >>> the multiplexing and aggregate behaviours...its just a >>> >>> timescale/granualrity difference in the end >>> >> >>> >>Jon. In my humble opinion, there is a big difference depending on the >>> >>kind of traffic that is being injected into the network. >>> >> >>> >>Say, for example you have a CBR (constant bit rate) traffic for VoIP, >>> >>video-conferencing and you need to provide stringent qos requirements. >>> >>You donot bring congestion in the network and here, CAC plays important >>> >>role. Because any implementation of congestion control mechanism at the >>> >>core nodes would produce delay etc which we donot want for CBR kind of >>> >>traffic. The schedulling in this case at each node would also be highest. >>> >>In above traffic, delay and jitter are important qos parameters. >>> >> >>> >>But, for elastic traffic (like FTP) which is also greedy and built over >>> >>TCP we need to be careful about the throughput because here throughput is >>> >>more important than delay and hence, we need to deploy proper RED >>> >>mechanism and maintain high throughput and admit more flows. Dropping of >>> >>packets and little delay is accpetable. But, throughput should be high. >>> >>Therefore, CAC algorithm should consider this and accept such elastic >>> >>traffic accordingly, fulling knowing that RED and congestion control >>> >>(TCP) is used for such traffic. >>> >> >>> >>For CBR traffic, CBR algorithm cannot take the chance for congestion and >>> >>most importantly, delay and loss of packets, therefore, never >>> >>overprovision any flow (flows are also more UDP-oriented). Then there can >>> >>be other kinds of flows like VBR, elastic short-lived flows and best-effort. >>> >> >>> >> Thanks Ping Pan for the information again :) But, plz help me clarify >>> >>following: >>> >> >>> >>> >> >>> >>> >>Another observation, most deployed MPLS networks in metro area use LDP >>> >>> >>to setup LSP's. LDP does not have QoS awareness by design. >>> >> >>> >>This is informative. But, could you plz tell if coming up with good MPLS >>> >>over DiffServ CAC algorithms that would help the incoming traffic meet its >>> >>requested QoS be useful (commercially). From what you have said, it feels >>> >>that ISPs are not doing it and may not need it at present, but future could be a >>> >>possiblity. Am i right? >>> >> If people have already done some work, can you plz refer some links to me >>> >>(from where I can know the state-of-art of MPLS over DiffServ admission >>> >>control algorithms)? >>> >> >>> >>Thanks a lot Again. >>> >> >>> >>Warm Regards, >>> >>Sudeep >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>> >>- Ping >>> >>> >> >>> >>> >> >>> >>> >>Sudeep Goyal wrote: >>> >>> >>> Hi Ping Pan, >>> >>> >>> >>> >>> >>> Thanks for the information. But, you say that CAC would make sense at >>> >>> >>> the edge. Would you please tell what are the mechanisms used in real >>> >>> >>> ISP networks to find out the explicit paths that meet certain QoS flow >>> >>> >>> requirement. Or are the paths are statically (manually) set without any >>> >>> >>> dynamic traffic engineering ? >>> >>> >>> I am presently working on algorithms on admission control on MPLS (and >>> >>> >>> MPLS over DiffServ network) and have worked out few algorithms in >>> >>> >>> theory. But, I donot yet know how and what actually ISPs are doing in >>> >>> >>> reality for admission control ? Does it make sense commercially to come >>> >>> >>> up with good TE techniques or algorithms that would help us find >>> >>> >>> explicit paths in MPLS network at the edge that would meet certain QoS >>> >>> >>> requirements. Or may be, given a LSP path, it makes more sense going for >>> >>> >>> a DiffServ admission control rather than finding explicit path. >>> >>> >>> >>> >>> >>> Thanks for anticipated help. >>> >>> >>> >>> >>> >>> warm regards, >>> >>> >>> Sudeep >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, 4 Nov 2004, Ping Pan wrote: >>> >>> >>> >>> >>> >>>> First, in the (MPLS) backbone networks, most of the links are >>> >>> >>>> over-provisioned, so not sure CAC and many QoS enforcement would make >>> >>> >>>> much >>> >>> >>>> use there. >>> >>> >>>> >>> >>> >>>> At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP, >>> >>> >>>> that can be used to carry DiffServ class. The LSP's that carry such >>> >>> >>>> information is called EXP-inferred LSP (E-LSP). The MPLS router can >>> >>> >>>> run the >>> >>> >>>> standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the >>> >>> >>>> packets within the LSP. This function becomes more important during flow >>> >>> >>>> aggregation. >>> >>> >>>> >>> >>> >>>> There are a bunch of drafts from Cisco on this topic over the years. >>> >>> >>>> >>> >>> >>>> - Ping >>> >>> >>>> >>> >>> >>>>> -----Original Message----- >>> >>> >>>>> From: end2end-interest-bounces@postel.org >>> >>> >>>>> [mailto:end2end-interest-bounces@postel.org] On Behalf Of Fahad Dogar >>> >>> >>>>> Sent: Wednesday, October 20, 2004 12:12 AM >>> >>> >>>>> To: end2end-interest@postel.org >>> >>> >>>>> Subject: [e2e] Admission Control and Policing in MPLS >>> >>> >>>>> >>> >>> >>>>> >>> >>> >>>>> Hi, >>> >>> >>>>> >>> >>> >>>>> I would like to know the mechanism employed in MPLS networks >>> >>> >>>>> for admission control and the process of subsequently >>> >>> >>>>> policing the flow in order to ensure that it does not violate the SLA. >>> >>> >>>>> >>> >>> >>>>> Any help or pointers to any standardized requirements would >>> >>> >>>>> be greatly appreciated. >>> >>> >>>>> >>> >>> >>>>> Thanks in advance, >>> >>> >>>>> Fahad >>> >>> >>>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> cheers >>> >>> >>> >>> jon >>> >>> >>> >>> >>> >> >>> >>-- >>> >>> cheers >>> >>> jon cheers jon From rja at extremenetworks.com Sun Nov 7 08:16:36 2004 From: rja at extremenetworks.com (RJ Atkinson) Date: Sun Nov 7 08:17:43 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: <418D5B98.9050103@cs.columbia.edu> References: <418D5B98.9050103@cs.columbia.edu> Message-ID: <65EACC64-30D8-11D9-9F0C-000D93B505E6@extremenetworks.com> On Nov 6, 2004, at 18:17, Ping Pan wrote: > Since the beginning of commercial data networking, carrier's business > model has been selling guaranteed bandwidth to individual users. Much > of the telecom operation has been built around this model (accounting, > planning, restoration, OAM...). And this is not likely to change in > the near future, even when you have GigE all over the place. Thus, > per-flow, per-customer, per-call, per-whatever policing will still be > in place at edge. However, this does not impact how e2e applications > suppose to work - long live TCP. ;-) In several Asian and Nordic countries, several different telecommunications carriers are offering "best effort" services (NOT guaranteed bandwidth) to their end-users over their GigE links. So there is some evidence that the historic "guaranteed bandwidth" model already has changed in some parts of the world for some firms. And I would guess that you and I have slightly different defintions for "data networking". For services like Frame Relay, your description of history is correct. For IP services that ISPs offer (e.g. UUnet, Sprint.net), those services have always been "best effort" not "guaranteed bandwidth". Depending on one's viewpoint, IP services might be part of "commercial data networking" -- certainly I would consider best-effort-only IP services to be part of "commercial data networking" at least since the advent of UUnet (roughly 15 years ago now). Ran rja@extremenetworks.com From Bonaventure at info.ucl.ac.be Sun Nov 7 13:12:52 2004 From: Bonaventure at info.ucl.ac.be (Olivier Bonaventure) Date: Sun Nov 7 13:13:16 2004 Subject: [e2e] topological locality of Internet communication? In-Reply-To: <418A9D3F.9020302@netlab.nec.de> References: <418A9D3F.9020302@netlab.nec.de> Message-ID: <1099861972.1832.79.camel@pcobo> Lars, > since we were just talking about Internet statistics: > > I'm looking to get a feel of how much topological locality Internet > communication exhibits, to calibrate some simulations we plan to run. > > Is anyone aware of measurements of how many "AS hops" typical > connections cross in the Internet? Ideal would be a CDF of "AS hops > crossed" for connection percentages. We did a detailed analysis of all the packets sent by our University during one month and checked their topological distribution. You can find more information in the paper. I have also attached the abstract. S. Uhlig, V. Magnin, O. Bonaventure, C. Rapier, and L. Deri. Implications of the topological properties of Internet traffic on traffic engineering. In 19th ACM Symposium on Applied Computing, Special Track on Computer Networks, March 2004. In this paper we study the behavior of Internet traffic on the AS-level topology and discuss its implications on interdomain traffic engineering. We rely on two notable interdomain traffic traces, the first is one month long and the other is one day long. This study shows that interdomain paths are stable for a large majority of the traffic from a routing viewpoint. We show that the aggregation of the traffic occurring on the AS-level graph is essentially limited to direct peers, with almost no aggregation occurring at larger AS hop distances. Furthermore, only part of the AS paths of the AS-level topology that see a lot of traffic are stable, when considering their presence among the largest AS paths on a hourly basis. Relying on the largest AS paths in traffic over a time window to capture the traffic over the next time interval discloses the important variability of the traffic seen by the largest AS paths in traffic. Interdomain traffic engineering is hence due to be difficult because of the limited traffic aggregation on the AS-level topology and the important topological variability of the traffic for a significant percentage of the total traffic. See http://totem.info.ucl.ac.be/publications.html Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/ From Bonaventure at info.ucl.ac.be Sun Nov 7 13:17:25 2004 From: Bonaventure at info.ucl.ac.be (Olivier Bonaventure) Date: Sun Nov 7 13:18:43 2004 Subject: [e2e] Internet path dynamics In-Reply-To: <418A4EBA.3090307@end2end.l.wanda.ch> References: <418A4EBA.3090307@end2end.l.wanda.ch> Message-ID: <1099862245.1832.86.camel@pcobo> On Thu, 2004-11-04 at 16:46, Marcel Waldvogel wrote: > Dmitri, > > the ones I know are due to personal communications and seem to be based > on informal sources or close personal contacts with ISPs. As such, there > is really nothing public I can point you to, sorry. I know at least two interesting studies of the stability of IGPs : @inproceedings{infocom04MIBCD:2004, author = {Markopoulou, A. and Iannaccone, G. and Bhattacharyya, S. and Chuah, C. and Diot, C.}, title = {Characterization of Failures in an {IP} Backbone}, booktitle = {IEEE Infocom2004}, address = {Hong Kong}, month = {March}, year = {2004} } @inproceedings{Shaikh_Case:2002, author = {Aman Shaikh and Chris Isett and Albert Greenberg and Matthew Roughan and Joel Gottlieb}, title = {A case study of OSPF behavior in a large enterprise network}, booktitle = {Proceedings of the second ACM SIGCOMM Workshop on Internet measurment}, year = 2002, isbn = {1-58113-603-X}, pages = {217--230}, location = {Marseille, France}, doi = {http://doi.acm.org/10.1145/637201.637236}, publisher = {ACM Press} } @inproceedings{Watson_OSPF:2003, author = {D. Watson and F. Jahanian and C. Labovitz}, title = {Experiences With Monitoring OSPF on a Regional Service Provider Network}, booktitle = {Proceedings of the 23rd International Conference on Distributed Computing Systems}, year = {2003}, isbn = {0-7695-1920-2}, pages = {204}, publisher = {IEEE Computer Society}, } For those running a network with ISIS, we have developped a set of perl scripts that allows to easily monitor the stability of the IGP inside the network. We used it for several ISP networks, but haven't published any results due to NDA issues. See http://totem.info.ucl.ac.be/tools.html for LISIS Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/ From Bonaventure at info.ucl.ac.be Sun Nov 7 13:22:59 2004 From: Bonaventure at info.ucl.ac.be (Olivier Bonaventure) Date: Sun Nov 7 13:23:17 2004 Subject: [e2e] QBONE abandon QoS research ? In-Reply-To: <20041105104527.7272.qmail@web15403.mail.cnb.yahoo.com> References: <20041105104527.7272.qmail@web15403.mail.cnb.yahoo.com> Message-ID: <1099862578.1686.91.camel@pcobo> Jing, > To my knowledge, some new ISP establish QoS enabled > service around but some old ISP still overprovision > their backbone. QBONE could be the first testbed for > QoS across WAN. But, words on their homepage > (http://qbone.internet2.edu) seem to indicate they > give up QoS at all while they try to find something > like "less than best effort". > > My questions: > > 1. Is there any summary report/paper on their > experience with DiffServ+MPLS based QoS? Have they > summarized the result of implementing WRED (or similar > technique) in QBONE? Research networks like I2 or GEANT in Europe are often overprovisionned and do not necessarily need QoS.Furthermore, their customers usually do not pay directly and there is no strict incentive for stringent SLAs. Commercial ISPs have stringent QoS needs. See : @Article{Filsfils_Engineering:2002, author = {C. Filsfils and J. Evans}, title = {Engineering a multiservice IP backbone to support tight SLAs }, journal = {Computer Networks }, year = 2002, volume = 40, number = 1, pages = {131-148}, month = {September} } See also http://doi.acm.org/10.1145/944592.944598 Olivier From rsatish at yahoo.com Sun Nov 7 15:23:24 2004 From: rsatish at yahoo.com (Satish Raghunath) Date: Sun Nov 7 15:24:43 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: <418EA70C.2080600@research.att.com> Message-ID: <20041107232324.12931.qmail@web51804.mail.yahoo.com> I would like to point to recent related work we did at AT&T Labs Research and RPI, regarding admission control, traffic matrices and provisioning when we are dealing with MPLS based IP VPNs. In our upcoming paper in INFOCOM 2005, we examine the question of admitting VPNs (point-to-multipoint aggregates in general) and how it is impacted by admission control choices and presence of Traffic matrix estimates: http://networks.ecse.rpi.edu/~rsatish/vpn_resmgmt.pdf The above simulation study is based on a large-scale measurement study we did to estimate IP VPN traffic matrices. As Dr. Crowcroft notes, this is not a trivial question. Our paper in IMC 2004 sheds more light on state-of-the-art in Carrier measurement for VPNs and how best to glean traffic matrices from them: http://networks.ecse.rpi.edu/~rsatish/vpn_tm.pdf In combination, the papers above deal with the question of how to obtain traffic matrices in a realistic carrier scenario; given TMs we then look at what impact such information has in the presence of statistical admission and/or signaling-based admission control choices. Best, Satish -------- Original Message -------- Subject: Re: [e2e] Admission Control and Policing in MPLS Date: Sun, 07 Nov 2004 12:04:59 +0000 From: Jon Crowcroft To: Ping Pan ,end2end-interest@postel.org, Jon.Crowcroft@cl.cam.ac.uk I can't stress how much I agree about the evolution of carrierbusiness - this is an area that is extremely interesting, bothcommercially to vendors and service providers, but also to researchersas we need to consider how to provision for aggregates oftraditional traffic, but flowing over VPNs and current work onprovisioning has tended to assume the traffic matrix is transparent,whereas its partially opaque in a vpn....plus the "arrival process" for a network provider is of entire legacyenterprise nets (previously provisioned using frame relay or atm ) moving over to the IP core...it would be interesting to get estimatesfrom the large teleco/isps (at&t obviously, but on a smaller scale alot of european outfits - certinly BT, FT and DT and telecom italia)of the amount of legacy net that we might expect to migrate...also agree about voip..In missive <418D5B98.9050103@cs.columbia.edu>, Ping Pan typed: >>> what i mean is that the _algorithms and framework_ to do congestion >>> control and to do CAC are related and similar - the timescales are >>> different - one is per packet or rtt, the other is per session or flow >>> or call or forwarding equiv. class or diff serve class or whatever >>> aggregate you want but as the system gets very big, the differences >>> get very small indeed actually. >>> >> >>Agree 100%. With the advance in silicon, per-flow policing/shaping, >>queuing and scheduling for various traffic types, dropping... can be >>done at very high speed. Not sure there much magic in this area. The >>issue becomes where to apply all this. >> >>> i wasnt suggesting that all video/voice/game traffic should be >>> converted to be elastic adaptive behaviour (although its not so hard >>> for many of them) - conversely one can argue that limiting the number >>> of TCP flows through CAC might give a good (near guaranteed ) response >>> time to web users too - sure - two sides of same coin.... >>> In missive , Sudeep Goya >>> l typed: >>> >> >>Maybe. There are a couple of exceptions here. >> >>Since the beginning of commercial data networking, carrier's business >>model has been selling guaranteed bandwidth to individual users. Much of >>the telecom operation has been built around this model (accounting, >>planning, restoration, OAM...). And this is not likely to change in the >>near future, even when you have GigE all over the place. Thus, per-flow, >>per-customer, per-call, per-whatever policing will still be in place at >>edge. However, this does not impact how e2e applications suppose to work >>- long live TCP. ;-) >> >>Another issue is the method of migrating traffic from the existing >>networks to new ones, while still making money for the carriers. This is >>likely taking place at the edge. During the migration, the entire suite >>of QoS must be in place for many business users. This is where some >>DiffServ type of conditioning would be useful. This is the reason why >>you see a number of proposals on ATM-MPLS interworking in recent months. >>Again, you may find them from IETF MPLS/PWE3/L2VPN WG drafts.... >> >>As for the traffic types. VoIP traffic is not CBR, and never will be. >>;-) In fact, the entire VoIP looks like an enterprise/end-user >>application to me. The switches/routers have no way of knowing what it >>is from the packet itself. One deployment scenario I have seen is to map >>VoIP traffic onto a VLAN, and provisioning BW on that VLAN from network >>edge. In this case, a simple priority queue or a half decent WFQ would >>do the job. >> >>- Ping >> >>> >>On Sat, 6 Nov 2004, Jon Crowcroft wrote: >>> >> >>> >>> on a more general point... >>> >>> >>> >>> personally , i could never see the fundamental different between >>> >>> packet drop mechanis and congestion control >>> >>> and >>> >>> call admission control with call blocking >>> >>> >>> >>> in both cases, you have to look at the provisioning of buffers - >>> >>> based on some model of the traffic source, and make decisions about >>> >>> which packet/flow to drop/block based on the specific source model and >>> >>> the multiplexing and aggregate behaviours...its just a >>> >>> timescale/granualrity difference in the end >>> >> >>> >>Jon. In my humble opinion, there is a big difference depending on the >>> >>kind of traffic that is being injected into the network. >>> >> >>> >>Say, for example you have a CBR (constant bit rate) traffic for VoIP, >>> >>video-conferencing and you need to provide stringent qos requirements. >>> >>You donot bring congestion in the network and here, CAC plays important >>> >>role. Because any implementation of congestion control mechanism at the >>> >>core nodes would produce delay etc which we donot want for CBR kind of >>> >>traffic. The schedulling in this case at each node would also be highest. >>> >>In above traffic, delay and jitter are important qos parameters. >>> >> >>> >>But, for elastic traffic (like FTP) which is also greedy and built over >>> >>TCP we need to be careful about the throughput because here throughput is >>> >>more important than delay and hence, we need to deploy proper RED >>> >>mechanism and maintain high throughput and admit more flows. Dropping of >>> >>packets and little delay is accpetable. But, throughput should be high. >>> >>Therefore, CAC algorithm should consider this and accept such elastic >>> >>traffic accordingly, fulling knowing that RED and congestion control >>> >>(TCP) is used for such traffic. >>> >> >>> >>For CBR traffic, CBR algorithm cannot take the chance for congestion and >>> >>most importantly, delay and loss of packets, therefore, never >>> >>overprovision any flow (flows are also more UDP-oriented). Then there can >>> >>be other kinds of flows like VBR, elastic short-lived flows and best-effort. >>> >> >>> >> Thanks Ping Pan for the information again :) But, plz help me clarify >>> >>following: >>> >> >>> >>> >> >>> >>> >>Another observation, most deployed MPLS networks in metro area use LDP >>> >>> >>to setup LSP's. LDP does not have QoS awareness by design. >>> >> >>> >>This is informative. But, could you plz tell if coming up with good MPLS >>> >>over DiffServ CAC algorithms that would help the incoming traffic meet its >>> >>requested QoS be useful (commercially). From what you have said, it feels >>> >>that ISPs are not doing it and may not need it at present, but future could be a >>> >>possiblity. Am i right? >>> >> If people have already done some work, can you plz refer some links to me >>> >>(from where I can know the state-of-art of MPLS over DiffServ admission >>> >>control algorithms)? >>> >> >>> >>Thanks a lot Again. >>> >> >>> >>Warm Regards, >>> >>Sudeep >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>> >>- Ping >>> >>> >> >>> >>> >> >>> >>> >>Sudeep Goyal wrote: >>> >>> >>> Hi Ping Pan, >>> >>> >>> >>> >>> >>> Thanks for the information. But, you say that CAC would make sense at >>> >>> >>> the edge. Would you please tell what are the mechanisms used in real >>> >>> >>> ISP networks to find out the explicit paths that meet certain QoS flow >>> >>> >>> requirement. Or are the paths are statically (manually) set without any >>> >>> >>> dynamic traffic engineering ? >>> >>> >>> I am presently working on algorithms on admission control on MPLS (and >>> >>> >>> MPLS over DiffServ network) and have worked out few algorithms in >>> >>> >>> theory. But, I donot yet know how and what actually ISPs are doing in >>> >>> >>> reality for admission control ? Does it make sense commercially to come >>> >>> >>> up with good TE techniques or algorithms that would help us find >>> >>> >>> explicit paths in MPLS network at the edge that would meet certain QoS >>> >>> >>> requirements. Or may be, given a LSP path, it makes more sense going for >>> >>> >>> a DiffServ admission control rather than finding explicit path. >>> >>> >>> >>> >>> >>> Thanks for anticipated help. >>> >>> >>> >>> >>> >>> warm regards, >>> >>> >>> Sudeep >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, 4 Nov 2004, Ping Pan wrote: >>> >>> >>> >>> >>> >>>> First, in the (MPLS) backbone networks, most of the links are >>> >>> >>>> over-provisioned, so not sure CAC and many QoS enforcement would make >>> >>> >>>> much >>> >>> >>>> use there. >>> >>> >>>> >>> >>> >>>> At the edge, CAC is relevant. In MPLS label, there is a 3-bit field, EXP, >>> >>> >>>> that can be used to carry DiffServ class. The LSP's that carry such >>> >>> >>>> information is called EXP-inferred LSP (E-LSP). The MPLS router can >>> >>> >>>> run the >>> >>> >>>> standard DiffServ 2-color/1-color CAC, queuing, dropping etc. on all the >>> >>> >>>> packets within the LSP. This function becomes more important during flow >>> >>> >>>> aggregation. >>> >>> >>>> >>> >>> >>>> There are a bunch of drafts from Cisco on this topic over the years. >>> >>> >>>> >>> >>> >>>> - Ping >>> >>> >>>> >>> >>> >>>>> -----Original Message----- >>> >>> >>>>> From: end2end-interest-bounces@postel.org >>> >>> >>>>> [mailto:end2end-interest-bounces@postel.org] On Behalf Of Fahad Dogar >>> >>> >>>>> Sent: Wednesday, October 20, 2004 12:12 AM >>> >>> >>>>> To: end2end-interest@postel.org >>> >>> >>>>> Subject: [e2e] Admission Control and Policing in MPLS >>> >>> >>>>> >>> >>> >>>>> >>> >>> >>>>> Hi, >>> >>> >>>>> >>> >>> >>>>> I would like to know the mechanism employed in MPLS networks >>> >>> >>>>> for admission control and the process of subsequently >>> >>> >>>>> policing the flow in order to ensure that it does not violate the SLA. >>> >>> >>>>> >>> >>> >>>>> Any help or pointers to any standardized requirements would >>> >>> >>>>> be greatly appreciated. >>> >>> >>>>> >>> >>> >>>>> Thanks in advance, >>> >>> >>>>> Fahad >>> >>> >>>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> cheers >>> >>> >>> >>> jon >>> >>> >>> >>> >>> >> >>> >>-- >>> >>> cheers >>> >>> jon cheers jon __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From braden at ISI.EDU Sun Nov 7 22:05:47 2004 From: braden at ISI.EDU (Bob Braden) Date: Sun Nov 7 22:21:28 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: <20041107232324.12931.qmail@web51804.mail.yahoo.com> References: <418EA70C.2080600@research.att.com> Message-ID: <5.1.0.14.2.20041107220454.00a7c8a0@boreas.isi.edu> People, PLEASE rrim the cruft off the end of your messages! It is good email manners. Thanks, Bob Braden From jshen_cad at yahoo.com.cn Mon Nov 8 05:19:21 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Mon Nov 8 05:20:19 2004 Subject: [e2e] Re: QBONE abandon QoS research ? In-Reply-To: <86fz3o3pk1.fsf@abel.internet2.edu> Message-ID: <20041108131921.30126.qmail@web15405.mail.cnb.yahoo.com> Hi, > The closest we've come to writing is: > http://qbone.internet2.edu/papers/non-architectural-problems.txt > > See also: > http://portal.acm.org/citation.cfm?id=944600 > http://portal.acm.org/citation.cfm?id=944603 That could be interesting, esp. DoS & QoS > The networks were upgraded faster than the users' > appetites for > capacity use grew. Doubling every year (on average) > is a reasonable > rule of thumb. How fast does your traffic grow? The begining of this year there is 7.5Gbps available( In/Out), by last month there is 10Gbps available. But the BW utlization of three PoS is 90% (bidirectional), the last one hit by congestion. This is only a subnetwork statistics, while in backbone congestion happen months ago. Is that reasonable to double BW year by year? If it is, why ISP should keep on investing while per-customer price keeps decreasing? regards Jing ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From shalunov at internet2.edu Mon Nov 8 10:00:37 2004 From: shalunov at internet2.edu (stanislav shalunov) Date: Mon Nov 8 10:00:20 2004 Subject: [e2e] QBONE abandon QoS research ? In-Reply-To: <20041108131921.30126.qmail@web15405.mail.cnb.yahoo.com> References: <20041108131921.30126.qmail@web15405.mail.cnb.yahoo.com> Message-ID: <86oei82pbu.fsf@abel.internet2.edu> Jing Shen writes: > Is that reasonable to double BW year by year? If it is, why ISP > should keep on investing while per-customer price keeps decreasing? To remain competitive? Increasing capacity is the cheapest way of providing QoS at the moment. You could ask the same question about CPUs: why should Intel and AMD keep making faster chips, if CPUs aren't getting any more expensive? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at room temperature. From simon at limmat.switch.ch Mon Nov 8 12:05:50 2004 From: simon at limmat.switch.ch (Simon Leinen) Date: Mon Nov 8 12:06:32 2004 Subject: [e2e] QBONE abandon QoS research ? In-Reply-To: <1099862578.1686.91.camel@pcobo> (Olivier Bonaventure's message of "07 Nov 2004 22:22:59 +0100") References: <20041105104527.7272.qmail@web15403.mail.cnb.yahoo.com> <1099862578.1686.91.camel@pcobo> Message-ID: Olivier Bonaventure writes: > Research networks like I2 or GEANT in Europe are often > overprovisionned and do not necessarily need QoS. As someone who helps run such a network (a small European "NREN"), I tend to agree. > Furthermore, their customers usually do not pay directly True in some places. Our users (R&E institutions) certainly do pay us directly. Our charging scheme is probably at least as complex as any commercial ISP's, and includes volume- (differentiated by destination and time of day) and access-rate-based components. Because we do charge our users, we have LESS, not more need for QoS mechanisms in our network, because we can maintain a healthy (if slow) feedback loop between user behavior and the resources available for upgrading the backbone. (Although most "end" users don't pay or even see our bills, they get various kinds of signals from those who do.) Given our cost structure and the approximate elasticities of customer traffic demand and willingness to pay, I'm pretty sure that we can continue building out our backbone in this overprovisioned regime for many years to come. On the other hand we're not here to make money, although we do compete with commercial ISPs in a way. > and there is no strict incentive for stringent SLAs. As some of us serve hospitals and such, the question of well-defined SLAs does come up occasionally even for research networks. It's true that customers tend to feel more entitled to SLAs when they pay for the service directly. It's also true that the uptake of SLAs in the research network space is slow, but I don't think lack of QoS mechanisms is an important reason for that. How "tight" or "stringent" these SLAs need to be is another question. In many cases customers are mostly interested in availability guarantees. Others say they need N Mb/s guaranteed bandwidth, but in fact they are only worried that they can transfer M Megabytes of bulk data through our network and back every afternoon and be damn sure that the results are back in time for the evening news whether forecast. > Commercial ISPs have stringent QoS needs. See : [pointers to two papers by employees of a large vendor of expensive QoS-capable core network equipment explaining network operators why they need this] (Why does this make me think of Randy Bush talking about "IntServ, DiffServ, and SelfServ"? :-) I know many commercial ISPs that don't have stringent QoS needs. Or maybe they just don't know it yet. Of course those that do probably make all the money. Whether they add sufficient value to justify the additional complexity in the long run is another question. Note that I do think a mechanism like diffserv is a great tool to have in my toolkit. I just hope I'll never have to use it :-) -- Simon. From nataraja at cis.udel.edu Tue Nov 9 15:31:03 2004 From: nataraja at cis.udel.edu (Preethi Natarajan) Date: Tue Nov 9 15:31:52 2004 Subject: [e2e] Minimum RTO values Message-ID: Hello, I am trying to probe webservers in the Internet for TCP Min RTO values. Based on my preliminary tests I saw the following results, which I want to validate. Linux : around 200 ms FreeBSD : around 1s Sun Solaris : around 4s Microsoft windows server : around 2s Can anybody throw some light on the actual Min RTO values used by different OSes? (listed above or otherwise)? Thanks a lot, Preethi From christin at SIMS.Berkeley.EDU Tue Nov 9 17:10:50 2004 From: christin at SIMS.Berkeley.EDU (Nicolas Christin) Date: Tue Nov 9 17:12:05 2004 Subject: [e2e] Minimum RTO values In-Reply-To: References: Message-ID: <20041110011050.GI1652@dogmatix.SIMS.Berkeley.EDU> Preethi, On Tue Nov 09, 2004, Preethi Natarajan wrote: > > I am trying to probe webservers in the Internet for TCP Min RTO > values. Based on my preliminary tests I saw the following results, > which I want to validate. Looking at the source code of the various OS's you refer to might help... > Linux : around 200 ms Sounds about right (at least for Linux 2.4). From /usr/src/linux/include/net/tcp.h: #define TCP_RTO_MIN ((unsigned)(HZ/5)) where HZ is roughly equivalent to one second. > FreeBSD : around 1s It depends. Some versions of FreeBSD (e.g., 4.x) have 1s, indeed. The value is in /usr/sys/include/netinet/tcp_timer.h: #define TCPTV_MIN (hz) but I also saw some branches which have a 3 in there instead, e.g., the current branch (see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_timer.h?rev=1.26&content-type=text/x-cvsweb-markup). > Sun Solaris : around 4s Solaris 8 has in /usr/include/netinet/tcp_timer.h: #define TCPTV_MIN (1*PR_SLOWHZ) which should indicate a 1 second minimum RTO. Hope this helps! -- Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041109/beb21bdd/attachment.bin From weigengyu at hotmail.com Tue Nov 9 23:22:00 2004 From: weigengyu at hotmail.com (weigengyu) Date: Tue Nov 9 23:22:01 2004 Subject: [e2e] Admission Control and Policing in MPLS References: <418D5B98.9050103@cs.columbia.edu> <65EACC64-30D8-11D9-9F0C-000D93B505E6@extremenetworks.com> Message-ID: ----- Original Message ----- From: "RJ Atkinson" To: "Ping Pan" Cc: "end-to-end list" Sent: Monday, November 08, 2004 12:16 AM Subject: Re: [e2e] Admission Control and Policing in MPLS > > In several Asian and Nordic countries, several different > telecommunications > carriers are offering "best effort" services (NOT guaranteed bandwidth) > to their > end-users over their GigE links. So there is some evidence that the > historic > "guaranteed bandwidth" model already has changed in some parts of the > world for some firms. I would like to tell you a fact here. A telecom carrier build another IP based network dedicated to some basic service, like voice, video. Because the first IP based network always congested and cannot provide QoS needed although they increased capacity. > And I would guess that you and I have slightly different defintions for > "data networking". For services like Frame Relay, your description of > history is correct. For IP services that ISPs offer (e.g. UUnet, > Sprint.net), > those services have always been "best effort" not "guaranteed > bandwidth". > Depending on one's viewpoint, IP services might be part of "commercial > data networking" -- certainly I would consider best-effort-only IP > services > to be part of "commercial data networking" at least since the advent of > UUnet > (roughly 15 years ago now). > > Ran > rja@extremenetworks.com > Guaranteed services are the most concern problems by telcom carriers since they are deploying SLA (Service Level Aggreement). Gengyu WEI From rja at extremenetworks.com Wed Nov 10 05:51:24 2004 From: rja at extremenetworks.com (RJ Atkinson) Date: Wed Nov 10 05:52:06 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: References: <418D5B98.9050103@cs.columbia.edu> <65EACC64-30D8-11D9-9F0C-000D93B505E6@extremenetworks.com> Message-ID: <9C572250-331F-11D9-A78A-000D93B505E6@extremenetworks.com> On Nov 10, 2004, at 02:22, weigengyu wrote: > Guaranteed services are the most concern problems by telcom carriers > since they are deploying SLA (Service Level Aggreement). I have no doubt that is true for many telecom carriers. I also know of many telecom carriers who are not concerned about guaranteed services. The world is large enough that one can find many examples that are different from each other. :-) Ran From Venkata.Naidu at Marconi.com Wed Nov 10 14:19:57 2004 From: Venkata.Naidu at Marconi.com (Naidu, Venkata) Date: Wed Nov 10 14:21:21 2004 Subject: [e2e] Minimum RTO values Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F80001306C@usvissfp01.win.marconi.com> Preethi, -> Hello, -> -> I am trying to probe webservers in the Internet for TCP Min -> RTO values. -> Based on my preliminary tests I saw the following results, -> which I want to -> validate. -> -> Linux : around 200 ms Yes. This is correct. Most of the Lunux TCP constants are defined in ~/include/net/tcp.h : #define TCP_RTO_MAX ((unsigned)(120*HZ)) #define TCP_RTO_MIN ((unsigned)(HZ/5)) Linux 2.4 and previous versions use HZ of 100ms (default) and Linux 2.6 uses HZ of 1000ms (default). But, the defines are tuned to reflect TCP_RTO_MIN to 200ms. -> FreeBSD : around 1s This value of 1s is used in old FreeBSD versions. Now the min RTO in FreeBSD is 30ms. Note that, this constants are specific to FreeBSD and very different from NetBSD and OpenBSD. If you are looking for NetBSD and OpenBSD values, let me know. /* * Minimum retransmit timer is 3 ticks, for algorithmic stability. * TCPT_RANGESET() will add another TCPTV_CPU_VAR to deal with * the expected worst-case processing variances by the kernels * representing the end points. Such variances do not always show * up in the srtt because the timestamp is often calculated at * the interface rather then at the TCP layer. This value is * typically 50ms. However, it is also possible that delayed * acks (typically 100ms) could create issues so we set the slop * to 200ms to try to cover it. Note that, properly speaking, * delayed-acks should not create a major issue for interactive * environments which 'P'ush the last segment, at least as * long as implementations do the required 'at least one ack * for every two packets' for the non-interactive streaming case. * (maybe the RTO calculation should use 2*RTT instead of RTT * to handle the ack-every-other-packet case). * * The prior minimum of 1*hz (1 second) badly breaks throughput on any * networks faster then a modem that has minor (e.g. 1%) packet loss. */ #define TCPTV_MIN ( 3 ) /* minimum allowable value */ #define TCPTV_CPU_VAR ( hz/5 ) /* cpu variance allowed (200ms) */ #define TCPTV_REXMTMAX ( 64*hz) /* max allowable REXMT value */ -> Sun Solaris : around 4s Should be 400ms as per Solaris 9 Tunable parameters document: http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWaadm/SOLTUNEPARAMREF/p 36.html -> Microsoft windows server : around 2s Sorry I don't have access to such kernels or (at least) header files or documents. -> Can anybody throw some light on the actual Min RTO values used by -> different OSes? (listed above or otherwise)? -> -> Thanks a lot, -> Preethi Venkata. From pingpan at cs.columbia.edu Thu Nov 11 07:39:19 2004 From: pingpan at cs.columbia.edu (Ping Pan) Date: Thu Nov 11 07:40:19 2004 Subject: [e2e] Admission Control and Policing in MPLS In-Reply-To: References: <418D5B98.9050103@cs.columbia.edu> <65EACC64-30D8-11D9-9F0C-000D93B505E6@extremenetworks.com> Message-ID: <419387A7.7020803@cs.columbia.edu> weigengyu wrote: > > I would like to tell you a fact here. A telecom carrier build another IP based network > dedicated to some basic service, like voice, video. > Because the first IP based network always congested and cannot provide QoS needed > although they increased capacity. > Another fact: some carriers have never moved their voice traffic off ATM backbone, because the IP backbone cannot sustain delay-sensitive traffic at large volume. The problem takes place at edge. > > Guaranteed services are the most concern problems by telcom carriers > since they are deploying SLA (Service Level Aggreement). > SLA is NOT about rate guarantee only. It also includes accounting, restoration, per-flow manageability... - Ping From faber at ISI.EDU Thu Nov 4 11:00:31 2004 From: faber at ISI.EDU (Ted Faber) Date: Thu Nov 11 10:45:54 2004 Subject: [e2e] CFP: Global Internet 2005 Message-ID: <20041104190031.GI16671@pun.isi.edu> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041104/d7a267d0/attachment.bin From weigengyu at hotmail.com Thu Nov 11 17:51:26 2004 From: weigengyu at hotmail.com (weigengyu) Date: Thu Nov 11 17:50:49 2004 Subject: [e2e] Admission Control and Policing in MPLS References: <418D5B98.9050103@cs.columbia.edu> <65EACC64-30D8-11D9-9F0C-000D93B505E6@extremenetworks.com> <419387A7.7020803@cs.columbia.edu> Message-ID: ----- Original Message ----- From: "Ping Pan" > > Another fact: some carriers have never moved their voice traffic off ATM > backbone, because the IP backbone cannot sustain delay-sensitive traffic > at large volume. The problem takes place at edge. > Telecom carriers here just use IP backbone for long haul transimision. > > SLA is NOT about rate guarantee only. It also includes accounting, > restoration, per-flow manageability... > Accepted concepts about SLA are difined by TMF. Gengyu From jshen_cad at yahoo.com.cn Mon Nov 15 03:37:05 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Mon Nov 15 03:37:53 2004 Subject: [e2e] Computing Traffic Matrix from netflow data Message-ID: <20041115113705.99914.qmail@web15405.mail.cnb.yahoo.com> Hi, I'm starting to do up scripts which could be used to compute traffic matrix (node-to-node). But, I found it's a little bit troublesome as routing path may change with time. Also, using (source_ip, dest_ip) is hard to compute node level metrix because routing table size is really large and amount of raw data is huge( my situation, more than 120GB). Is there anybody has such experience ? Is there any body would like to share your work? thanks . Jing ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From ssuryaputra at HatterasNetworks.com Mon Nov 15 06:29:42 2004 From: ssuryaputra at HatterasNetworks.com (Stephen Suryaputra) Date: Mon Nov 15 06:29:54 2004 Subject: [e2e] WFQ with shared buffering Message-ID: <8052E2EA753D144EB906B7A7AA39971402B9C127@mailserv.hatteras.com> Hi, I'm wondering if anybody aware of any studies on the effect of sharing buffers among queues that are served with WFQ (or any approximation like DRR, SCFQ, ...). I'm interested in the scenario when no queues have a dedicated amount of buffering and once the packet is queued, the buffer cannot be taken back until the packet is transmitted. Any pointer is appreciated. Thanks, From Arnaud.Legout at sophia.inria.fr Mon Nov 15 08:29:14 2004 From: Arnaud.Legout at sophia.inria.fr (Arnaud Legout) Date: Mon Nov 15 08:30:56 2004 Subject: [e2e] WFQ with shared buffering In-Reply-To: <8052E2EA753D144EB906B7A7AA39971402B9C127@mailserv.hatteras.com> References: <8052E2EA753D144EB906B7A7AA39971402B9C127@mailserv.hatteras.com> Message-ID: <4198D95A.9010105@sophia.inria.fr> Hi, B. *Suter*, T. V. Lakshman, D. Stiliadis and A. Choudhury, "/Design considerations for supporting TCP with per-flow queuing/," Proc. of INFOCOMM '98, Apr. 1998. is a good starting point. You can also have a look at: A. Legout, and E. W. Biersack. *"Revisiting the Fair Queueing Paradigm for End-to-End Congestion Control*". /IEEE Network Magazine/, 16(5), September 2002. which extends a simulation of the paper of B. Suter to large topologies. Regards, Arnaud. Stephen Suryaputra wrote: >Hi, > >I'm wondering if anybody aware of any studies on the effect of sharing buffers among queues >that are served with WFQ (or any approximation like DRR, SCFQ, ...). I'm interested in the >scenario when no queues have a dedicated amount of buffering and once the packet is queued, the >buffer cannot be taken back until the packet is transmitted. > >Any pointer is appreciated. > >Thanks, > > > > -- Arnaud Legout, Ph.D. INRIA Sophia Antipolis - Plan?te Phone : 00.33.4.92.38.78.15 2004 route des lucioles - BP 93 Fax : 00.33.4.92.38.79.78 06902 Sophia Antipolis CEDEX E-mail: arnaud.legout@sophia.inria.fr FRANCE Web : http://www-sop.inria.fr/planete/Arnaud.Legout/index.html From jshen_cad at yahoo.com.cn Tue Nov 16 03:48:52 2004 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Tue Nov 16 03:49:59 2004 Subject: [e2e] Re: Computing Traffic Matrix from netflow data In-Reply-To: <200411151538.iAFFcjwn103682701@chips.research.att.com> Message-ID: <20041116114852.72403.qmail@web15405.mail.cnb.yahoo.com> Hi , Thanks for your help. > > http://www.cse.ucsd.edu/~teixeira/tm.pdf > > for details. For this study, we collected a feed of > iBGP update > messages from each of the ingress routers of > interest, so we > could track the changes in the BGP next-hops > continuously. To my situation, there is three E-BGP border routers which connect to the same AS with multiple links. In order to balance load on those links, BGP advertisement is modified manually ( for traffic in), and some part of network traffic is hard routed to special BGP border router. So, OSPF just control part of intra-AS traffic while BGP behavior is modified too. In fact, I don't think this is a good manner to follow in network optimization. But, before we get to know load requirement, esp. the trends of load variation, it's not possible to start network optimization. That's the reason why I do with netflow. Work on similar problem or information on how those ISPs do with such problem is valuable. > If you just want to compute the router-to-router > traffic matrix, > you could > > - collect Netflow measurements on the incoming > traffic > - aggregate traffic with the same destination > prefix, using > the BGP prefix information > - aggregate traffic with the same BGP next-hop, > using the > BGP next-hop information > If I do not make a mistake, above method is good for deriving traffic matrix for a backbone AS. But my situation is to optimize a "stub" network connecting to one AS. The network has its own ASN, it runs BGP with upper AS when it runs OSPF inside. Is there any work on deriving traffic matrix for OSPF area 0? Any work on OSPF optimzation for traffic engineering? thanks again. regards Jing 'spam control ' _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From Kaouthar.Sethom at int-evry.fr Mon Nov 22 01:54:48 2004 From: Kaouthar.Sethom at int-evry.fr (Kaouthar SETHOM) Date: Mon Nov 22 09:48:45 2004 Subject: [e2e] CFP ASWN 2005 Message-ID: <1101117288.41a1b7682363f@imp> Please accept my apologies if you receive multiple copies of this CfP CFP of the 5th Workshop on Applications and Services in Wireless Networks Maison de la Chimie, PARIS, FRANCE June 29th - July 1st, 2005 http://int-evry.fr/aswn2005/ Specific areas of interest in Applications and Services on Wireless Networks include, but are not limited to, the following topics: ?X Advances in WPAN, Personal Services and Networks ?X Mobile Ad-Hoc Networks and Multihop Wireless ?X Sensor Networks ?X Self Organizing Systems ?X Moving Networks ?X Inter Domain and System Mobility ?X Service discovery : protocols and frameworks ?X Naming and Addressing ?X Peer to Peer communications and paradigms ?X Media & content distribution over wireless networks ?X Audio-visual and Mobile Multimedia Applications ?X Nomadic Services ?X Middleware for Mobile Applications and Services ?X Service Execution Environments, Service Life Cycle and Mobile Service Interworking ?X Context Awareness and Personalization ?X QoS Profiling and Pricing, end-to-end QoS ?X Security architectures and mechanisms ?X Reconfigurable Systems and Networks ?X Cooperative Networks ?X Beyond 3G Enabling Technologies and Architectures ?X Performance of Wireless Networks and Systems IMPORTANT DEADLINES Full paper submission: March 22, 2005 Notification of acceptance: April 26, 2005 Camera ready due: May 12, 2005 Submitted papers should be full-scope manuscripts, and should not have been previously published, in part or in full, or be under consideration of another conference or journal. Submissions should be written in English using fonts no smaller than 10 points, and should not exceed 10 single-spaced pages. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: CFP_ASWN_2005.pdf Type: application/pdf Size: 748718 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041122/8ae803ca/CFP_ASWN_2005-0001.pdf From dima at krioukov.net Wed Nov 24 18:40:46 2004 From: dima at krioukov.net (Dmitri Krioukov) Date: Wed Nov 24 18:42:14 2004 Subject: [e2e] topological locality of Internet communication? In-Reply-To: <418B7483.60802@netlab.nec.de> Message-ID: lars, although not precisely what you're looking for, but the AS hop length distributions (or simply distance distributions) derived from BGP and *traceroute* data are not drastically different: http://www.caida.org/analysis/topology/as_topo_comparisons/master.xml (the associated text is in http://www.caid.org/~dima/pub/ccr-ivs_as-topo-comparisons.pdf ). also note that the average distance from ASs of degree-k exhibits *very slow* power-law decrease with k. finally, check this paper: http://arxiv.org/abs/cs/0411051 the above observations suggest that the AS hop length distribution in the "average host communication pattern" is unlikely to differ drastically from the distance distribution in the whole AS graph. -- dima. http://www.caida.org/~dima/ > -----Original Message----- > From: end2end-interest-bounces@postel.org > [mailto:end2end-interest-bounces@postel.org]On Behalf Of Lars Eggert > Sent: Friday, November 05, 2004 4:40 AM > To: Panos TRIMINTZIOS > Cc: end2end-interest@postel.org > Subject: Re: [e2e] topological locality of Internet communication? > > > Panos TRIMINTZIOS wrote: > > Information about AS Paths from routes advertised with BGP on the > > average/maximum AS path length (maybe also taking into account AS Path > > prepending statistics) is an indication of the "AS hops" a typical > > connection may cross in the Internet. Currently I the average AS Path > > size is around 3.5 AS hops, while the maximum 11-12. > > Thanks to Panos and others for providing these BGP-based numbers! > > However, they're not exactly what I was looking for. Knowing that the > average BGP path is around 3.5 hops is useful *if* the "average" host > starts connections to random other hosts in the Internet. I'm pretty > sure that the latter doesn't hold, i.e., that the communication pattern > of hosts isn't random. > > Jennifer's work on an AS-level traceroute is also interesting and > relevant; thanks for pointing me at it. However, I'm not completely sure > whether her tool can be run against an existing dump or requires live > traces. If the latter, I fear that those measurements could take up the > student's entire thesis time to be reasonably accurate. > > Thanks again to all who responded! > > Lars > -- > Lars Eggert NEC Network Laboratories > From arjuna at dcs.kcl.ac.uk Thu Nov 25 12:53:40 2004 From: arjuna at dcs.kcl.ac.uk (Arjuna Sathiaseelan) Date: Thu Nov 25 12:55:19 2004 Subject: [e2e] Satellite Date Rates In-Reply-To: <200411252000.iAPK04t07955@boreas.isi.edu> References: <200411252000.iAPK04t07955@boreas.isi.edu> Message-ID: <32870.137.73.8.107.1101416020.squirrel@137.73.8.107> Dear All, I would like to know what are the current range of data rates currently offered by GEO stationary satellites? Is it in the order of Kbps or can it transfer in Mbps? I would also like to know, whether there are any papers that have researched the effects of packet reordering on satellite networks? Reordering in satellites occurs mainly due to link level retransmissions and I would like to know what are the observed reordering rates in a satellite environment? I would be very much obliged if someone could clarify my doubts please. Regards, Arjuna From arjuna at dcs.kcl.ac.uk Fri Nov 26 01:27:54 2004 From: arjuna at dcs.kcl.ac.uk (Arjuna Sathiaseelan) Date: Fri Nov 26 01:28:53 2004 Subject: [e2e] Satellite Date Rates In-Reply-To: References: <200411252000.iAPK04t07955@boreas.isi.edu> <32870.137.73.8.107.1101416020.squirrel@137.73.8.107> Message-ID: <3582.195.92.67.78.1101461274.squirrel@195.92.67.78> Dear Lloyd, Thanks for your explainations. I am writing down the details provided by Sally Floyd's RR-TCP:Reordering Robust TCP paper: Satellite links have very long RTTs, typically on the order of several hundred milliseconds. To keep the pipe full,link-layer retransmission protocols for such links must continue sending subsequent packets while awaiting for an ACK or NAK for a previously sent packet. Here, a link-layer retransmission is reordered by however many packets were sent between the original transmission of that packet and the return of the ACK or NAK. [C.Ward, H.Choi and T.Hain. A datalink control protocol for LEO satellite networks providing a reliable datagram service. IEEE/ACM Transactions on Networking, 3(1):91-103,Feb 1995.] I was wondering whether this causes any reordering in GEO satellites? Regards, Arjuna >> Reordering in satellites occurs mainly due to link level retransmissions > > It does? Can you give us evidence supporting that claim? > > (People tend to presume a satellite channel is more errored than it > is. You need a BER better than 10e-5 to carry IP traffic well, so you > dimension coding for the channel appropriately. A 45MHz transponder > with an HDLC serial stream going through it may have no link layer to > speak of.) > > If the link layer is causing massive reordering, it may not be > designed well for IP traffic - see RFC3366 section 3.1. From dpreed at reed.com Fri Nov 26 09:28:44 2004 From: dpreed at reed.com (David P. Reed) Date: Fri Nov 26 09:31:56 2004 Subject: [e2e] Satellite Date Rates In-Reply-To: <3582.195.92.67.78.1101461274.squirrel@195.92.67.78> References: <200411252000.iAPK04t07955@boreas.isi.edu> <32870.137.73.8.107.1101416020.squirrel@137.73.8.107> <3582.195.92.67.78.1101461274.squirrel@195.92.67.78> Message-ID: <41A767CC.4050209@reed.com> This just triggered a thought on my part that might be worth following up. Why not use erasure-coding (tornado code or digital fountain) as the basis of recovery for lost packets on such long-delay links? This wouldn't reduce the latency for any individual lost packet, of course, but would allow "optimistic retransmission" (i.e. graceful blending with an FEC strategy, if the "retransmission" is done before the packet loss is known). If no one has invented this yet, please note that this email is prior art, and blocks any attempt to patent the idea. Arjuna Sathiaseelan wrote: >Dear Lloyd, > Thanks for your explainations. I am writing down the details provided by >Sally Floyd's RR-TCP:Reordering Robust TCP paper: > >Satellite links have very long RTTs, typically on the order of several >hundred milliseconds. To keep the pipe full,link-layer retransmission >protocols for such links must continue sending subsequent packets while >awaiting for an ACK or NAK for a previously sent packet. Here, a >link-layer retransmission is reordered by however many packets were sent >between the original transmission of that packet and the return of the ACK >or NAK. >[C.Ward, H.Choi and T.Hain. A datalink control protocol for LEO satellite >networks providing a reliable datagram service. IEEE/ACM Transactions on >Networking, 3(1):91-103,Feb 1995.] > >I was wondering whether this causes any reordering in GEO satellites? > >Regards, >Arjuna > > > > > >>>Reordering in satellites occurs mainly due to link level retransmissions >>> >>> >>It does? Can you give us evidence supporting that claim? >> >>(People tend to presume a satellite channel is more errored than it >>is. You need a BER better than 10e-5 to carry IP traffic well, so you >>dimension coding for the channel appropriately. A 45MHz transponder >>with an HDLC serial stream going through it may have no link layer to >>speak of.) >> >>If the link layer is causing massive reordering, it may not be >>designed well for IP traffic - see RFC3366 section 3.1. >> >> > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dpreed.vcf Type: text/x-vcard Size: 113 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041126/3c40d67e/dpreed.vcf From dpreed at reed.com Fri Nov 26 13:01:13 2004 From: dpreed at reed.com (David P. Reed) Date: Fri Nov 26 13:03:57 2004 Subject: [e2e] Satellite Date Rates In-Reply-To: References: <200411252000.iAPK04t07955@boreas.isi.edu> <32870.137.73.8.107.1101416020.squirrel@137.73.8.107> <3582.195.92.67.78.1101461274.squirrel@195.92.67.78> <41A767CC.4050209@reed.com> Message-ID: <41A79999.1010201@reed.com> Lloyd Wood wrote: >On Fri, 26 Nov 2004, David P. Reed wrote: > > > >>This just triggered a thought on my part that might be worth following >>up. Why not use erasure-coding (tornado code or digital fountain) as >>the basis of recovery for lost packets on such long-delay links? >> >> > >because, when you have a backchannel for some form of ARQ strategy, >the loss of link capacity simply isn't worth it, and simple FEC gives >better link utilisation without adversely affecting path utilisation. >Erasure codes are a massive performance hit, and lack the tuning to >channel conditions of FEC. > > "simply isn't worth it" is an attempt to "put down" my idea without one instant of thinking. Do you have a hair up your ***? Do suggestions from others challenge your manhood? Ignoring your utterly foul attitude for the moment, erasure codes are not a massive performance hit on the wire, since they use zero extraneous bits, and for that matter are not terribly expensive to compute, compared, say, to the cost of the system that tracks and manages the satellite. >I see that XM satellite radio licensed erasure codes from Digital >Fountain for satellite broadcast in November 2003. >http://www.digitalfountain.com/company/pressReleaseItem.cfm?uid=45 > >No backchannel there -- and that predates your specious claim below. > > My claim, if you read it carefully, was for the use of erasure codes in a novel hybrid ARQ scheme, not as a pure FEC scheme, and would be distinct from the use licensed. I am fully aware that Digital Fountain is a patent factory, just like Qualcomm. I don't begrudge them that, but am very careful to establish dates on any possible novel ideas that get close to their grabby little hands. If I happen to invent something, I don't want someone else claiming it. And in my case, that has happened several times. The most extreme case, which is beyond dispute, is a patent filed by Data General that consists entirely of paragraph-for-paragraph transcriptions of my S.M. thesis, which was in the public domain. Unfortunately, the patent expired shortly after they attempted to use it to extort money out of IBM and others, which is what brought it to my attention, or I'd probably be a rich man. Regarding your use of the word "specious", it may be that you were trying to be nasty, but I'll presume the primary definition instead, below, and thank you for the flattery. From Webster's Revised Unabridged Dictionary: *specious* \Spe"cious\, a. [L. speciosusgood-looking, beautiful, specious, fr. species look, show, appearance; cf. F. sp['e]coeux. See Species .] 1. Presenting a pleasing appearance; pleasing in form or look; showy. Some [serpents] specious and beautiful to the eye. --Bp. Richardson. The rest, far greater part, Will deem in outward rites and specious forms Religion satisfied. --Milton. 2. Apparently right; superficially fair, just, or correct, but not so in reality; appearing well at first view; plausible; as, specious reasoning; a specious argument. Misled for a moment by the specious names of religion, liberty, and property. --Macaulay. In consequence of their greater command of specious expression. --J. Morley. Syn: Plausible; showy; ostensible; colorable; feasible. See Plausible . -- Spe\"xious*ly , adv. -- Spe\"cious*ness , n. -------------- next part -------------- A non-text attachment was scrubbed... Name: dpreed.vcf Type: text/x-vcard Size: 113 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041126/21c6cfca/dpreed.vcf From dpreed at reed.com Mon Nov 29 20:02:26 2004 From: dpreed at reed.com (David P. Reed) Date: Mon Nov 29 20:05:52 2004 Subject: [e2e] Satellite Date Rates In-Reply-To: References: <200411252000.iAPK04t07955@boreas.isi.edu> <32870.137.73.8.107.1101416020.squirrel@137.73.8.107> <3582.195.92.67.78.1101461274.squirrel@195.92.67.78> <41A767CC.4050209@reed.com> <41A79999.1010201@reed.com> Message-ID: <41ABF0D2.60907@reed.com> Actually, Lloyd, I was proposing something based on the simplest, most basic digital fountain idea. If you remember Luby's original papers, the basic idea is that the digital fountain stream is an infinite sequence of packets that encodes a source file that is N packets long, such that if you receive ANY subset of N packets correctly, you can reconstruct the original file. I.e., it's pretty close to the information theoretic efficiency of the packet-at-a-time channel. You may also remember that the first N packets of the fountain are just those of the source file, while subsequent packets are combinations of the preceding frames. Also, I was not proposing an idea to optimize the *utilization* of the satellite link, but to avoid such links' high variance in latency. when packets are dropped by processes that may be far from poisson or other simple distributions that can be handled by short-span FECs. The problem with ARQ on geosync satellite links is that anticipating which packet you need to retransmit is not useful, so the recipient must buffer at least a full round-trip's worth of data in a jitter buffer if he wants reliable isochronous transmission at minimal latency. If instead the sender encodes each half-round-trip of data as a digital fountain, and dribbles the tail into the succeeding epochs to anticipate lost packets, you have a scheme that might help reduce the jitter buffer, and reduces the worst-case latency. The protocol would use the reverse channel to adjust the rate of dribbles and stop the dribble of each successively received fountain. This is analogous to an adaptive FEC, and becomes one, but based on a somewhat different theory and loss model, and with a quite different optimization goal - to wit, minimizing end-to-end latency and jitter given a requirement of reliable, sequenced packet delivery within a flow, not maximizing utilization. Anyway, I was making no particular claims that this was the "best" way to do anything. It was merely a suggestion of an interesting approach, at least one that was interesting to me, and possibly of interest to others. Maybe it doesn't even work very well. I wasn't intending it as equivalent to a published paper, just musing. Perhaps the above paragraphs explain more why I think it was interesting, perhaps not. You are always free to ignore random ideas put forth by others. PS: you persist in using disparaging words like "disingenuous" in this latest posting (like your use of "specious claim" in the prior email). "Disingenuous" is usually used to characterize a person as an intentional liar. Come on, man. I may or may not say stupid things. I may have dumb ideas. I characterized my original suggestion as an interesting thought. But what on earth makes you persist in derogatory accusations about my motives and morals? -------------- next part -------------- A non-text attachment was scrubbed... Name: dpreed.vcf Type: text/x-vcard Size: 113 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041129/ecdaf7cc/dpreed.vcf From huitema at windows.microsoft.com Mon Nov 29 20:38:23 2004 From: huitema at windows.microsoft.com (Christian Huitema) Date: Mon Nov 29 20:39:50 2004 Subject: [e2e] Satellite Date Rates Message-ID: > Normally you'd tailor your FEC for the usual channel conditions for > original transmissions, and fall back to ARQ for unusual. Explicit > ARQ, buffering at only one end, does have some advantages. It also has some drawbacks. You can only do with "buffering at one end" if you don't care about out of order delivery, or if you are content with a simple Go-Back-N scheme. Go-Back-N schemes are very sensitive to the combination of error rates with high bandwidth and long delays, and are thus not a very good choice on satellite links. You want to apply a selective ACK, which is very efficient but requires buffering twice the bandwidth delay product at the sender and once more at the receiver, for re-sequencing. In short, there is no free lunch there either -- you trade better efficiency for large buffer and longer delays, i.e. an average sojourn of an additional RTT in the re-sequencing buffer if errors are frequent enough. -- Christian Huitema From matta at cs.bu.edu Tue Nov 30 07:03:36 2004 From: matta at cs.bu.edu (Ibrahim Matta) Date: Tue Nov 30 07:02:18 2004 Subject: [e2e] Satellite Date Rates Message-ID: <0511C607B17F804EBE96FFECD1FD98591E7849@cs-exs2.cs-nt.bu.edu> > This is analogous to an adaptive FEC, and becomes one, but based on a > somewhat different theory and loss model, and with a quite different > optimization goal - to wit, minimizing end-to-end latency and jitter > given a requirement of reliable, sequenced packet delivery within a > flow, not maximizing utilization. FYI, we have looked at adaptive FEC for reliable transfer subject to delay deadlines (in a different context) at: Jaehee Yoon, Azer Bestavros, and Ibrahim Matta. SomeCast: A Paradigm for Real-Time Adaptive Reliable Multicast. In Proceedings of RTAS'2000: The IEEE Real-Time Technology and Applications Symposium, Washington, DC, May 2000. http://www.cs.bu.edu/fac/matta/Papers/rtas00.pdf ibrahim === Ibrahim Matta, Associate Professor Computer Science Department Boston University, Boston, MA 02215, USA Tel: (617) 358-1062, Fax: (617) 353-6457 matta@cs.bu.edu http://www.cs.bu.edu/~matta