Hi, rereading RFC 3002 walled garden treatment in IETF, it also describes like follows,
"Recognition that the "walled garden" model has some perceived benefits led to recommendations to better integrate it into the Internet architecture. These focused on service location and escape from the "walled garden"." " It was recommended to investigate standard protocols for service and proxy discovery within the "walled garden" domain." "It was recommended to investigate standard methods to transport through the garden wall (e.g., escape to the Internet)." So, it does not recommend targeting this model of walled garden, but it looks recommending to standardize better co-existence method of open model and closed model. The model that the current dhcp route option draft describes seems me to fall into the matter of co-existence. Thanks. 2012/11/5 Brian E Carpenter <brian.e.carpen...@gmail.com> > 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 >
_______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
