Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
John, You'd like to make the meeting shorter. Obviously, other things being equal, it'd be great -- it'd be easier not to miss sessions, and it'd be fewer days of travel. I don't have a plan of what 30 track-hours (~20 WG sessions) to slash or how to expand hotels to have higher concurrency. Realistically, I don't expect that the Friday creep can be reversed, but it'd be great. Meeting duration is not what I am proposing to change one way or the other. Personally, I'm OK with it ending either day, as long as everyone knows what day it is. Currently we have a fuzzy end and bad WG slots during it. We can fix this by moving the technical plenary to the end of the IETF meeting, where it was before. My guess is it's easiest to make the end at about the same time as now. If it can be Thursday night, fantastic, but the problem I would like to see addressed is not duration, but the damaged goods at the end of the schedule. And, unlike the duration, which is a complicated balancing act, making the end sharp is straightforward. If we have WG meetings on Friday, technical plenary should be Friday afternoon. If Friday is not good enough for technical plenary, it's not good enough for WGs. [If you're right about the duration being unbearable, one outcome might be low attendance of the technical plenary. That would cost us one poorly attended technical plenary and would put to rest the idea that Friday is a normal day. A poorly attended technical plenary would cost us roughly triple the damage we get from poorly attended WGs on Friday and would thus be recouped within a year.] -- Stas -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com On Nov 11, 2009, at 2:43 AM, John C Klensin wrote: --On Tuesday, 10 November, 2009 17:05 +0900 Stanislav Shalunov shalu...@bittorrent.com wrote: ... Here are some immediate, but invalid, objections that this proposal is prone to elicit: But nobody will come to the technical plenary Friday afternoon! -- 1. We did come to the technical plenary when it was the last thing on Thursday, and it was in the evening. But, depending on location, attendance at the Thursday Plenary was often lower than that at the Wednesday one as people try to leave town. Also note that, for people trying to get home to families before the weekend (see below for more on that subject), there is a huge difference between leaving Thursday night or Friday morning (or for some location pairs, Friday afternoon) and trying to make people travel Saturday, especially after we have wiped out the prior weekend with Sunday meetings of various sorts, a Sunday evening reception, and sessions first thing Monday. For some participants, travel Saturday just isn't going to happen if they see any alternative, no matter what scheduling tricks we perform to provide incentives. 2. If people won't come to the technical plenary, they won't come to WG meetings. If it's an unsuitable meeting time, we should not put WGs there. But, if people are trying to lose as little as the weekend as possible, there are large differences as one goes down the curve from leave Thursday night after the plenary to leave early Friday to leave early Friday afternoon to leave Friday night to leave Saturday. Can't we just make sure it's not the same groups that get put on Friday? -- Zero-sum redistribution of pain pitting WGs against one another does not reduce total pain. We can fix the bug instead of making everyone suffer equally. You can't fix the bug except by doing away with Friday sessions except for special meetings and groups that want them. We need to keep in mind that the IETF can't fire someone for not attending that that, in many countries, companies are prohibited by law from firing someone who refuses to work on weekends. The only thing that surprises me about the Friday situation is that more people haven't voted with their feet. ... We shouldn't suffer from the Friday bug and repeat normal day mantra. We should fix the bug that detached the technical plenary from the end of the IETF meeting by moving it to the end again. Also keep in mind that, as the IETF becomes more international, Friday is part of the (religious as well as secular) weekend for some cultures and that the religious weekend starts late Friday afternoon for others. I think there are reasonable odds that the problems with Friday meetings --especially those that run into the afternoon -- are going to get worse over time, no matter what the IETF does. Disclosure: I don't buy the theory that we solve the demand for more slots by making the meetings longer. I think it ultimately would take us to two weeks off meetings or demand for late-afternoon Friday meeting slots at least. I've proposed in the past that areas be limited in the number of WGs that they are permitted to have by the number they can manage effectively. The latter should include
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
This would recognize that Friday is not a normal day and so would be an improvement. First, I appreciate you stepping forward. This would redistribute ~5% of the existing Friday pain to RRG. Regardless of other outcomes of this discussion, RRG should always from now on be scheduled on Friday as long as we have a Friday. Second, do we have ~19 more WGs that would trade off having the Friday pain for having a consistent meeting day on Friday? -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com On Nov 11, 2009, at 4:04 AM, Marshall Eubanks wrote: Dear Stanislav; RRG always had good attendance on Friday. It was, I think, viewed by the people interested as a session to schedule for. So, one possible solution would be to see if there were WG or RG that wanted permanent Friday status. That way, people who wanted to attend these sessions would know that they had to be there on Friday. This implies that there would be people that would only come for that day, or for the end of the week, but we have some of that already. Marshall On Nov 10, 2009, at 3:05 AM, Stanislav Shalunov wrote: [I hope to raise this issue during the administrative plenary. Because I obviously won't have time at the microphone to present the full argument and because I might not get the chance at all, I'm writing something down and sending it out now.] When you participated in a WG on any Friday during the past meetings, you probably noticed impaired attendance. This becomes particularly visible for WG chairs, few of whom are thrilled to get a slot on Friday. Friday is declared to be a real day, but the declaration is disregarded (rationally, as I'll explain) by a fraction of participants. This makes Friday a defective day, making it rational for more people not to attend, creating a positive feedback loop making it more defective. The fuzzy end bug wasn't always there. When the IETF didn't have sessions on Friday, the technical plenary was the last thing that happened during each meeting for normal participants [1]. The plenaries have the largest attendance, so it put a very sharp stop to the IETF meeting. When Friday sessions were added, there were few to begin with, so the end got fuzzy and the attendance problems began. For some participants, it is rational to skip Friday in its present form. Checking this meeting's agenda, Monday currently has 124 track-hours [2] worth of sessions. (Tuesday-Thursday are similar full-day affairs for most people, even if differently structured because of the social and the plenaries.) Friday currently has 29.5 track-hours worth of sessions, ~4.2 times less. For a person who is only interested in a few sessions, there's a good chance that none of them will fall on Friday. If the person judges that the relatively small probability of missing an interesting session (or, more precisely, the relatively small expected number of interesting sessions) that fall(s) on Friday, multiplied by the cost of missing a session, is smaller than the cost of an extra day of travel, it is rational for them not to attend Friday. Repeating that Friday is a normal day is not going to change the calculation if Friday continues to be ~4.2 less valuable. Once these participants choose to go home on Friday, the value of Friday is further depleted. Not only there are fewer sessions on Friday, but they are not as well attended, creating a multiplier through a positive feedback loop. The bug is easy to fix: we should restore the technical plenary to where it was before -- namely, to the very end of the IETF meeting for normal participants. Put the technical plenary on Friday afternoon. This will make it natural to increase the number of track-sessions on Friday. This will restore a sharp end to the IETF, fixing the Friday bug. A side effect of the fix is that it would increase the total number of available track-hours by about 15%, making scheduling easier for the next few meetings after implementation. Here are some immediate, but invalid, objections that this proposal is prone to elicit: But nobody will come to the technical plenary Friday afternoon! -- 1. We did come to the technical plenary when it was the last thing on Thursday, and it was in the evening. 2. If people won't come to the technical plenary, they won't come to WG meetings. If it's an unsuitable meeting time, we should not put WGs there. +1 Marshall Can't we just make sure it's not the same groups that get put on Friday? -- Zero-sum redistribution of pain pitting WGs against one another does not reduce total pain. We can fix the bug instead of making everyone suffer equally. Can't we only put unimportant sessions, like second sessions and maybe these two session I personally don't like, on Friday? -- No. Friday started out with only non-technical sessions
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
If it's not good enough for the technical plenary, if that's what you're saying, let's not put WGs there. -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com On Nov 11, 2009, at 12:31 PM, Fred Baker wrote: On Nov 10, 2009, at 5:05 PM, Stanislav Shalunov wrote: The fuzzy end bug wasn't always there. When the IETF didn't have sessions on Friday, the technical plenary was the last thing that happened during each meeting for normal participants [1]. well, yes, and many people left on Thursday evening or afternoon after their last session instead of waiting for the plenary. Not sure your proposed solution fixes the problem that people would rather spend their weekends at home. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technicalplenary the last IETF session, like it was before
On Nov 11, 2009, at 12:14 PM, John C Klensin wrote: My much greater concern, as I tried to make clear, is where we draw the line about expanding meetings. Maybe the right answer is that we stop after the Thursday evening plenary. Maybe before noon on Friday. Maybe the end of the day Friday. Maybe we should be expanding into the following week. Maybe the ITU is right and SG meetings lasting two or three weeks are reasonable. But, sooner or later, we need to stop and start prioritizing. This is totally reasonable, desirable, and, while not orthogonal, independent of making the meeting stop sharp for normal attendees and punctuating the stop with the technical plenary. The technical plenary should be the last thing you need to attend if you come for the IETF meeting. Like it was. The problem that putting the technical plenary at the end solves is not the meeting size creep, but having a declared normal day that's actually clearly not normal. -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] Call for Comments: Peer-to-peer (P2P) Architectures
Gonzalo, I now see how my initial reading of the document was informed mainly by expectations set by the title and the abstract. I suspect that I might be alone in this. If the title and the abstract were to better reflect the content and to avoid what I read as overpromise, the document would be much improved. I see you've already changed the abstract to refer to multiple taxonomies. This is helpful, thank you. I was actually initially confused by the title, Peer-to-peer (P2P) Architectures. The sort of thing that came to my mind reading that title was a discussion of several architectures that would include design philosophy considerations, main architectural ideas from the P2P world, toolbox, tradeoffs, applicability of techniques, architectural design choices made by particular P2P apps, the motivation of the choices, consequences of the choices, and such. The document does have architectural guidance on when to use P2P as opposed to a server-based arch, but the plural of architectures in the title primed me for a discussion of peer protocol choice and design, organization mechanisms to use in the system, and generally something that'd get a server-based protocol jock sufficiently informed about P2P to design working P2P systems rather than to conclude that a given application looks like a potential match for a P2P approach. If the document were to have a different title, my mindset diving in would be different. If the title more precisely reflected the content I would take the document for what it is instead of expecting something that wasn't intended to be there. How about Peer-to-peer (P2P) architecture: definition, examples, and applicability for a title? Something along those lines would definitely help me get the right idea of the document. I've taken the liberty to massage the abstract: We define P2P, explain how a P2P architecture differs from a client/ server architecture, and provide a non-exhaustive survey of P2P systems and of their taxonomies. We discuss the applicability of P2P and tradeoffs between client/server and P2P and how the best choice depends on the properties and the requirements of the application. Also, I'd consider pulling out the definition, which currently starts with We consider into a paragraph marked with something like Definition: at the beginning -- or just the first paragraph of the corresponding section. And still, I'd suggest making it more clear that, say, BitTorrent, which has trackers, or Skype, which has a website where you can manage your account, are, indeed, P2P systems, despite the fact that they have elements that only provide and don't consume a service. Let me know what you think, -- Stas -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com On Sep 11, 2009, at 3:08 AM, Gonzalo Camarillo wrote: Hi Stanislav, thanks for your comments. With respect to including more examples of P2P systems, we received similar comments in the past. Some people thought (like you) that a document having a high number of examples (maybe even an almost-exhaustive list) would be useful for the community. At that point, we decided not to include all those examples in this document and focus instead on general properties and guidelines. However, you are right that such a document could be helpful. During our past discussions, we identified the P2P RG, which was being rechartered at the time of writing the document, as a potential venue to write such a document (we were in touch with the chairs of the RG while writing this document). We realize that there are many potentially-useful documents that can be written in the area of P2P systems and that this document only covers a tiny part of the area. Regarding a correct definition of a P2P system, one of the points the document stresses is the fact that there are multiple definitions in the literature. The document discusses them and describes what they have in common in order to find a common denominator. We believe this approach is more useful than providing our own definition without referencing existing ones. With respect to the taxonomy, you are right that the document provides several taxonomies and not a single one. Section 4 states that but both the Abstract and the title of Section 4 talk about a taxonomy in singular. We will clarify this point so that it does not confuse readers. With those explanations for why the document is the way it is, and with the commitment to clean up the single vs multiple taxonomy, would you like to suggest any specific textual edits to this document with these goals? If so, we would happily consider them to the document's next revision. Thanks, Gonzalo Stanislav Shalunov wrote: I fail to understand the purpose of this document or of publishing it. The abstract promises three things: * a survey
Re: Call for Comments: Peer-to-peer (P2P) Architectures
of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural tradeoffs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application. Please provide your feedback before August 15, 2009. For the IAB, --Olaf Kolkman IAB Chair ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Stanislav Shalunov BitTorrent Inc shalu...@bittorrent.com personal: http://shlang.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
On Oct 13, 2008, at 5:23 AM, Pekka Savola wrote: I believe this work could be useful and would provide an improvement over existing p2p usage and traffic management. I also believe that an ALTO WG should be formed and would like to contribute to a solutions draft. The current requirements and problem statement are scoped rather narrowly around a solution in mind. This is recognized by the BoF chairs and the authors, and I would be interested in contributing to these documents so that they more generally applicable. A solutions draft should be a start to help think about the solutions space. The starting point for the solutions idea is described at http://www.ietf.org/mail-archive/web/p2pi/current/msg00508.html This is intended to answer Lisa's call for example candidate solutions to better understand the space. The solution will emphasize simplicity, privacy, and, correspondingly, clear understanding of what information is given to whom. The question at hand is not consensus on the requirements or even problem statement, but just the charter. I believe the charter has by now been crafted with the intention of covering the known cases. One small concern that I didn't previously raise because I just noticed it is that the charter still says A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses. This starts to specify an architecture. While the known candidate solutions seem to fit, I would prefer clarifying that it's not request/ response protocol or data format that's the point, but the information. One way of doing so would to to rephrase as follows: A complete mechanisms that enables clients to learn from the ALTO service information useful for peer selection. Again, this should go forward. Thanks, -- Stas -- Stanislav Shalunov ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Summer of Code: Event notification service for the IETF
The IETF Tools team is looking for student applicants to work on a Summer of Code project in which an event notification service for the IETF would be created. The likely mentor for the project is Henrik Levkowetz. The project will be done with Internet2 as the mentoring organization. If you know of students who might be interested in participating, please pass this along to them. If you are a student with some coding experience and interest in open-source development, please consider applying. Assuming the project is successful, Google will pay the student doing it $4500. The deadline for applications is May 8, 2006. The project description follows (from http://transport.internet2.edu/soc2006/ideas.html). Summary: Put together an event notification service for the IETF where people can subscribe through a web interface for personalized notifications, and provide notifications through any of the following mechanisms: RSS, Atom, Mail, and Web-pages (individually customized). This work will be done in collaboration with the IETF Tools team. Background: Work in the IETF is carried out in more than 100 different working groups, with around 2000 active document at any given time. For any single participant, only a small subset of this work is of immediate interest, but when anything happens that is of interest, he would like to know as early and clearly as possible. The subset of interest to any one participant is also generally different from that of all other participants, so individually customized notifications would be optimal. A browsable view of the process is available through document overview pages for individual working groups, but this needs to be complemented with a notification service for events such as draft updates, new drafts, last call announcements, published RFCs, new working groups, etc. Some constraints: Individual events will be provided in a single format, to be agreed on. The notification service should store events by time and classification, and offer a web interface by which individual subscription to a subset of events is possible. The interface should dynamically build the offered selection criteria based on the field types already seen in incoming events. Events should be transformed from the canonical format to RSS, Atom, Mail, and HTML format. There is a strong preference for the system to be coded in Python. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at an angle of 45 degrees. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
indication of internet-draft status
Context: The IETF Tools team works on requirements for various automated tools for the IETF. Many of the tools have to deal with internet-drafts; in these cases, the information whether an internet-draft is a working group draft or a personal draft is important. The mechanism by which such information is kept thus needs to be known to the tools and, correspondingly, reflected in the requirements. There appear to be at least three conceivable ways of keeping the information about internet-draft status: 1. Internet-draft name: working group internet-drafts are always named draft-ietf-*, while personal drafts do not match this pattern. For a working group internet-draft, the third component of the file name is the working group abbreviation. When a personal internet-draft becomes a working group item, or when a working group item is no longer one, or when an internet-draft changes the working group, the internet-draft gets republished under a new name, without exception. (This could be automated in a way that would ensure that name history is consistently and reliably captured.) 2. Metadata kept separately: the file name has nothing to do with the status, which is kept separately. The file name is stable and never changes (other than the version number). The working group status is prominently indicated by all tools (in announcement subject lines, etc.). 3. Current situation: technically, (2) (however, name stability isn't enforced or actively encouraged). Informally, (1) for most working groups. Many (most?) participants infer (1). Tools penalize non-draft-ietf-* working group internet-drafts by making their working group status less prominent. For the purposes of specifying the requirements for tool development, it is necessary to know which way to keep the information. It is rather obvious that (1) and (2) are both vastly preferable to (3). The choice between (1) and (2) is less clear. Advantages of (1): * simpler; * matches existing expectations of most participants; * makes working group status automatically prominent. Advantages of (2): * cleaner; * allows tracking of document history better and easier. It appears that the Tools team has a slight preference of (1) in favor of (2) because of the existing convention (but (2) is perfectly workable; it would simply require a bit of an education effort). However, (3) appears so much inferior to either (1) or (2) that proponents of (1) and (2) would both be reasonably expected to be willing to compromise so that (3) is avoided. With this in mind, we would like to raise the question: Which way of keeping the status should the Tools team use in the requirements for the tools it is specifying? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed with 0.06479891g of NaCl. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard
Jeffrey Hutzelman [EMAIL PROTECTED] writes: ISO/IEC 9899:1990 section 6.1.3.4 has this to say: This differs from my account in not requiring the first octal digit after backslash to be zero. Thank you for correcting that; \61, indeed, works as 1 in C. (Thus, there are enough digits to represent any value of an octet.) In any case, my original point was not to get into a discussion of the finer details of character escapes in particular programming languages, nor to suggest that every escape permitted by C or Perl be used in this context. Rather, it was to point out that the existing, commonly-used convention for character escapes of this form uses octal digits, not decimal, and that differing in this particular way would be likely to lead to confusion. Agreed. [...] it is likely to lead to significant confusion. I also agree that \027 for ESC is unnecessarily confusing. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed in boustrophedon. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
email document delivery service
Internet-draft announcements, as they are currently generated, include a MIME-based mechanism to request internet-drafts via email. Do you use this feature? If you do, could you please let me know? Background: the IETF Tools team is working on a draft, draft-ietf-tools-notification-03.txt, that specifies the requirements for a document notification service. We'd like to better understand how email document delivery is actually used. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at room temperature. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard
Jeffrey Hutzelman [EMAIL PROTECTED] writes: [..T]he _common_ convention is to use a backslash followed by the value of the octet as an unsigned integer represented by exactly three _octal_ digits. This is the syntax used by programming languages like C and perl. For example, ASCII ESC (0x1b) is represented as \033, not \027. Actually, the convention used in C and Perl is to use \0, followed by zero, one, or two octal digits (leaving some values of octets without representation). I personally think it's a poor convention as it uses varying number of digits, so it becomes difficult to represent, say, the NUL character followed by the digit 1. (I still use the convention in cases when it is familiar to most from documentation, e.g., \015\012 in Perl.) A reasonable convention is hexadecimal: backslash, followed by the letter x, followed by exactly two hexadecimal digits; e.g., \x1b for ESC. This notation, while looking familiar, has differences from both Perl and C hex notations: in Perl, you can have just a single hex digit following ``backslash x'', while in C you can have arbitrarily many. With the common conventions so unnecessarily complex and difficult to use, it doesn't surprise me that the document authors chose to use a nonstandard one. I'd have chosen a different one (hex with exactly two digits, which won't deceive C and Perl programmers in the same way \027 meant for ESC would), but that's just a minor typographic convention. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed with 0.06479891g of NaCl. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] List of Old Standards to be retired
William Allen Simpson [EMAIL PROTECTED] writes: RFC1598 PPP in X.25 RFC1618 PPP over ISDN At one time, these were incredibly important in the 3rd world, and some parts of Europe and Japan. Is X.25 completely non-existant today? Heck, folks were running X.25 over ISDN D-channels, and those still exist on every PRI circuit For what it's worth, the AX.25 protocol number in IPv4 is still used by some poor souls. (Carries just about 3MB/day on the Abilene backbone and used to be several times more.) http://netflow.internet2.edu/weekly/longit/protocols93-octets.png -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed upside down. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Yahoo is not using ESMTP
Fred Baker [EMAIL PROTECTED] writes: That is the ISP's choice. As a percentage of total volume, SMTP/ESMTP is a small proportion of total traffic, or so please I can read sample measurements (like http://www.caida.org/dynamic/analysis/workload/sdnap/0_0_/ts_top_n_app_bytes.html) would lead me to believe. I can confirm this for a different network. Email (which includes [E]SMTP, POP, IMAP, versions of these over TLS, and such) comprises about 0.5% of the traffic on Abilene. For comparison, HTTP is about 15%. (The ratio is almost exactly the same as in the plot Fred cites.) Even during weeks when there is an unusually large amount of SMTP traffic because of email worms, we're still talking about 2% of traffic being mail. http://netflow.internet2.edu/weekly/ -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at an angle of 45 degrees. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: SMTP compressed protocol...
On Fri, Dec 05, 2003 at 02:15:43AM -0500, John C Klensin wrote: I'd also guess that, given the kind of connectivity Internet2 implies, that you see very little mail relaying in practice (beyond initial submission). The backbone in question (Abilene) would see most traffic from a US research university to a US research university (for example, this message would not traverse Abilene because the IETF mail reflector does not have Abilene connectivity). Perhaps to put the fraction of traffic that is email in a better perspective, the ratio of HTTP traffic to email traffic is more than 20. (I'm not claiming that inter-university traffic is a representative sample of anything, but this might be a useful datapoint.) But compression, properly thought out, might still be very useful at the edges of the network with lower levels of resources and bandwidth... I just don't know. SMTP-level email compression might very well be useful for some edges. I would think that the challenge would be to design it so that these edges could take advantage of it, while better-connected sites would not need to spend CPU cycles compressing and decompressing when exchanging email among themselves. One way to accomplish that could be to have two compression-related ESMTP options: ``support compression'' and ``prefer compression.'' Any site might support compression, while only capacity-starved edges with a large fraction of traffic that is email might prefer compression (at the site administrator's discretion). Then, message SHOULD be compressed if and only if both ESMTP peers support compression and at least one of the peers prefers compression. This way, only sites that need compression would end up using it -- for both incoming and outgoing mail. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/
Re: SMTP compressed protocol...
On Fri, Dec 05, 2003 at 03:38:20AM -0500, John C Klensin wrote: From a simple syntax standpoint, one option with an advertised prefer/ accept parameter would do the job, and would be much preferable architecturally to two options. Yes. connection-time-limited What's a connection-time-limited environment? And something batch-oriented also solves the what to do about those Received headers problem As well as the the extra round-trip times problem associated with SMTP. A disadvantage of batch-oriented approaches is that mail rejection could happen later.
Cable Co's view: NAT is bad because we want to charge per IP
NAT is an ugly hack that's impairing people's connectivity, right? For some, it might be. Others find different faults with NAT. A highly unusual for an IETFer (and very disturbing) perspective of cable companies is provided in an article in CED magazine The CAT and the NAT by Leslie Ellis, Technology Analyst: http://www.cedmagazine.com/ced/2001/1101/11d.htm (Link appeared on Slashdot.) This article proceeds to describe NATs as incarnations of everything evil. One of the reasons they are so evil, according to Leslie Ellis, is that they allow users to avoid paying for extra IP numbers: What's the value of the stolen goods? Revenues associated with additional IP addresses, for one. Let's say one in 10 of the 5 million U.S. cable modem subscribers are usurping IP addresses without paying the $4.95 per month fee that's typically charged (beyond a pre-specified limit, which varies MSO to MSO.) Right off that bat, that's just shy of $30 million lost, annually. [I replaced the Microsoft character for the apostrophe with ASCII in the paragraph above.] I can see it: So, you'd like to purchase a /48 with your eye-pee-vee-sex package? Are you saying it should be the default allocation? I don't know who told you that it should be the default, but we can do that for you. It would be for our everyday low price of $6044629098073145873530880 per month, first month prepaid. Yes, that's six septillion, forty-four sextillion, six hundred twenty-nine queen-... quintillion... Are you there? Hello? We actually do have a 15% discount package! Hello?! The article then proceeds to describe some snake oil solution (the CAT part) that would go one step further, essentially saying, `Pardon, NAT, but what's that behind you?' (Microsoft characters replaced with ASCII, again). The important thing to realize here is that there are many people who read THE PREMIER MAGAZINE OF BROADBAND TECHNOLOGY and absorb the infinite wisdom of its Techology Analysts. Boy, am I glad I don't have to deal with a cable company! Cable... Where idiotic business models and complete lack of understanding of networks are combined! P.S.: Just to be clear, the other problem that the article finds with NAT is that it enables you to share your connection with neighbors. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Nuclear war would really set back cable [television]. -- Ted Turner
non-US-ASCII characters in IETF documents
-BEGIN PGP SIGNED MESSAGE- Dave Crocker [EMAIL PROTECTED] writes: Equally, it is clear that the strongly international quality to the IETF requires permitting at least SOME encoding of non-ASCII. I would say that to the contrary, the strongly international nature of IETF (with different default character sets, different sets of fonts, various national conventions, etc.), dictates using a lowest common denominator of US-ASCII for the documents (in much the same way that diversity of computing environments encourages plain text documents). As you note, at least being able to encode a person's name properly would seem more than appropriate. The proper encoding of my name is óÔÁÎÉÓÌÁ× ûÁÌÕÎÏ× (in KOI8-R; the Russian language has at least four character sets in active use). Can you read that? I thought so. That's why I write it in US-ASCII in English-language documents (such as I-Ds). -BEGIN PGP SIGNATURE- Version: 2.6.3ia iQCVAwUBO7Ehs5RUn1EgN49xAQFbzQP7BOzifCePHptkEi85ueXuOM+BE1wMvHbY i/2EEyGG/ls/9eAAEnQ+tK4+i7/o3jeAcf2S9TCTAKImac/ifh2zHrlbsqbWXt7L O3qq6ydO88ZPpSg8iejCCr1PqgE49XiNk64fMkHWqxgf/NtzXkbmripXSxlRXrD5 Wv0Y64As9fM= =uGkA -END PGP SIGNATURE- -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Beware of Programmers who carry screwdrivers.-- Leonard Brandwein
duplicate messages on IETF mailing lists
A number of messages sent to various IETF mailing lists have arrived in multiple copies. One such message (just an example that I received five times) is [EMAIL PROTECTED]. According to Received lines, this message was received once by astro.cs.utk.edu with an internal id of NAA18284 on Wed, 25 Jul 2001 13:53:38 -0400 (EDT). It was then received by odin.ietf.org with id NAA16715 on Wed, 25 Jul 2001 13:54:01 -0400 (EDT); with id OAA18788 on Wed, 25 Jul 2001 14:14:11 -0400 (EDT); with id OAA21900 on Wed, 25 Jul 2001 14:44:11 -0400 (EDT); with id PAA25476 on Wed, 25 Jul 2001 15:14:10 -0400 (EDT); with id PAA28761 on Wed, 25 Jul 2001 15:44:13 -0400 (EDT). It appears that astro.cs.utk.edu has transmitted the message at least five times, with probably sendmail running with `-q30m' option, the message was transmitted successfully, but astro.cs.utk.edu didn't learn about the success at least the first four times. The only reasonable explanation for this behaviour would be that odin.ietf.org is in violation of RFC1047 (or that astro is broken, which is ruled out by the fact that there are numerous messages from various places sent to various ietf.org lists that arrived in duplicates and triplicates). Since odin says it runs Sendmail 8.9.1a, while in fact that's not what's listening to the incoming SMTP connections (it looks like smap or some other filter) it's hard to actually debug anything. Pure minimal SMTP listener: $ telnet odin.ietf.org 25 Trying 132.151.1.176... Connected to odin.ietf.org. Escape character is '^]'. 220 *2**200**200***0*00 * EHLO cain 500 Command unrecognized: cain HELP 500 Command unrecognized: QUIT 221 ietf.org closing connection Connection closed by foreign host. May I suggest installing Postfix or a recent version of Sendmail on odin.ietf.org? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ .signature: I/O Error
Re: duplicate messages on IETF mailing lists
Vernon Schryver [EMAIL PROTECTED] writes: Please consider the rest of RFC 1047, and note that while other messages have been duplicated, only that one was multipled a dozen times. There were other messages that were delivered multiple times, including those large virus files that mostly came two or three times. Here are just a few: 4 [EMAIL PROTECTED] 3 [EMAIL PROTECTED] 3 [EMAIL PROTECTED] 3 [EMAIL PROTECTED] 3 [EMAIL PROTECTED] 3 [EMAIL PROTECTED] Since at least about 8.11.1, sendmail has had a default hour or two timeout for the DATA command. The fact that the messages from astro.cs.utk.edu were coming more frequently than once an hour is evidence that it has shorter than default sendmail timeout, and might be related those duplicates. Timeout.datafinal is, indeed, usually 1 hour. The astro machine must be using a shorter timeout, but other machines have delivered messages multiple times, too. Incidentally, this happens to include your machine, which delivered the message [EMAIL PROTECTED] (your internal id f6JF51CK005137) to odin.ietf.org on Thu, 19 Jul 2001 11:04:07 -0400 (EDT) and then again, less than three minutes later, on Thu, 19 Jul 2001 11:06:43 -0400 (EDT) [timestamps generated by odin]. This morning (7/27) ietf.org or optimus.ietf.org claims via the HELP command to be running Sendmail 8.9.1a. There are reasons that many people consider sufficent to switch from ancient 8.9 to current 8.11.4 or even 8.12.0. Why would you look at optimus.ietf.org when ietf.org has a single MX record: odin.ietf.org? ietf.org43200 INMX 10 odin.ietf.org $ telnet odin.ietf.org 25 Trying 132.151.1.176... Connected to odin.ietf.org. Escape character is '^]'. 220 *2**2000*00 * HELP 500 Command unrecognized: QUIT 221 ietf.org closing connection This clearly is no sendmail. And whatever it is, it clearly is causing trouble with duplicates. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ According to my math: 2**32 = 4,294,967,295 [...] -- John S. Giltner, Jr. in comp.protocols.tcp-ip, 20010305
Re: filtering of mailing lists and NATs
John Stracke [EMAIL PROTECTED] writes: [Randomly selected moderators.] Then you have to educate the subscribers on how to approve messages. Include a short explanation in the message of why it is sent, and offer to follow a URL to approve the message. One of the randomly choosen subscribers presumably knows how to follow a link. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at 600 mph.
Re: Restaurant Guide: 50th IETF -- Schneier Cooper
There's a stack of these guides on a desk opposite to the registration desk. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Sex is the mathematics urge sublimated. -- M. C. Reed.
Re: An alternative to TCP (part 1)
[EMAIL PROTECTED] (Jun'an Gao) writes: There are two annoying incompetence of TCP. One is that TCP does not distinguish packet loss caused by network transmission error from that caused by network congestion. But ECN seems to address this issue, and it can work for UDP as well as TCP. This results in an unnecessary reduction in link bandwidth utilization, especially in the environment of wireless physical links. One could argue that it's a responsibility of wireless link-layer protocols to ensure that random loss is rare (say, by employing an ECC). The other is that the unit of TCP sequence number is byte (octet) while the the sequence number is only 32 bit wide. What practical implications does sequence numbers wrap-around have in foreseeable future? At 10Gbps, sequence number space will last for 3.4s, which seems to be larger than your typical round-trip time of a hundred or two milliseconds. It seems it could start to be a problem at 100Gbps speeds, but current trend seems to be to increase the number of 10Gbps lamdba channels rather than their bandwidth... -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ I never let school stand in the way of my education. -- Mark Twain
