Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
On Nov 1, 2007, at 4:40 PM, Brian E Carpenter wrote: Leslie asked for comments from uninvolved parties and I'm giving my personal opinion that I would not find this work useful. If others do, we should go charter it. I think it will be useful, if it succeeds in rigorously defining metrics for upper layer protocols, given their dependencies on the metrics for lower layer protocols. The context is how to write meaningful service level agreements for application level services, which require well-defined and reproducible metrics. For the services I work on in my day job (e.g. multicast/unicast real- time video streaming) the metrics I am concerned with are either: a) RTP/RTCP transport metrics, for which AVT has done a very good job with and hence PMOL is redundant, or b) session protocol setup metrics (e.g. RTSP), which are mostly useful for debugging as opposed to service measurement c) application-level SLA metrics, which are pretty abstract and not amenable to direct computation (e.g. visible artifacts per hour), or d) encoding/perceptual metrics, such as PSNR, R-factor, etc. which are in generally defined on bodies other than the IETF and which have been the subject of much controversy both in the industry and in the IETF when people have tried to get them blessed. As such, PMOL would be valuable to me if: 1. it succeeded in developing useful algorithms/methods for correlating these metrics to lower level metrics like route convergence time or congestive loss rates, or 2. it succeeded in developing application metrics which are less susceptible to industry controversy, vendor wars, service-provider count everything that moves behavior, and found wide adoption. My personal assessment is: a) the likelihood of PMOL succeeding at either of these is quite low, but I'm willing to be pleasantly surprised, and b) if PMOL starts encroaching on the work in AVT I will be unhappy as I think AVT does a very good job without needing a new venue for developing useful transport level metrics, at least for real time flows In summary, my general level of interest in PMOL is low, but that's a moot point since the WG has been chartered and I wish the group the best of luck! Dave Oran (IAB hat off). Brian ___ PMOL mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/pmol ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the iab net neutrality
On Mar 29, 2006, at 10:56 AM, Henning Schulzrinne wrote: We could ask the IEEE, since the relationship between the WiFi folks and IEEE 802.11 seems to be somewhat similar. One of the problems I see is that many of the industry associations (SIP Forum, IPv6 forum, to name two I'm somewhat familiar with) tend to focus on service providers, not consumers. But an organization such as the SIP Forum could provide a VoIP-optimized label for NAT boxes and maybe even ISPs. I'm a board member of the SIP Forum, so I'd like to respond to Henning. (I'm speaking as an individual here who happens to be on the SIP Forum board so these are personal views neither discussed with nor agreed to by the rest of the board. Ditto for the IAB.) The SIP Forum is a creature of our members, which today are almost exclusively service providers and equipment vendors. We try to respond to the pain points they bring us and add value by bridging the gap between protocol standardization through the IETF and needs in the market. So far, we've been pretty successful at running interoperability testing through the SIPIT program, and coming up with deployment and feature bundling specifications in areas like hooking up SIP-based enterprise VoIP systems to service providers who are offering PSTN origination and termination services. The question of how to help the consumer market segment is one we are stumped on, for a number of reasons. First, there is no obvious advocate for the needs of consumers among our membership. Second, few to none of the vendors who sell consumer gear (e.g. Linksys, Netgear, Sony, Apple) are members. Third, much of that market segment is driven by offshore manufacturers who have little incentive to lead in engineering. Their expertise is in channel and brand management, and in minimizing all costs, including engineering (not to mention forum memberships...). That said, a number of us believe that we are having a modest effect. For example, in the enterprise interconnect specification, we worked very hard to make sure straightforward interconnect worked without mandating extra firewall, NAT or B2BUA functionality. The idea of having the SIP Forum sponsor work to at least partially drain the NAT/firewall traversal swamp is a good one. So - seeing as this is on the IETF public list, let me offer a plea: if you work with or build SIP products for consumers, JOIN THE SIP FORUM and help us put together a program in our Technical Working Group to address these issues. We are driven by our members. Membership is free for individuals and of modest cost for companies. Cheers, Dave Oran Thus, I think we need a separate organization (or work with a separate organization) that does branding and certification. It's hard to buy a non-WiFi device in stores today; the equivalent consumer assurance needs to be true for core consumer and small- business network devices, and possibly services. I don't know how this would work, but if it could be made to work, that might be very helpful. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why?
Snipping out everything not related to one error I'd like to correct. On Mar 14, 2005, at 11:00 PM, Tony Hain wrote: [suresh] VOIP appls go through the same kind of paylod processing in firewalls as do NATs with ALG support for the application. In many implementations, firewall and NAT share the same ALG for protocol monitoring and application processing. This will be interesting when the VoIP apps start encrypting end to end. SRTP is just as opaque to those ALGs as IPsec, so either route will mean a change to traditional firewalls and policies. SRTP only encrypts the media payload, not the RTP headers, so in fact SRTP is one protocol not broken by ALGs. (The above is not to be taken as an endorsement of ALGs, NATs or any other middleboxes which break end-to-end transparency.) Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Hotel online reservations
do not work as advertised. All rooms show booked, despite putting in correct dates and group code as instructed. I called the hotel and had no trouble booking by phone. Just a word to the wise... ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]
On Aug 11, 2004, at 7:58 AM, Pekka Savola wrote: On Tue, 10 Aug 2004, Fleischman, Eric wrote: I am aware of some use of RSVP in labs but I am not aware of any use of RSVP in production networks (i.e., real life networks people connect to the Internet with). Simultaneously, I am encountering I-Ds and other work planning to use RSVP. This possible disconnect concerns me. Therefore, I would appreciate being educated by anybody using RSVP in production settings. Would you please let me know how many devices, what applications, and how successful these deployments (if any) are? Thank you. I'd be interested about this as well, but also in more general. I'd be in favor of deprecating the IP router alert option completely. Effectively this affects RSVP and MLD *). I'd want to similarly do away with the IPv6 Hop-by-Hop options. At the very least, I'd like to prevent further standardization of these options. The justification is simple: any magic packets which all routers on the path must somehow examine and process seems a very dubious concept when we want to avoid DoS attacks etc. on the core equipment which must run on hardware: effectively this means that either these are ignored in any case (nullifying the use of such options), or put on a slow path (causing a potential for DoS). IMHO, it seems just simply bad protocol design to require such behaviour. I'm interested what others think about this.. :) If you can come up with another technique for doing path-coupled signaling which is less susceptible to abuse I'd drop RAO in a heart-beat. There are a bunch of very useful things that require (or at least work a heck of a lot better with) path-coupled signaling: - figuring out where to install QoS state in complex topologies - firewall and NAT traversal - finding the thing furthest away from you (as opposed to closest to you) that performs a certain function, such as state-deaggregation for QoS or tunnel anchor for IPSEC tunnels. It seems to me that the key is to be able to screen packets at wire rate, even if they must be looked at by the control plane of each router. that seems only loosely related to RAO itself. *) MLD should be relatively straight-forward to re-design (just send the MLD reports to a link-local address which the router is listening), or just keep it as is for now. RSVP can probably thrown away without many tears. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: [EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]
I question the usefulness of path-coupled signalling beyond a certain point in the network. Dean Anderson voiced them pretty well in the original thread about RSVP -- it just doesn't seem to make any sense beyond a very closed environment (like the first hop) -- and in that case, you should be able to use another kind of signalling as well. If we don't learn anything of the mistakes we did with RSVP, we're bound to repeat them. First, we have to agree on what the mistakes were :-) For example, has the design clearly restricted itself to the first or the last hop, or within the first couple of hops? No. Here's one counter-argument. Enterprise networks tend to have dumb-bell topologies, where the bottleneck links are in the interior rather than at the edges (exactly the opposite of serivce provider networks). They have meshes of 100meg+ all over each site, but the sites are interconnected with some service (like MPLS VPN, frame relay, etc.) which is expensive and often with very limited bandwidth (sometimes sub-T1). These links are not necessarily all that easy to identify in the topology, because for reliability enterprises configure mulitple routers and backup links. There is strong demand for flow-granularity admission control on such links, and an end-to-end model works better because site-to-site flows can swamp both the uplink at one end and the downlink at the other end. There are other useful examples which I can share if people are interested. For that purpose, I'm not 100% sure if you would need a path-coupled signalling. You'll certainly want path-coupled signalling for signalling with a much wider span (because it's the simplest way to do it from the host's perspective), but I'm arguing (as Dean was) that this isn't an interesting approach from the network operators' perspective. What about discovery of the furthest point. Do you not find that a persuasive use case? ... As for the alternatives: 1) for first-hop only, there's really little need for a router alert, any protocol would do, as you already know who your routers are :-) 2) for hops beyond the first-hop router, I'd consider setting up a single server which would be responsible for brokering the QoS capabilities, firewall holes, etc. You contact the server, and ask it to open a certain kind of hole, set up certain QoS between (source, destination), etc. There are a number of options how you could discover this kind of system: a) a DHCP option b) a DNS lookup (e.g., SRV record based on your DNS search path) c) asking the upstream router using protocol learned in 1). This assume edge tree topologies, which are common but hardly ubiquitous. These kind of approaches essentially move the intelligence and processing to specific nodes who are better capable of handling such requests, having policy who can request what, removing the processing and cruft from the routers. And the hosts have have much easier time figuring out whether requesting these capabilities is supported in the network, instead of spewing a considerable amount of in-band signalling attempts to the network. This is hardly a neutral characterization of the tradeoffs. Cheers, Dave. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: [EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Has anybody heard back from the Hotel in Seoul?
I sent in my reservation request the day after registration opened and I have heard nothing back at all. Have others similarly gotten no response, or is it likely my room request got dropped and I need to retransmit? (Probably better to reply to me rather than the list unless people suspect we have a generic problem). Dave Oran David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Vienna Social event (sorry for bothering such a wide audience)
I tried online registration for the social event via http://files.aon.at/ietf/payment.htm and got this form is no longer valid There were no links on any of the pages to tech support for the social event sponsors. Any ideas? Dave.
RE: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
) and not an RIR responsibility. Leaks are a multifaceted problem. On one hand it might facilitate tracking the source of the leak, but on another it makes it impossible for everyone to know that this specific prefix is supposed to be filtered. While it might be nice to believe that defining a space as non-routable means it won't be routed, reality is that ISPs that want to survive will do what the paying customer says. The only defense against route-for-hire table bloat is the technical infeasibility created by ambiguity. That would leave another topic which I consider separate: whether we ought to create some number of 1918-like addresses that organizations that are really isolated (not connected even with other prefixes) can use without needing to have a negotiation with an RIR. The answer, I think, is probably yes, but it really is a policy question, not a technical one. And, on the above model, an ISP offering service (and prefixes) to an enterprise could be expected to insist that the enterprise not be using any of those isolated addresses in their local environment. It is absolutely unreasonable for an ISP to tell their customer anything about running their network that is not directely related to the customer/provider interface. As long as the enterprise traffic over that interface is related to the capabilities they are paying for, it is none of the ISPs (or IETFs) business what they are doing elsewhere. That said, I do have a draft that globally preallocates space in an unabmiguous way (http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-03.txt). This would allow use without the need to register, and if organizations merged there would be no collision. As a side effect, when those values were leaked into the global routing system, they can be proxy aggregated at least at the transcontinental level. The text is currently focused at the multi-homing problem, but it could easily be reworded. I obviously don't understand all of the issues here well enough. But the traffic of the last few days has left me with the strong impression that SL may be an answer to the wrong question. If so, is the suggestion above closer to the right question? And, unfortunately, since this approach involves a change in the advice the IETF gives the RIRs, it probably does belong on the IETF list and not that of a WG. Eventually if policy needs to change, then yes. At this point though I believe the fundamental issue is really about people coming to grips with the concept that unlike IPv4, - all IPv6 nodes will have multiple addresses per interface. - Once that is understood, the noise about the cost of renumbering goes away because that is simply the act of adding a prefix to the nodes that care to use it. If one chooses to take the old one away at some point, that is fine. But that step is not mandatory, which significantly reduces the costs associated with flash cutovers. This also means that sites that want to filter can use different prefixes for global vs. local access and only those nodes needing global access would configure the global prefix. As you noted earlier, it really doesn't matter what the local use prefix is for this purpose, the only reasons for the ambiguous one is the lack of need to register it (pay and/or expose your business case), the ability to keep those values out of the global routing table, and for applications that care to look, a hint that there is a filter somewhere in the network. Tony ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: [EMAIL PROTECTED]
Re: 802.11b access in Tokyo and Kyoto with IP mobility
I tried it as well, and was getting 80-100% packet loss to just about everywhere beyond the first-hop router. Not usable. --On Saturday, July 13, 2002 7:57 PM +0900 Fred Baker [EMAIL PROTECTED] wrote: For the record, I'm sitting at this instant in Tokyo Station, and am on my way from Narita to Yokohama. I am sitting in the green car, and I accessed the appropriate web page. I have wonderful 802.11 connectivity, and I have an IP address. Whether that means I can use the Internet is another question. On the parts of the track where the connectivity is there, we see ping round trip delays varying from 380 ms to over four seconds. There are fairly large parts of the track where the NTT DoCoMo 3G data connectivity appears to simply not be there - especially when in concrete tubes and ditches, but also on places with open track. So I think here the term seamless, when applied to connectivity, doesn't really apply.
RE: Kudos to MSP IETF hosts other ramblings
The economy was probably at least as big a deterrent as the weather. That's one deterrent I wold rather not have as a permanent feature :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of RJ Atkinson Sent: Thursday, March 22, 2001 6:26 PM To: [EMAIL PROTECTED] Subject: Kudos to MSP IETF hosts other ramblings At 12:52 22/03/01, William Allen Simpson wrote: This is a rare case where I disagree with Phil. This is a good location. Unfortunately, it wasn't cold enough to discourage the usual gaggle of folks that haven't read the charter or the drafts I thought the host folk and hotel did a fine job overall. I encourage IETF visiting cold climates during the local winter and hot steamy climates during local summer. For example, next time we do Oslo or Stockholm, maybe we could do so in winter. I did think that the percentage of attendees who seemed genuinely interested and engaged in technical discussion during WG meetings was much higher than in San Diego. Also, I was able to attend WG meetings that I tried to attend in Minneapolis, whereas I got into zero of the WG meetings I tried to attend in San Diego. Ran - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Maurizio Codogno.
