Re: TCPMUX (RFC 1078) status
On 8/15/2013 4:18 PM, Joe Touch wrote: On 8/10/2013 12:29 PM, Wesley Eddy wrote: On 8/10/2013 1:43 AM, Martin Sustrik wrote: Hi all, Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used? Is it the case that there are inetd daemons in TCPMUX mode running everywhere, or can it be rather considered a dead protocol? Specifically, if I implement a new TCPMUX daemon how likely I am to clash with an existing TCPMUX daemon listening on port 1? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are probably security issues. There are semantics issues to; see draft-touch-tcp-portnames-00 for information (this is being revised for resubmission shortly, FWIW). I totally agree. In fact, in the update to the TCP roadmap [1], we added TCPMUX to the section on Historic and Undeployed Extensions, though it definitely bears further discussion than is currently in the roadmap. I think we should add a reference to your portnames doc to explain why this should be Historic plus check a bit more to see if the code that's out there is really being used or whether it's just hanging out like a vestigal limb in the various inetd packages. If it's fair to ask Martin ... I'm kind of curious why you might want to be using it or think it sounds useful? I think a lot of admins would be concerned that it could be used to get around port-based firewall rules, etc. [1] http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-00 -- Wes Eddy MTI Systems
Re: TCPMUX (RFC 1078) status
On 8/10/2013 1:43 AM, Martin Sustrik wrote: Hi all, Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used? Is it the case that there are inetd daemons in TCPMUX mode running everywhere, or can it be rather considered a dead protocol? Specifically, if I implement a new TCPMUX daemon how likely I am to clash with an existing TCPMUX daemon listening on port 1? It's in the FreeBSD inetd, among others, but to to my knowledge, nobody actually turns it on. There are probably security issues. -- Wes Eddy MTI Systems
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 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 3/4/2013 3:07 AM, Eggert, Lars wrote: There are qualified people in the industry, and that's where most of the past ADs have come from. In the last few years, it's been increasingly harder to get them to step forward, because their employers are reluctant to let them spend the time. I actually think that this is because employers realize that these skills are important and rare to find, and so you want these guys to work on internal things and not donate them to the IETF. When the TSV ADs asked the directorate about this topic, one of the things we heard is that transport features don't strongly associate with product lines or features. So there may also be a case where management doesn't identify with the value in TSV, and maybe companies aren't internally developing people as much for TSV expertise as for other topics. Also, sponsoring an AD does not seem to be generally feasible for small companies or services-based companies (compared to product- based companies) without some outside support, since otherwise the hours spent ADing are overhead. This further limits the pool. -- Wes Eddy MTI Systems
Re: Limitations in RFC Errata mechanism
On 8/30/2011 11:19 AM, Mykyta Yevstifeyev wrote: Hello all, I've observed several problems with submission mechanism for RFC Errata. Here they are: First, we have only two types of errata - Technical or Editorial. In presence of http://www.ietf.org/iesg/statement/rfc-metadata-errata.html, IESG Statement on IESG Processing of RFC Errata concerning RFC Metadata, I think the third type is necessary - Metadata. I agree with this part of the proposal, at least. -- Wes Eddy MTI Systems ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 7/13/2011 1:31 PM, Joel M. Halpern wrote: Replacing a widely used term (on the wire) with term that folks will not understand does not seem to me personally to be a benefit. I think Joe's point is that it's widely used as a concept, but what it means specifically in this document is not clear. A sentence to clarify up-front what the definition is in this document might be enough. In terms of this document, I do not see a problem with the usage as it is. This is not a protocol document. The use of the current term in this context seems helpful rather than harmful. It might be reasonable to add a sentence that says, In this document, 'on the wire' refers to (A) the routing protocol data itself, as well as (B) the way in which routing protocol data is exchanged using underlying protocols, including the headers and other meta-data used by those underlying protocols, or something like that? To me, that's a lot more useful than saying this term is commonly used without defining in what sense(s) you mean it in the present document. I think it's important because the protections possible are potentially a lot different, and if you want people to think about only one or both, it should be made explicit. On a lighter note, I once generated a lot of confusion using this term with people working on satellite networks, who were wondering what wires I could possibly be talking about since all of our links were microwave. I guess if KARP covered MANET protocols we'd have to protect them on the wireless. -- Wes Eddy MTI Systems ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 7/13/2011 2:34 PM, Joel M. Halpern wrote: As I said in my earlier note proposing responses to Joe, we would be happy to some text in the front clarifying the usage. Quoting from my earlier email: This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. Apparently, this does not address Joe's concern. message sent from one routing process to another doesn't seem to be right to me either since it sounds like the first definition that covers routing protocol data only, and not underlying protocols, so I wouldn't expect that proposal to address Joe's concern. -- Wes Eddy MTI Systems ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
