On 06/11/2012 01:09, Ted Lemon wrote: > On Nov 5, 2012, at 7:49 PM, Lorenzo Colitti > <lore...@google.com> wrote: >> It's not just a clean-up. Points 2, 3, and 4 in the email >> (especially 4) are issues that need to be dealt with in in >> order for this requirement to be valid at all. The IAB >> guidance on walled gardens is quite substantive to many of >> the use cases for this draft, and is therefore a serious >> concern. > > It's an interesting point, but what we're talking about here > is dedicated routing for streaming services like VoIP and > video, not a walled garden in the old sk00l AOL/Compuserve > sense. You could get to the service over the best-effort > routing as well, but you will do better getting to that > service over the custom route. This is an application which > seems to be quite popular among various ISPs—the Wifi > Alliance is working on it, I know of at least one customer of > my own employer who wants to do something like this, and > apparently BBF considers it useful. > > Is this what the IAB meant when they said that we shouldn't > support walled gardens? This is a serious question—it is > not my impression that this is what they meant, but I > honestly don't know.
Speaking as a participant at the IAB workshop that led to RFC 3002 (and with no authority beyond that of a participant): Firstly, please read section 3.1 of that RFC. Perhaps the key quote is this: 'The term "walled garden" was coined to describe the resulting captive customer economic and service model. That is, the user is constrained within the limits of the service provided by the carrier with limited ability to extend features or access services outside the provider.' and a bit later: 'Some discussion focused on whether cellular carriers could be persuaded to transition toward the Internet "open" service model. Responses indicated that there was little hope of this as carriers will always fight being reduced to a "bit pipe", fearing they cannot sustain sufficient revenues without the value added services.' It's also worth reading section 4.2 'Recommendations for Dealing with "Walled Garden" Model.' This is written constructively on the assumption that there will be walled gardens, so the IETF should live with it despite not liking it. The dislike is very explicit: 'It was strongly recommended that independent of the ubiquity of the "walled garden" deployment scenario that protocols and architectural decisions should not target this model.' I think it's a bit of a stretch to say that draft-ietf-mif-dhcpv6-route-option explicitly targets this model; it's actually a generic mechanism, even if some of the use cases do fit the walled garden model. > Of course, that opens up the question of why not use existing > QoS mechanisms, and I honestly don't know the answer to > that—I'm not an expert on existing solutions to that problem. > I suspect the goal is to avoid expensive, specialized > switching gear near the provider edge, but that's just a > guess. The main existing QoS mechanism is known as "throw bandwidth at the problem", and providing a dedicated route on a path known to have adequate bandwidth is exactly that. But there are people considering other approaches including diffserv or the flow label. There is yet another approach about which draft-sun-semantic-usecase and draft-jiang-semantic-prefix will enlighten you. Brian _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
