Re: congestion control? - (was Re: Appointment of a Transport Area Director)
Roger, On 3/4/13 7:20 PM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) That basic question is a very important one to ask from time to time. Others have already answered, and I will simply add one addition: the way one implements congestion control (or not) has impact not only on the party or parties with whom your computer is speaking, but on every communication that shares the links between your computer and those parties. So: get it wrong and you can hurt others. And it's easy to get wrong. Eliot
RE: Appointment of a Transport Area Director
We had such a WG-Chairs session dedicated exactly to this topic (document shepherding) at IETF-82 - including a panel of document shepherds and ADs sharing experience and discussing ways to improve the process and make the shepherds role more efficient. Dan -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alia Atlas Sent: Tuesday, March 05, 2013 1:12 AM To: Benoit Claise Cc: John Leslie; IETF IETF Subject: Re: Appointment of a Transport Area Director Perhaps even dedicate a WG-Chairs lunch meeting to it? I think the role has grown over the years. Alia On Mon, Mar 4, 2013 at 6:05 PM, Benoit Claise bcla...@cisco.com wrote: On 4/03/2013 15:57, John Leslie wrote: Eggert, Lars l...@netapp.com wrote: On Mar 4, 2013, at 13:18, Eric Burger ebur...@standardstrack.com wrote: I will say it again - the IETF is organized by us. Therefore, this situation is created by us. We have the power to fix it. We have to want to fix it. Saying there is nothing we can do because this is the way it is is the same as saying we do not WANT to fix it. what is the fix? There is an obvious place to look for ideas: the directorates. See: http://www.ietf.org/iesg/directorate.html That would help if the AD job would not be a full time job. Sure. And I see some suggestions in this email thread to rely more on the directorates. That makes sense (but reviews vary greatly, however) One track not mentioned in this thread is the document shepherd. The document shepherd job, when done according to RFC 4858 (see specifically section 3.2 and 3.3) would save a huge amount of time to the AD. Recently, for a single draft, I spent hoouuurrr trying to track all the open issues from the directorates and the IESG, and chasing the authors. On top of taking some time, I had to be become expert for every single aspect of the specification to evaluate whether the answer was right... while the document shepherd has already the expertise. We should probably stress (again) the importance of document shepherd function... Regards, Benoit
Re: Call for Comment: RFC Format Requirements and Future Development
- Original Message - From: Andrew Sullivan a...@anvilwalrusden.com To: ietf@ietf.org Sent: Tuesday, March 05, 2013 12:30 AM Subject: Re: Call for Comment: RFC Format Requirements and Future Development On Tue, Mar 05, 2013 at 12:48:53AM +0100, Martin Rex wrote: Limiting the waste of network bandwidth seems like a desirable goal, no matter how I look at it, from the waiting for download perspective as well as the environmental impact. All that requires is the availability of a small file, not an overall limitation on the size of files. No? There is a parallel thread on the IETF list about the difficulty of staffing the IETF which has contained references to how the IETF is different, how we do not want to be like the ITU-T. What prompted my comment is a wish for the technology of the IETF to evolve, not to make a quantum leap to be like the technology of other SDOs. I assume that whatever we do with RFC, which is the subject of the Call for Comment, will inevitably cascade into all I-Ds and even to some extent into mailing lists. The IETF has been conservative in its use of technology and I think that that is part of its success. If the entry point for participating in the IETF were a 20MBit/s link to the desktop with the latest versions of MS Office, Acrobat reader, Photoshop etc then we would be an insignificant pimple on the back of other SDOs. I quoted the example of a document from another SDO which was 16 times larger than it would have been using IETF technology. I have seen individual documents that are even more expanded. Look at where the documents have been - MS Word is good at telling me that - and it is from within large organisations, to whom the latest technology is likely no barrier. The other example I have quoted before is a WG mailing list discussion where the e-mails in the thread went over one Mbyte in size each and yes, there were commenting from perspective of another SDO. Whether or not the SDO's technology was being used I cannot tell but I am sure that the e-mails reflected the common practice of that SDO. The actual text added in each successive post was a few hundred bytes, following the conventions of the IETF would have made the e-mails a few thousand bytes, but those with a background in another SDO has no concerns about turning them into a Megabyte or more. That is inconsiderate and thoughtless. That is why I believe that there must be a limit, to avoid a quantum leap in the costs that will reduce or eliminate the ready availability of the IETF to potential participants. Tom Petch A -- Andrew Sullivan a...@anvilwalrusden.com
Re: Nomcom Reports
On 5/03/2013 00:49, Spencer Dawkins wrote: On 3/4/2013 2:31 PM, Mary Barnes wrote: As far as I can tell, the last official Nomcom report was from the Nomcom I chaired (2009-2010): http://tools.ietf.org/id/draft-barnes-nomcom-report-2009-00.txt I have a general question for the community as to whether they find such reports useful and whether we should encourage future nomcom chairs to produce these? While this is not listed as a requirement in RFC 3777, I had understood as chair that this was a requirement for the job, but again, I've not seen that carried on. Personally, I don't find a few .ppt charts adequate in terms of summarizing the outcome of such an important IETF process. The Nomcom gains a unique insight into the operation of the IETF (and its leadership) that no one else gets. Mary, I found your report useful, especially when I served as the IAB liaison to the Nomcom the following year. I would like to see reports like yours in the future. +1 Regards, Benoit
Re: Appointment of a Transport Area Director
- Original Message - From: Sam Hartman hartmans-i...@mit.edu To: Mary Barnes mary.ietf.bar...@gmail.com Cc: Sam Hartman hartmans-i...@mit.edu; IETF ietf@ietf.org Sent: Monday, March 04, 2013 8:26 PM Mary == Mary Barnes mary.ietf.bar...@gmail.com writes: Mary And, I continue to support Sam's position as well. To me the Mary question at hand is whether it will do more harm to fill the Mary position with someone that doesn't have the specific expertise Mary that his being sought than to leave the position unfilled. Mary Having dealt with the exact same issue when I was Nomcom Mary chair, I thoroughly understand the issue at hand. And, Mary certainly, there was a lot of criticism of the choice of the Mary Nomcom I chaired, but we really are between a rock and a hard Mary place yet again. I think it would be really useful to get someone like Lars or the chair of the tcpm working group to comment on how much congestion control experience we're talking about as a requirement. Not much, based on my experience:-( The I-Ds I have been closely involved with have typically drawn DISCUSS from Security and Transport and while those from Security have usually given me pause, enlightened me, made me do my homework, those for Transport seem to be saying that you must not give any encouragement to the use of UDP and nothing more than that. I do track TCPM and ICCRG and have some insight into the sophistication of modern control mechanisms, but outside those groups, the application of congestion control seems basic; TCP and its (friendly) derivatives OK, anything else not OK. Tom Petch When I read Lars's messages, I'm not actually sure he and I are disagreeing. There's a lot of things it could mean for the IESG to have congestion control expertise.
Re: Appointment of a Transport Area Director
Hi Dave, On 03/04/2013 11:19 PM, Dave Crocker wrote: On 3/4/2013 1:48 PM, Margaret Wasserman wrote: The problem with this argument is that it appears that we have a choice between limited knowledge of congestion control and an empty seat. Which one is more likely to be able to learn about it? Carefully considering the tradeoffs and requirements seems to be the corre challenge here. To extend this point further: We've defined job requirements that produce an extremely small pool of candidates. In the case of TSV, the pool is zero, but in others it is also problematic. This is a long-standing problem, but we keep ignoring it. Rather than carefully consider the essential job requirements -- in terms of the core work that must be done by an AD -- we seem to think that we can continue with unchanged job requirements. Not fully true: There will be a discussion in the TSVAREA session at the IETF-86 meeting in Orlando, exactly discussing the job requirements for the TSV AD position: https://datatracker.ietf.org/meeting/86/agenda/tsvarea/ Martin ADs do not 'lead' the work of their area. They do not initiate the work, produce the charters or write the specifications. Work that fails or succeeds does so because it has community consensus and demand, not because an AD was diligent or clever. The job of an AD is to facilitate community efforts, not to direct them. Technical expertise in a technical manager is essential as an adjunct to the management. We keep confusing this essential requirement with the kind of work that an individual contributor does. As long as we maintain that confusion, we will define a job that is too demanding, and demands too many of the wrong skills. d/ -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
Re: Appointment of a Transport Area Director
Hi Tom, On 03/05/2013 11:38 AM, t.p. wrote: - Original Message - From: Sam Hartman hartmans-i...@mit.edu To: Mary Barnes mary.ietf.bar...@gmail.com Cc: Sam Hartman hartmans-i...@mit.edu; IETF ietf@ietf.org Sent: Monday, March 04, 2013 8:26 PM Mary == Mary Barnes mary.ietf.bar...@gmail.com writes: Mary And, I continue to support Sam's position as well. To me the Mary question at hand is whether it will do more harm to fill the Mary position with someone that doesn't have the specific expertise Mary that his being sought than to leave the position unfilled. Mary Having dealt with the exact same issue when I was Nomcom Mary chair, I thoroughly understand the issue at hand. And, Mary certainly, there was a lot of criticism of the choice of the Mary Nomcom I chaired, but we really are between a rock and a hard Mary place yet again. I think it would be really useful to get someone like Lars or the chair of the tcpm working group to comment on how much congestion control experience we're talking about as a requirement. Not much, based on my experience:-( The I-Ds I have been closely involved with have typically drawn DISCUSS from Security and Transport and while those from Security have usually given me pause, enlightened me, made me do my homework, those for Transport seem to be saying that you must not give any encouragement to the use of UDP and nothing more than that. I do Can you clarify about what point of time you're talking about? There are multiple instances of the IESG and also the TSV ADs and handling of the issue might have changed over the years. The recent instance is good with using UDP, but the draft needs to clearly state how it addresses congestion control and that is the point where a lot of draft fail. This has been also the case in the past, when I remember right. track TCPM and ICCRG and have some insight into the sophistication of modern control mechanisms, but outside those groups, the application of congestion control seems basic; TCP and its (friendly) derivatives OK, anything else not OK. Also a very shortened view. However, TCP and derivatives are well understood in large-scale deployments, e.g., in the Internet, others are too, e.g., SCTP, while some aren't. Martin Tom Petch When I read Lars's messages, I'm not actually sure he and I are disagreeing. There's a lot of things it could mean for the IESG to have congestion control expertise. -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
Re: Appointment of a Transport Area Director
Brian, On 03/03/2013 03:35 PM, Brian E Carpenter wrote: Lars, Let's try that statement parametrised: *Someone* on the IESG needs to understand X. I think there are many plausible values of X, certainly including congestion control. But what do we do when, for some value of X, there is no such AD? What I'm getting at is that this line of argument doesn't scale. The only solution I see is to replace it by Several people on the Y Directorate need to understand X. That probably does scale. Of course, it implies that ADs consult and trust the relevant Directorate. Even if the directorate is doing all of its reviews there is still plenty of follow-ups to be done by the responsible ADs, e.g., discussing with the draft authors on how to address the comments, check the updated drafts, discuss with the IESG about this, etc. This won't go away, even if the directorate is reviewing each and every draft. Martin Regards Brian On 03/03/2013 12:50, Eggert, Lars wrote: On Mar 3, 2013, at 13:37, Eric Burger ebur...@standardstrack.com wrote: There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed. Since I believe neither is the case, it sounds like the IESG requirements are too tight. I don't believe the requirements are too tight. *Someone* one the IESG needs to understand congestion control. The likely possibility is that many qualified people failed to get sufficient employer support to be able to volunteer. It's at least a 50% time committment. Lars. -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
Re: Appointment of a Transport Area Director
Mary, On 03/03/2013 05:32 PM, Mary Barnes wrote: Lars, Do you not have individuals in the directorate that are experts on congestion control (that aren't document authors) that can review for technical sanity of the proposal? ISTM that some of the TSV nominees We have individuals in the directorate that are experts on congestion control and we will have also knowledge in the IESG after Wes will step down in the next week, i.e., which is me. I am not a full congestion control expert like some individuals out of the directorate and also the community. But I do understand the topic well enough and do know whom to ask in the case of doubt. However, it is always good to have multiple eyes/2 ADs with a congestion control background, as the topic is so sensitive to the proper operation of the Internet and sometimes things slip through for a number or reasons, i.e., for eyes see more than two eyes. have broad technical skills, including management that could be quite useful. Certainly, we have an example where a Nomcom appointed someone with little expertise for a specific area and the result was not good. However, I believe that was far more to do with how the individual approached the role - authoritarian versus understanding that from a technical perspective they should really listen to the experts. IMHO, that's the most important skill that some ADs lack - i.e., listening. I agree and disagree: An AD must be a good manager and be able to listen. But, an AD must have a broad knowledge about the Area's technical topics, as the time to dig into all fields is just too scare once you are an AD. I.e., there is not enough time to arrive as a manager and to learn all the tech topics. Regards, Martin In my experience at not all ADs carefully scrutinize WG items and they tend to rely on the write-up of the shepherd. While the shepherd is most often the WG chair, if they do their job properly, I believe that the problems that an AD might encounter are fewer. I will note that from what I have seen not all shepherds actually review the documents themselves, which is a problem unto itself. There is often quite visible when one does gen-art reviews. ISTM, there is a way for the process to work with an AD that is not the technical expert in specific areas IF others down the chain do their jobs properly. Of course, IETF is really bad at managing down the chain when there are weak links. IMHO, someone with decent project management and people management skills can make a huge difference. Regards, Mary. On Sun, Mar 3, 2013 at 9:55 AM, Eggert, Lars l...@netapp.com wrote: Hi, On Mar 3, 2013, at 15:35, Brian E Carpenter brian.e.carpen...@gmail.com wrote: What I'm getting at is that this line of argument doesn't scale. The only solution I see is to replace it by Several people on the Y Directorate need to understand X. only if the Y directorate reviews all IDs going through the IESG. Which in itself is a scaling issue. It may work for some topics, but things will fall through the cracks for various reasons. IMO congestion control is important and fundamental enough that the IESG itself needs to have the knowledge. YEs, I'm biased. Lars -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
Re: Appointment of a Transport Area Director
- Original Message - From: Martin Stiemerling martin.stiemerl...@neclab.eu To: t.p. daedu...@btconnect.com Cc: Sam Hartman hartmans-i...@mit.edu; IETF ietf@ietf.org Sent: Tuesday, March 05, 2013 11:13 AM Hi Tom, On 03/05/2013 11:38 AM, t.p. wrote: - Original Message - From: Sam Hartman hartmans-i...@mit.edu To: Mary Barnes mary.ietf.bar...@gmail.com Cc: Sam Hartman hartmans-i...@mit.edu; IETF ietf@ietf.org Sent: Monday, March 04, 2013 8:26 PM Mary == Mary Barnes mary.ietf.bar...@gmail.com writes: Mary And, I continue to support Sam's position as well. To me the Mary question at hand is whether it will do more harm to fill the Mary position with someone that doesn't have the specific expertise Mary that his being sought than to leave the position unfilled. Mary Having dealt with the exact same issue when I was Nomcom Mary chair, I thoroughly understand the issue at hand. And, Mary certainly, there was a lot of criticism of the choice of the Mary Nomcom I chaired, but we really are between a rock and a hard Mary place yet again. I think it would be really useful to get someone like Lars or the chair of the tcpm working group to comment on how much congestion control experience we're talking about as a requirement. Not much, based on my experience:-( The I-Ds I have been closely involved with have typically drawn DISCUSS from Security and Transport and while those from Security have usually given me pause, enlightened me, made me do my homework, those for Transport seem to be saying that you must not give any encouragement to the use of UDP and nothing more than that. I do Can you clarify about what point of time you're talking about? There are multiple instances of the IESG and also the TSV ADs and handling of the issue might have changed over the years. The recent instance is good with using UDP, but the draft needs to clearly state how it addresses congestion control and that is the point where a lot of draft fail. This has been also the case in the past, when I remember right. Martin I am looking back over a number of years (eg SNMP, syslog). A perspective over many years, in any area, is that some problems become solved, with changes in technology. What is post graduate research becomes the next generation's seventh grade homework. Congestion control is essential else we have congestive collapse, which I have had to find and fix in my time; but I am positing that for most of the IETF, congestion control is a solved topic and little expertise is needed, in contrast to Security which is for ever changing (SHA2 or SHA3 or will MD5 still suffice?). Yes, a high-level of skill exists, especially in the ICCRG (and I struggle to follow it) but I wonder if we need that skill in the IETF ie a basic familiarity with what TCP offers and UDP does not will serve most of our work. Tom Petch track TCPM and ICCRG and have some insight into the sophistication of modern control mechanisms, but outside those groups, the application of congestion control seems basic; TCP and its (friendly) derivatives OK, anything else not OK. Also a very shortened view. However, TCP and derivatives are well understood in large-scale deployments, e.g., in the Internet, others are too, e.g., SCTP, while some aren't. Martin Tom Petch When I read Lars's messages, I'm not actually sure he and I are disagreeing. There's a lot of things it could mean for the IESG to have congestion control expertise. -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
The problem with the congestion/interference and corruption problem is that error notification does not percolate up the stack. If a MAC driver could say 'this frame is corrupt, failed CRC' and that information percolated up the layers into the flow to the endpoints, TCP or similar might have more to go on. But that information is hard to convey, multiple links may be affected, it gets lost... first hops benefit most. in other words, Explicit Corruption Notification would fail for the same reasons that Explicit Congestion Notification does. And this is presuming that enough of the frame is recoverable to know which higher-layer flow it is associated with reliably, ie some header check passes, but overall frame check fails so there's a discard, and state is around to signal the right flow. And to make the header checks pass with a chance of decoding the headers have to be coded better than the payloads - and this applies at each layer, recursively. um. But there's a paucity of cross-layer signalling, and a paucity of higher layers even sanity-checking their header with checksums. And a paucity of available state to track and associate with flows. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dearlove, Christopher (UK) [chris.dearl...@baesystems.com] Sent: 05 March 2013 11:55 To: m...@sap.com; bra...@isi.edu Cc: ietf@ietf.org Subject: RE: congestion control? - (was Re: Appointment of a Transport Area Director) I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: Appointment of a Transport Area Director
On Mar 5, 2013, at 12:43, t.p. daedu...@btconnect.com wrote: but I am positing that for most of the IETF, congestion control is a solved topic and little expertise is needed I have seen too many WGs trying to build lightweight UDP-based application protocols that do not correctly back off under loss to agree with you here. It's solved IFF a standard transport like TCP is used. Not otherwise. (And even when TCP is used, questions like how many parallel connections remain.) Lars
RE: Appointment of a Transport Area Director
Ah, the 'but security, unlike transport, is actually important' argument. Having seen subscribers to that philosophy unsuccessfully attempt to design transport protocols (and raise the MD5 issue repeatedly, because it's considered a security issue, and they're at home with security), I would argue that there is a lack of appreciation and understanding of the nuances of transport protocol issues in the IETF. Reliability, implications of the end-to-end protocol, feedback loops... Today's crypto hash is tomorrow's probably-not-a-collision error detection, with no claims to security or protection against deliberate attacks. MD5 has made that transition, just because some collisions can be calculated. Better protocols will follow, because collisions will eventually be found. Considering entropy suggests this. Ethernet CRCs have collisions, but they have a useful role in error detection. Checksums are not secure, but that is not what they are used for. And they suffice for that purpose. No-one complains about Ethernet CRCs or one's complement checksums (OMG you can swap entire bvtes in TCP and just swap addresses and the echo server still works!) being insecure. Perhaps they still should. Being adequate for purpose is not enough if they're not secure! I find it difficult to care about the digest function fashion of the day. (For MD5, see RFC6151.) But watching security people make a hash of transport protocol design really isn't fun. That and the lack of transport expertise concerns me. Lloyd Wood http://sat-net.com/L.Wood/dtn Congestion control is essential else we have congestive collapse, which I have had to find and fix in my time; but I am positing that for most of the IETF, congestion control is a solved topic and little expertise is needed, in contrast to Security which is for ever changing (SHA2 or SHA3 or will MD5 still suffice?). Yes, a high-level of skill exists, especially in the ICCRG (and I struggle to follow it) but I wonder if we need that skill in the IETF ie a basic familiarity with what TCP offers and UDP does not will serve most of our work.
RE: Nomcom Reports
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mary Barnes I have a general question for the community as to whether they find such reports useful and whether we should encourage future nomcom chairs to produce these? While this is not listed as a requirement in RFC 3777... [WEG] Yes, and Yes. However, looking at this as an outsider based just on your report and the thread that caused you to send this email, we have a larger fault, in that it appears that no one in I* is taking ownership of the problems identified. We'd be in a bit less of a crisis mode right now if someone had gotten out ahead of this problem, which says to me that we may need an update to 3777 to require both this report *and* a formal response by I* orgs to any issues identified in said report, even if it is just to take this to the community for discussion and suggestions when the problem is identified, rather than after we've already tripped over it. Thanks for sending this out Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Appointment of a Transport Area Director
Hi Russ, On Mar 4, 2013, at 5:05 PM, Russ Housley hous...@vigilsec.com wrote: The problem with this argument is that it appears that we have a choice between limited knowledge of congestion control and an empty seat. Which one is more likely to be able to learn about it? If that were the extent of this discussion, then the answer would be obvious. It is not that simple. I understand. I was responding only to the discussion of the fact that we couldn't find a candidate with expertise in congestion control, so we shouldn't appoint anyone. If we absolutely need someone with that expertise on the IESG, that isn't likely to be resolved by proposals to reorganize the IESG and/or eliminate this position, either. Margaret
RE: Difficulty finding ADs (was: Appointment of a Transport Area Director)
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Benoit Claise Recently, for a single draft, I spent hoouuurrr trying to track all the open issues from the directorates and the IESG, and chasing the authors. [WEG] While I realize that Benoit was originally speaking to the need for subject matter expertise, this comment also says to me that we are not doing a good enough job providing the tools that IESG needs to be as efficient as possible with their time, which when combined with the increased volume of work in IETF is leading to the borderline unsupportable time commitment. I therefore echo the suggestion that IESG should be charged with identifying actionable ways to make their jobs easier. I suggest that they set up a meeting, perhaps a half or full day with the full IESG, but also at least part of the day should be open to any interested former IESG members, plus perhaps secretariat, RSE, and tools team representatives. This group would discuss what improvements to process, workflow and tools are needed to make the IESG job easier by offloading some of the administrative overhead. The end result of that would be an internet-draft to track the suggestions and give the community an opportunity to provide additional suggestions and get some consensus behind it before some or all of the suggestions are put into motion. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. The effects you mention were definitely discussed in PILC. http://www.ietf.org/wg/concluded/pilc.html Maybe the PILC documents need revision? Brian I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions.
Re: Appointment of a Transport Area Director
inline - Original Message - From: l.w...@surrey.ac.uk To: daedu...@btconnect.com; martin.stiemerl...@neclab.eu Cc: hartmans-i...@mit.edu; ietf@ietf.org Sent: Tuesday, March 05, 2013 12:53 PM Ah, the 'but security, unlike transport, is actually important' argument. Having seen subscribers to that philosophy unsuccessfully attempt to design transport protocols (and raise the MD5 issue repeatedly, because it's considered a security issue, and they're at home with security), I would argue that there is a lack of appreciation and understanding of the nuances of transport protocol issues in the IETF. Reliability, implications of the end-to-end protocol, feedback loops... snip But watching security people make a hash of transport protocol design really isn't fun. That and the lack of transport expertise concerns me. tp We are not talking of transport protocol design - SCTP, DCCP, ... - but of Congestion Control design. The question is can we do with a Transport Area Director whose congestion control skills are limited; I am suggesting we can, because of all the work over the years in congestion control and the relative stability of the topic. Transport matters, congestion control matters, I am just suggesting that the latter is not developping so much that we need an AD who is abreast of the research in it. Tom Petch Lloyd Wood http://sat-net.com/L.Wood/dtn Congestion control is essential else we have congestive collapse, which I have had to find and fix in my time; but I am positing that for most of the IETF, congestion control is a solved topic and little expertise is needed, in contrast to Security which is for ever changing (SHA2 or SHA3 or will MD5 still suffice?). Yes, a high-level of skill exists, especially in the ICCRG (and I struggle to follow it) but I wonder if we need that skill in the IETF ie a basic familiarity with what TCP offers and UDP does not will serve most of our work.
Re: Appointment of a Transport Area Director
Hi Tom On 03/05/2013 12:43 PM, t.p. wrote: - Original Message - From: Martin Stiemerling martin.stiemerl...@neclab.eu To: t.p. daedu...@btconnect.com Cc: Sam Hartman hartmans-i...@mit.edu; IETF ietf@ietf.org Sent: Tuesday, March 05, 2013 11:13 AM Hi Tom, On 03/05/2013 11:38 AM, t.p. wrote: - Original Message - From: Sam Hartman hartmans-i...@mit.edu To: Mary Barnes mary.ietf.bar...@gmail.com Cc: Sam Hartman hartmans-i...@mit.edu; IETF ietf@ietf.org Sent: Monday, March 04, 2013 8:26 PM Mary == Mary Barnes mary.ietf.bar...@gmail.com writes: Mary And, I continue to support Sam's position as well. To me the Mary question at hand is whether it will do more harm to fill the Mary position with someone that doesn't have the specific expertise Mary that his being sought than to leave the position unfilled. Mary Having dealt with the exact same issue when I was Nomcom Mary chair, I thoroughly understand the issue at hand. And, Mary certainly, there was a lot of criticism of the choice of the Mary Nomcom I chaired, but we really are between a rock and a hard Mary place yet again. I think it would be really useful to get someone like Lars or the chair of the tcpm working group to comment on how much congestion control experience we're talking about as a requirement. Not much, based on my experience:-( The I-Ds I have been closely involved with have typically drawn DISCUSS from Security and Transport and while those from Security have usually given me pause, enlightened me, made me do my homework, those for Transport seem to be saying that you must not give any encouragement to the use of UDP and nothing more than that. I do Can you clarify about what point of time you're talking about? There are multiple instances of the IESG and also the TSV ADs and handling of the issue might have changed over the years. The recent instance is good with using UDP, but the draft needs to clearly state how it addresses congestion control and that is the point where a lot of draft fail. This has been also the case in the past, when I remember right. Martin I am looking back over a number of years (eg SNMP, syslog). A perspective over many years, in any area, is that some problems become solved, with changes in technology. What is post graduate research becomes the next generation's seventh grade homework. Congestion control is essential else we have congestive collapse, which I have had to find and fix in my time; but I am positing that for most of the IETF, congestion control is a solved topic and little expertise is needed, in contrast to Security which is for ever changing (SHA2 or SHA3 or will MD5 still suffice?). Yes, a high-level of skill exists, especially in the ICCRG (and I struggle to follow it) but I wonder if we need that skill in the IETF ie a basic familiarity with what TCP offers and UDP does not will serve most of our work. I have to disagree here and recommend to take a look to the RMCAT working group. Congestion control isn't completely done and there are always new or changed challenges. Martin Tom Petch track TCPM and ICCRG and have some insight into the sophistication of modern control mechanisms, but outside those groups, the application of congestion control seems basic; TCP and its (friendly) derivatives OK, anything else not OK. Also a very shortened view. However, TCP and derivatives are well understood in large-scale deployments, e.g., in the Internet, others are too, e.g., SCTP, while some aren't. Martin Tom Petch When I read Lars's messages, I'm not actually sure he and I are disagreeing. There's a lot of things it could mean for the IESG to have congestion control expertise. -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 -- martin.stiemerl...@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 8:15 AM, Brian E Carpenter wrote: On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. The effects you mention were definitely discussed in PILC. http://www.ietf.org/wg/concluded/pilc.html Maybe the PILC documents need revision? Brian TRIGTRAN tried to nail this down in more detail after PILC concluded (I co-chaired both PILC and the TRGTRAN BOFs). This quote from the IETF 56 minutes pretty much captured where that ended up: quote Spencer summarized a private conversation with Mark Allman as, Gee, maybe TCP does pretty well often times on its own. You may be able to find cases where you could do better with notifications, but by the time you make sure the response to a notification doesn't have undesirable side effects in other cases, TCP doesn't look so bad /quote If we had to have all the TCP responding-to-loss mechanisms in an implementation anyway, and we could tell a sender to slow down, but not to speed up, it wasn't clear that additional mechanisms would buy you much. References are at http://www.ietf.org/proceedings/55/239.htm and http://www.ietf.org/proceedings/56/251.htm The high order bit on this may have been that TRIGTRAN wasn't IETF-ready and should have gone off to visit IRTF-land, but in the early 2000s, I (at least) had no idea how to make that happen. Spencer I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions.
Fwd: [e2e] Why do we need congestion control?
Begin forwarded message: From: Srinivasan Keshav kes...@uwaterloo.ca Subject: [e2e] Why do we need congestion control? Date: March 5, 2013 15:04:48 GMT+01:00 To: end2end-inter...@postel.org end2end-inter...@postel.org To answer this question, I put together some slides for a presentation at the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we always size a shared resource (such as a link or a router) smaller than the sum of peak demands. This can result in transient or persistent overloads, reducing user-perceived performance. Transient overloads are easily relieved by a buffer, but persistent overload requires reductions of source loads, which is the role of congestion control. Lacking congestion control, or worse, with an inappropriate response to a performance problem (such as by increasing the load), shared network resources are always overloaded leading to delays, losses, and eventually collapse, where every packet that is sent is a retransmission and no source makes progress. A more detailed description can also be found in chapter 1 of my PhD thesis [2]. Incidentally, the distributed optimization approach that Jon mentioned is described beautifully in [3]. hope this helps, keshav [1] Congestion and Congestion Control, Presentation at IRTF ICCRG Workshop, PFLDnet, 2007, Los Angeles (California), USA, February 2007. http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, published as UC Berkeley TR-654, September 1991 http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf [3] Palomar, Daniel P., and Mung Chiang. A tutorial on decomposition methods for network utility maximization. Selected Areas in Communications, IEEE Journal on 24.8 (2006): 1439-1451. http://www.princeton.edu/~chiangm/decomptutorial.pdf
Re: Appointment of a Transport Area Director
On Mar 5, 2013, at 15:10, t.p. daedu...@btconnect.com wrote: The question is can we do with a Transport Area Director whose congestion control skills are limited; I am suggesting we can, because of all the work over the years in congestion control and the relative stability of the topic. Martin already mentioned RMCAT. And I mentioned Wgs wanting to build lightweight UDP-based protocols, which are hitting transport issues incl. congestion control all the time. See these slides (mostly done by Magnus) for some of those issues. We want someone on the IESG who is very familiar with them: http://eggert.org/talks/ietf73-wgchairs-training.pdf Lars
Re: Appointment of a Transport Area Director
Allison: The split between Transport and RAI was needed. Together it is too much work for one Area. The rest of your question ought to be discussed at the TSVAREA meeting in Orlando. Russ On Mar 4, 2013, at 5:44 PM, Allison Mankin wrote: Hi, Russ, Was there something causative about extracting RAI from Transport? Allison On Tue, Mar 5, 2013 at 6:05 AM, Russ Housley hous...@vigilsec.com wrote: Margaret: The problem with this argument is that it appears that we have a choice between limited knowledge of congestion control and an empty seat. Which one is more likely to be able to learn about it? If that were the extent of this discussion, then the answer would be obvious. It is not that simple. This is not the first time we have experienced difficulty in filling the Transport AD seat. Frankly, since RAI was extracted from Transport this has been a recurring concern. At various points over the last three years, there have been discussions about reorganization. That topic has come up on this thread already. So, the community is faced with two choices: (1) fill the seat with someone with limited knowledge of congestion control, but adequate time commitment to do the job; or (2) reorganize the areas in some fashion. Russ
Re: Appointment of a Transport Area Director
Hi, On Mar 4, 2013, at 23:44, Allison Mankin allison.man...@gmail.com wrote: Was there something causative about extracting RAI from Transport? a lot of thought went into making sure that the WGs that went on to form RAI formed a cohesive whole. In hindsight, we should have thought more about how cohesive the set of WGs was that ended up remaining in TSV. After the split, TSV consisted of an assortment of odd WGs without much of a shared identity. Moreover, all the WGs that had any sort of direct relation to product features were moved into RAI. (With the exception of storage, but they are their own little clique.) That severely limited the pool of AD candidates from industry, because it's difficult to construct a business case to one's management. That has been changing over the last year or two, with Google, Apple and others beginning some serious work on extending and enhancing transport protocols in an attempt to improve latencies. Unfortunately, the transport folks at such employers are probably to valuable internally to be able to volunteer. Finally, let's not forget that this year was a special case, because the incumbent was forced to pull out at a very late stage of the process. This left the community very little time to come up with alternatives. I believe that if that had happened earlier, we would have been able to deepen the pool. Lars
More Plugins for Firefox to do draft searches and draft/RFC HTML downloads
Hi.
Thanks to Dale for the new search plugins - useful.
I made these other ones that get RFCs and use the tools.ietf.org HTML
page to find sets of drafts from a few words. They were originally
published on the tools discuss list about 19 months ago.
Download the attachments into the searchplugins sub-directory of the
Firefox installation directory or your local profile
(~/.mozilla/firefox/X.default/searchplugins on Linux) and restart
Firefox. Its easy enough to customize the plugins if you want a specific
WG/RG because you are dealing with it all the time.
I'd like the searches to download the HTML or text etc to taste if the
search finds only one draft, but the 404 error handler doesn't deal with
extra parameters at the mome
Hope these might be useful.
Regards,
Elwyn
SearchPlugin xmlns=http://www.mozilla.org/2006/browser/search/;
ShortNameRFC HTML get (RFC ...)/ShortName
DescriptionIETF RFC Series Archive Search/Description
InputEncodingUTF-8/InputEncoding
Image width=16 height=16data:image/png;base64,iVBORw0KGgoNSUhEUgAAABAQCAMoLQ9TLHRFWHRDcmVhdGlvbiBUaW1lAFRodSAxOSBEZWMgMjAwMiAxNDozOToxOSArMDEwMAbxpfkHdElNRQfSDBULOgQfhKipCXBIWXMAAArwAAAK8AFCrDSYBGdBTUEAALGPC/xhBQAAAwBQTFRFMwAAZgAAmQAAzAAA/wAAADMAMzMAZjMAmTMAzDMA/zMAAGYAM2YAZmYAmWYAzGYA/2YAAJkAM5kAZpkAmZkAzJkA/5kAAMwAM8wAZswAmcwAzMwA/8wAAP8AM/8AZv8Amf8AzP8A//8zMwAzZgAzmQAzzAAz/wAzADMzMzMzZjMzmTMzzDMz/zMzAGYzM2YzZmYzmWYzzGYz/2YzAJkzM5kzZpkzmZkzzJkz/5kzAMwzM8wzZswzmcwzzMwz/8wzAP8zM/8zZv8zmf8zzP8z//8zAABmMwBmZgBmmQBmzABm/wBmADNmMzNmZjNmmTNmzDNm/zNmAGZmM2ZmZmZmmWZmzGZm/2ZmAJlmM5lmZplmmZlmzJlm/5lmAMxmM8xmZsxmmcxmzMxm/8xmAP9mM/9mZv9mmf9mzP9m//9mAACZMwCZZgCZmQCZzACZ/wCZADOZMzOZZjOZmTOZzDOZ/zOZAGaZM2aZZmaZmWaZzGaZ/2aZAJmZM5mZZpmZmZmZzJmZ/5mZAMyZM8yZZsyZmcyZzMyZ/8yZAP+ZM/+ZZv+Zmf+ZzP+Z//+ZAADMMwDMZgDMmQDMzADM/wDMADPMMzPMZjPMmTPMzDPM/zPMAGbMM2bMZmbMmWbMzGbM/2bMAJnMM5nMZpnMmZnMzJnM/5nMAMzMM8zMZszMmczMzMzM/8zMAP/MM//MZv/Mmf/MzP/M///MAAD/MwD/ZgD/mQD/zAD//wD/ADP/MzP/ZjP/mTP/zDP//zP/AGb/M2b/Zmb/mWb/zGb//2b/AJn/M5n/Zpn/mZn/zJn//5n/AMz/M8z/Zsz/mcz/zMz//8z/AP//M///Zv//mf//zP//3jnFswAAAFZJREFUeNptjoENACEIA91/ni7RCbrOQyGPGhGRnLW4dMUCQCkqxGwTxOGaBQFU6U2MwmD32EDL/yfs2zFlqXrs62NHPBRCDWV4RG/grGn2KNBrFDLEB5CVxULY70vUAElFTkSuQmCC/Image
Url type=text/html method=GET template=http://tools.ietf.org/html/{searchTerms};
/Url
SearchFormhttp://tools.ietf.org/id/SearchForm
/SearchPlugin
SearchPlugin xmlns=http://www.mozilla.org/2006/browser/search/;
ShortNameWG Draft (draft-ietf-...)/ShortName
DescriptionIETF Working Group Internet Draft Archive Search/Description
InputEncodingUTF-8/InputEncoding
Image width=16
Re: Orlando time for human language draft discussion
Hi all, I created a Doodle poll to see if we can find a time in Orlando to meet face to face. Doodle poll for time at Orlando to discuss open issues and moving forward with Human Language Negotiation: http://doodle.com/uwedikez6etwsf39 Link to current version (-02) of draft: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- Ignorance is nothing more than indifference to what is before us; we have only to pay attention--and we are paying attention in a way, but to pretty noise, the newer the better. --Wyatt Mason, review of E.E. Cummings biography, Harper's May 2005.
Re: Appointment of a Transport Area Director
On 3/5/2013 8:42 AM, Eggert, Lars wrote: Finally, let's not forget that this year was a special case, I'm going to strongly suggest that that is both wrong and counter-productive to claim. As Mary (and I) noted, TSV has been at a crisis level to fill for some years now, but I believe it is merely the most extreme of a broader problem. Other areas often have very, very thin candidate pools. And none of this is new. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Appointment of a Transport Area Director
On Mar 5, 2013, at 8:25 AM, Margaret Wasserman m...@lilacglade.org wrote: Hi Russ, On Mar 4, 2013, at 5:05 PM, Russ Housley hous...@vigilsec.com wrote: The problem with this argument is that it appears that we have a choice between limited knowledge of congestion control and an empty seat. Which one is more likely to be able to learn about it? If that were the extent of this discussion, then the answer would be obvious. It is not that simple. I understand. I was responding only to the discussion of the fact that we couldn't find a candidate with expertise in congestion control, so we shouldn't appoint anyone. If we absolutely need someone with that expertise on the IESG, that isn't likely to be resolved by proposals to reorganize the IESG and/or eliminate this position, either. I must agree with Margaret here. As with code refactoring, eventually you've refactored away the simpler bits. Usually you are left with a core of something that was too hard to refactor. Even if we agree that the IESG has work that could be redistributed in some fashion, it's arguable this solves the problem at hand. -- Jeff
Re: Appointment of a Transport Area Director
On 3/5/2013 8:18 AM, Eggert, Lars wrote: Martin already mentioned RMCAT. And I mentioned Wgs wanting to build lightweight UDP-based protocols, which are hitting transport issues incl. congestion control all the time. Which is why we learned 30 years ago that building a transport protocol at the application layer is generally a Bad Idea. Why do the same bad ideas keep being reinvented? Bob Braden
Re: Appointment of a Transport Area Director
Original Message - From: Eggert, Lars l...@netapp.com To: t.p. daedu...@btconnect.com Cc: l.w...@surrey.ac.uk; martin.stiemerl...@neclab.eu; ietf@ietf.org Sent: Tuesday, March 05, 2013 4:18 PM On Mar 5, 2013, at 15:10, t.p. daedu...@btconnect.com wrote: The question is can we do with a Transport Area Director whose congestion control skills are limited; I am suggesting we can, because of all the work over the years in congestion control and the relative stability of the topic. Martin already mentioned RMCAT. And I mentioned Wgs wanting to build lightweight UDP-based protocols, which are hitting transport issues incl. congestion control all the time. See these slides (mostly done by Magnus) for some of those issues. We want someone on the IESG who is very familiar with them: http://eggert.org/talks/ietf73-wgchairs-training.pdf tp And the concluding slide of that presentation says Use a Standard Tranport! while earlier it says There are some standard building blocks available AIMD TFRC so I am not persuaded that for Congestion Control, an AD needs need any more than a working knowledge, perhaps of 10 years ago, of what TCP does. (Unlike security, where the 2013 thinking on, say, SHA3 is necessary) Tom Petch Lars
Re: Appointment of a Transport Area Director
On 3/4/2013 2:19 PM, Dave Crocker wrote: ... ADs do not 'lead' the work of their area. They do not initiate the work, produce the charters or write the specifications. Work that fails or succeeds does so because it has community consensus and demand, not because an AD was diligent or clever. The job of an AD is to facilitate community efforts, not to direct them. ADs also comprise the IESG, which reviews RFCs before publication. We should not expect to appoint IESG members that need a tutorial on basic protocol principles. Further, if the TSV AD can't stand up for cong control and other TSV-specific work or TSV-specific concerns raised on other drafts, then who will? Joe
Re: Nomcom Reports
From: Mary Barnes mary.ietf.bar...@gmail.com As far as I can tell, the last official Nomcom report was from the Nomcom I chaired (2009-2010): http://tools.ietf.org/id/draft-barnes-nomcom-report-2009-00.txt I have a general question for the community as to whether they find such reports useful and whether we should encourage future nomcom chairs to produce these? I haven't read this NomCom report, or any others. But I consider them very valuable -- if I ever considered volunteering for NomCom, I'd want to read the last five or more reports to get some background on the job. Dale
Re: Call for Comment: RFC Format Requirements and Future Development
Wouldn't it suffice to say The IETF should not use a document format if it is substantially bulkier than an alternative format that satisfies substantially similar goals. and leave the details to the RFC Editor? Dale
Re: Appointment of a Transport Area Director
Joe, On 3/5/2013 10:28 AM, Joe Touch wrote: On 3/4/2013 2:19 PM, Dave Crocker wrote: ... ADs do not 'lead' the work of their area. They do not initiate the work, produce the charters or write the specifications. Work that fails or succeeds does so because it has community consensus and demand, not because an AD was diligent or clever. The job of an AD is to facilitate community efforts, not to direct them. ADs also comprise the IESG, which reviews RFCs before publication. We should not expect to appoint IESG members that need a tutorial on basic protocol principles. Further, if the TSV AD can't stand up for cong control and other TSV-specific work or TSV-specific concerns raised on other drafts, then who will? If you can explain how your note relates to mine, I'd appreciate it. You appear to be responding to a point that has been raised elsewhere in the discussion (by others), but has nothing at all to do with the points I was making. Best I can guess is that you somehow think that because I didn't mention something I meant that it didn't matter. If so, please re-target your note because that would be a bad reading. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Appointment of a Transport Area Director
On 3/5/13 9:28 AM, Joe Touch wrote: We should not expect to appoint IESG members that need a tutorial on basic protocol principles. I haven't seen anybody propose appointing someone who needs a tutorial on basic protocol principles. The discussion so far has seemed mostly to be whether or not to appoint someone who has something short of specialist-level knowledge. Melinda
Re: Appointment of a Transport Area Director
On 3/5/2013 10:33 AM, Dave Crocker wrote: Joe, On 3/5/2013 10:28 AM, Joe Touch wrote: On 3/4/2013 2:19 PM, Dave Crocker wrote: ... ADs do not 'lead' the work of their area. They do not initiate the work, produce the charters or write the specifications. Work that fails or succeeds does so because it has community consensus and demand, not because an AD was diligent or clever. The job of an AD is to facilitate community efforts, not to direct them. ADs also comprise the IESG, which reviews RFCs before publication. We should not expect to appoint IESG members that need a tutorial on basic protocol principles. Further, if the TSV AD can't stand up for cong control and other TSV-specific work or TSV-specific concerns raised on other drafts, then who will? If you can explain how your note relates to mine, I'd appreciate it. I took your point as suggesting that an AD could get by with less background because they weren't leaders. In the past, ADs have either been people who do lead, or have led in the recent past. If that's not your intent, I still stand by my post as relating to the overall thread, but apologize for any confusion. Joe
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 10:40 AM, Spencer Dawkins wrote: On 3/5/2013 8:15 AM, Brian E Carpenter wrote: On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. The effects you mention were definitely discussed in PILC. http://www.ietf.org/wg/concluded/pilc.html Maybe the PILC documents need revision? Brian TRIGTRAN tried to nail this down in more detail after PILC concluded (I co-chaired both PILC and the TRGTRAN BOFs). This quote from the IETF 56 minutes pretty much captured where that ended up: quote Spencer summarized a private conversation with Mark Allman as, Gee, maybe TCP does pretty well often times on its own. You may be able to find cases where you could do better with notifications, but by the time you make sure the response to a notification doesn't have undesirable side effects in other cases, TCP doesn't look so bad /quote If we had to have all the TCP responding-to-loss mechanisms in an implementation anyway, and we could tell a sender to slow down, but not to speed up, it wasn't clear that additional mechanisms would buy you much. References are at http://www.ietf.org/proceedings/55/239.htm and http://www.ietf.org/proceedings/56/251.htm The high order bit on this may have been that TRIGTRAN wasn't IETF-ready and should have gone off to visit IRTF-land, but in the early 2000s, I (at least) had no idea how to make that happen. Later on, there was also a proposed TERNLI BoF and mailing list, and bar BoF that resulted in: http://tools.ietf.org/id/draft-sarolahti-tsvwg-crosslayer-01.txt But didn't go any farther, that I'm aware of. Section 6 actually puts into context TRIGTRAN and other attempts to do something in this space. There's quite a bit of history just in the IETF. RFC 4907 (IAB's Architectural Implications of Link Indications) is also a good snapshot of the thinking at that time. -- Wes Eddy MTI Systems
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion = backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, TCP penalties that assume delay is loss, ... the end result is that every 3GPP network in the world (guessing) has proxies in place to manipulate TCP so that when you go to speedtest.net your $serviceprovider looks good. Is this good cross-layer optimization, no... but this is how it is. So, fundamentals of CC and TCP have resulted in commercial need for middleboxes in the core of the fastest growing part of the internet. This is sometimes known as tcp optmization or WAN acceleration, both murky terms. The issues in CC result is the re-invention of congestion control at higher layers like http://en.wikipedia.org/wiki/QUIC And, fun things like draft-ietf-rtcweb-data-channel CB -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to fix the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 3:01 PM, Cameron Byrne wrote: In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, TCP penalties that assume delay is loss, ... the end result is that every 3GPP network in the world (guessing) has proxies in place to manipulate TCP so that when you go to speedtest.net your $serviceprovider looks good. Is this good cross-layer optimization, no... but this is how it is. So, fundamentals of CC and TCP have resulted in commercial need for middleboxes in the core of the fastest growing part of the internet. This is sometimes known as tcp optmization or WAN acceleration, both murky terms. There may be some things the IETF can do to improve this. It's not clear yet, but some of the relevant vendors are participating in a non-WG mailing list, focused on one aspect of the situation (TCP option numbers), but recently more ambitious work was suggested: http://www.ietf.org/mail-archive/web/middisc/current/msg00121.html People who are interested in this, should *definitely* self-organize a bit and think about a BoF, in my opinion. -- Wes Eddy MTI Systems
Re: Appointment of a Transport Area Director
On Mar 5, 2013, at 18:58, Bob Braden bra...@isi.edu wrote: Which is why we learned 30 years ago that building a transport protocol at the application layer is generally a Bad Idea. Why do the same bad ideas keep being reinvented? Because we don't have a good selection of transport protocols at the transport layer. I'm chairing one of the WGs with a UDP-based application protocol. TCP's congestion control, even if we could use TCP, wouldn't do much for us. Now here is my point: I need TSV ADs that are strong on the technical side. A weak TSV AD might be -- too cautious, listening to all kinds of Cassandras that haven't bothered to look at the actual protocol, slowing us down unneededly, or -- too bold, allowing us to deploy a protocol that causes a congestion collapse that can only be alleviated by physically chiseling nodes out of walls. Clearly, I want neither of these to happen. (Now, we have received pretty good transport input in 2012, but the IESG will look at this in 2013, and that's where a highly educated decision has to be made.) Grüße, Carsten
Re: Appointment of a Transport Area Director
Russ, On Tue, Mar 05, 2013 at 11:18:20AM -0500, Russ Housley wrote: The split between Transport and RAI was needed. Together it is too much work for one Area. Not everybody believed at the time, and still believes that increasing the size of a committee makes the committee function better. David Kessens ---
Re: Appointment of a Transport Area Director
While the IETF is unique in many ways, the staff-volunteer issue isn't all that unique. Many organizations face this. As one example, organizations like IEEE and ACM struggle with this. (For example, they have, over the years, delegated many functions in conference management that used to be done by volunteers to paid staff.) Even government regulatory bodies operate with a mixture of volunteer labor (advisory councils) and paid staff. The solution space seems rather constrained: (1) Fish in the shallow pool of full-time volunteers who have a large corporate sponsor. Risk that the corporate sponsor wants something in return. (2) Pay the person a salary while on leave from their home institution/employer. As an example, NSF and DARPA do this for their program managers. The employer still takes a hit and there's some risk to the person that they won't get their job back, but it allows a larger number of individuals to participate. (3) Scale back the responsibilities of the individual to make it a 10-20% job. Senior technical or regulatory staff don't read every document line-by-line or, for a conference chair, read every paper, but focus on key issues, by asking questions and relying on more junior staff/volunteers to prepare briefings, for example. Financially, (1) and (2) aren't all that different financially, except that the money flow is more opaque than an explicit tax. I don't think that adding tools helps except at the margins, and only in combination with changing the process. Also, this is not likely to work for just one area. You can't easily have one AD do grammar and spelling corrections on every IANA registration draft, and another just do big-think. Henning On Mar 5, 2013, at 11:46 AM, Dave Crocker d...@dcrocker.net wrote: On 3/5/2013 8:42 AM, Eggert, Lars wrote: Finally, let's not forget that this year was a special case, I'm going to strongly suggest that that is both wrong and counter-productive to claim. As Mary (and I) noted, TSV has been at a crisis level to fill for some years now, but I believe it is merely the most extreme of a broader problem. Other areas often have very, very thin candidate pools. And none of this is new. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
WG Review: Hypertext Transmission Protocol Authentication (httpauth)
A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-03-12. Hypertext Transmission Protocol Authentication (httpauth) Current Status: Proposed Working Group Chairs: TBD Assigned Area Director: Sean Turner turn...@ieca.com Mailing list Address: http-a...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/http-auth Archive: http://www.ietf.org/mail-archive/web/http-auth/ Charter of Working Group: Authentication of users to servers over HTTP has always been a weak point in web services. The current HTTP authentication mechanisms, basic and digest, pass the credentials in the clear or employ weak algorithms and are considered to be insecure today. Authentication through non-standard web forms is much more commonly used, but also pass the credentials in the clear. There is a need for improved mechanisms that can replace or augment HTTP authentication without the need to rely on transport layer security. Only HTTP authentication is in scope for this WG; form-based or web authentication is out of scope. The httpauth WG will be a short-lived working group that will document a small number of HTTP user authentication schemes that might offer security benefits, and that could, following experimentation, be widely adopted as standards-track schemes for HTTP user authentication. Each of these RFCs will be Informational or Experimental, and should include a description of when use of its mechanism is appropriate, via a use-case or other distinguishing characteristics. Standards track solutions for HTTP Authentication schemes are out of scope, as none of the proposals are expected to be sufficiently widely deployed to warrant that status before the WG closes. All schemes to be developed in the httpauth WG must be usable with the existing HTTP authentication framework, or with evolutions of that framework as developed in the httpbis WG. That is, the evolution of the HTTP authentication framework is to be done in the httpbis WG and not in the httpauth WG. The httpauth WG will work closely with the httpbis WG to ensure that the outcomes from the httpauth WG do not conflict with work done elsewhere. The drafts currently under consideration as WG items include: - draft-williams-http-rest-auth - draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension - draft-farrell-httpbis-hoba - draft-montenegro-httpbis-multilegged-auth - draft-melnikov-httpbis-scram-auth The WG will produce two standards track documents that will obsolete the basic and digest schemes defined in RFC 2617 taking into account errata on that specification. For the digest scheme, the new specification will incorporate more modern algorithm agility and internationalization support, which requires input from internationalization experts. draft-ahrens-httpbis-digest-auth-update documents one possible approach that the WG could adopt and modify as it sees fit. For the basic scheme, no technical changes are envisaged other than to handle internationalization of usernames and passwords. The goal is to improve the scheme's documentation and to obsolete RFC 2617, which has some significant flaws that have emerged through 13 years of experience. The WG is not required to merge all proposals into one. The goal is not to produce perfect mechanisms, but to review and improve proposals and to quickly produce stable specifications for the purpose of obtaining implementation and deployment experience. The working group will then close, and any further culling or refinement of the experimental mechanisms will be done in another context. It is expected that the market/community will select which if any of the RFCs developed might be worth progressing on the standards-track at a later date, in a different WG. Adoption of additional work items is not expected and will require a re-charter. The following are explicitly out of scope: - changes to TLS - changes to HTTP, except for those made in the httpbis WG - definition of authentication mechanisms that do not work with the HTTP authentication framework - authentication schemes that distinguish between devices and humans - authentication schemes that cannot be sensibly used for and by humans - web authentication that is not HTTP authentication Milestones: TBD
WG Action: Rechartered Extensible Messaging and Presence Protocol (xmpp)
The Extensible Messaging and Presence Protocol (xmpp) working group in the Real-time Applications and Infrastructure Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Extensible Messaging and Presence Protocol (xmpp) Current Status: Active Working Group Chairs: Joe Hildebrand jhild...@cisco.com Ben Campbell b...@nostrum.com Assigned Area Director: Robert Sparks rjspa...@nostrum.com Mailing list Address: x...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/xmpp Archive: http://www.ietf.org/mail-archive/web/xmpp/ Charter of Working Group: The Extensible Messaging and Presence Protocol (XMPP) is an technology for the near-real-time exchange of messages and presence notifications, where data is exchanged over Extensible Markup Language (XML) streams. The original XMPP working group published RFCs 3920-3923. Implementation and deployment experience since that time has resulted in errata, clarifications, and suggestions for improvement to the core XMPP specifications (RFCs 3920 and 3921). Some technologies on which XMPP depends (e.g., Transport Layer Security and the Simple Authentication and Security Layer) have undergone modifications of their own, which XMPP needs to track. Finally, the group needs to define a sustainable solution to internationalization of XMPP addresses, since the approach taken in RFC 3920 (based on stringprep profiles) is limited to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and draft-saintandre-rfc3921bis-* reflect community input so far regarding these modifications, but the group needs to complete this work, especially with regard to internationalization. Because of the scope of changes involved, it is envisioned that these specifications will be cycled at Proposed Standard. Although RFC 3923 defines an end-to-end signing and encryption technology for use by XMPP systems, to date it has not been implemented. A goal of the group is to develop an implementable method for end-to-end encryption, preferably based on well known and widely deployed security technologies. XMPP uses TLS for encryption and the Simple Authentication and Security Layer (SASL) for authentication. In the case of a server-to-server stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, where each peer presents an X.509 certificate. This model introduces scaling challenges in multi-domain deployments because RFC 3920 requires that a stream cannot be reused for more than one domain, thus necessitating multiple TCP connections. The group will work to overcome these challenges by defining an optional mechanism for using a single connection with multiple identities. It is anticipated that most of the work will consist of defining and providing requirements to the TLS and SASL working groups. In addition to the TCP binding defined in RFC 6120, the XMPP community has long employed an HTTP binding (XEP-0124 and XEP-0206 published by the XMPP Standards Foundation). Given that this binding uses HTTP long polling, which has many known issues (RFC 6202), it is reasonable to transition to use of the WebSocket protocol (RFC 6455) instead. Work has begun on defining a WebSocket subprotocol for XMPP (draft-moffitt-xmpp-over-websocket). The group will complete the definition of such a subprotocol, and coordinate reviews with the HYBI WG where appropriate. In completing its work, the group will strive to retain backwards compatibility with RFCs 3920 and 3921. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Milestones: Done - Decide upon a direction for server-to-server connection reuse. Done - Deliver rfc3920bis and rfc3921bis to the IESG. Done - Decide upon a direction for end-to-end encryption. Mar 2012 - Define a solution for server-to-server connection reuse. Aug 2012 - Define a solution for end-to-end encryption. Sep 2012 - Define a solution for internationalization of XMPP addresses (Update of RFC 6122)
WG Action: Formed JSON data formats for vCard and iCalendar (jcardcal)
A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. JSON data formats for vCard and iCalendar (jcardcal) Current Status: Proposed Working Group Chairs: Peter Saint-Andre stpe...@stpeter.im Bert Greevenbosch bert.greevenbo...@huawei.com Assigned Area Director: Pete Resnick presn...@qti.qualcomm.com Mailing list Address: jcard...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jcardcal Archive: http://www.ietf.org/mail-archive/web/jcardcal/ Charter of Working Group: Problem Statement: The standard iCalendar [RFC5545] and vCard [RFC6350] data formats are in widespread use for calendaring and contacts data exchange. In addition to the text formats described in the base specifications, alternative XML formats have been defined ([RFC6321] and [RFC6351] respectively). Interest has been expressed in also having JSON [RFC4627] formats for both iCalendar and vCard to allow easier integration of such data with web or other Javascript based applications, and other JSON-based protocols being developed by IETF working groups such as jose, scim, and weirds. Because iCalendar and vCard formats have a similar schema (a component/property/parameter/value model) it is often the case that iCalendar and vCard data handling is carried out by libraries with a high degree of code re-use for each format. It is thus highly desirable that the JSON formats for iCalendar and vCard are aligned in terms of their JSON structures so that the policy of code re-use for iCalendar/vCard parsing/generation can continue. Objectives: The jcardcal working group is chartered to develop JSON-based data formats that are accurate, straightforward representations of iCalendar and vCard data, allowing for conversion between any of the various equivalent data formats without any loss of semantic meaning, and maximal interoperability. Consideration will be given to compactness and readability of the JSON data formats, whilst at the same time maintaining the underlying data models of the respective original formats. The JSON formats will re-use the extensibility model of the base formats. The JSON formats will use similar data models in JSON to allow for optimal code re-use when parsing/generating jCard and jCal. Syntactic requirements from other working groups looking to adopt the jCard or jCal data formats will be considered. However, changes to the semantics of vCard and iCalendar are out of scope. Requirements that are not explicitly mentioned in this charter will be considered so long as they do not conflict with the other stated objectives. Specific requirements for consideration are: * a need for conveying unstructured address information (weirds WG). Milestones: Mar 2013 - Determine initial requirements of other Working Groups. Mar 2013 - Accept jCard and jCal documents as Working Group items. May 2013 - Request publication of jCard document. Jun 2013 - Request publication of jCal document.
IETF 86 - Social Tickets
86th IETF Meeting Orlando, FL, USA March 10-15, 2013 Hosts: Comcast and NBCUniversal Meeting venue: Caribe Royale http://www.cariberoyale.com Register online at: http://www.ietf.org/meetings/86/ If you would like to purchase social tickets or additional tickets for the IETF 86 Social at The Wizarding World of Harry Potter™ on Tuesday evening, you can now buy up to 4 tickets! Tickets are limited and will be on a first come, first serve basis. You can purchase social tickets using the link you received in your IETF Registration email from regist...@ietf.org. Once again, tickets are limited. Tickets may not be available on site. If you need help logging in or have questions, please send them to regist...@ietf.org.
WG Action: Conclusion of FEC Framework (fecframe)
The FEC Framework (fecframe) working group in the Transport Area has concluded. The IESG contact persons are Martin Stiemerling and Wesley Eddy. The FECFRAME working group has successfully finished its chartered work and is now closed. The FECFRAME mailing list (fecfr...@ietf.org) will remain open. Thank you to all contributors, draft authors, and the chairs!
