Call for participation: Transport Services
Dear all, Sorry if you receive multiple copies of this! I sent it to all the lists with potentially interested folks... (this should be okay to do according to RFC5434, which says various mailing lists). A community of interest is being formed to gauge whether there is sufficient interest to host a BOF at the London IETF, on the topic of Transport Services. The intention is to create a WG that would define the set of services that transport protocols offer to applications, such that applications could at some point in the future request a service, not a protocol. This could foster innovation (protocols could be tried out, with a fall-back, without requiring the application programmer to include such functionality); it could also give more freedom to whatever resides below the API to automatically make the best out of what it currently has available. If you're interested in this problem space, please visit the related webpage that I have set up: https://sites.google.com/site/transportprotocolservices/ There you'll find an initial stab at a charter and all information about the mailing list - please join us and participate in discussions! Thanks! Cheers, Michael
Re: hop-by-hop and router alert options
Hi folks, I would just like to add that our studies are ongoing, and this: variety of Internet paths. It observes that on average, IP options introduce between 7% and 26% (for different sets of paths at different times) of additional delay. The article says that In any case, the additional delay is clearly an order of magnitude smaller than the RTT. is only a part of our findings, which are only a part of all the things that *should* be looked at. As Simon suggests, processing overhead in routers may be an issue if they are flooded with packets carrying options. Moreover, we also saw that this: 3.) Operators configure their routers to ignore IP Options. and this 4.) Operators configure their routers to drop packets with IP Options. is already happening quite a bit nowadays. Our findings are also limited to NOP options vs. no option at all, and ICMP packets, not TCP. For different (even more disappointing) findings with TCP and a new option number, see pages 9/10 of: http://www.icir.org/mallman/papers/tcp-evo-submit.ps ... who knows what's happening to packets that carry RA. I believe that options are a very reasonable (and certainly the most flexible) means of communication between end systems and routers by design, and they could theoretically be used for lots of great things in the future. The point of my ongoing measurement effort is to show that they might not be absolutely useless in the current Internet, and give folks some concrete numbers - I don't believe that options are ALWAYS useless (but don't ask me for a counterexample :( ); depending on the envisioned usage scenario, the measured properties will make things look good or bad. Cheers, Michael ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: [Tsvwg] pre-BOF discussion
Hi, I did not CC the other private mail addresses ... please don't, we don't want to bother all of them with the discussion. Also, please move all related discussion to the abr-internet list: http://www.tk.uni-linz.ac.at/~michael/abr-internet/ If you MUST reach a broader audience, I figure including end2end-interest may be okay - but I would suggest that this is the last e-mail on ABR-Internet that is going to the tsvwg group and [EMAIL PROTECTED] (and siglite sure is an exception for this very mail :) ) This sounds like it could be part of the Next Steps in Signaling work, that has been proposed as a working group. I haven't heard of any progress in that area. Perhaps Allison M. is putting something together for that. Actually, that's what I thought when the siglite discussion started. I mentioned my current work on Explicit Rate signaling at the siglite list last January but the reaction was scarce. I got the feeling that what they are actually looking for is not just generic signaling but signaling for resource reservation. If I'm wrong - great! In this case, sigliters, please take a look at the above URL ;-) I'd be more than willing to join you! Cheers, Michael
pre-BOF discussion
Hello everyone, I would like to start a discussion to gauge interest in possibly having a BOF (note that nothing has been decided yet - but starting with a mailing list and a web site seems to be a good idea) at the London IETF meeting. The topic is ABR to the Internet - in fact, it's ABR Explicit Rate Feedback related mechanisms for the Internet. To quote from the web site: The goal: A generic approach to ... - identify relevant information - propose a new protocol and/or changes to existing protocols - propose ways to use specific information (endpoint behaviour) to achieve a certain QoS gain Don't think of it as strictly ABR-like (requiring per flow state). Think of it as ECN with a finer granularity. Let us see if we can find enough common ground to justify a BOF request. To join the discussion, subscribe to the mailing list at: http://www.tk.uni-linz.ac.at/~michael/abr-internet/ You will find about anything you need at this web site. Kind regards, Michael Welzl -- Dipl.-Ing. Michael Welzl Researcher Telecooperation GroupDpt. of Computer Science University of Linz Altenberger Str. 69, A-4040 Linz, Austria Phone: +43/732/2468-9264 Fax: +43/732/2468-9829 ICQ # 38201212 http://www.tk.uni-linz.ac.at/~michael/
CFP: Special session ABR to the Internet, SCI 2001, ext. abstracts due 31.12.00
Our apologies if you receive this message more than once. Please distribute this call to any of your colleagues who might be interested. C A L L F O R P A P E R S Special Session: ABR to the Internet THE 5TH WORLD MULTICONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS SCI'2001 July, 22-25, 2001 Orlando, Florida(USA) Sheraton World http://www.iiis.org/sci/ THE "ABR TO THE INTERNET" SESSION: ATM's "Available Bit Rate" (ABR) service provides a dramatically reduced cell loss ratio by means of a signaling mechanism called "Explicit Rate Feedback"; information from the network is provided to end nodes in order to facilitate adaptation. On the contrary, adaptive Internet applications rely on mechanisms that probe the network in order to avoid congestions; packet loss must be experienced before it can be avoided on a long term basis. Developers of commercial applications seem to avoid adaptation because they don't see enough QoS benefit. SCOPE: As a first step, we have seen ECN enhance adaptation on the Internet. We are looking for papers that represent the next step. Topics of interest include, but are not limited to, the following questions: * What data should be provided to end nodes? * Which QoS could be achieved? * Where should the signaling take place? (end2end, edge2edge, core, ...) * How do we deal with path changes? * Can the signaling be incorporated with DiffServ, MPLS, ...? * What about fairness issues and TCP-friendliness? SUBMISSION OF PAPERS: Prospective authors are invited to submit an extended abstract (about 1.5 to 2 pages) to Michael Welzl ([EMAIL PROTECTED]) in postscript, PDF or Word 97 format. English is the official language of SCI 2001, thus all papers must be submitted and presented in English. EVALUATION PROCESS: Papers will be evaluated for originality, significance, clarity, and soundness. Each paper will be refereed by several researchers in the topical area. THE CONFERENCE: SCI 2001 is an international forum for scientists and engineers, researchers and consultants, theoreticians and practitioners in the fields of Systemics, Cybernetics and Informatics. It is a forum for focused disciplinary research, as well as for multi, inter and transdiciplinary studies and projects. One of its aims is to relate disciplines fostering analogical thinking and, hence, producing input to the logical thinking. Invited Sessions with high quality papers might be selected for multiple author book publications. Two books are being published now as result of good invited sessions. IMPORTANT DATES: 31. 12. Submission of extended abstracts (1.5 - 2 pages) 16. 02. Notification of acceptance 13. 04. full papers due All accepted papers are expected to be presented at the conference. OTHER INFORMATION: It is planned to hold a BOF session on "ABR to the Internet" at a future IETF meeting; authors are invited to join this collaborative effort which may eventually be a realization of this session's topic. Further information on the BOF can be found at http://www.tk.uni-linz.ac.at/~michael/ptp SESSION CHAIR / CONTACT: Michael Welzl Telecooperation Group Dpt. of Computer Science Johannes Kepler University of Linz Altenberger Str. 69 A-4040 Linz, Austria Phone: +43 (732) 2468 - 9264 Fax: +43 (732) 2468 - 9829 E-mail: [EMAIL PROTECTED] SESSION CO-CHAIR: Prof. Dr. Max Mühlhäuser TU Darmstadt - FB 20 FG Telekooperation Alexanderstrasse 6, D-64283 Darmstadt / Germany Phone: +49 (6151) 16 - 3709 Fax: +49 (6151) 16 - 3052 Refer to http://www.tk.uni-linz.ac.at/~michael/abr2internet for up-to-date information.
ABR to the Internet pre-BOF collaboration / discussion
I am a Ph.D. student whose work is basically about bringing an ABR-like mechanism to the Internet. I identified some data to be transmitted to end nodes and designed a protocol to carry them (draft-welzl-ptp-03.txt). Please take a look at http://www.tk.uni-linz.ac.at/~michael/ptp/ to see the current state of my work; the specification encompasses the definition of Content Types (the type of data to be transmitted). However, I am convinced that a more generic approach (like IntServ / RSVP) would be better: - Various Content Types could be used, showing different properties - like "does the calculation infer per-flow state in routers?". This is not necessarily restricted to bandwidth calculations; for instance, a link's MTU could also be transmitted to provide more efficient Path MTU Discovery. Once Content Types are identified, it is necessary to discuss what should be simulated and/or tested. - Partly depending on the data to be transmitted, it would make sense not only to define a new protocol but also to define extensions to other protocols such as RSVP and RTCP. Actually, the name "ABR to the Internet" is not quite precise; in fact, it's more like "ABR Explicit Rate Feedback related mechanisms for the Internet". In any case, it all needs IETF standardization because it will never really work without router support. Therefore, I believe parties working in related areas should request permission to hold a BOF session. I would personally do so, but I might not be able to attend the next two IETF meetings due to our departments current financial situation. I could do it at the London meeting next summer, though. That also gives us some time to refine the concept. Be it for a BOF or not, I would really like to get some cooperation and discussion going. I set up the page at http://www.tk.uni-linz.ac.at/~michael/ptp/ in support of this mail. If you want to participate, please join the list (details at the site). Kind regards, Michael Welzl PS: Feel free to forward this to anybody you think might be interested. Also, if you know the e-mail address of Tim Mangan ( http://www.frforum.com/3000/tim.html ), please forward this to him; [EMAIL PROTECTED] doesn't seem to work - he originally had the idea of forming a Working Group. David Lapsley should also be interested, but [EMAIL PROTECTED] doesn't work either.
Warriors of the net
Hi all, I just saw this today ... for those of you who don't know it yet, it truly is a must-see. Note that this is NOT spam! It's something funny - and so cool that you IETF people just need to see it. I just watched it three times in a row :) Besides being funny, it's a great way to teach your kids how the 'net works, too. http://www.warriorsofthe.net/ Also note that I'm by now means involved with this project (wish I was :) ), I'm just impressed by it. Cheers, Michael Welzl
RE: Email messages: How large is too large?
o Internet driving licences may seem a bit naff, but there is value in requiring people to migrate to a power-user status by at least trying to teach them that there are consequences to using tools in distributed communications Just to point out that there appears to be something called the European Computer Driving License (see URL:http://www.wlv.ac.uk/pers/csdpages/ ecdl.htm for instance). I've no idea what sort of Internet training this provides to end users but I would guess its more the "which button to press in IE 5" type of training course. I'll find out early next year as my girlfriend who is a public librarian is going to have to go on the course. User education is a tricky subject. One of my collegues in the Networks Team is currently on the phone explaining to an end user that sending an email with a large Word attachment to all 15000 users on campus isn't a good idea as our mail servers will melt. Despite our email training courses telling people this, its a regular request, especially from non-academic departments who are used to doing paper based mass mailings Having done the "which button to press in IE5" as well as "how to send an email" type of training courses for over a year, I came up with a little routine when it came to attachments: I explained the consequences of big attachments and told them if they don't want the receiver to get angry at them, they should ask before sending a big attachment. As a definition of "big", I said "1 MB and more". To me, this makes sense; I believe we can avoid some of those problems through user education. Regards, Michael Welzl
